Das Scheitern von DevOps ist für manche ein heikles Thema, da DevOps typischerweise als eine Möglichkeit wahrgenommen wird, vermeiden Fehler. Wenn Sie bei einer DevOps-Praxis scheitern, kann die Situation daher fast hoffnungslos erscheinen. Doch genau wie ein Fail-Fast-Geschäftsansatz oder die Agile-Methode „scheitern und früher anpassen“ beweist oft, dass DevOps-Fehler tatsächlich ein Schritt in die richtige Richtung sind. Sie sind der erste Schritt, um aus Fehlern zu lernen und Ihre DevOps-Praxis in eine zu verwandeln, die Sie eher früher als später zu noch größerem Erfolg führt.

DevOps hat seine Wurzeln in Agile, wo kürzere Entwicklungszyklen mit häufigen Feedbackschleifen Sie über einen bestimmten Zeitraum hinweg schnell zu einer Produktlieferung führen, die besser auf die Kundenbedürfnisse abgestimmt ist. Der Sinn der Feedbackschleife besteht darin, durch Kundenfeedback aus Ihren Aktionen zu lernen und dann zu messen, was richtig gelaufen ist und was verbessert werden kann.

Die Feedbackschleifen sind effektiv, weil häufige Änderungen und Fehler Gelegenheiten zum Lernen bieten, die das Risiko tatsächlich verringern. Es gibt viele Arten von Fehlern, die bei einer DevOps-Praxis auftreten können, und Ihre Reaktion darauf ist wichtig. Lassen Sie uns jetzt einige davon untersuchen.

Fehler bei der Reaktion auf Vorfälle

Wenn Softwareprobleme auftreten – ob sie nun mit der Bereitstellung zusammenhängen oder Fehler sind – ist Ihre Reaktion darauf oft wichtiger als die Tatsache, dass sie überhaupt aufgetreten sind. Fehler können in diesem Fall in mehreren Formen auftreten, darunter:

• Überreaktion: Zu viel Zeit oder zu viele Ressourcen für die Behebung von Fehlern oder für den Versuch, Wiederholungsfehler zu vermeiden, aufwenden
• Falsche Reaktion: Fehldiagnose eines Problems oder Annahme eines falschen Problems, möglicherweise aufgrund fehlender Informationen
• Ausbleibende Reaktion: Das Problem wird nicht schnell genug oder nicht effektiv genug behoben, und das Problem tritt bald darauf erneut auf.

Vorfallmanagement und die Bewertung des Erfolgs anhand von KPIs sind wichtige Bestandteile der Messung, die für den Erfolg von DevOps entscheidend sind. Bewerten und lösen Sie Vorfälle schnell, indem Sie relevante Informationen ans Licht bringen, andere Teammitglieder zur Hilfe heranziehen und das System als Ganzes betrachten, anstatt auf einzelne Komponenten (und die Menschen dahinter) als Ursache hinzuweisen.

Die Erkenntnisse hier umfassen einen ganzheitlichen Ansatz für Reaktion auf Vorfälle , Verbreitung von Wissen, Lernen aus Fehlern und vergangenen Vorfällen, um zukünftige Probleme zu vermeiden, und Automatisierung von Antworten, um Probleme schneller zu lösen.

Zu viele Prozesse erstellen

Manche denken, DevOps sei einfach ein Prozess oder ein Tool, und richten starre, formale Verfahrensabläufe ein, denen man folgen muss. Aber zu viel Formalität, zu strenge Prozesse und die Vorgabe bestimmter Toolsets können die Flexibilität Ihres Unternehmens bei Änderungen einschränken. Stattdessen sollte DevOps Folgendes beinhalten: Werkzeuge und Verfahren, die die Flexibilität Ihres Unternehmens steigern.

Tools, die Ihre allgemeine Effizienz bei der Softwareentwicklung und -bereitstellung messen, helfen Ihnen beispielsweise dabei, Feedback zur Verbesserung dieser Effizienz zu erhalten. Wie? Indem sie aufzeigen, wo Änderungen vorgenommen werden müssen und die Engpässe, die beseitigt werden müssen . Wenn die Strukturen zu starr sind, kann sich Ihr Unternehmen möglicherweise nicht schnell genug verändern, um sich zu verbessern oder die Anforderungen einer sich verändernden Benutzerbasis oder eines sich verändernden Marktes zu erfüllen.

Begrenzung des Umfangs von DevOps

Die Arbeit einer DevOps-Praxis fällt nicht einer einzelnen Person oder einem Team innerhalb Ihrer Organisation zu. Ich habe Situationen erlebt, in denen Personen speziell als „DevOps-Person“ eingestellt wurden, die auf magische Weise „DevOps-Sachen“ erledigen würden, um alle bestehenden Probleme bei der Bereitstellung und Wartung der Software zu beheben. Aber hier ist die Kurzfassung: Dieser Ansatz Wille scheitern.

Ebenso habe ich Situationen erlebt, in denen Kundenservice und Support Mitarbeiter haben Anrufe von Kunden erhalten, die sich auf eine neue Funktion berufen, die am Wochenende installiert wurde und von der sie nichts wussten. Wenn wichtige Supportmitarbeiter von Ihren Kunden von Änderungen an Ihrer Software erfahren, liegt ein DevOps-Fehler vor.

DevOps ist eine organisatorische Praxis, die das übernimmt, was gelernt von Agile Entwicklung und Anwendung durchgängig während der gesamten Softwarebereitstellung. Diese Vorgehensweise sollte auf andere Funktionen im gesamten Unternehmen ausgeweitet werden. Das bedeutet, dass die Entwicklungsarbeit auf den Kundennutzen und nicht auf Projekte ausgerichtet ist und dass Produktteams nicht nur mit IT-Mitarbeitern zusammenarbeiten, sondern auch mit den Leuten, die Anrufe entgegennehmen, die technische Dokumentation schreiben, die Anwendung bewerben und vermarkten und als Geschäftssponsoren fungieren – einschließlich der Führungskräfte, die für die Zukunft planen. Wenn Feedbackschleifen auf alle Mitarbeiter der Organisation ausgeweitet werden, kann jeder etwas lernen.

Hieraus ergibt sich die Notwendigkeit, Feedbackschleifen, Kommunikation und wichtige Messaktivitäten auf alle Teile Ihres Unternehmens auszuweiten. Ignorieren Sie außerdem nicht Drittanbieter, Lieferanten oder Komponenten. Denken Sie daran, auch Validierung, Auditierung und Überwachung für externe Komponenten einzubeziehen.

Schuldzuweisungen und Konkurrenzkampf

Da Agile häufig Engpässe in der Softwarebereitstellungspipeline eines Unternehmens aufdeckt, ist es leicht, mit dem Finger auf Personen oder Aktivitäten zu zeigen, die die Dinge verlangsamen. In diesem Fall kann DevOps einen noch größeren Keil zwischen die Teams treiben – und das genaue Gegenteil von dem, was beabsichtigt war.

Stattdessen, die Silos entfernen (Teams oder Personen, die dazu neigen, im Vakuum zu arbeiten) und reißen Sie die Mauern zwischen den Teams nieder, bevor Sie Engpässe und Verbesserungen identifizieren. Wenn alle zunächst zusammenarbeiten und gemeinsame Verantwortlichkeiten haben, werden Verbesserungen als einheitliches Team und nicht als Ergebnis von Konkurrenz zwischen ihnen erzielt.

Ein oder zwei Silos unterhalten

Es ist nicht ungewöhnlich, dass Organisationen – selbst solche, die mit Agile und DevOps tatsächlich Erfolg hatten – Ausnahmen innerhalb des Unternehmens machen, wenn es um die Praxis geht. Vielleicht handelt es sich um eine Legacy-Anwendung, ein bewährtes Team oder sogar einen erfahrenen Mitarbeiter. Der Ausschluss einer einzelnen Person oder eines Teams von der DevOps-Praxis kann jedoch problematisch sein.

Silos können sich vermehren und für die Softwarebereitstellungspraxis eines Unternehmens schädlich sein. Selbst wenn sich in dem Silo ein Mitbegründer des Unternehmens befindet, sollte niemand von den Prozessen und der Zusammenarbeit ausgeschlossen sein, die die DevOps-Praxis Ihres Unternehmens fördert. Kurz gesagt: DevOps bedeutet, Silos und Engpässe zu beseitigen. Ohne Ausnahmen.

Ignorieren der Entwicklungsumgebung

DevOps gilt für mehr als die Produktionsumfeld und Bereitstellungen. Selbst wenn Agile-Entwicklungssprints erfolgreich sind, Produktionsbereitstellungen automatisiert sind und Tests kontinuierlich durchgeführt werden, schafft es seine eigenen Probleme, wenn diese Praktiken nicht auf die Entwicklungsumgebung ausgedehnt werden. Wenn beispielsweise Entwicklungs- und Testumgebungen nicht mit denselben Tools, Ansätzen und Personen verwaltet werden, die Ihre Produktionsumgebung verwalten, riskieren Sie Produktionsprobleme, wenn Ihre Software zum ersten Mal auf potenziell einzigartige Konfigurationen trifft, was oft zu unerwarteten Fehlern führt.

Wissen Sie, wie die Entwicklungsarbeit durchgeführt wird, wo sie durchgeführt wird und wo sie in der Produktion enden wird. Wenn einer dieser drei Punkte zum Zeitpunkt der Entwicklung unbekannt ist, wird das Risiko eines Fehlers zum Zeitpunkt der Veröffentlichung nahezu sicher steigen. Es ist absolut entscheidend, Ihre Entwicklungsabläufe und -umgebungen auf die gleiche Weise zu orchestrieren und zu steuern, wie sie wahrscheinlich in der Produktion existieren werden.

Zu viel Teamzugriff

Die verbesserte Teamarbeit, die sich aus DevOps ergibt, ist eine gute Sache, ebenso wie die wachsenden Fähigkeiten der Teammitglieder, wenn sie mit neueren Verfahren oder Komponenten Ihrer Software vertraut gemacht werden. Wenn man jedoch die damit verbundene zusätzliche Verantwortung außer Acht lässt, kann dies zu kritischen Fehlern führen. Während es beispielsweise im Allgemeinen gut ist, dass DevOps einem UI-Entwickler dabei hilft, sich mit der Datenbank einer Anwendung vertraut zu machen – und diesen UI-Entwickler sogar in die Lage versetzt, DB-Änderungen selbst vorzunehmen – ist es nicht gut, wenn versehentlich Änderungen an einer Produktionsdatenbank vorgenommen werden. Während Engpässe beseitigt werden, müssen auch Kontrollen vorhanden sein, um Katastrophen zu vermeiden.

Die Erkenntnisse hieraus bestehen darin, unerwartete Zugriffe auf kritische Produktionssysteme zu überwachen und zu melden und Verfahren einzurichten, um schädliche Änderungen, ob unbeabsichtigt oder nicht, rückgängig zu machen (oder sogar wieder rückgängig zu machen).

Fazit: Es geht um Menschen

Das Ziel ist nicht erfolgreiches DevOps an und für sich – es ist weder ein Prozess noch eine Aktivität. Vielmehr besteht das Ziel darin, die Grundsätze von DevOps zu nutzen, um Ihre Software, das Kundenerlebnis und Ihre Organisation zu verbessern. Tatsächlich kann sich das Leben als schwierig erweisen, wenn einer dieser Grundsätze fehlt, selbst wenn Sie glauben, dass Sie bei DevOps erfolgreich sind.

Es ist wichtig, sich daran zu erinnern, dass all diese Zutaten echte Menschen beinhalten. Unabhängig davon, wie DevOps Ihnen hilft, dorthin zu gelangen, aus Fehlern zu lernen, eine Kultur der ständigen Verbesserung zu etablieren, Kunden glücklich machen und dabei Spaß zu haben, ist das, was wirklich zählt. Denken Sie bei der täglichen Arbeit an Ihren Zielen immer daran, was wirklich zählt.