Black Swans in IT-Systemen und Ausfälle 2020

Präventionsmaßnahmen

Auch wenn Black-Swans nach Definition unvorhersehbare Ereignisse sind, kann mit bestimmten Prozessen oder Maßnahmen gegen solche Ausfälle vorgegangen werden. Die beschriebenen Muster können dabei helfen präventiv entgegenzuwirken, da je nach Ursache und Muster eines Ausfalls ähnliche Möglichkeiten zur Vermeidung existieren.

Betrachtet man die Muster der Ausfälle in 2020 führt in drei der vier Fälle das Erreichen einer Kapazität (Hitting Limit) zum Ausfall. Hier kann eine Überschreitung durch umfangreiches Monitoring sowie ein Monitoring-Alert, also ein Alarm beim Erreichen bestimmter Kapazitäten, vor der Beeinträchtigung des Systems festgestellt werden. Dies hätte sowohl beim AWS Thread Limit, als auch bei Azures VM-Pool zu einer vorzeitigen Erkennung des Problems geführt und den Ausfall durch dann getroffene Maßnahmen verhindert. Auch bei Slack hätte funktionierendes Monitoring, wie bereits beschrieben, den Ausfall des Systems verhindert, da der Bug dadurch frühzeitiger erkannt worden wäre. Zusätzlich helfen Last- und Kapazitätstests die bis dahin unbekannte Limits eines Systems überhaupt erst zu erkennen. Als weitere Maßnahme kann durch ausgeprägte und einheitliche Dokumentationen vermieden werden, dass Limits ignoriert werden. So bleibt das Wissen über Limits auch bei Veränderungen der Systemverantwortlichkeiten bestehen und kann dann beachtet werden.

Um Ausfälle aufgrund von Spreading Slowness zu vermeiden, ist wiederum “Failing-Fast” der Teilsysteme das Stichwort, um Ausfälle des gesamten Systems zu verhindern. Wenn Systeme mit einer riesigen Warteschlange von Anfragen vorliegen und die Puffer voll sind, ist das gefährlich für das gesamte System. Die dadurch entstehenden, blockierten Systeme sind nur schwer zu entwirren, um wieder einen betriebsfähigen Zustand herzustellen. Dies zeigte sich auch am Beispiel Azure, welches durch Failing Fast des Dienstes ab dem Zeitpunkt der Kapazitätsgrenze die gesamte Verlangsamung des Systems verhindern hätten können. Nur die VM-Anfragen nach Erreichen der Kapazität wären demnach fehlerhaft gewesen. Außerdem sind Deadlines für Anfragen sowohl bei Zugriffen auf das System, als auch für die Kommunikation zwischen Microservices eine Möglichkeit, Spreading Slowness präventiv zu vermeiden.

Um Thundering Herds entgegenzuwirken, ist gezielt und beabsichtigt eingesetzter Jitter als “Tool” denkbar, der zeitgleiche Anfragen einer Ressource entzerrt. Zudem sollten Thundering-Herds durch Chaos-Testing ermittelt und dabei beobachtet werden, wie das System auf eine unrealistisch wirkende Anzahl an Anfragen reagiert. Hier hätte im beschriebenen Ausfall Azures die Möglichkeit bestanden, die Auswirkungen einer großen VM Nachfrage zu ermitteln, um die nachträglich umgesetzten Anpassungen bereits präventiv zu implementieren. Thundering-Herds können, wie bereits beschrieben, jeden im Internet zur Verfügung gestellten Dienst betreffen und müssen dementsprechend regelmäßig getestet und durch geeignete Maßnahmen in ihrer Auswirkung verringert werden.

Gegen die in allen ULS-Systemen verwendeten Automatisierungstechniken zu kontrollieren, sollten diese Automatisierungen durch Beschränkungen kontrollierbar und im Falle eines Fehlers auch abschaltbar sein (siehe auch Control Automation AWS [18]). Nur wenn automatisierte, komplexe Systeme durch Menschen steuerbar sind, können Black-Swans durch Automation Interactions vermieden werden. Dies nutzte Google, um den beschriebenen Ausfall schnell festzustellen und innerhalb kurzer Zeit zu beheben. Auch bei Slack hätte es geholfen das AutoScaling kurzfristig manuell zu übernehmen, ehe der Bug (durch funktionierendes Monitoring) und die Ursachen der veralteten HAProxy-Slots gefunden werden konnte.

Weitere Maßnahmen, um gegen Muster der Black-Swan vorzugehen werden in Laura Nolans USENIX-Konferenzbeitrag [2] beschrieben. Dabei werden auch Präventionsmaßnahmen für Cyberattacks und Dependency Problems näher beschrieben, die in den genannten Ausfällen 2020 nicht als Muster auftauchen,

Fazit

Die beschriebenen Ausfälle des vergangenen Jahres zeigen, dass die von Laura Nolan definierten Muster durchaus auch in aktuellen Ausfällen auftauchen und dadurch auch Muster der Prävention aufzeigen. Vor allem gegen Limits, die in drei der vier Ausfällen mit ausschlaggebend waren, sollte dementsprechend durch Monitoring und Kapazitätstest vorgegangen werden. Zudem fällt auf, dass Muster in Kombinationen auftreten bzw. Muster wie zum Beispiel das Erreichen eines Limits, wiederum andere Muster (z.B. Spreading Slowness oder Thundering Herds) auslösen, die dann zum Ausfall eines Systems führen.

Es wird zusätzlich deutlich, dass Änderungen innerhalb des Systems eine häufige Ursache der Ausfälle darstellt. Dies bestätigt sowohl Googles Incidents-Analyse von Sue Lueder [18], als auch drei der vier beschrieben Ausfälle 2020. Führte die Änderung der Datenbank am Vormittag bei Slack zum erhöhten Traffic und war dadurch zwar nicht ausschlaggebend aber mitverantwortlich für den Ausfall, waren bei AWS und Google Änderungen des Systems Hauptursachen der Ausfälle. Bei AWS die Erhöhung der Front-Fleet Kapazität, bei Google der Umzug des User-ID-Services auf ein neues Quota-System. Um solchen Ausfällen entgegenzuwirken, sollten Änderungen immer auf kleinen Prozentsätzen (z.B: 5%) eines Produktivsystems durchgeführt und nicht direkt auf ein gesamtes System ausgerollt werden. Dann ist ein genaues Beobachten dieses Teilbereichs möglich und kann genau auf Fehler analysiert und ggf. durch “Fast Roll Back” rückgängig gemacht werden. Dieser “Smal Subset First” Ansatz wird von Laura Nolan auch als “Canarying” beschrieben. “Schwarzen Schwänen” also mit “Kanarienvögeln” zu begegnen, stellt hier einen vielversprechenden Ansatz dar.

Denn auch wenn Black-Swans nach Definition nicht vorhersehbar sind, gibt es die beschriebenen Möglichkeiten um diese durch geeignete Architekturen und Prozesse innerhalb eines Systems zu vermeiden oder zumindest Auswirkungen zu reduzieren. Trotzdem wird auch das Jahr 2021 Ausfälle und ggf. auch weitere Black-Swans in IT Systemen hervorbringen und es bleibt spannend, welche weiteren Muster herausgefiltert werden können. Denkbare Erweiterungen der sechs beschriebenen Muster wären beispielsweise Missverständnisse innerhalb der Systemadministration oder Cache-Probleme, die durchaus auch zu Ausfällen großer, verteilter Systeme führen können.