Manchmal fällt das Frühstück aus
An einem Donnerstagmorgen kurz nach 7 Uhr startete sich einer unserer Hosts aus unbekanntem Grund neu. Die VMs, die auf dem Host liefen, fielen dadurch aus. Das Monitoring zeichnete die Störung auf und verkürzte automatisch das Testintervall, um eine dauerhafte Störung sofort zu erkennen. Mit wenigen Minuten Verzögerung wurde das Team per SMS und Pager alarmiert. Die Verzögerung stellt sicher, dass der Alarm nicht durch kurze Wackler in den Internetverbindungen ausgelöst wird.
Ich sitze zu diesem Zeitpunkt mit meiner Familie am Frühstückstisch. Eine SMS geht ein und ich ahne, dass in wenigen Sekunden der Pager piepst. So ist es auch. Ich quittiere den Alarm und werfe via Smartphone einen Blick auf unsere Statusanzeige. Diese verrät mir, dass die Störung auf einen Host begrenzt ist. Ich lasse meine Familie sitzen und begebe mich ins Homeoffice.
Dort starte ich meinen PC, prüfe noch einmal die Status-Anzeige und melde den Kollegen, dass ich den Fall bearbeite, aber potentiell Unterstützung benötigte. Ich erfasse die Störung auf der Status-Seite. Ich verbinde mich mit einem der internen VPNs und prüfe, ob ich mich auf dem Host einloggen kann. Das gelingt problemlos. Ein kurzer Check zeigt, dass der Host kürzlich neu gebootet hat, aber keine offensichtlichen Probleme aufweist. Daher entscheide ich mich, auf die Möglichkeit zum Failover zu verzichten und die VMs neu zu starten. Während die VMs starten, teile ich den Kollegen die Erkenntnisse und den Sachstand mit. Ferner sehe ich mir lokale und zentral abgelegte Logs an. Ich wechsle das VPN, um weitere Prüfungen in einer anderen Sicherheitszone vornehmen zu können.
Verschiedene Kollegen sind inzwischen ebenfalls online und bieten Unterstützung an. Ich freue mich, dass ich nicht allein bin, sollten sich in der Folge doch noch Probleme ergeben.
Alle VMs sind laut Monitoring wieder erfolgreich am Start. Ich schließe die Status-Meldung vorerst ab. Zwischen Eintritt der Störung und dem Abschluss des Hochfahrens der Dienste in den betroffenen VMs sind keine 25 Minuten vergangen.
«««< HEAD:content/blog/2022/morgens-halb-acht-im-hostsharing-service/index.md Mein Frau bringt mir dankenswerterweise meinen nunmehr kalten Kaffee und mein Käsebrot ins Homeoffice. Sie verabschiedet sich und bricht mit unseren Kindern in die Kita und anschließend in ihr Büro auf.
Meine Frau bringt mir meinen nunmehr kalten Kaffee und mein Käsebrot ins Homeoffice. Sie verabschiedet sich und bricht mit unseren Kindern in die Kita und zur Arbeit auf.
bced4eb67bf6c22ea61eb2501fc814a566d06c4b:content/blog/2022/service-ausserhalb-der-geschaeftszeiten/index.md
Ein Kollege vermutet derweil Auffälligkeiten in einem Log. Wir starten eine Ad-Hoc-Konferenz mit Screen-Sharing und gehen der Sache gemeinsam nach. Die Auffälligkeiten erweisen sich als harmlos und ohne Bezug zum Fall. Ein weiterer Kollege stößt hinzu.
Ein Mitglied meldet sich telefonisch, dessen Nextcloud unser genossenschaftlicher Webmaster as a Service betreut. Ich nehme das Gespräch an. In der Nextcloud läuft nach dem Reboot etwas nicht rund. Da der Kollege, der das Mitglied persönlich betreut, ebenfalls online ist, gebe ich das Anliegen per Chat weiter. Wenige Minuten später meldet der Kollege die Entstörung. Derweil suche ich weiter nach Auffälligkeiten in den Logs. Spezielle Aufmerksamkeit spendiere ich den Temperatursensoren, die einen kurzen Sprung von 45 °C auf 52 °C aufweisen. Dies liegt aber vermutlich nur an dem parallelen Start mehrerer VMs.
Wir beschließen, den Sachverhalt zu beobachten und im Laufe des Vormittags noch einmal alle Datenquellen, die Information zur eigentlichen Ursache (root cause) enthalten könnten, gemeinsam durchzusehen. Damit ist die akute Bearbeitung der Störung gegen 9 Uhr abgeschlossen.
Die Störung trat in der Nebenzeit auf, in der eigentlich nur eine begrenzte Zahl von Mitarbeitern im Einsatz ist. Die Nebenzeit gilt von 6 bis 8 Uhr und von 20 bis 24 Uhr, sowie samstags von 6 bis 12 Uhr. Die normale Hauptzeit im Service gilt montags bis freitags von 8 bis 20 Uhr. In der übrigen Zeit, vor allem nachts und an Sonn- und Feiertagen, haben einzelne Servicemitarbeiter Bereitschaft. «««< HEAD:content/blog/2022/morgens-halb-acht-im-hostsharing-service/index.md Die Alarmierung erfolgt parallel über mehrere Kanäle und klingelt Diensthabende – wie bei der Feuwerwehr – auch gnadenlos auch aus der Tiefschlafphase.
Da kann dich der Alarm auch schon einmal aus der Tiefschlafphase klingeln.
bced4eb67bf6c22ea61eb2501fc814a566d06c4b:content/blog/2022/service-ausserhalb-der-geschaeftszeiten/index.md
Die ständige Einsatzbereitschaft unseres Service finanzieren wir vor allem über den Extended Support. Der Extended Support garantiert den Mitgliedern, die ihn buchen, verkürzte Reaktionszeiten von acht, vier oder zwei Stunden. Mitglieder, die unternehmenskritische Systeme betreiben, sollten deshalb möglichst immer den Hostsharing Extended Support hinzubuchen. Sie sichern sich damit schnelle Reaktionszeiten, gegebenenfalls auch mitten in der Nacht. Und sie helfen mit, dass die Genossenschaft sich ein Serviceteam für eine 24/7 Betreuung der Cooperative Community Cloud leisten kann. Deshalb sei allen Mitgliedern, die Extended Support gebucht haben, auch im Namen aller anderen Mitgliedern hier einmal gedankt.
Der Extended Support berechtigt überdies zur Inanspruchnahme des Webmaster on Demands im Notfall, also auch in der Nacht oder am Wochenende wie in dem Blogartikel »Gemeinsam gegen Malware« beschrieben. Der Webmaster on Demand hilft, Störungen an den individuellen Anwendungen, die nicht in die Verantwortung von Hostsharing fallen, zu beheben.
