GitHub veröffentlicht Schadensbericht, um Ausfall zu erklären

Am 28. Januar 2016 war GitHub ab 1:23 Uhr mitteleuropäischer Zeit für über zwei Stunden nicht erreichbar. Damit dürften deutsche Nutzer des Codeverwaltungsdiensts zwar nicht unbedingt in Mitleidenschaft gezogen worden sein, das Thema war in den sozialen Netzen trotzdem noch einige Zeit präsent. Um Aufklärungsarbeit zu leisten und aufzuzeigen, welche Maßnahmen das Unternehmen aus dem Ausfall ableitet, hat GitHub-Mitarbeiter Scott Sanders nun einen Blogeintrag mit einem Schadensbericht veröffentlicht.

Demnach gab es im primären Datenzentrum des Unternehmens eine Störung der Stromversorgung, die dafür sorgte, dass etwa ein Viertel der Server und Netzwerkgeräte neu starten mussten. In der Folge fehlte den nicht betroffenen Frontend-Anwendungsservern das System zur Anfragenverarbeitung, was zur Auslieferung der Fehlermeldungen führte. Nachdem das Team eine DDoS-Attacke ausschließen konnte, stellte es fest, dass Teile der Netzwerkausstattung Probleme beim Booten hatten und sich daher Teile des Redis-Cluster nicht erreichen ließen.

In der Folge konnten einige der Anwendungsprozesse nicht wie gewohnt starten, sodass ein Teil der Entwickler das Cluster auf Alternativhardware neu aufbauen musste, während sich der andere der Wiederherstellung widmete. Ersteres gestaltete sich wohl komplizierter als gedacht, da einige der entscheidenden Komponenten auf der nicht erreichbaren Hardware hinterlegt waren. So vergingen vom Ausfall bis zur erneuten Erreichbarkeit zwei Stunden und sechs Minuten. Sanders bedauert, dass GitHub auf seiner Statusseite wegen Problemen mit dem ChatOps-System erst acht Minuten nach dem Zusammenbruch entsprechend informieren konnte. Da man um die Wichtigkeit des Diensts wisse, wolle sich das Team bemühen, hier in Zukunft schneller zu sein.

Nachlese und Änderungen

GitHub werde auch in Zukunft nicht hundertprozentig in der Lage sein, Infrastrukturausfälle zu verhindern, allerdings habe das Unternehmen aus der Störung gelernt. So wolle man künftig unter anderem stärker ein Auge auf neue Firmware-Updates haben, da das Hardwareproblem wohl bekannt war und es ein entsprechendes Update gab. Darüber hinaus will das Team die Anwendungs-Testsuite aktualisieren, um sicherzustellen, dass Prozesse auch dann starten können, wenn bestimmte externe Systeme nicht erreichbar sind. Dieser Schritt ergibt sich aus der Erkenntnis, dass die Anwendungsprozesse hätten starten können, wenn nicht im Bootpfad des Anwendungscodes eine Abhängigkeit zum Riak-Cluster enthalten gewesen wäre.

Weitere Maßnahmen umfassen eine Prüfung der Erreichbarkeitsanforderungen des internen Systems, das etwa zum Provisionieren neuer Dienste nötig ist, sowie eine Verbesserung der Kommunikation zwischen Teams und gegenüber den Nutzern. Weitere Informationen zum Ausfall lassen sich dem Originalbericht entnehmen. (jul)