«Bitrix24»: «Schnell aufgestellte Dinge gelten nicht als gefallen»

Bis heute verfügt der Dienst „Bitrix24“ nicht über Hunderte von Gigabit-Traffic und hat keinen riesigen Serverpark (obwohl es natürlich eine beträchtliche Anzahl an vorhandenen Servern gibt). Für viele Kunden ist er jedoch das zentrale Arbeitswerkzeug im Unternehmen und ein wirklich geschäftskritisches Anwendung. Ein Ausfall ist also absolut inakzeptabel. Was aber, wenn es doch zu einem Ausfall kommt, der Dienst sich aber so schnell erholt, dass es niemand bemerkt? Und wie gelingt es, dabei ein Failover ohne Qualitätseinbußen und Verlust von Kunden umzusetzen? Alexander Demidov, Direktor der Cloud-Services bei „Bitrix24“, erläuterte in unserem Blog, wie sich das System der Reservierung in den letzten sieben Jahren seit der Einführung des Produkts weiterentwickelt hat.

Als SaaS haben wir „Bitrix24“ vor 7 Jahren gestartet. Die größte Herausforderung bestand wahrscheinlich darin, dass dieses Produkt vor dem öffentlichen Launch als SaaS nur in Form einer Boxlösung existierte. Die Kunden kauften es bei uns, installierten es auf ihren Servern, richteten ein Unternehmensportal ein — eine gemeinsame Lösung für die Kommunikation der Mitarbeiter, die Speicherung von Dateien, das Aufgabenmanagement, CRM, all das. Bis 2012 hatten wir beschlossen, es als SaaS zu launchen, autonom zu verwalten und Ausfallsicherheit sowie Zuverlässigkeit zu gewährleisten. Wir sammelten Erfahrungen während des Prozesses, da wir zuvor einfach keine hatten – wir waren lediglich Softwarehersteller und keine Dienstleister.

Als wir den Service starteten, war uns klar, dass das Wichtigste die Gewährleistung von Ausfallsicherheit, Zuverlässigkeit und ständiger Verfügbarkeit ist. Denn wenn Sie eine ganz normale Webseite, beispielsweise einen Shop, haben und diese fällt aus und liegt eine Stunde lang, leidet nur Ihr Unternehmen darunter. Sie verlieren Bestellungen und Kunden, aber für den Kunden selbst ist es nicht so kritisch. Natürlich ist er enttäuscht, aber er geht und kauft auf einer anderen Webseite. Wenn es sich jedoch um eine Anwendung handelt, die für die gesamte interne Unternehmensarbeit, die Kommunikation und Entscheidungen entscheidend ist, besteht der Schlüssel darin, das Vertrauen der Nutzer zu gewinnen, das heißt, sie nicht im Stich zu lassen und nicht auszufallen. Denn die gesamte Arbeit kann stillstehen, wenn etwas intern nicht funktioniert.

Bitrix24 als SaaS

Der erste Prototyp wurde ein Jahr vor dem öffentlichen Launch im Jahr 2011 zusammengebaut. Wir haben ihn etwa eine Woche lang entwickelt, getestet und sogar zum Laufen gebracht. Man konnte die Form eingeben, den Namen des Portals eintragen, und ein neues Portal wurde aufgesetzt, eine Benutzerdatenbank wurde erstellt. Wir schauten es an, bewerteten das Produkt im Prinzip, stellten es ein und arbeiteten ein ganzes Jahr weiter daran. Denn wir hatten eine große Aufgabe: Wir wollten keine zwei verschiedenen Codebasen erstellen, wir wollten kein separates Boxprodukt und separate Cloud-Lösungen unterstützen – wir wollten alles innerhalb eines Codes umsetzen.

Zu diesem Zeitpunkt war eine typische Webanwendung ein Server, auf dem ein PHP-Code läuft, eine MySQL-Datenbank, Dateien werden hochgeladen, Dokumente und Bilder werden in einen Upload-Ordner gelegt – und das war's. Leider ist es unmöglich, einen kritisch stabilen Webservice auf dieser Basis zu starten. Verteiltes Caching und Datenbank-Replikation werden dort nicht unterstützt.

Wir haben die Anforderungen formuliert: die Fähigkeit, an verschiedenen Standorten gehostet zu werden, die Unterstützung von Replikation und idealerweise die Platzierung in geografisch verteilten Rechenzentren. Die Trennung der Produktlogik und der Datenspeicherung. Die Möglichkeit, dynamisch nach Last zu skalieren und statische Inhalte auszulagern. Aus diesen Überlegungen entstanden die Anforderungen an das Produkt, das wir im Laufe des letzten Jahres weiterentwickelt haben. Während dieser Zeit haben wir eine einheitliche Plattform geschaffen – sowohl für Boxlösungen als auch für unseren eigenen Service – und haben die erforderlichen Funktionen integriert. Die Unterstützung der MySQL-Replikation auf Produktebene: Das heißt, der Entwickler, der Code schreibt, muss sich keine Gedanken darüber machen, wie seine Anfragen verteilt werden. Er nutzt unsere API, und wir wissen, wie wir Lese- und Schreibanfragen richtig zwischen Master- und Slave-Datenbanken verteilen.

Wir haben die Produktunterstützung für verschiedene Cloud-Objektstorage-Lösungen implementiert: Google Storage, Amazon S3 — sowie die Unterstützung für OpenStack Swift. Das macht es sowohl für uns als Dienstleister als auch für die Entwickler, die mit unserer Boxlösung arbeiten, bequem: Wenn sie einfach unsere API nutzen, müssen sie sich nicht darum kümmern, wo die Datei letztendlich gespeichert wird — ob lokal im Dateisystem oder im objektbasierten Dateispeicher.

Letztendlich haben wir uns sofort entschieden, auf der Ebene eines gesamten Rechenzentrums zu redundieren. Im Jahr 2012 haben wir vollständig auf Amazon AWS gestartet, da wir bereits Erfahrung mit dieser Plattform hatten – unsere eigene Website war dort gehostet. Wir waren von der Tatsache angezogen, dass es in jeder Region von Amazon mehrere Verfügbarkeitszonen gibt – im Grunde genommen, (in ihrer Terminologie) mehrere Rechenzentren, die mehr oder weniger unabhängig voneinander sind und es uns ermöglichen, auf der Ebene eines gesamten Rechenzentrums zu redundieren: Falls dieses plötzlich ausfällt, werden die Datenbanken master-master repliziert, die Webanwendungsserver sind reserviert, und die statischen Inhalte werden in den Objektspeicher S3 ausgelagert. Die Last wird ausgeglichen — damals mit Amazon's ELB, aber etwas später haben wir unsere eigenen Load-Balancer entwickelt, weil wir eine komplexere Logik benötigten.

Was wir wollten, haben wir bekommen…

Alle grundlegenden Dinge, die wir sicherstellen wollten – die Ausfallsicherheit der Server, der Webanwendungen, der Datenbanken – haben gut funktioniert. Das einfachste Szenario: Wenn eines unserer Webanwendungen ausfällt, ist es ganz einfach – sie werden aus der Lastverteilung entfernt.

Die ausgefallenen Maschinen des Load Balancers (damals war es ein Amazon ELB) wurden selbst als ungesund markiert und die Lastverteilung auf sie deaktiviert. Der Amazon Auto Scaling war aktiv: Wenn die Last anstieg, wurden neue Maschinen zur Auto Scaling-Gruppe hinzugefügt, und die Last wurde auf die neuen Maschinen verteilt – alles lief gut. Bei unseren Load Balancern funktioniert die Logik ähnlich: Wenn etwas mit dem Anwendungsserver passiert, entfernen wir die Anfragen von ihm, nehmen diese Maschinen aus dem Betrieb, starten neue und arbeiten weiter. Die Vorgehensweise hat sich über die Jahre etwas verändert, funktioniert aber weiterhin: Sie ist einfach, verständlich und es gibt keine Schwierigkeiten damit.

Wir arbeiten weltweit, die Lastspitzen unserer Kunden sind sehr unterschiedlich, und im Idealfall sollten wir die Möglichkeit haben, Wartungsarbeiten an beliebigen Komponenten unseres Systems jederzeit durchzuführen – ohne dass die Kunden etwas davon mitbekommen. Daher haben wir die Möglichkeit, die Datenbank abzuschalten und die Last auf das zweite Rechenzentrum umzuverteilen.

Wie funktioniert das alles? — Wir leiten den Datenverkehr auf ein betriebsbereites Rechenzentrum um – im Falle eines Ausfalls des Rechenzentrums komplett; wenn es sich um unsere planmäßigen Arbeiten an einer bestimmten Datenbank handelt, leiten wir einen Teil des Datenverkehrs, der diese Kunden bedient, auf das zweite Rechenzentrum um, die Replikation wird eingestellt. Wenn neue Maschinen für Webanwendungen benötigt werden, weil die Last im zweiten Rechenzentrum gestiegen ist, starten sie automatisch. Nach Abschluss der Arbeiten wird die Replikation wiederhergestellt, und wir leiten die gesamte Last zurück. Wenn wir bestimmte Arbeiten im zweiten Rechenzentrum spiegeln müssen, zum Beispiel Systemupdates installieren oder die Einstellungen der zweiten Datenbank ändern, machen wir im Grunde das Gleiche, nur in umgekehrter Reihenfolge. Bei einem Ausfall handeln wir ganz einfach: Im Überwachungssystem verwenden wir den Mechanismus der Event-Handler. Wenn mehrere Überprüfungen ausgelöst werden und der Status auf kritisch wechselt, wird dieser Handler aktiviert, der eine bestimmte Logik ausführen kann. Für jede Datenbank haben wir festgelegt, welcher Server als Failover dient und wohin der Datenverkehr im Falle ihrer Nichterreichbarkeit umgeschaltet werden muss. Historisch bedingt verwenden wir in irgendeiner Form Nagios oder dessen Forks. Solche Mechanismen sind in praktisch jedem Überwachungssystem vorhanden, etwas Komplexeres verwenden wir derzeit nicht, aber möglicherweise werden wir das irgendwann tun. Derzeit löst die Überwachung bei Nichterreichbarkeit aus und hat die Möglichkeit, etwas umzuleiten.

Haben wir alles reserviert?

Wir haben viele Kunden aus den USA, viele Kunden aus Europa und viele Kunden, die näher am Osten wohnen – Japan, Singapur und so weiter. Natürlich gibt es auch eine große Anzahl von Kunden in Russland. Das bedeutet, dass unsere Tätigkeit nicht auf eine einzige Region beschränkt ist. Den Nutzern ist eine schnelle Reaktion wichtig, es gibt Anforderungen zur Einhaltung verschiedener lokaler Gesetze, und innerhalb jeder Region reservieren wir zwei Rechenzentren. Zudem gibt es zusätzliche Dienste, die, wiederum, praktisch innerhalb einer Region platziert werden – für Kunden, die in dieser Region arbeiten. REST-Handler und Authentifizierungsserver sind weniger kritisch für die allgemeine Funktionsweise des Kunden; hier kann man mit einer akzeptablen Verzögerung wechseln. Aber man möchte nicht das Rad neu erfinden, indem man sich über das Monitoring und die Handhabung Gedanken macht. Deshalb versuchen wir, soweit wie möglich, bereits bestehende Lösungen zu nutzen und nicht eigene Kompetenzen für zusätzliche Produkte zu entwickeln. An einigen Stellen verwenden wir einfach DNS-Umleitungen, wobei die Verfügbarkeit des Dienstes ebenfalls über DNS bestimmt wird. Amazon bietet den Dienst Route 53, der nicht nur ein einfaches DNS ist, in das man Einträge eingeben kann – es ist deutlich flexibler und benutzerfreundlicher. Über ihn lassen sich geo-verteilte Dienste mit Geolokalisierungen aufbauen, bei denen man mithilfe von Route 53 feststellt, woher der Kunde kommt, und ihm entsprechende Einträge bereitstellt – mithilfe dessen kann man Failover-Architekturen erstellen. Auch die Health-Checks werden direkt in Route 53 konfiguriert; man gibt Endpunkte an, die überwacht werden, definiert Metriken und legt fest, nach welchen Protokollen die „Lebendigkeit“ des Dienstes überprüft werden soll – tcp, http, https, und legt die Häufigkeit der Prüfungen fest, die bestimmen, ob der Dienst aktiv ist oder nicht. Und im DNS legt man fest, was Primary und was Secondary sein wird und wohin umgeschaltet werden soll, wenn der Health-Check innerhalb von Route 53 anspringt. Das alles lässt sich mit anderen Tools realisieren, aber der große Vorteil ist, dass man einmal konfiguriert und danach gar nicht mehr darüber nachdenken muss, wie die Überprüfungen ausgeführt werden und wie der Wechsel funktioniert: es läuft einfach.

Das erste „Aber“: Wie und womit sichern wir Route 53? Man weiß ja nie, was passieren könnte. Glücklicherweise sind wir bisher nie auf diese Probleme gestoßen, aber ich werde gleich erzählen, warum wir uns gedacht haben, dass es besser ist, eine Sicherung zu machen. Hier bereiten wir uns im Voraus vor. Mehrmals täglich führen wir einen vollständigen Export aller Zonen durch, die wir in Route 53 eingerichtet haben. Die API von Amazon ermöglicht es, diese einfach im JSON-Format abzurufen, und wir haben mehrere Backup-Server eingerichtet, auf die wir dies umwandeln und als Konfiguration speichern. So haben wir im Großen und Ganzen eine Backup-Konfiguration. Für den Fall der Fälle können wir sie schnell manuell wiederherstellen, ohne DNS-Einstellungen zu verlieren.

Das zweite „Aber“: was in diesem Bild noch nicht reserviert ist? Nur der Load Balancer! Wir haben die Verteilung der Kunden nach Regionen sehr einfach gestaltet. Wir haben Domains wie bitrix24.ru, bitrix24.com, .de – derzeit sind es etwa 13 verschiedene, die in den verschiedensten Zonen funktionieren. Unser Ansatz ist: In jeder Region gibt es eigene Load Balancer. So ist es einfacher, je nach Spitzenlast im Netzwerk regional zu verteilen. Wenn es einen Ausfall bei einem einzelnen Load Balancer gibt, wird er einfach außer Betrieb genommen und aus dem DNS entfernt. Tritt ein Problem mit einer Gruppe von Load Balancern auf, werden sie auf anderen Plattformen reserviert, und der Wechsel zwischen ihnen erfolgt über das gleiche Route53, da der Wechsel dank der kurzen TTL maximal innerhalb von 2, 3, 5 Minuten geschieht.

Das dritte „aber“: Was ist noch nicht reserviert? S3, richtig. Als wir Dateien speicherten, die bei den Nutzern in S3 abgelegt waren, waren wir aufrichtig überzeugt, dass es unverwundbar ist und man dort nichts reservieren muss. Aber die Geschichte zeigt, dass es anders kommt. Amazon beschreibt S3 tatsächlich als einen grundlegenden Dienst, weil Amazon selbst S3 für die Speicherung von Maschinen-Images, Konfigurationen, AMI-Images, Snapshots usw. verwendet. Und wenn S3 ausfällt, wie es in den letzten 7 Jahren, in denen wir Bitrix24 nutzen, einmal geschehen ist, zieht es eine ganze Reihe von Problemen mit sich — die Unzugänglichkeit des Starts von virtuellen Maschinen, API-Ausfälle und so weiter.

Und S3 kann ausfallen – das ist schon einmal passiert. Daher haben wir uns folgende Strategie überlegt: Vor einigen Jahren gab es in Russland keine ernsthaften öffentlichen Objektspeicher, und wir haben darüber nachgedacht, etwas Eigenes zu entwickeln... Glücklicherweise haben wir das nicht getan, denn wir hätten uns mit einem Fachwissen auseinandersetzen müssen, das uns fehlt, und hätten sicherlich Fehler gemacht. Jetzt gibt es S3-kompatible Speicher bei Mail.ru, bei Yandex und bei einigen anderen Anbietern. Letztendlich sind wir zu dem Schluss gekommen, dass wir, erstens, Redundanz und, zweitens, die Möglichkeit zur Arbeit mit lokalen Kopien haben wollen. Für den speziellen russischen Raum nutzen wir den Service Mail.ru Hotbox, der über eine API mit S3 kompatibel ist. Es waren keine ernsthaften Anpassungen am Code innerhalb der Anwendung erforderlich, und wir haben den folgenden Mechanismus implementiert: In S3 gibt es Trigger, die bei der Erstellung/Löschung von Objekten aktiviert werden, und Amazon hat einen Service namens Lambda – das ist serverloses Codeausführen, das genau bei der Auslösung der genannten Trigger ausgeführt wird.

Wir haben es ganz einfach gemacht: Wenn unser Trigger ausgelöst wird, führen wir den Code aus, der das Objekt in den Speicher von Mail.ru kopiert. Um die Arbeit mit lokalen Datenkopien vollständig zu starten, benötigen wir außerdem eine Rücksynchronisation, damit Kunden im russischen Sektor mit dem Speicher, der ihnen näher ist, arbeiten können. Mail wird bald die Trigger in ihrem Speicher fertigstellen — dann können wir bereits auf Infrastruktur-Ebene die Rücksynchronisation durchführen, momentan machen wir das auf Ebene unseres eigenen Codes. Wenn wir sehen, dass ein Kunde eine Datei hochgeladen hat, setzen wir auf unserer Code-Ebene ein Ereignis in die Warteschlange, verarbeiten es und führen die Rückreplication durch. Das ist das Problem: Wenn wir für unsere Objekte außerhalb unseres Produkts mit externen Mitteln arbeiten, berücksichtigen wir das nicht. Daher warten wir, bis die Trigger auf der Ebene des Speichers verfügbar sind, damit unabhängig davon, von wo wir den Code ausgeführt haben, das Objekt, das zu uns gelangt, in die andere Richtung kopiert wird.

Auf der Code-Ebene haben wir für jeden Kunden beide Speicherorte definiert: einem wird als der Hauptspeicher betrachtet, der andere als Backup. Wenn alles gut funktioniert, arbeiten wir mit dem Speicherort, der uns näher ist: Das heißt, unsere Kunden, die in Amazon sind, arbeiten mit S3, während diejenigen, die in Russland sind, mit Hotbox arbeiten. Wenn ein Schalter aktiviert wird, muss unser Failover aktiviert werden, und wir schalten die Kunden auf einen anderen Speicherort um. Wir können diesen Schalter unabhängig nach Regionen setzen und sie hin und her wechseln. In der Praxis haben wir dies noch nicht genutzt, aber wir haben diesen Mechanismus vorgesehen und denken, dass wir irgendwann dieses Umschalten benötigen werden. Einmal ist es bereits passiert.

Oh, ist euer Amazon verschwunden…

Diesen April jährt sich der Beginn der Telegramm-Sperren in Russland. Der am stärksten betroffene Anbieter, der darunter leidet, ist Amazon. Und leider haben vor allem russische Unternehmen, die global tätig waren, noch stärkere Schäden erlitten.

Wenn ein Unternehmen global ist und Russland für es einen ganz kleinen Markt darstellt, 3-5% — nun, so oder so, kann man diese opfern.

Wenn es sich um ein rein russisches Unternehmen handelt, bin ich mir sicher, dass eine lokale Präsenz erforderlich ist – einfach weil es für die Nutzer bequem und komfortabel wäre, und die Risiken geringer wären.

Und wenn es sich um ein Unternehmen handelt, das global tätig ist und etwa gleich viele Kunden aus Russland hat wie aus anderen Teilen der Welt? Die Verbindung der Segmente ist wichtig, und sie sollten in irgendeiner Form zusammenarbeiten müssen.

Bereits Ende März 2018 hat die Roskomnadsor den größten Betreibern einen Brief geschickt, in dem sie darüber informieren, dass sie planen, mehrere Millionen IP-Adressen von Amazon zu blockieren, um… den Messenger Zello zu sperren. Danke an diese Anbieter – sie haben den Brief erfolgreich allen zugespielt, und es wurde klar, dass die Verbindung zu Amazon zusammenbrechen könnte. Es war Freitag, und wir sind in Panik zu unseren Kollegen von servers.ru gelaufen, mit den Worten: „Freunde, wir brauchen ein paar Server, die nicht in Russland, nicht bei Amazon stehen, sondern zum Beispiel irgendwo in Amsterdam“, um die Möglichkeit zu haben, dort zumindest irgendwie eigene zu platzieren. vpn und ein Proxy für bestimmte Endpoints, auf die wir keinen Einfluss haben, beispielsweise die Endpoints von S3 — es ist nicht möglich, einen neuen Service hochzufahren und eine andere IP zu erhalten, wir müssen immer noch darauf zugreifen. In ein paar Tagen haben wir diese Server eingerichtet und hochgefahren, und im Allgemeinen waren wir zum Zeitpunkt des Beginns der Blockierungen vorbereitet. Interessanterweise sagte die RKDN, als sie den Aufruhr und die Panik sahen: "Nein, wir werden jetzt nichts blockieren." (Aber das war genau bis zu dem Moment, als sie begannen, Telegram zu blockieren.) Nachdem wir die Umgehungsmöglichkeiten eingerichtet hatten und verstanden, dass keine Blockierung eingeführt wurde, wollten wir trotzdem nicht alles weiter aufschlüsseln. So, nur für den Fall.

Und so leben wir im Jahr 2019 tatsächlich in einer Umgebung mit Einschränkungen. Ich habe letzte Nacht geschaut: Rund eine Million IP-Adressen werden weiterhin blockiert. Zwar wurden fast alle Amazon-Adressen freigegeben, in der Spitze waren es bis zu 20 Millionen Adressen… Die Realität ist, dass Konnektivität, gute Konnektivität — die kann plötzlich fehlen. Sie kann aus technischen Gründen wegfallen — Brände, Bagger, solche Dinge. Oder, wie wir gesehen haben, aus nicht ganz technischen Gründen. Daher kann jemand Großes und Bedeutendes, mit eigenen AS-Systemen, das vielleicht auf andere Weise steuern — direkte Verbindungen und ähnliche Dinge bereits auf der L2-Ebene. Aber im einfacheren Fall, wie wir oder kleinere Anbieter, sollte man zur Sicherheit eine Reserve auf der Ebene von Servern haben, die irgendwo anders aufgestellt sind, mit vorab konfigurierten VPNs, Proxys, mit der Möglichkeit, schnell auf sie umzuschalten in den Bereichen, in denen die Konnektivität kritisch für uns ist. Das hat uns mehrfach geholfen, als die Amazon-Blockierungen begannen; wir haben so im schlimmsten Fall den S3-Verkehr darüber geleitet, aber schlussendlich hat sich alles geklärt.

Und wie reserviert man… einen ganzen Anbieter?

Derzeit haben wir kein Szenario für den Totalausfall von Amazon. Wir verfügen jedoch über ein ähnliches Szenario für Russland. Dort haben wir uns bei einem Anbieter platziert, der mehrere Standorte anbietet. Vor einem Jahr hatten wir ein Problem: Selbst wenn es sich um zwei Rechenzentren handelt, können bereits auf der Ebene der Netzwerkkonfiguration des Anbieters Probleme auftreten, die beide Rechenzentren betreffen. Dadurch kann es zu Ausfällen an beiden Standorten kommen. Und genau das ist passiert. Letztendlich haben wir die Architektur überdacht. Sie hat sich nicht grundlegend geändert, aber für Russland haben wir nun zwei Standorte, die nicht bei einem einzigen Anbieter liegen, sondern bei zwei verschiedenen. Wenn einer ausfällt, können wir auf den anderen umschalten.

Hypothetisch ziehen wir für Amazon in Betracht, eine Reservierung auf der Ebene eines anderen Anbieters vorzunehmen; vielleicht Google, vielleicht jemand anderes… Aber in der Praxis haben wir bisher beobachtet, dass, wenn bei Amazon Ausfälle in einer Verfügbarkeitszone auftreten, umfassende Ausfälle auf der Ebene einer Region eher selten sind. Daher haben wir theoretisch eine Vorstellung davon, dass wir möglicherweise eine Reservierung von "Amazon — nicht Amazon" vornehmen könnten, aber bisher gibt es so etwas nicht in der Praxis.

Ein paar Worte zur Automatisierung

Ist Automatisierung immer notwendig? Hier ist der Dunning-Kruger-Effekt relevant. Auf der x-Achse haben wir unser Wissen und die Erfahrung, die wir sammeln, und auf der y-Achse unser Vertrauen in unser Handeln. Zuerst wissen wir nichts und sind überhaupt nicht sicher. Dann wissen wir ein bisschen und werden mega-sicher — das ist der sogenannte "Peak of Stupidity", gut veranschaulicht durch das Bild "Dummheit und Tapferkeit". Danach haben wir ein bisschen gelernt und sind bereit, in den Kampf zu ziehen. Dann treten wir auf einige mega ernste Hürden und fallen ins Tal der Verzweiflung, wenn wir zwar denken, etwas zu wissen, aber in Wirklichkeit wissen wir viel zu wenig. Mit zunehmender Erfahrung werden wir dann zuversichtlicher.

Unsere Logik über verschiedene Umschaltungen bei bestimmten Störungen lässt sich sehr gut durch dieses Diagramm erklären. Wir haben angefangen – wir hatten keine Ahnung, nahezu alle Arbeiten wurden manuell durchgeführt. Dann haben wir erkannt, dass wir alles automatisieren können, um uns beruhigt zurücklehnen zu können. Und plötzlich treten wir in ein großes Fettnäpfchen: Wir erleben einen False Positive, und wir schalten den Verkehr hin und her, obwohl es eigentlich nicht nötig gewesen wäre. Dadurch bricht die Replikation oder etwas Ähnliches zusammen – das ist das Tal der Verzweiflung. Danach kommen wir zu der Erkenntnis, dass man alles mit Bedacht angehen sollte. Das heißt, es macht Sinn, sich auf die Automatisierung zu verlassen, jedoch mit der Möglichkeit eines Fehlalarms. Aber! Wenn die Folgen katastrophal sein könnten, ist es besser, dies den Bereitschaftsteams, den diensthabenden Ingenieuren zu überlassen, die sicherstellen, kontrollieren, dass es tatsächlich eine Störung gibt, und die erforderlichen Maßnahmen manuell durchführen.

Fazit

In den letzten sieben Jahren haben wir den Weg von Panik, wenn etwas ausfiel, zu einem Verständnis zurückgelegt, dass es keine Probleme gibt, sondern nur Aufgaben, die gelöst werden müssen — und auch gelöst werden können. Wenn Sie einen Service aufbauen, betrachten Sie ihn aus einer Überblicksperspektive und bewerten Sie alle Risiken, die auftreten können. Wenn Sie diese Risiken schnell identifizieren, planen Sie im Voraus für Redundanz und die Möglichkeit, eine ausfallsichere Infrastruktur zu schaffen, denn jeder Punkt, der ausfallen kann und den Dienst beeinträchtigt, wird definitiv ausfallen. Und selbst wenn Sie denken, dass bestimmte Infrastrukturkomponenten wie S3 niemals ausfallen, sollten Sie dennoch im Hinterkopf behalten, dass sie es können. Haben Sie zumindest theoretisch einen Plan, was Sie tun werden, falls etwas passiert. Entwickeln Sie einen Risiko-Management-Plan. Wenn Sie darüber nachdenken, alles automatisiert oder manuell zu erledigen, bewerten Sie die Risiken: Was passiert, wenn die Automatisierung anfängt, alles umzustellen — führt das möglicherweise zu einer noch schlimmeren Situation im Vergleich zu einem Ausfall? Möglicherweise ist es an manchen Stellen notwendig, einen vernünftigen Kompromiss zwischen der Nutzung von Automatisierung und der Reaktion eines Ingenieurs zu finden, der die tatsächliche Situation bewertet und entscheidet, ob sofortige Änderungen notwendig sind oder ob es besser ist, zu warten und nichts zu tun.

Ein vernünftiger Kompromiss zwischen Perfektionismus und den realen Ressourcen, Zeit und Geld, die Sie für das endgültige Konzept aufwenden können.

Dieser Text ist eine erweiterte und ergänzte Version des Vortrags von Alexander Demidov auf der Konferenz. Uptime Tag 4.

Quelle: habr.com