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

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

Einige der Anwendungsprozesse konnten dann nicht mehr wie gewohnt starten, sodass das Cluster von einem Teil der Entwickler auf Alternativhardware neu aufgebaut werden musste, während sich der andere Teil um die Wiederherstellung kümmerte. Da einige der entscheidenden Komponenten auf der nicht erreichbaren Hardware hinterlegt waren, gestaltete sich ersteres wohl komplizierter als gedacht. Vom Ausfall bis zur erneuten Erreichbarkeit vergingen so zwei Stunden und sechs Minuten.

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

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

(mt, hannover)

(siehe auch heise-News-Ticker:)

Hannover · EDV-Beratung · Linux · Novell · Microsoft · Seminar · IT-Consult · Netzwerk · LPIC · CLE