Wieviel ist DevOps wert?

Meiner Erfahrung nach, fokussiert sich die Geschäftsleitung selten auf das IT-Team, es sei denn eine Katastrophe oder Ausfall passieren – dann wird man plötzlich so lange beachtet, bis alles wieder normal läuft. Es ist recht einfach die grundlegende Arbeit, die IT-Teams fast jeden Tag leisten, damit alles glatt läuft, zu ignorieren. In diesem Post bespreche ich die Quantifizierung des Wertes von DevOps im Unternehmen. DevOps ist einfach zu erklären: Entwickler arbeiten mit dem Operations Team zusammen, um Prozesse effizienter, automatisiert und wiederholbar erledigen zu können. Wenn dieser Prozess funktioniert, dann sieht der Zyklus folgendermaßen aus:

DevOps

DevOps bestehen aus Tools, Prozessen und den kulturellen Veränderungen, die im gesamten Unternehmen anfallen wenn beide integriert werden. In großen Firmen wird dies meiner Erfahrung nach vom Management getrieben und in kleineren Firmen kommt dies normalerweise von der IT Ebene.

Meine IT Karriere fing als ein NOC-Techniker in einem Rechenzentrum an. Ich verbrachte den Großteil meiner Zeit damit Kunden zu helfen ihre Server zu installieren oder zu aktualisieren. Wenn einer der von uns verwalteten Server versagte, war es meine Aufgabe, diesen so schnell wie möglich zu reparieren. Ich war außerdem dafür verantwortlich Firmen beim Management ihre Applikationen zu helfen. Zu dieser Zeit waren die meisten Webapplikationen eher schlicht, mit nur zwei Servern – einem Datenbankenserver und einem Applikationsserver:

monolithic_app

Als nächsten Karriereschritt, bin ich dann zur technischen Seite übergewechselt und habe angefangen umfangreiche Webapplikationen zu entwickeln. Die Applikationen, an denen ich arbeitete, waren sehr viel komplizierter als die, an die ich noch aus meinen Rechenzentrumstagen gewohnt war. Nicht nur der Aufbau und Code waren komplexer geworden, sondern die Verwaltungsdaten und Overheads, die notwendig waren um solch eine große Infrastruktur zu managen, verlangten eine neue Einstellung meinerseits und bessere Tools.

distributed_app

Als ich dann Applikationen baute und einsetzte, mussten wir unsere Server von Grund auf neu aufbauen. Im Zeitalter der Cloud kann man sich das Problem in das man Zeit investiert um es zu lösen aussuchen. Wenn man sich für eine Infrastruktur-as-a-Service entscheidet, dann ist man nicht nur für die Applikation und Daten verantwortlich, sondern ebenfalls die Technologie und auch das Operationssystem.  Wenn man sich für eine Plattform-as-a-Service entscheidet, muss man nur die Applikation und die Daten unterstützen. Die traditionelle On-Premise Option trägt trotz der größeren Freiheiten ebenfalls die Verantwortung über Hardware, Netzwerk und Leistung. Man sollte sich seine Entscheidung also gut überlegen:

Screen Shot 2014-03-12 at 11.50.15 AM

Als ein Applikationsmanager in einem großen Team findet man schnell heraus, wie gut ein Team zusammenarbeitet. In den Tagen vor DevOps sah es typischerweise wie folgt aus, wenn es ein Problem zu lösen gab:

Screen Shot 2014-03-12 at 11.49.50 AM

1) Support erstellt ein Ticket und weist eine relative Priorität zu

2) Operations fängt mit der Untersuchung an und schiebt das Problem auf die Entwickler

3) Die Entwickler sagen, dass dies unmöglich ist, denn alles funktioniert in der Entwicklung, und verweisen das Ticket wieder an Operations

4) Das Operations-Team eskaliert das Problem und puscht es so lange zur Geschäftsführung, bis das Operations-Team und die Entwickler zusammenarbeiten, um die Grundursache feststellen zu können

5) Beide Seiten behaupten, dass das Problem nicht so schlimm ist, wie es dargestellt wird und setzen die Priorität neu

6) Die Geschäftsführung hört von dem Ticket und setzt es wieder auf Prioritätenstufe 1

7) Das Operations-Team und die Entwickler finden die Grundursache zusammen heraus und beheben das Problem

8) Support schließt das Ticket

Wir haben oftmals eine Menge Zeit damit verschwendet Support-Tickets zu untersuchen, welche eigentlich keine wirklichen Probleme darstellten. Wir mussten diese nachprüfen, weil wir uns nicht auf die Leistungs-Checks und Überwachungs-Tools, die überprüfen sollten, ob diese Probleme gültig waren, verlassen konnten. Entweder konnten wir die Tickets nicht reproduzieren oder die Probleme lagen bei einer dritten Partei. Egal wo das Problem lag, wir mussten die notwendige Zeit investieren, um dies herauszufinden. Wir haben nie ausgerechnet, wie viel Geld diese Fehlalarme die Firma in Arbeitsstunden gekostet haben.

Screen Shot 2014-03-12 at 11.50.35 AM

Mit besseren Applikation-Monitoring Tools konnten wir dann die Anzahl der Fehlalarme und die verschwendeten Unkosten drastisch reduzieren.

Wie viel Rendite hat das Unternehmen verloren?

noidea

Ich habe  es kein einziges Mal geschafft genau auszudrücken wie viel Geld unser Team mit der Integration von Tools und verbesserten Prozessen gespart hat. Im Zeitalter von DevOps gibt es mittlerweile eine Menge Tools.

In dem man die Infrastruktur mit Tools wie Chef, Puppet und Ansible automatisiert, kann man sie wie einen Code behandeln, sie automatisieren, versionsgerecht und testbar einstellen und am allerwichtigsten, wiederholbar machen. Wenn das nächste mal ein Server zusammenbricht, dauert es nur Sekunden, um eine identische Instanz zu erstellen. Wie viel Zeit haben Sie Ihrem Unternehmen mit einer konsequenten Methodik zum Konfigurationswechsel gespart?

Mit dem Einsatz von Deployment Tools wie Jenkins, Fabric und Capistrano kann man zuversichtlich und konsistent Applikationen in seinen Umgebungen einsetzen. Wie viel Zeit haben Sie Ihrer Firma mit dem Einsatz dieser Tools gespart?

Durch den Einsatz von Log-Automatisation Tools wie Logstash, Splunk, SumoLogic und Loggly kann man die Logs für jeden Service erfassen und indexieren. Wie viel Zeit haben Sie Ihrer Firma dadurch erspart, ein problematisches Gerät nicht mehr manuell suchen zu müssen sondern die zugehörigen Logs mit einem Klick aufzurufen?

Mit dem Einsatz von Application-Management Tools wie AppDynamics kann man ganz einfach Einsicht in die Codelevel der Produktionsprobleme bekommen und versteht genau, welche Noden die Probleme verursachen. Wie viel Zeit haben Sie Ihrer Firma gespart, indem Sie APM eingesetzt haben um Probleme sofort ausfindig zu machen?

Durch den Einsatz von Run-Book-Automatisation Tools wie AppDynamics kann man allgemeine Applikationsprobleme automatisch finden und in der Cloud skalieren. Wie viel Zeit können Sie Ihrem Unternehmen sparen, indem Sie automatisch allgemeine Applikationsprobleme reparieren, ohne auch nur einen Knopf zu drücken?

Es ist einfach den Wert dieser Tools und Prozesse für Ihr Unternehmen zu verstehen:

devops_tasks

DevOps = Automation & Kollaboration = Zeit = Geld

 

Wenn Sie DevOps in Ihrem Unternehmen einsetzen wollen, ist der beste Tip, den ich Ihnen geben kann, dass Sie alles automatisieren und trotzdem immer auf einen Notfall vorbereitet sind. Eine Umfrage von RebelLabs/ZeroTurnaround zeigt:

1) DevOps-Teams verbringen mehr Zeit damit, Dinge zu verbessern anstatt sie zu reparieren

2) DevOps-Teams erholen sich schneller von Niederlagen

3) DevOps-Teams veröffentlichen Apps mehr als zweimal so schnell

Wie viel kostet Sie ein Ausfall?

Dieser Post wurde von einer technischer Diskussion, die ich geleitet habe, inspiriert: https://speakerdeck.com/-dustinwhittle/devops-pay-raise-devnexus

Nehmen sie sich fünf Minuten Zeit und bekommen Sie noch heute umfassende Einsicht in die Performance Ihrer Produktionsanwendungen mit AppDynamics.

Dieser Artikel wurde aus dem Englischen übersetzt. Den originalen Text finden Sie hier: http://blog.appdynamics.com/devops/quantifying-the-value-of-devops/