„Bitrix24“: „Schnell aufgestellte Dinge zählen nicht als gefallen“

Der Dienst „Bitrix24“ hat heute keine Hunderte von Gigabit Traffic, keine riesigen Serverparks (obwohl es natürlich auch einige gibt). Für viele Kunden ist es jedoch das Hauptwerkzeug in ihrem Unternehmen, eine echte business-kritische Anwendung. Daher darf ein Ausfall einfach nicht passieren. Und was, wenn doch ein Ausfall eingetreten ist, der Dienst jedoch so schnell „auferstanden“ ist, dass niemand etwas bemerkt hat? Und wie gelingt es dabei, Failover zu realisieren, ohne die Qualität der Arbeit und die Anzahl der Kunden zu beeinträchtigen? Alexander Demidov, Direktor der Cloud-Services bei „Bitrix24“, hat für unseren Blog erzählt, wie sich das Reservierungssystem in den 7 Jahren des Bestehens des Produkts entwickelt hat.

Wir haben „Bitrix24“ vor 7 Jahren als SaaS gestartet. Die größte Herausforderung war wahrscheinlich folgendes: Vor dem öffentlichen Start als SaaS existierte dieses Produkt einfach in Form einer Boxlösung. Kunden kauften es bei uns, installierten es auf ihren eigenen Servern, und definierten ein Unternehmensportal – eine Gesamtlösung für die Kommunikation der Mitarbeiter, Speicherung von Dateien, Aufgabenverwaltung, CRM und all das. Und bis 2012 haben wir beschlossen, dass wir es als SaaS starten wollen, um es selbst zu administrieren und Ausfallsicherheit sowie Zuverlässigkeit zu gewährleisten. Unsere Erfahrungen haben wir im Prozess gesammelt, denn bis zu diesem Zeitpunkt hatten wir einfach keine – wir waren nur Softwarehersteller, keine Serviceanbieter.

Als wir den Dienst starteten, wussten wir, dass das Wichtigste darin besteht, Ausfallsicherheit, Zuverlässigkeit und ständige Verfügbarkeit des Dienstes zu gewährleisten, denn wenn Sie eine einfache Website haben, beispielsweise einen Online-Shop, und sie stürzt ab und bleibt eine Stunde lang offline, leiden nur Sie selbst, Sie verlieren Aufträge, Sie verlieren Kunden, aber für den Kunden selbst ist das nicht sehr kritisch. Er ist natürlich enttäuscht, aber er geht und kauft auf einer anderen Website. Wenn es sich jedoch um eine Anwendung handelt, von der die gesamte Arbeit im Unternehmen abhängt, Kommunikation und Entscheidungen, dann ist das Wichtigste, das Vertrauen der Benutzer zu gewinnen, d.h. sie nicht im Stich zu lassen und nicht abzustürzen. Denn die gesamte Arbeit kann stillstehen, wenn etwas im Inneren nicht funktioniert.

Bitrix24 als SaaS

Den ersten Prototypen haben wir ein Jahr vor dem öffentlichen Launch im Jahr 2011 zusammengestellt. Wir haben ihn in etwa einer Woche zusammengebaut, angesehen und ausprobiert – er war sogar schon funktionsfähig. Das heißt, man konnte in das Formular gehen, den Namen des Portals eingeben, und es wurde ein neues Portal erstellt, und eine Benutzerdatenbank angelegt. Wir haben uns das angeschaut, das Produkt grundsätzlich bewertet, es verworfen und ein ganzes Jahr weiter daran gearbeitet. Denn wir hatten eine große Herausforderung: Wir wollten keine zwei verschiedenen Codebasen erstellen, wir wollten kein separates Box-Produkt und separate Cloud-Lösungen unterstützen – wir wollten all das innerhalb eines Codes umsetzen.

Ein typisches Webanwendungsdesign zu diesem Zeitpunkt war ein einzelner Server, auf dem ein PHP-Code lief, eine MySQL-Datenbank, Dateien wurden hochgeladen, Dokumente und Bilder landeten im Upload-Ordner – und das war's. Leider ist es unmöglich, einen kritischen, stabilen Webdienst auf dieser Grundlage zu starten. Verteilte Caching-Methoden werden nicht unterstützt, die Replikation von Datenbanken ist nicht möglich.

Wir haben die Anforderungen formuliert: Es muss möglich sein, sich an verschiedenen Standorten zu platzieren, Replikation zu unterstützen, idealerweise in geografisch verteilten Rechenzentren untergebracht zu werden. Die Logik des Produkts von der Datenlagerung zu trennen. Dynamisch skalierbar zu sein je nach Last, statische Daten vollständig auszulagern. Aus diesen Überlegungen ergaben sich letztlich die Anforderungen an das Produkt, das wir im Laufe des Jahres entwickelt haben. Während dieser Zeit haben wir in der Plattform, die uns eine Einheitlichkeit bot – sowohl für Box-Lösungen als auch für unseren eigenen Dienst – die Unterstützung für die Dinge integriert, die wir benötigten. Unterstützung für MySQL-Replikation auf Produktebene: das heißt, der Entwickler, der den Code schreibt, muss sich keine Gedanken darüber machen, wie seine Anfragen verteilt werden, er nutzt unsere API, und wir können die Anfragen zum Schreiben und Lesen zwischen Master- und Slave-Datenbanken korrekt verteilen.

Wir haben auf Produktebene die Unterstützung für verschiedene Cloud-Objektspeicher eingerichtet: Google Storage, Amazon S3 – plus die Unterstützung für OpenStack Swift. Daher war es sowohl für uns als Dienstleister als auch für die Entwickler, die mit der Box-Lösung arbeiten, praktisch: Wenn sie einfach unsere API nutzen, brauchen sie sich keine Gedanken darüber zu machen, wo die Datei letztendlich gespeichert wird, ob lokal im Dateisystem oder im objektorientierten Dateispeicher.

Letztendlich haben wir uns sofort entschieden, dass wir uns auf der Ebene eines gesamten Rechenzentrums reservieren werden. 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. Uns hat angezogen, dass es in jeder Region bei Amazon mehrere Verfügbarkeitszonen gibt – im Wesentlichen (in ihrer Terminologie) mehrere Rechenzentren, die mehr oder weniger unabhängig voneinander sind und uns ermöglichen, auf der Ebene eines gesamten Rechenzentrums zu reservieren: Wenn eines plötzlich ausfällt, werden die Datenbanken master-master repliziert, die Webanwendungsserver sind reserviert, und die Statische wird in den Objektspeicher S3 ausgelagert. Die Last wird verteilt – zu diesem Zeitpunkt mit Amazons ELB, aber etwas später haben wir eigene Lastenausgleicher entwickelt, da wir komplexere Logiken benötigten.

Was wir wollten, das haben wir auch bekommen...

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

Die ausgefallenen Maschinen wurden vom Lastenausgleicher (damals war es Amazons ELB) selbst als unhealthy markiert und die Lastverteilung auf sie wurde deaktiviert. Amazons Auto-Scaling funktionierte: Wenn die Last anstieg, wurden neue Maschinen zur Auto-Scaling-Gruppe hinzugefügt, die Last wurde auf die neuen Maschinen verteilt – alles war gut. Mit unseren Lastenausgleichern gilt eine ähnliche Logik: Wenn etwas mit dem Anwendungsserver passiert, entfernen wir die Anfragen von ihm, werfen diese Maschinen heraus, starten neue und arbeiten weiter. Das Schema hat sich über all die Jahre etwas geändert, funktioniert aber weiterhin: Es ist einfach, verständlich und es gibt dabei keine Schwierigkeiten.

Wir arbeiten weltweit, die Lastenspitzen unserer Kunden sind absolut unterschiedlich, und im Idealfall sollten wir in der Lage sein, zu jeder Zeit Wartungsarbeiten an beliebigen Komponenten unseres Systems unbemerkt für die Kunden durchzuführen. Deshalb haben wir die Möglichkeit, die Datenbank abzuschalten und die Last auf ein zweites Rechenzentrum umzuleiten.

Wie funktioniert das alles? — Wir leiten den Traffic auf ein funktionierendes Rechenzentrum um — wenn es sich um einen Ausfall im Rechenzentrum handelt, dann vollständig, wenn es sich um geplante Wartungsarbeiten an einer bestimmten Datenbank handelt, dann leiten wir einen Teil des Traffics, der diese Kunden bedient, auf das zweite Rechenzentrum um, die Replikation wird pausiert. Wenn wir neue Maschinen für Webanwendungen benötigen, da die Last im zweiten Rechenzentrum gestiegen ist, werden sie automatisch gestartet. Die Arbeiten werden abgeschlossen, die Replikation wird wiederhergestellt, und wir geben die gesamte Last zurück. Wenn wir spiegelbildlich Arbeiten im zweiten Rechenzentrum durchführen müssen, zum Beispiel systemweite Updates installieren oder Einstellungen in der zweiten Datenbank ändern, wiederholen wir im Grunde alles genau so, nur in die andere Richtung. Und wenn es sich um einen Ausfall handelt, handeln wir ganz banal: Im Überwachungssystem verwenden wir einen Event-Handler-Mechanismus. Wenn mehrere Überprüfungen auslösen und der Status auf kritisch wechselt, wird dieser Handler, der eine bestimmte Logik ausführen kann, aktiviert. Für jede Datenbank haben wir festgelegt, welcher Server für sie als Failover dient und wohin der Traffic im Fall ihrer Nichterreichbarkeit umgeleitet werden muss. Wir verwenden – so hat es sich historisch ergeben – in irgendeiner Form Nagios oder eines seiner Forks. Prinzipiell sind solche Mechanismen in praktisch jedem Überwachungssystem vorhanden, etwas Komplexeres verwenden wir derzeit nicht, aber möglicherweise werden wir das irgendwann tun. Momentan reagiert die Überwachung auf Nichterreichbarkeit und hat die Möglichkeit, etwas umzuleiten.

Haben wir alles reserviert?

Wir haben viele Kunden aus den USA, viele Kunden aus Europa, viele Kunden, die näher am Osten sind – Japan, Singapur und so weiter. Natürlich ist ein großer Teil der Kunden in Russland. Das heißt, die Arbeit findet nicht nur in einer Region statt. Die Benutzer wünschen sich eine schnelle Reaktion, es gibt Anforderungen zur Einhaltung verschiedener lokaler Gesetze, und innerhalb jeder Region reservieren wir uns zwei Rechenzentren. Außerdem gibt es einige zusätzliche Dienste, die ebenfalls bequem innerhalb einer Region platziert werden können – für Kunden, die in dieser Region arbeiten. REST-Handler und Autorisierungsserver sind für die Gesamtfunktionalität des Kunden weniger kritisch; man kann mit ihnen bei einer geringen akzeptablen Verzögerung umschalten, aber wir möchten das Rad nicht neu erfinden, wie man sie überwacht und was man mit ihnen macht. Daher versuchen wir, so weit wie möglich, bestehende Lösungen zu nutzen und nicht intern eine Kompetenz für zusätzliche Produkte zu entwickeln. Und manchmal nutzen wir einfach DNS-Wechsel, wobei die Verfügbarkeit des Dienstes ebenfalls über die DNS ermittelt wird. Bei Amazon gibt es den Dienst Route 53, aber das ist nicht einfach nur ein DNS, in das man Einträge einfügen kann – es ist viel flexibler und benutzerfreundlicher. Darüber hinaus kann man geo-verteilte Dienste mit Geolokalisierungen aufbauen, wenn man mit seiner Hilfe bestimmt, von wo der Kunde kommt, und ihm die entsprechenden Einträge gibt – damit kann man Failover-Architekturen erstellen. Dieselben Health-Checks werden direkt in Route 53 konfiguriert; man gibt den zu überwachenden Endpunkt an, definiert Metriken und legt fest, nach welchen Protokollen die „Lebendigkeit“ des Dienstes bestimmt werden soll – TCP, HTTP, HTTPS; man gibt die Häufigkeit der Prüfungen an, die bestimmen, ob der Dienst lebendig ist oder nicht. Und in den DNS selbst gibt man an, was primary und was secondary sein wird sowie wohin umgeschaltet wird, wenn ein Health-Check innerhalb von Route 53 aktiviert wird. All dies kann auch mit anderen Werkzeugen erledigt werden, aber der Vorteil ist, dass man es einmal konfiguriert und dann überhaupt nicht mehr darüber nachdenken muss, wie unsere Prüfungen durchgeführt werden und wie der Umschaltung erfolgt: alles funktioniert automatisch.

Das erste „Aber“: aber wie und womit reserviert man Route 53? Wer weiß, vielleicht passiert etwas mit ihm? Glücklicherweise sind wir bisher nie auf diese Probleme gestoßen, aber ich werde gleich erklären, warum wir doch über eine Reservierung nachdenken mussten. Hier bereiten wir uns im Voraus vor. Mehrmals täglich laden wir alle Zonen, die wir in Route 53 eingerichtet haben, vollständig herunter. Die API von Amazon ermöglicht es, diese problemlos im JSON-Format bereitzustellen, und wir haben mehrere Backup-Server eingerichtet, auf denen wir dies umwandeln, in Form von Konfigurationen auslagern und grob gesagt eine Backup-Konfiguration haben. Im Notfall können wir sie schnell manuell wiederherstellen, ohne die DNS-Einstellungen zu verlieren.

Zweites „aber“: was in diesem Bild noch nicht reserviert ist? Der Load Balancer! Unsere Verteilung der Kunden nach Regionen erfolgt sehr einfach. Wir haben Domains wie bitrix24.ru, bitrix24.com, .de – insgesamt sind es jetzt etwa 13 verschiedene, die in den unterschiedlichsten Zonen arbeiten. Wir sind zu folgendem gekommen: In jeder Region gibt es eigene Load Balancer. Das erleichtert die Verteilung je nach regionaler Auslastung. Wenn ein einzelner Load Balancer ausfällt, wird er einfach außer Betrieb genommen und aus den DNS entfernt. Wenn es ein Problem mit einer Gruppe von Load Balancern gibt, werden diese auf anderen Plattformen reserviert, und der Wechsel zwischen ihnen erfolgt mithilfe von Route 53, da der Wechsel aufgrund der kurzen TTL maximal innerhalb von 2, 3, 5 Minuten stattfindet.

Drittes „aber“: was ist noch nicht reserviert? S3, richtig. Als wir die Dateien, die wir bei den Nutzern in S3 speichern, hochluden, waren wir überzeugt, dass es eine zuverlässige Lösung ist und keine Reservierungen notwendig sind. Aber die Geschichte zeigt, dass es anders kommt. Im Allgemeinen beschreibt Amazon S3 als einen grundlegenden Service, weil Amazon selbst S3 zur Speicherung von Maschinenbildern, Konfigurationen, AMI-Images, Snapshots usw. verwendet. Und wenn S3 ausfällt, wie es einmal in diesen 7 Jahren, in denen wir Bitrix24 nutzen, der Fall war, zieht es eine Menge Dinge mit sich – die Unzugänglichkeit des Starts von VMs, Störungen in der API usw.

Und es kann passieren, dass S3 ausfällt – das ist einmal passiert. Deshalb sind wir zu folgendem Schema gekommen: vor einigen Jahren gab es in Russland keine ernsthaften objektbasierten öffentlichen Speichern, und wir haben darüber nachgedacht, etwas Eigenes zu machen… Glücklicherweise haben wir damit nicht begonnen, denn wir hätten uns in eine Expertise vergraben, die wir nicht besitzen, und hätten sicherlich Fehler gemacht. Jetzt gibt es S3-kompatible Speicher bei Mail.ru, bei Yandex und auch bei einigen anderen Anbietern. Schließlich kamen wir zu dem Schluss, dass wir, erstens, eine Sicherung benötigen und, zweitens, die Möglichkeit haben wollen, mit lokalen Kopien zu arbeiten. Für die spezifische russische Region nutzen wir den Service Mail.ru Hotbox, der über API mit S3 kompatibel ist. Wir benötigten keine bedeutenden Anpassungen des Codes innerhalb der Anwendung, und wir haben folgenden Mechanismus entwickelt: In S3 gibt es Trigger, die bei der Erstellung/Löschung von Objekten aktiviert werden, und Amazon hat einen solchen Service namens Lambda – das ist serverloses Ausführen von Code, der genau beim Auslösen dieser Trigger ausgeführt wird.

Wir haben es sehr einfach gestaltet: Wenn ein Trigger aktiviert wird, führen wir den Code aus, der das Objekt in den Speicher von Mail.ru kopiert. Um die Arbeit mit lokalen Kopien von Daten vollständig zu starten, benötigen wir noch eine Rücksynchronisierung, damit die Kunden, die im russischen Segment arbeiten, mit dem Speicher arbeiten können, der ihnen näher ist. Mail wird gerade die Trigger in seinem Speicher finalisieren – man wird bereits auf Infrastrukturebene die Rücksynchronisierung durchführen können, während wir dies derzeit auf der Ebene unseres eigenen Codes tun. Wenn wir sehen, dass ein Kunde eine Datei hochgeladen hat, platzieren wir auf der Ebene unseres Codes ein Ereignis in die Warteschlange, bearbeiten es und führen die Rückreplication durch. Das Problem dabei ist: Wenn irgendetwas mit unseren Objekten außerhalb unseres Produkts geschieht, also mit irgendwelchen externen Mitteln, werden wir das nicht berücksichtigen. Deshalb warten wir darauf, dass die Trigger auf der Ebene des Speichers verfügbar sind, damit unabhängig davon, von wo aus wir den Code ausgeführt haben, das Objekt, das zu uns gekommen ist, in die andere Richtung kopiert wird.

Auf Code-Ebene sind für jeden Kunden beide Speicher definiert: einer wird als primär betrachtet, der andere als Backup. Wenn alles gut läuft, arbeiten wir mit dem Speicher, der uns näher ist: Das heißt, unsere Kunden in Amazon nutzen S3, während jene in Russland mit Hotbox arbeiten. Wenn das Flag aktiviert wird, muss unser Failover aktiviert werden, und wir schalten die Kunden auf einen anderen Speicher um. Dieses Flag können wir unabhängig nach Regionen setzen und die Kunden hin und her umschalten. In der Praxis haben wir es bisher nicht genutzt, aber wir haben diesen Mechanismus vorgesehen und glauben, dass wir irgendwann auf dieses Umschalten angewiesen sein werden. Es ist bereits einmal passiert.

Oh, und euer Amazon ist abgehauen…

In diesem April jährt sich die Einführung der Telegramm-Sperren in Russland. Der am stärksten betroffene Anbieter, der darunter gelitten hat, ist Amazon. Leider haben vor allem russische Unternehmen, die weltweit tätig waren, mehr schadhaft unter den Blockaden gelitten.

Wenn ein Unternehmen global tätig ist und Russland nur einen sehr kleinen Marktanteil von 3-5% hat – ja, dann kann man sie irgendwie opfern.

Wenn es sich um ein rein russisches Unternehmen handelt – dann bin ich mir sicher, dass man lokal agieren muss – es wäre für die Nutzer einfach bequemer, komfortabler, mit weniger Risiken.

Und wenn es sich um ein Unternehmen handelt, das global tätig ist und etwa gleich viele Kunden aus Russland und anderen Teilen der Welt hat? Die Anbindung der Segmente ist wichtig, und sie müssen miteinander arbeiten.

Bereits Ende März 2018 hat die Roskomnadzor den größten Anbietern ein Schreiben geschickt, in dem sie ankündigten, mehrere Millionen IP-Adressen von Amazon zu sperren, um… den Messenger Zello zu blockieren. Dank dieser Provider wurde das Schreiben erfolgreich an alle weitergeleitet, und es entstand das Bewusstsein, dass die Anbindung an Amazon zusammenbrechen könnte. Es war ein Freitag, und wir rannten in Panik zu den Kollegen von servers.ru mit den Worten: 'Freunde, wir brauchen ein paar Server, die nicht in Russland, nicht in Amazon stehen, sondern zum Beispiel irgendwo in Amsterdam', um zumindest irgendwie die Möglichkeit zu haben, dort eigene zu platzieren. vpn und proxy für einige endpoints, auf die wir keinen Einfluss haben können, wie zum Beispiel die endpoints von s3 – wir können keinen neuen Dienst hochfahren und andere IPs erhalten, wir müssen trotzdem dorthin gelangen. Innerhalb von wenigen Tagen haben wir diese Server eingerichtet und hochgefahren und waren im Großen und Ganzen bis zum Beginn der Blockierungen vorbereitet. Interessanterweise hat die RKN, als sie die Aufregung und die Panik sah, gesagt: „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 und verstanden hatten, dass die Blockierung nicht eingeführt wurde, haben wir dennoch nicht alles weiterverfolgt. So, nur für den Fall.

Und so leben wir im Jahr 2019 unter den Bedingungen von Blockierungen. Ich habe gestern Nacht geschaut: Rund eine Million IPs werden weiterhin blockiert. Allerdings wurde Amazon fast vollständig entsperrt, im Höchstfall waren es bis zu 20 Millionen Adressen… Die Realität ist, dass die Konnektivität, gute Konnektivität – es könnte sie nicht geben. Plötzlich. Sie könnte aus technischen Gründen fehlen – 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, wahrscheinlich auf andere Weise damit umgehen, – Direct Connect und andere Dinge bereits auf der L2-Ebene. Aber im einfachen Fall, wie wir oder kleinere Anbieter, kann man zur Sicherheit eine Reserve auf der Ebene von Servern haben, die irgendwo anders hochgefahren wurden, vorab konfigurierte VPNs, Proxys, mit der Möglichkeit, die Konfiguration schnell in den Segmenten umzuschalten, die für die Konnektivität kritisch sind. Das kam uns mehrfach zu gute, als die Blockierungen von Amazon begannen; wir haben in dem schlechtesten Fall gerade den S3-Verkehr darüber geleitet, aber nach und nach hat sich das alles geklärt.

Und wie reserviert man… einen ganzen Anbieter?

Aktuell haben wir kein Szenario für den Ausfall von Amazon. Für Russland haben wir ein ähnliches Szenario. Wir haben uns in Russland bei einem Anbieter in zwei verschiedenen Rechenzentren platziert. Vor einem Jahr hatten wir ein Problem: Auch wenn es zwei Rechenzentren sind, können bereits auf der Ebene der Netzwerkkonfiguration des Anbieters Probleme auftreten, die beide Rechenzentren betreffen. Dies kann zu Ausfällen an beiden Standorten führen. Genau das ist passiert. Wir haben die interne Architektur daraufhin überdacht. Sie hat sich nicht grundlegend verändert, aber jetzt haben wir in Russland zwei Standorte bei zwei unterschiedlichen Anbietern. Wenn einer ausfällt, können wir auf den anderen umschalten.

Hypothetisch ziehen wir für Amazon in Betracht, auf einer anderen Anbieter-Ebene Reservierungen vorzunehmen; vielleicht Google, vielleicht irgendwann auch andere… Aber bis jetzt haben wir in der Praxis beobachtet, dass Ausfälle bei Amazon auf der Ebene einer Availability Zone zwar vorkommen, aber Ausfälle auf regionaler Ebene sind eher selten. Daher haben wir theoretisch die Vorstellung, dass wir eventuell Reservierungen zwischen "Amazon und Nicht-Amazon" vornehmen, aber in der Praxis gibt es so etwas noch nicht.

Ein paar Worte zur Automatisierung

Ist Automatisierung immer notwendig? Hier ist es angebracht, den Dunning-Kruger-Effekt zu erwähnen. Auf der x-Achse haben wir unser Wissen und unsere gesammelten Erfahrungen, auf der y-Achse das Vertrauen in unser Handeln. Zuerst wissen wir nichts und sind völlig ungewiss. Dann wissen wir ein wenig und werden mega-sicher – das ist der sogenannte „Gipfel der Dummheit“, gut veranschaulicht durch das Bild „Torheit und Mut“. Danach haben wir schon ein wenig gelernt und sind bereit, in den Kampf zu ziehen. Dann treten wir auf einige mega-ernste Fallen und gelangen ins Tal der Verzweiflung, wo wir zwar etwas wissen, aber in Wirklichkeit wissen wir noch sehr viel weniger. Mit zunehmender Erfahrung werden wir dann selbstbewusster.

Unsere Logik über verschiedene Umschaltungen bei bestimmten Notfällen wird durch dieses Diagramm sehr gut beschrieben. Wir haben angefangen – wir konnten nichts, praktisch alle Arbeiten wurden manuell durchgeführt. Dann haben wir verstanden, dass wir alles automatisieren können und, sozusagen, ruhig schlafen können. Und plötzlich treten wir auf die Mega-Schaufel: wir haben einen False Positive und wechseln den Traffic hin und her, obwohl wir das in einer idealen Situation nicht tun sollten. Folglich bricht die Replikation oder etwas anderes zusammen – das ist das Tal der Verzweiflung. Und dann kommen wir zu der Einsicht, dass man alles mit Bedacht angehen muss. Das heißt, es macht Sinn, sich auf die Automatisierung zu verlassen und die Möglichkeit eines Fehlalarms einzuplanen. Aber! Wenn die Konsequenzen verheerend sein könnten, ist es besser, dies den Bereitschaftsschichten, den Bereitschaftsingenieuren zu überlassen, die sicherstellen und überprüfen, dass es sich wirklich um einen Notfall handelt und die erforderlichen Maßnahmen manuell ergreifen…

Fazit

In 7 Jahren sind wir von dem Punkt gekommen, als etwas ausfiel – da war Panik-Panik, zu dem Verständnis, dass es keine Probleme gibt, nur Aufgaben, die gelöst werden müssen – und die kann man lösen. Wenn Sie einen Service aufbauen, schauen Sie ihn aus einer höheren Perspektive an, bewerten Sie alle Risiken, die auftreten könnten. Wenn Sie sie sofort sehen – planen Sie im Voraus Redundanz und die Möglichkeit, eine fehlertolerante Infrastruktur aufzubauen, denn jeder Punkt, der ausfallen kann und zu einem Ausfall des Services führt, wird es zwangsläufig tun. Und selbst wenn es Ihnen so scheint, als ob einige Elemente der Infrastruktur nicht ausfallen werden – wie das gleiche s3 – denken Sie daran, dass sie es trotzdem können. Und zumindest theorisch sollten Sie eine Vorstellung davon haben, was Sie mit ihnen tun werden, falls doch etwas passiert. Haben Sie einen Plan zur Risikominderung. Wenn Sie darüber nachdenken, alles automatisiert oder manuell zu erledigen – bewerten Sie die Risiken: Was passiert, wenn die Automatisierung alles umschaltet – führt das nicht zu einem noch schlimmeren Szenario als bei einem Notfall? Möglicherweise ist es in einigen Fällen sinnvoll, einen vernünftigen Kompromiss zwischen dem Einsatz von Automatisierung und der Reaktion des Bereitschaftsingenieurs zu finden, der das reale Bild beurteilt und versteht, ob er sofort etwas umschalten muss oder „ja, aber nicht jetzt“.

Ein vernünftiger Kompromiss zwischen Perfektionismus und den realen Ressourcen, der Zeit und dem Geld, die Sie für das Schema aufwenden können, das Sie letztendlich haben werden.

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

Quelle: habr.com