Sonntag 19.Mai 2024 | 10:34 Uhr

| online: 163 Gäste 

  Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting]  Mittwoch, 17 Mai 2017 | Blog: 7 | No: 38520    

Patching is hard?

OK, das wird mir jetzt hier gerade zu krass. Besonders niederschmetternd war ein Leserbrief zu Alternativlos 39 aus einem Elektronik-KMU vom Lande, der da die Apokalypse grafisch beschrieben hat, und dann am Schluss meinte, ich solle das bitte nicht ins Blog tun, das könne man rückverfolgen. Nachdem er als Sahnehäubchen erwähnte, dass die Firma ja jetzt IOT-Geräte bauen will.
Daher jetzt auch mal was Konstruktives. Eine Einsendung von Kris Köhntopp, wie man Rollout und Testing richtig macht.

Victim Blaming: »Patching is hard? Yes—and every major tech player, no matter how sophisticated they are, has had catastrophic failures when they tried to change something. Google once bricked Chromebooks with an update. A Facebook configuration change took the site offline for 2.5 hours. Microsoft ruined network configuration and partially bricked some computers; even their newest patch isn't trouble-free. An iOS update from Apple bricked some iPad Pros. Even Amazon knocked AWS off the air.«
Wo ich arbeite haben wir dieselbe Beobachtung gemacht. Wir haben ein Outage Budget, d.h. wir messen die tatsächlichen Einnahmen und vergleichen mit den vorhergesagten Einnahmen. Ist durch einen mißglückten Rollout ein Einnahmeausfall zu verzeichnen, buchen wir das vom Outage Budget ab.
Wir versuchen das so gut als möglich zu treffen. Wenn wir mehr Outage als geplant haben, ist das zu viel Risk Taking, wenn wir zu wenig Outage hatten, ist das nicht genug Risk Taking und wir sind zu langsam und complacent.
Häufige Rollouts sind kleine Changes und die sind viel besser zu kontrollieren als große unübersichtliche Changes. Daher versuchen wir, so oft als möglich einen Rollout (== Patch) zu machen und so die Patches möglichst klein zu halten.
Wenn wir Rollout-Probleme haben, dann meist in den Subsystemen, die wir nicht oft genug ausrollen und in denen dann sekundäre Changes (== Library Changes, die mit sich schneller ändernden Systemen geteilt werden) den Rollout zerknallen. Die Lösung ist für uns, so was auch dann auszurollen wenn sich im Code selbst nix geändert hat (also Dependency-Änderungen auszurollen).
Alles in allem ist das eine sehr anschauliche Darstellung von Technical Debt: Je größer der Diff zwischen ausgerollt und trunk ist, um zu wahrscheinlicher ist es, daß Trunk in Production explodiert.
Um Patching sicher zu machen, muß man es oft tun.
Wenn man oft patchen möchte, müssen Patches und deren Rollouts ein Operativer Prozeß und kein Upgrade-Migrationsprojekt sein.
Wenn Rollouts ein operative Prozeß sein sollen, dann muß man Testen in der Produktion sicher und überlebbar machen.
Um Testen in der Produktion sicher zu machen, muß man:

• das Austeilen von Code und die Aktivierung von Code trennen, also Feature Flags und Experiments einführen,
• sich ändernde persistente Datenstrukturen doppelt führen (alte und neue Version gleichzeitig und parallel aktualisieren, sodaß alter und neuer Code coexistieren können).
• Reporting und Monitoring exzessiv ausbauen und den Monitoring Lag (Event Timestamp vs. Timestamp in dem das Event im Monitoring auf dem Operator Screen sichtbar wird) mitloggen und Anzeigen ("Monitoring Framerate einblenden")
• und den Leuten klar machen, daß es wichtig ist, eine Fehlerkultur zu etablieren ("blameless postmortem" einführen und durchsetzen).
• Canaries
• Overcapacity
• nur 2 Versionen aktiv zur Zeit (also nicht drei- oder mehrphasige Rollouts laufen haben)

Alles kein Hexenwerk eigentlich.

Ein Canary ist ein Kanarienvogel im Kohleminen-Sinn. Man schiebt die neue Version nicht gleich auf das ganze Rechenzentrum, sondern erstmal nur auf ein paar Kisten, und da routet man nur ein paar User hin. Und guckt, ob es platzt. Das ist an sich eine gute Praxis, aber man muss aufpassen, dass man das nur kurzzeitig macht. Ich habe schon Firmen gesehen, die praktisch permanent diverse Versionen parallel ausgerollt hatten. Das ist nicht gut.
Overcapacity heißt einfach, dass man nicht am Limit fährt mit seiner Hardware, damit man eine Performance-Regression zur Not mal kurzzeitig abfangen kann.
Stört euch bitte nicht an dem Denglisch, das ist in der Ops-Abteilung von internationalen Firmen durchaus normal :-)

Twiter-Ticker