So stand es an einem Freitag auf Mastodon geschrieben. Nach einem Schmunzeln fragte ich mich: „Ja warum eigentlich nicht?“ Dieser Frage möchte ich heute nachgehen.
Der englischsprachige Satz aus dem Titel ist eine Aufforderung, an einem Freitag keine Änderungen an produktiven Systemen vorzunehmen, um das Wochenende nicht zu gefährden. Viele von euch kennen vermutlich berühmte letzte Worte wie:
- Was soll schon schiefgehen?
- Nur noch diese kleine Änderung, dann ist Feierabend.
- Das wurde getestet, da kann nichts passieren.
- Das geht ganz schnell, ich mache das noch eben.
Nicht selten hat sich der Feierabend oder das Wochenende nach diesen Sätzen erheblich verzögert oder sind ganz ausgefallen, weil eben doch etwas schiefgegangen ist. In der Folge waren wichtige Dienste nicht mehr verfügbar und Systemadministratoren haben das Abendessen mit ihrer Familie versäumt, weil sie den Klump wieder zum Laufen bringen mussten. Solche Erlebnisse führen zu Aussagen wie:
- Never change a running system. Oder eben
- Don’t push to production on Friday
Die Logik dahinter ist bestechend einfach. Wenn etwas funktioniert und man nichts daran ändert, wird wohl auch nichts kaputt gehen. Allerdings stehen diese Aussagen dem DevOps-Mantra von Continuous Integration and Continuous Delivery (CI/CD) entgegen, welches fordert, dass Änderungen zu jeder Zeit möglich sein müssen.
Und wer hat nun recht? Ich denke, die Wahrheit liegt wie so oft irgendwo in der Mitte.
Ob Änderungen durchgeführt werden können, hängt in meinen Augen nicht vom Wochentag ab, sondern vielmehr von den Antworten auf die folgenden Fragen:
- Sind alle für die Abnahmetests erforderlichen Key-User nach der Änderungen verfügbar und können direkt im Anschluss testen?
- Sind alle Verantwortlichen anwesend bzw. verfügbar, welche entscheiden, ob die Änderung bzw. das Deployment erfolgreich war oder nicht?
- Liegt das Wartungsfenster in einem Zeitraum, in dem ggf. externe Supportdienstleister erreichbar und diese Zeiträume durch Service-Level-Agreements (SLA) abgedeckt sind?
- Findet die Änderung in einem Zeitfenster statt, in dem Störungen toleriert werden können?
Sind zum Beispiel alle 37 Key-User, 8 Abteilungsleiterinnen und das 20-köpfige Betriebs-Team für die Personal- und Buchhaltungsanwendung Freitag nach 18:00 bis voraussichtlich 21:00 Uhr alle verfügbar und können im Fehlerfall mit offenem Ende verfügbar bleiben, steht einer Änderung bzw. einem Deployment nichts im Wege. Ist dies jedoch nicht der Fall und man stellt Fehler möglicherweise erst im Laufe des kommenden Montags fest, wo ein Rollback evtl. schon nicht mehr möglich ist, sollte man den Change vielleicht lieber Montagmorgen starten?
In einem anderen Fall ist das Team nicht sicher, ob sie das System im Fehlerfall ohne Hilfe des Herstellers wiederherstellen können. Der Support-Vertrag deckt jedoch nur die Zeiten Mo-Fr von jeweils 08:00-17:00 Uhr mit 4 Stunden Reaktionszeit ab. Hier ist es vielleicht ebenfalls besser, das Wartungsfenster in den frühen Morgen als in den Freitagabend zu legen.
Habe ich hingegen einen 24/7-Supportvertrag und meine IT-Betriebsabteilung darf auch am Wochenende arbeiten, bietet sich ein Change mit langer Dauer am Wochenende an, um die Betriebsabläufe möglichst wenig zu beeinträchtigen.
Sind Änderungen nur von kurzer Dauer und man möchte möglichst viele User verfügbar haben, die sofort testen und mögliche Fehler finden, ist vermutlich auch Dienstag Vormittag 10:00 Uhr eine gute Zeit.
Es hängt also nicht primär vom Wochentag, sondern vielmehr von einigen anderen Faktoren ab, wann Änderungen in Produktion ausgerollt werden sollten.
Wie seht ihr das? Nach welchen Kriterien werden bei euch Deployments geplant und durchgeführt?
PS: Ich finde jedoch absolut nichts Verwerfliches daran, wenn man sich den Freitag für die Pflege und Aktualisierung der Dokumentation reservieren kann und nicht mit aller Gewalt noch etwas kaputtfuckeln muss. ;-)
Meiner Meinung nach ist das ziemlich veraltet.
Ich habe in Umgebungen gearbeitet, wo bewusst am Freitag neue Anwendungen verteilt wurden, um das Wochenende Zeit zu haben, eventuelle Fehler zu reparieren, aber das schreibst Du ja auch selber.
In der Regel kann man bei Firmen auch Projektsupport einkaufen.
Wenn ich neue Software Montagmorgen verteile, riskiere ich, dass die Mitarbeiter zu Bürozeiten nicht arbeiten können.
Prinzipiell – wenn es mit Unterbrüchen verbunden ist – sollten solche Produktionseinführungen zu Zeit gemacht werden, in denen die Auswirkungen minimal sind und das kann auch mitten in der Nacht sein. Ich hatte bei einem Kunden schon einmal ein regelmässiges Wartungsfenster in der Nacht von Sonntag auf Montag, 02:00-03:00 Uhr.
Das Einspielen von Änderungen ohne Unterbruch sollte jederzeit möglich sein.
Hi,
wie heute Mittag schon kurz im Chat (#my-it-brain:matrix.org) geschrieben, kann man den Text auch wie folgt zusammenfassen: „Wann man Änderungen und Wartungsfenster plant, hängt von vielen Faktoren ab, jedoch nicht primär vom Wochentag.“
Ich stimme dir zu, dass Änderungen ohne Serviceunterbrechung jederzeit möglich sein sollten. Unter der Bedingung, dass Erfolgskriterien definiert sind und überprüft werden können.
Wenn man über Erfolgskriterien verfügt und in der Organisation das Wissen vorhanden ist, wie man diese prüft, kann man einen Schritt weitergehen und die Abnahmetests automatisieren. Dies führt dazu, dass nach einer Änderung weniger Personal (Key-User) verfügbar sein muss und man an Flexibilität dazugewinnt.
In Umgebungen mit sehr hohem Automatisierungsgrad wird für diese Schritte in der Regel deutlich weniger Personal benötigt. Hier findet bei Abnahmetests mit negativem Ergebnis häufig sogar der Rollback automatisch statt. Im Gegensatz dazu gibt es aber auch Umgebungen, wo Abnahmetests von Menschen anhand von Testbüchern manuell durchgeführt werden und wo Tätigkeiten außerhalb eines Arbeitszeitkorridors mit einer Vorlaufzeit von mehreren Wochen schriftlich (auf Papier) anzuordnen sind.
:-)