Du hast nicht viel über das Infrastructure-Team von DreamHost gehört (abgesehen von Teil 1 und 2 dieser Serie)? Das bedeutet, dass sie ihre Arbeit gut machen!
In ihrer Welt ist Stille Gold wert und das Chaos immer nur wenige Millisekunden entfernt.
Während wir anderen streamen, schlafen oder unsere Online-Präsenz aufbauen, geht dieses Team durch kalte Gänge, überprüft Dashboards, tauscht RAID-Karten aus und bereitet sich auf Notfälle vor, die (hoffentlich) nie eintreten.
Dies ist ein Einblick in die Kriegszimmer, seltsame Momente und die ständige Wachsamkeit, die DreamHost und deine Website am Laufen hält.
Der Tag, An Dem Portland Dunkel Wurde
Wenn es eine Geschichte gibt, die die Widerstandsfähigkeit des Teams zusammenfasst, dann ist es der Ausfall in Portland im November 2023.
„PGE (Portland General Electric) führte Wartungsarbeiten an einem der beiden Stromzuführungen zum Rechenzentrum durch“, erklärte Chris Lewis, DreamHosts Manager für Rechenzentrumsbetrieb, bezüglich eines Problems mit der Stromversorgung des Gebäudes.
Dann fiel auch die andere Stromversorgung aus, was zu einem kompletten Stromausfall führte.
Die Batterien sprangen an. Generatoren brüllten auf und alles schien in Ordnung. Doch als PGE die Wartungszufuhr wieder einschaltete, verursachte dies eine Schaltstörung, die einen gefährlichen Stromstoß auslöste, der ein Feuer entfachte und eine Reihe von Schaltern zerstörte. Mit nur wenigen Minuten Restlaufzeit der Backup-Batterie stand das Team vor dem Worst-Case-Szenario: einem vollständigen Ausfall des Rechenzentrums.
„Fast 75-80% unserer Racks sind ausgefallen, einschließlich des Kernnetzwerks“, sagte Chris. „Es war Wahnsinn.“
Und dennoch, innerhalb von 14 Stunden und mit der vollen Zusammenarbeit des Teams, war alles wieder am Laufen. Hier ist, wie das Team den Dienst deutlich schneller als die geschätzten 2 Tage bis zu einer Woche (im schlimmsten Fall) wiederherstellte:
- Erwartung Einer Katastrophe
- Das Team erwartete einen katastrophalen Ausfall (nicht diesen speziell) und migrierte proaktiv zu einem System, in dem die meisten Maschinen ohne Netzwerkabhängigkeit starten konnten, was erhebliche Zeit einsparte.
- Vorbeugende Wartung Und Belastbare Systeme
- Konstante vorbeugende Wartung und widerstandsfähige Systeme (Raids und Zpools) schützten Daten und erlaubten vernünftige Austauschzeiten anstatt zur Wiederherstellung defekter Arrays zu eilen.
- Nähe Und Bereitschaft Des Bereitschaftspersonals
- Die Administratoren vor Ort wohnen innerhalb einer Stunde vom Rechenzentrum entfernt und waren schnell vor Ort (in diesem Fall war der Administrator vor Ort zwanzig Minuten nach der Alarmierung da).
- Durch den Stromausfall wurden Türen von außen verriegelt und physische Sicherheitssysteme deaktiviert. Daher war es entscheidend, jemanden vor Ort zu haben, der manuell Identitäten überprüft – denn jemanden ohne angemessene Kontrolle auf die Etage zu lassen, wäre ein schwerwiegender Sicherheitsverstoß (oder schlimmer, ein Einbruch à la Mission: Impossible).
- Fachkundiges und globales TechOps-Team mit klarer Führung
- Ein umfangreiches, fähiges und weltweites TechOps-Team stellte frische Schichten und Fernüberwachung bereit.
- Klare Führung kanalisierte Informationen und priorisierte Aufgaben, ermöglicht durch ein tiefes Verständnis der Ebenen und Vertrauen in das Team, alle auf dem Laufenden über den Status aller beweglichen Teile zu halten.
💡Wusstest Du?
Die Dieselmotoren von DreamHost können ganze Rechenzentren bis zu 24 Stunden lang mit Strom versorgen, solange die Treibstofflieferungen fortgesetzt werden. Während des Ausfalls waren sie der einzige Grund dafür, dass Lichter (und Websites) weiterhin funktionierten.
Redundanz: Die Kunst paranoid zu sein (auf eine gute Art)
Katastrophenwiederherstellung wird nicht spontan erstellt, sie wird weit im Voraus konzipiert.
„Wir gehen davon aus, dass etwas kaputt geht“, sagte Luke Odom, der Direktor für IT-Betrieb bei DreamHost. „Deshalb planen wir für den Ausfall.“
- Leistung? Jedes Rack verfügt über redundante PDUs (Stromverteilungseinheiten) an separaten Einspeisungen.
- Netzwerk? Mehrere ISPs (Internetdienstanbieter) über verschiedene Zugangspunkte.
- Speicher? RAID-Arrays, Replikationsschichten und sofort verfügbare Backups.
Chris bringt es klar auf den Punkt und wendet Murphys Gesetz an: „Alles, was schiefgehen kann, wird auch schiefgehen.“ Es geht nicht darum, ob ein Fehler auftritt, sondern wann. Der entscheidende Faktor liegt darin, wie schnell sie sich erholen können oder noch besser, wie sie solche unerwarteten Ereignisse verhindern können.
Überwachung: Der Stille Schild
Online bleiben ist nicht glamourös, aber es ist ständig.
„Wir gehen durch die Räume, prüfen die Beleuchtung, überprüfen die Dashboards jeden Tag“, sagte Chris. „Manchmal meldet die Hardware ihren eigenen Ausfall nicht, also suchen wir danach.“
Diese Sorgfalt bedeutet, dass kleine Probleme erkannt werden, bevor sie zu vollständigen Ausfällen werden.
Aktuelle Projekte umfassen das Upgrade von Firmware, das Patchen von Sicherheitslücken und die Einführung verbesserter Berichterstattung, damit Probleme schneller erkannt (und gelöst) werden können.
„Wir überwachen alles, was wir können“, sagte Chris. „Und wenn etwas durchrutscht, finden wir heraus warum und reparieren das System.“
Wenn Automatisierung Ausfällt (Denn Das Passiert)
Automatisierung ist nützlich, bis sie es nicht mehr ist.
„Wir durchbrechen regelmäßig die Automation“, sagte Luke. „Die Hälfte von dem, was wir tun, ist eigentlich keine Automation, es sind nur Werkzeuge, die unsere manuelle Arbeit schneller und einfacher machen.“
Eine bedeutende Sicherheitslücke zwang das Team beispielsweise dazu, fast alles neu zu starten und das BIOS in ihrer gesamten Infrastruktur zu aktualisieren. Es war mühsam und nicht automatisiert, bis sie ein Werkzeug entwickelten, um wiederholbare Schritte zu vereinfachen. Sie verwenden es noch heute.
Die Bereitstellung von Servern, die früher Stunden in Anspruch nahm, dauert jetzt mit OpenStack und Ansible nur noch 20 Minuten. Wenn jedoch Firmware, Betriebssystemversionen oder Treiber geändert werden, schlagen die Skripte fehl und es geht zurück zur manuellen Arbeit.
Kriegsgeschichte #2: Kuhweiden-Edition
Manchmal findet die Infrastrukturunterstützung an… unkonventionellen Orten statt.
Während seines Urlaubs in Südgeorgien erhielt Luke einen Anruf: RAID-Ausfall. Hardware ausgefallen und Server offline. Als letzte Rettung rief das Team Luke um Hilfe.
„Ich saß auf einem Vierrad, während ich Kühe hütete“, sagte er. „Ich führte den Techniker durch den Wiederaufbau des Arrays mit einer funktionierenden Festplatte. Wir duplizierten es, stellten das RAID wieder her und brachten die Kunden wieder online“, sagte er.
Ja, mitten aus einem Kuhfeld.
Kriegsgeschichte #3: Gamer Jimmy, Betrugsbekämpfer
Vor fast einem Jahrzehnt wurde DreamHost mit einer Welle von betrügerischen Anmeldungen getroffen. Hacker würden Konten kompromittieren, dedizierte Server oder VPS-Angebote bestellen und sie nutzen, um Angriffe zu starten oder Kryptowährungen zu schürfen.
Eintritt: Gamer Jimmy.
Kein Teammitglied, sondern ein berüchtigter Hacker, dessen Aktivitäten ein internes Skript inspirierten.
„Einer der Jungs schrieb ein Skript mit dem Namen „Gamer Jimmy“, sagte Chris. „Es scannte nach Betrugsindikatoren und lehnte verdächtige Anfragen automatisch ab.“
Es hat funktioniert.
💡Wusstest Du?
Das FBI hat einmal eine geheime Überwachungsanlage bei einem DreamHost-Kunden installiert: unter dem Boden des Rechenzentrums. Sie wurde später während einer Zentrumsabschaltung entdeckt. Der Standort des Anlageetiketts war buchstäblich: unter dem Boden.
DreamHost-Infrastruktur: Die Unbesungenen Helden
Am Ende des Tages geht es im Infrastrukturteam von DreamHost nicht nur um blinkende Lichter und Luftstrom. Sie sind diejenigen, die alles stehen und liegen lassen—Besprechungen, Schlaf, sogar Urlaube—um deine Website online zu halten.
„Du siehst uns nicht, bis etwas kaputt geht“, sagte Chris. „Aber das ist irgendwie der Sinn. Wenn wir unsichtbar sind, machen wir es richtig.“
Und wenn Du sie doch siehst?
Wahrscheinlich ist ein brennendes Schaltpult oder ein Vierradfahrzeug beteiligt. Und irgendwie hat es dein Server trotzdem geschafft.