DevOps Teil 4: Blame Game

Bewerten Sie diesen Beitrag!

In der Regel treffen Devs und Ops unter Zeitdruck aufeinander, zum Beispiel beim Deployment eines neuen Releases oder wenn es ein Problem (wie einen Systemausfall) gibt. Es beginnt dann das typische Blame Game, bei dem beide Lager sich gegenseitig die Schuld an der Situation geben. Ein paar Beispiele:

  • Die Entwicklung gibt ein neues Release zum Deployment an den Betrieb weiter, dem es aber einfach nicht gelingt, die Software auf der Produktivumgebung lauffähig zu machen. Als der Betrieb die Entwickler kontaktiert und die auftretenden Fehler beschreibt, blocken diese jedoch ab: Die Software würde auf der Entwicklungsumgebung fehlerfrei laufen und deshalb wäre klar, dass der Fehler beim Betrieb läge. In der Folge beschuldigen sich beide Seiten gegenseitig, schuld an dem Problem zu sein. Es kommt zu Krisensitzungen und vielen bösen Telefonaten bzw. E-Mails zwischen den Abteilungen und an die Vorgesetzten. Eine Untersuchung ergibt schließlich, dass sich Entwicklungs- und Produktivumgebung in einem wichtigen Detail unterscheiden (z. B. die Verwendung einer Komponente im Clustering-Modus), was aber keiner der beiden Seiten vorher bewusst war.
  • Der Benutzeransturm auf die neue Webseite ist so groß, dass die Antwortzeiten schon bald immer größer werden und einige Stunden später die Seite komplett zusammenbricht. Aus Geschäftssicht ist das eine Katastrophe. Aber das erste, was die beteiligten Lager (Entwicklung, Betrieb und gegebenenfalls weitere Abteilungen für Datenbankadministration, Qualitätssicherung etc.) machen, ist heftig über die vermeintliche Ursache zu spekulieren: „Das muss ganz klar ein Datenbankproblem sein!“ oder „Das sind bestimmt die neuen Server schuld!“ Erst viel später wird eine objektive Analyse gestartet, zu diesem Zeitpunkt haben die Kunden aber bereits akzeptiert, dass die neue Webseite ein Desaster ist.
  • Im Produktivsystem taucht ein ärgerliches Performanceproblem auf. Unter großem Druck arbeiten die Entwickler mehrere Nächte durch und liefern schließlich einen Patch. Der Betrieb jedoch hat Bedenken, dass der Patch die Stabilität des Systems gefährdet, weil er Änderungen an einer kritischen Komponente umfasst. Deshalb wird zunächst eine genaue Qualitätskontrolle auf einer Testumgebung verlangt, um die Lösung in realistischen Testszenarien zu überprüfen. Leider lässt sich die benötigte Last in der Testumgebung aber nicht adäquat darstellen. Viel Zeit vergeht, und einen Monat später ist der Patch immer noch nicht eingespielt. Die Entwickler sind enttäuscht, weil „es ja offenbar doch nicht so eilig war“.

Wer solche Situationen noch nicht erlebt hat, kann sich glücklich schätzen. Wer das Blame Game hingegen kennt, der weiß, dass man die dadurch verlorene Zeit besser zur Lösung des Problems hätte verwenden sollen. Schuldzuweisungen und das Sich-darüber-ärgern sind im Nachhinein immer noch möglich.

Dies ist ein Teil des Artikels „Die DevOps-Bewegung – Was ist das eigentlich und was bedeutet es für uns?“ von Dr. Patrick Peschlow.

Die Einleitung zum Artikel finden Sie hier. Das vorige Kapitel erreichen Sie hier, und hier geht es weiter zum nächsten Kapitel.

Stichworte:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close