Agiler Systemadministrator und Entwickler - Wie geht das? [geschlossen]

Agile Systemadministration und Devops sind heutzutage einige der aktuellsten Themen in Bezug auf Systemadministration und -betrieb. Beide Konzepte konzentrieren sich hauptsächlich auf die Überbrückung der Lücke zwischen Operations / Sysadmins und den Projekten (Entwickler, Unternehmen usw.). Auch wenn Sie noch nie von dem Devops-Konzept gehört haben, ich bin sicher, dass dieses Thema auch Ihr Anliegen ist.

Also, welche Tools und Techniken verwenden Sie, um Entwickler in Ihrem Unternehmen zu erreichen? Ich interessiere mich besonders für Themen wie Change Management, kontinuierliche Integration und Automatisierung, aber nicht nur für diese Themen. Bitte teilen Sie Ihre Gedanken. Ich freue mich auf eure Antworten / Meinungen :)

• svn / git - natürlich die revisionskontrolle.

• trac / redmine / jira - ticketing.

• cobbler - für die Server-Bereitstellung des Basisbetriebssystems. Cobbler ist ein auf RedHat-Familien fokussiertes Produkt, aber ich bin sicher, dass es für Debian / Ubuntu etwas Ähnliches gibt. In ähnlicher Weise werden die meisten "Cloud Control Panel" -Unternehmen wie RightScale dies für Sie bereitstellen. Das Motto lautet hier "JEOS" oder "gerade genug Betriebssystem". Meine Route besteht darin, die Zeile "% packages --nobase" in meinen Kickstarts zu verwenden und dann über ...

• puppet / chef - für das Konfigurationsmanagement und die Durchsetzung der Konsistenz. Es gibt auch hier andere Optionen, es ist wichtiger, dass Sie eine verwenden, als welche. Ein Trick, den ich als besonders wichtig empfunden habe, ist das Speichern der Konfigurationen in demselben Versionskontrollsystem, das die Entwickler verwenden. Dies hilft, den Workflow der beiden Teams zusammenzuführen und für einander sichtbar zu machen.

• func (oder capistrano oder cluster-ssh) - zum Ausführen des Bereitstellungsskripts im gesamten Cluster. Der Trick dabei ist, es zu etwas zu machen, das die Senior-Entwickler selbst ausführen können, um sowohl neue Dinge live voranzutreiben als auch die unvermeidlichen Korrekturen voranzutreiben.
  Dies ist der eigentliche Kern von Devops, der es den Entwicklern ermöglicht, die Umgebung zu beschädigen und zu reparieren. Viele Sysadmins sind zu machtgierig, um so etwas loszulassen, oder ihr Management arbeitet immer noch an der falschen Vorstellung, dass Sysadmins Entwickler überwachen sollten (als ob wir sogar die Hälfte dessen lesen könnten, was sie tun).

• kakteen / ganglien / collectd / munin - grafiken sind soooooo schlüssel. Es ist der Geschäftswert von Metriken mit dem menschlichen Wert einfacher visueller Elemente. Das Korrelieren des Zeitstempels von Code-Pushs mit dem Zeitstempel von Änderungen in den Diagrammen ist immens hilfreich, um Leistungsregressionen zu beheben und reale Fakten über Leistungsentscheidungen zu erkennen. Ein wesentlicher Punkt hierbei ist, dass die Diagramme von den Entwicklern leicht zu sehen und zu verwenden sein müssen und dass ihre Verwaltung dies von ihnen erwarten muss.

• nagios / zabbix / smokeping / etc - Überwachung von Serverkram und Leistungsmetriken vom Typ "Basisseite". Auch hier sind die Grafiken von zentraler Bedeutung. Diese sind eher für die Einsatzkräfte des Teams.

• gomez / keynote / browsermob - Externe Überwachung der vollständigen Browserleistung unter Berücksichtigung von Drittanbieter-Diensten, CDNs und Renderzeitproblemen. Diese sind eher für die Entwicklerseite des Teams.

Das ist eine Mischung aus Werkzeugen und Techniken. Konzentrieren Sie sich auf die Techniken. Insbesondere ändert sich die Einstellung der "Sysadmin" -Seite von "admin" zu "operations". Es geht darum, die Entwickler zu aktivieren. Ermöglichen, dass sie Dinge tun können, dass sie Dinge reparieren können, dass sie reale Fakten / Metriken / Diagramme darüber sehen können, was sie getan haben. Umgekehrt müssen sich die Entwickler bewusst sein, dass sie aktiviert wurden und tatsächlich Leistungstrends beobachten, Probleme beheben und nicht nur über Features nachdenken, sondern auch darüber, wie sie eingeführt werden und wie sie sich auf den Zustand des gesamten Systems / der Umgebung auswirken .

Genau daran arbeiten wir bei National Instruments. Weitere Informationen zu unseren Aktivitäten finden Sie unter http://dev2ops.org/blog/2010/4/27/qa-ernest-mueller-on-bringing-agile-to-operations.html

Der Werkzeugmix, den Cagenut hier erwähnt, geht im Grunde genommen in die Richtung, in die wir uns hier bewegen.

Der beste Ansatz besteht darin, die Umgebung zu verstehen, in der Sie arbeiten. Sprechen Sie zunächst mit den Entwicklern und Managern. Versuchen Sie, sie an Bord zu bringen und Ideen von ihnen abzuleiten. Höchstwahrscheinlich haben sie eine gute Vorstellung davon, wie die Dinge laufen und ob Ihre Ideen zur Einführung von Entwicklern Probleme verursachen.

Schauen Sie sich von dort aus die Anwendungen an und stellen Sie sie einzeln vor, um Probleme zu lösen.

Während die Tools und Techniken wichtig sind, besteht der kritische Pfad in der Zusammenarbeit im gesamten Unternehmen. In diesen Tagen IT Operations ist Business Operations. Etsy zeigt Änderungen der Einnahmen in ihren Dashboards an, die für alle sichtbar sind.