Heutzutage verfügt der Bitrix24-Dienst weder über Hunderte von Gigabit an Datenverkehr noch über eine riesige Serverflotte (obwohl es natürlich einige gibt). Für viele Kunden ist es jedoch das wichtigste Werkzeug für die Arbeit im Unternehmen, eine echte geschäftskritische Anwendung. Daher gibt es keine Möglichkeit zu fallen. Was wäre, wenn der Absturz zwar passiert wäre, sich der Dienst aber so schnell „wiederhergestellt“ hätte, dass niemand etwas bemerkt hätte? Und wie ist es möglich, ein Failover zu implementieren, ohne dass die Arbeitsqualität und die Anzahl der Clients verloren gehen? Alexander Demidov, Direktor für Cloud-Dienste bei Bitrix24, sprach für unseren Blog darüber, wie sich das Reservierungssystem in den sieben Jahren seines Bestehens entwickelt hat.
„Wir haben Bitrix24 vor 7 Jahren als SaaS gestartet. Die Hauptschwierigkeit war wahrscheinlich folgende: Bevor es als SaaS öffentlich eingeführt wurde, existierte dieses Produkt lediglich im Format einer Box-Lösung. Kunden haben es bei uns gekauft, auf ihren Servern gehostet, ein Unternehmensportal eingerichtet – eine allgemeine Lösung für Mitarbeiterkommunikation, Dateispeicherung, Aufgabenverwaltung, CRM, das ist alles. Und 2012 beschlossen wir, es als SaaS einzuführen, es selbst zu verwalten und Fehlertoleranz und Zuverlässigkeit sicherzustellen. Wir haben nebenbei Erfahrungen gesammelt, denn bis dahin hatten wir diese einfach nicht – wir waren nur Softwarehersteller, keine Dienstleister.
Bei der Einführung des Dienstes haben wir verstanden, dass es am wichtigsten ist, Fehlertoleranz, Zuverlässigkeit und ständige Verfügbarkeit des Dienstes sicherzustellen, denn wenn Sie eine einfache, gewöhnliche Website haben, zum Beispiel ein Geschäft, fällt es auf Sie und bleibt dort liegen Eine Stunde lang leiden nur Sie, Sie verlieren Aufträge, Sie verlieren Kunden, aber für Ihren Kunden selbst ist das nicht sehr kritisch. Er war natürlich verärgert, aber er kaufte es auf einer anderen Website. Und wenn es sich um eine Anwendung handelt, an der die gesamte Arbeit innerhalb des Unternehmens, die Kommunikation und die Entscheidungen hängen, dann ist es das Wichtigste, das Vertrauen der Benutzer zu gewinnen, das heißt, sie nicht im Stich zu lassen und nicht zu fallen. Denn jede Arbeit kann aufhören, wenn etwas im Inneren nicht funktioniert.
Bitrix.24 als SaaS
Den ersten Prototyp haben wir ein Jahr vor der öffentlichen Markteinführung, im Jahr 2011, zusammengebaut. Wir haben es in etwa einer Woche zusammengebaut, angeschaut, gedreht – es hat sogar funktioniert. Das heißt, Sie könnten in das Formular gehen, dort den Namen des Portals eingeben, ein neues Portal würde sich öffnen und eine Benutzerbasis würde erstellt. Wir haben es uns angeschaut, das Produkt grundsätzlich beurteilt, es verschrottet und ein ganzes Jahr lang weiter verfeinert. Denn wir hatten eine große Aufgabe: Wir wollten nicht zwei verschiedene Codebasen erstellen, wir wollten kein separates Paketprodukt und keine separaten Cloud-Lösungen unterstützen – wir wollten alles in einem Code erledigen.
Eine typische Webanwendung war damals ein Server, auf dem PHP-Code läuft, eine MySQL-Datenbank, Dateien hochgeladen, Dokumente, Bilder im Upload-Ordner abgelegt – nun, alles funktioniert. Leider ist es damit unmöglich, einen kritisch stabilen Webdienst zu starten. Dort wird der verteilte Cache nicht unterstützt, und die Datenbankreplikation wird nicht unterstützt.
Wir haben die Anforderungen formuliert: Dies ist die Fähigkeit, sich an verschiedenen Standorten zu befinden, die Replikation zu unterstützen und sich idealerweise in verschiedenen geografisch verteilten Rechenzentren zu befinden. Trennen Sie die Produktlogik und eigentlich die Datenspeicherung. Sie können je nach Belastung dynamisch skalieren und Statik völlig tolerieren. Aus diesen Überlegungen sind tatsächlich die Anforderungen an das Produkt entstanden, die wir im Laufe des Jahres verfeinert haben. Während dieser Zeit haben wir auf der Plattform, die sich als einheitlich herausstellte – für Boxlösungen, für unseren eigenen Service – Unterstützung für die Dinge geleistet, die wir brauchten. Unterstützung für die MySQL-Replikation auf der Ebene des Produkts selbst: Das heißt, der Entwickler, der den Code schreibt, denkt nicht darüber nach, wie seine Anfragen verteilt werden, er verwendet unsere API und wir wissen, wie man Schreib- und Leseanfragen korrekt zwischen Mastern verteilt und Sklaven.
Wir haben auf Produktebene Unterstützung für verschiedene Cloud-Objektspeicher bereitgestellt: Google Storage, Amazon S3 sowie Unterstützung für Open Stack Swift. Daher war dies sowohl für uns als Service als auch für Entwickler, die mit einer Paketlösung arbeiten, praktisch: Wenn sie unsere API nur für die Arbeit nutzen, denken sie nicht darüber nach, wo die Datei letztendlich gespeichert wird, lokal im Dateisystem oder im Objektdateispeicher.
Aus diesem Grund haben wir uns sofort entschieden, die Reservierung auf der Ebene des gesamten Rechenzentrums vorzunehmen. Im Jahr 2012 sind wir vollständig auf Amazon AWS gestartet, da wir bereits Erfahrungen mit dieser Plattform hatten – unsere eigene Website wurde dort gehostet. Uns hat die Tatsache gereizt, dass Amazon in jeder Region mehrere Verfügbarkeitszonen hat – tatsächlich (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 reservieren: Bei einem plötzlichen Ausfall werden die Datenbanken Master-Master repliziert, die Webanwendungsserver gesichert und die statischen Daten in den S3-Objektspeicher verschoben. Der Lastausgleich erfolgt – damals noch per Amazon elb, wenig später kamen wir aber zu eigenen Load Balancern, da wir eine komplexere Logik brauchten.
Was sie wollten, ist was sie bekamen...
Alle grundlegenden Dinge, die wir sicherstellen wollten – Fehlertoleranz der Server selbst, Webanwendungen, Datenbanken – alles hat gut funktioniert. Das einfachste Szenario: Wenn eine unserer Webanwendungen ausfällt, ist alles ganz einfach – sie werden vom Balancing abgeschaltet.
Der Balancer (damals noch Amazons elb) markierte Maschinen, die außer Betrieb waren, als ungesund und schaltete die Lastverteilung darauf ab. Amazon Autoscaling funktionierte: Als die Last wuchs, wurden neue Maschinen zur Autoscaling-Gruppe hinzugefügt, die Last wurde auf neue Maschinen verteilt – alles war in Ordnung. Bei unseren Balancern ist die Logik ungefähr dieselbe: Wenn etwas mit dem Anwendungsserver passiert, entfernen wir Anfragen von ihm, werfen diese Maschinen weg, starten neue und arbeiten weiter. Das Schema hat sich im Laufe der Jahre ein wenig verändert, funktioniert aber weiterhin: Es ist einfach, verständlich und es gibt keine Schwierigkeiten damit.
Wir sind auf der ganzen Welt im Einsatz, Lastspitzen bei Kunden sind völlig unterschiedlich und auf einvernehmliche Art und Weise sollten wir jederzeit und unbemerkt für Kunden bestimmte Servicearbeiten an beliebigen Komponenten unserer Anlage durchführen können. Daher haben wir die Möglichkeit, die Datenbank außer Betrieb zu setzen und die Last auf ein zweites Rechenzentrum umzuverteilen.
Wie funktioniert das Ganze? — Wir leiten den Datenverkehr an ein funktionierendes Rechenzentrum weiter. Wenn es im Rechenzentrum zu einem Unfall kommt, dann vollständig. Wenn dies unsere geplante Arbeit mit einer Datenbank ist, leiten wir einen Teil des Datenverkehrs, der diese Kunden bedient, an ein zweites Datenzentrum weiter und unterbrechen ihn es Replikation. Werden neue Maschinen für Webanwendungen benötigt, weil die Auslastung des zweiten Rechenzentrums zugenommen hat, starten diese automatisch. Wir beenden die Arbeit, die Replikation wird wiederhergestellt und wir geben die gesamte Last zurück. Wenn wir einige Arbeiten im zweiten DC spiegeln müssen, zum Beispiel Systemupdates installieren oder Einstellungen in der zweiten Datenbank ändern, dann wiederholen wir im Allgemeinen dasselbe, nur in die andere Richtung. Und wenn dies ein Unfall ist, machen wir alles trivial: Wir verwenden den Event-Handler-Mechanismus im Überwachungssystem. Wenn mehrere Prüfungen ausgelöst werden und der Status auf „Kritisch“ geht, führen wir diesen Handler aus, einen Handler, der diese oder jene Logik ausführen kann. Für jede Datenbank geben wir an, welcher Server als Failover für sie fungiert und wohin der Datenverkehr umgeleitet werden muss, wenn er nicht verfügbar ist. Historisch gesehen verwenden wir Nagios oder einige seiner Zweige in der einen oder anderen Form. Im Prinzip gibt es in fast jedem Überwachungssystem ähnliche Mechanismen; wir verwenden noch nichts Komplexeres, aber vielleicht werden wir es eines Tages tun. Jetzt wird die Überwachung durch Nichtverfügbarkeit ausgelöst und hat die Möglichkeit, etwas zu ändern.
Haben wir alles reserviert?
Wir haben viele Kunden aus den USA, viele Kunden aus Europa, viele Kunden, die näher am Osten liegen – Japan, Singapur und so weiter. Natürlich befindet sich ein großer Teil der Kunden in Russland. Das heißt, die Arbeit findet nicht in einer Region statt. Benutzer wünschen eine schnelle Reaktion, es gibt Anforderungen zur Einhaltung verschiedener lokaler Gesetze, und innerhalb jeder Region reservieren wir zwei Rechenzentren, außerdem gibt es einige zusätzliche Dienste, die wiederum bequem innerhalb einer Region platziert werden können – für Kunden, die sich dort aufhalten Diese Region funktioniert. REST-Handler und Autorisierungsserver sind für den Betrieb des Clients als Ganzes weniger kritisch. Sie können mit einer kleinen akzeptablen Verzögerung zwischen ihnen wechseln, aber Sie möchten das Rad nicht neu erfinden, wenn es darum geht, wie sie überwacht werden und was zu tun ist mit ihnen. Deshalb versuchen wir, bestehende Lösungen maximal zu nutzen, anstatt eine Art Kompetenz für zusätzliche Produkte zu entwickeln. Und irgendwo verwenden wir trivialerweise die Umschaltung auf DNS-Ebene und bestimmen die Lebendigkeit des Dienstes anhand desselben DNS. Amazon verfügt über einen Route 53-Dienst, aber es handelt sich nicht nur um einen DNS, in den Sie Einträge vornehmen können, und das war’s – er ist viel flexibler und bequemer. Dadurch können Sie geografisch verteilte Dienste mit Geostandorten erstellen, indem Sie damit feststellen, woher der Client kommt, und ihm bestimmte Datensätze geben – mit seiner Hilfe können Sie Failover-Architekturen erstellen. Dieselben Gesundheitsprüfungen werden in Route 53 selbst konfiguriert. Sie legen die Endpunkte fest, die überwacht werden, legen Metriken fest und legen fest, welche Protokolle die „Liveness“ des Dienstes bestimmen sollen – TCP, http, https; Legen Sie die Häufigkeit der Überprüfungen fest, mit denen festgestellt wird, ob der Dienst aktiv ist oder nicht. Und im DNS selbst geben Sie an, was primär und was sekundär sein soll und wohin gewechselt werden soll, wenn die Gesundheitsprüfung innerhalb der Route 53 ausgelöst wird. All dies kann mit einigen anderen Tools durchgeführt werden, aber warum ist das praktisch? Wir legen es fest Einmal hochfahren und dann überhaupt nicht darüber nachdenken, wie wir prüfen, wie wir wechseln: Alles funktioniert von selbst.
Das erste „aber“: Wie und womit kann man die Route 53 selbst reservieren? Wer weiß, was ist, wenn ihm etwas passiert? Glücklicherweise sind wir nie auf diesen Rechen getreten, aber ich möchte noch einmal eine Geschichte darüber erzählen, warum wir dachten, wir müssten trotzdem reservieren. Hier haben wir uns vorab Strohhalme ausgelegt. Mehrmals am Tag führen wir eine vollständige Entladung aller Zonen durch, die wir in der Route 53 haben. Mit der API von Amazon können Sie sie einfach in JSON senden, und wir haben mehrere Backup-Server, auf denen wir sie konvertieren, in Form von Konfigurationen hochladen und grob gesagt eine Backup-Konfiguration haben. Wenn etwas passiert, können wir es schnell manuell bereitstellen, ohne dass die DNS-Einstellungsdaten verloren gehen.
Zweites „aber“: Was auf diesem Bild ist noch nicht reserviert? Der Balancer selbst! Unsere Verteilung der Kunden nach Regionen ist sehr einfach. Wir haben die Domains bitrix24.ru, bitrix24.com, .de – mittlerweile sind es 13 verschiedene, die in verschiedenen Zonen operieren. Wir sind zu folgendem Ergebnis gekommen: Jede Region hat ihre eigenen Balancer. Dies erleichtert die regionale Verteilung, je nachdem, wo die Spitzenlast im Netzwerk liegt. Handelt es sich dabei um einen Ausfall auf der Ebene eines einzelnen Balancers, wird dieser einfach außer Betrieb genommen und aus dem DNS entfernt. Wenn bei einer Gruppe von Balancern ein Problem auftritt, werden diese auf anderen Standorten gesichert und die Umschaltung zwischen ihnen erfolgt über dieselbe Route53, da die Umschaltung aufgrund der kurzen TTL innerhalb von maximal 2, 3, 5 Minuten erfolgt .
Drittes „aber“: Was ist noch nicht reserviert? S3, richtig. Als wir die Dateien, die wir für Benutzer speichern, in s3 platzierten, waren wir der festen Überzeugung, dass es sich um panzerbrechende Dateien handelte und es keinen Grund gab, dort etwas zu reservieren. Aber die Geschichte zeigt, dass die Dinge anders kommen. Im Allgemeinen beschreibt Amazon S3 als einen grundlegenden Dienst, da Amazon selbst S3 zum Speichern von Maschinenbildern, Konfigurationen, AMI-Bildern, Snapshots usw. verwendet. Und wenn s3 abstürzt, wie es in diesen 7 Jahren, so lange wir es verwenden, einmal passiert ist bitrix24 folgt ihm wie ein Fan. Es kommt eine ganze Reihe von Dingen auf – virtuelle Maschinen können nicht gestartet werden, API-Fehler und so weiter.
Und S3 kann abstürzen – das ist einmal passiert. Deshalb kamen wir zu folgendem Plan: Vor einigen Jahren gab es in Russland keine ernsthaften öffentlichen Objektlager und wir dachten über die Möglichkeit nach, etwas Eigenes zu machen ... Glücklicherweise haben wir nicht damit begonnen, weil wir es tun würden Wir haben uns mit dem Fachwissen beschäftigt, das wir nicht haben, und würden es wahrscheinlich vermasseln. Jetzt verfügt Mail.ru über S3-kompatiblen Speicher, Yandex hat ihn und eine Reihe anderer Anbieter haben ihn. Schließlich kamen wir zu der Idee, dass wir erstens ein Backup und zweitens die Möglichkeit haben wollten, mit lokalen Kopien zu arbeiten. Speziell für die russische Region verwenden wir den Mail.ru Hotbox-Dienst, der API-kompatibel mit s3 ist. Wir brauchten keine größeren Änderungen am Code innerhalb der Anwendung und haben den folgenden Mechanismus erstellt: In s3 gibt es Trigger, die das Erstellen/Löschen von Objekten auslösen, Amazon hat einen Dienst namens Lambda – das ist ein serverloser Start von Code Das wird genau dann ausgeführt, wenn bestimmte Auslöser ausgelöst werden.
Wir haben es ganz einfach gemacht: Wenn unser Trigger ausgelöst wird, führen wir Code aus, der das Objekt in den Mail.ru-Speicher kopiert. Um die Arbeit mit lokalen Datenkopien vollständig zu starten, benötigen wir auch eine umgekehrte Synchronisierung, damit Kunden im russischen Segment mit Speicher arbeiten können, der näher bei ihnen liegt. Mail ist dabei, Trigger in seinem Speicher abzuschließen – es wird möglich sein, eine umgekehrte Synchronisierung auf Infrastrukturebene durchzuführen, aber im Moment tun wir dies auf der Ebene unseres eigenen Codes. Wenn wir sehen, dass ein Client eine Datei gepostet hat, stellen wir das Ereignis auf Codeebene in eine Warteschlange, verarbeiten es und führen eine umgekehrte Replikation durch. Warum es schlecht ist: Wenn wir mit unseren Objekten außerhalb unseres Produkts arbeiten, das heißt mit externen Mitteln, werden wir das nicht berücksichtigen. Deshalb warten wir bis zum Ende, wenn Trigger auf der Speicherebene erscheinen, sodass das zu uns gekommene Objekt, egal von wo aus wir den Code ausführen, in die andere Richtung kopiert wird.
Auf Codeebene registrieren wir beide Speicher für jeden Client: einer gilt als Hauptspeicher, der andere als Backup. Wenn alles in Ordnung ist, arbeiten wir mit dem Speicher, der uns näher ist: Das heißt, unsere Kunden, die bei Amazon sind, arbeiten mit S3, und diejenigen, die in Russland arbeiten, arbeiten mit Hotbox. Wenn das Flag ausgelöst wird, sollte eine Failover-Verbindung hergestellt werden und wir schalten die Clients auf einen anderen Speicher um. Wir können dieses Kästchen unabhängig nach Region aktivieren und zwischen ihnen wechseln. Wir haben dies noch nicht in der Praxis genutzt, aber wir haben für diesen Mechanismus gesorgt und wir glauben, dass wir genau diesen Schalter eines Tages brauchen und uns als nützlich erweisen werden. Das ist schon einmal vorgekommen.
Oh, und Amazon ist weggelaufen ...
Im April dieses Jahres jährt sich der Beginn der Telegram-Blockierung in Russland. Der am stärksten betroffene Anbieter, der darunter fiel, ist Amazon. Und leider haben russische Unternehmen, die für die ganze Welt arbeiteten, stärker gelitten.
Wenn das Unternehmen global ist und Russland mit 3-5 % nur ein sehr kleines Segment darstellt, können Sie sie auf die eine oder andere Weise opfern.
Wenn es sich um ein rein russisches Unternehmen handelt – ich bin mir sicher, dass es vor Ort ansässig sein muss –, dann ist es einfach bequem für die Benutzer selbst, komfortabel und es gibt weniger Risiken.
Was wäre, wenn es sich um ein Unternehmen handelt, das global agiert und ungefähr gleich viele Kunden aus Russland und irgendwo auf der Welt hat? Die Konnektivität der Segmente ist wichtig und sie müssen auf die eine oder andere Weise miteinander zusammenarbeiten.
Ende März 2018 schickte Roskomnadzor einen Brief an die größten Betreiber, in dem es hieß, dass sie planen, mehrere Millionen Amazon-IPs zu blockieren, um … den Zello-Messenger zu blockieren. Dank derselben Anbieter haben sie den Brief erfolgreich an alle weitergegeben, und es herrschte Einigkeit darüber, dass die Verbindung zu Amazon auseinanderbrechen könnte. Es war Freitag, wir rannten in Panik zu unseren Kollegen von Servers.ru mit den Worten: „Freunde, wir brauchen mehrere Server, die nicht in Russland, nicht bei Amazon, sondern zum Beispiel irgendwo in Amsterdam stehen.“ Um dort zumindest irgendwie unser eigenes VPN und unseren Proxy für einige Endpunkte installieren zu können, auf die wir keinen Einfluss haben, zum Beispiel Endpunkte desselben S3, können wir nicht versuchen, einen neuen Dienst zu erstellen und einen anderen zu erhalten ip, wir müssen noch dorthin gelangen. In nur wenigen Tagen haben wir diese Server eingerichtet, zum Laufen gebracht und uns im Allgemeinen auf den Moment vorbereitet, in dem die Blockierung begann. Es ist merkwürdig, dass RKN angesichts der Aufregung und Panik sagte: „Nein, wir werden jetzt nichts blockieren.“ (Aber das war genau bis zu dem Moment, als Telegram blockiert wurde.) Nachdem wir die Umgehungsfunktionen eingerichtet hatten und erkannten, dass die Blockierung nicht eingeführt worden war, begannen wir jedoch nicht damit, die ganze Angelegenheit zu klären. Ja, nur für den Fall.
Und im Jahr 2019 leben wir immer noch unter Bedingungen der Blockade. Ich habe gestern Abend nachgesehen: Etwa eine Million IPs sind weiterhin blockiert. Es stimmt, Amazon war fast vollständig entsperrt, auf dem Höhepunkt erreichte es 20 Millionen Adressen ... Im Allgemeinen ist die Realität so, dass es möglicherweise keine Kohärenz gibt, sondern gute Kohärenz. Plötzlich. Möglicherweise existiert es aus technischen Gründen nicht – Brände, Bagger usw. Oder, wie wir gesehen haben, nicht ganz technisch. Daher kann jemand Großes und Großes mit eigenen ASs dies wahrscheinlich auf andere Weise bewältigen – Direktverbindung und andere Dinge sind bereits auf der L2-Ebene. Aber in einer einfachen Version, wie unserer oder noch kleiner, können Sie für alle Fälle eine Redundanz auf der Ebene von Servern an anderer Stelle haben, vorab VPN oder Proxy konfigurieren, mit der Möglichkeit, die Konfiguration in diesen Segmenten schnell auf sie umzustellen die für Ihre Konnektivität von entscheidender Bedeutung sind. Dies kam uns mehr als einmal zugute, als die Blockierung durch Amazon begann; im schlimmsten Fall ließen wir nur S3-Verkehr durch Amazon zu, aber nach und nach wurde das alles gelöst.
Wie reserviere ich... einen ganzen Anbieter?
Im Moment haben wir kein Szenario für den Fall, dass Amazon ganz ausfällt. Wir haben ein ähnliches Szenario für Russland. In Russland wurden wir von einem Anbieter gehostet, von dem wir uns für mehrere Standorte entschieden haben. Und vor einem Jahr standen wir vor einem Problem: Obwohl es sich um zwei Rechenzentren handelt, kann es bereits auf der Ebene der Netzwerkkonfiguration des Anbieters zu Problemen kommen, die dennoch beide Rechenzentren betreffen. Und es kann sein, dass wir auf beiden Seiten nicht erreichbar sind. Natürlich ist das passiert. Am Ende haben wir die Architektur im Inneren noch einmal überdacht. Es hat sich nicht viel geändert, aber für Russland haben wir jetzt zwei Seiten, die nicht vom selben Anbieter, sondern von zwei verschiedenen Anbietern stammen. Wenn eines ausfällt, können wir zum anderen wechseln.
Hypothetisch erwägen wir für Amazon die Möglichkeit einer Reservierung auf der Ebene eines anderen Anbieters; Vielleicht Google, vielleicht jemand anderes ... Aber bisher haben wir in der Praxis beobachtet, dass es bei Amazon zwar zu Unfällen auf der Ebene einer Verfügbarkeitszone kommt, Unfälle auf der Ebene einer ganzen Region jedoch recht selten sind. Deshalb haben wir theoretisch die Idee, dass wir eine „Amazon ist nicht Amazon“-Reservierung vornehmen könnten, aber in der Praxis ist dies noch nicht der Fall.
Ein paar Worte zur Automatisierung
Ist Automatisierung immer notwendig? Hier ist es angebracht, an den Dunning-Kruger-Effekt zu erinnern. Auf der „x“-Achse steht unser Wissen und unsere Erfahrungen, die wir sammeln, und auf der „y“-Achse das Vertrauen in unser Handeln. Wir wissen zunächst nichts und sind uns überhaupt nicht sicher. Dann wissen wir ein wenig und werden mega-selbstbewusst – das ist der sogenannte „Höhepunkt der Dummheit“, gut illustriert durch das Bild „Demenz und Mut“. Dann haben wir ein wenig gelernt und sind bereit, in die Schlacht zu ziehen. Dann begehen wir einige gravierende Fehler und finden uns in einem Tal der Verzweiflung wieder, in dem wir scheinbar etwas wissen, in Wirklichkeit aber nicht viel wissen. Mit zunehmender Erfahrung werden wir dann selbstbewusster.
Unsere Logik bezüglich verschiedener automatischer Umschaltungen auf bestimmte Unfälle wird durch diese Grafik sehr gut beschrieben. Wir haben angefangen – wir wussten nicht, wie man etwas macht, fast die ganze Arbeit wurde von Hand erledigt. Dann wurde uns klar, dass wir alles automatisieren und ruhig schlafen konnten. Und plötzlich treten wir auf einen Mega-Rake: Es wird ein falsch positives Ergebnis ausgelöst und wir leiten den Verkehr hin und her, obwohl wir das im Guten nicht hätten tun sollen. Folglich bricht die Replikation zusammen oder etwas anderes – das ist das Tal der Verzweiflung. Und dann kommen wir zu der Erkenntnis, dass wir alles mit Bedacht angehen müssen. Das heißt, es ist sinnvoll, auf Automatisierung zu setzen, die die Möglichkeit von Fehlalarmen vorsieht. Aber! Wenn die Folgen verheerend sein können, ist es besser, dies dem Schichtdienst zu überlassen, den diensthabenden Ingenieuren, die sicherstellen und überwachen, dass es sich tatsächlich um einen Unfall handelt, und die erforderlichen Maßnahmen manuell durchführen ...
Abschluss
Im Laufe von 7 Jahren sind wir von der Tatsache, dass es Panik-Panik gab, wenn etwas fiel, zu der Erkenntnis gelangt, dass es keine Probleme gibt, es gibt nur Aufgaben, die gelöst werden müssen – und können. Wenn Sie einen Dienst aufbauen, betrachten Sie ihn von oben und bewerten Sie alle möglichen Risiken. Wenn Sie sie sofort sehen, dann sorgen Sie im Voraus für Redundanz und die Möglichkeit, eine fehlertolerante Infrastruktur aufzubauen, denn jeder Punkt, der ausfallen und zur Funktionsunfähigkeit des Dienstes führen kann, wird dies auf jeden Fall tun. Und auch wenn Sie den Eindruck haben, dass einige Elemente der Infrastruktur definitiv nicht ausfallen werden – wie das gleiche S3 – denken Sie dennoch daran, dass dies möglich ist. Und haben Sie zumindest theoretisch eine Vorstellung davon, was Sie mit ihnen machen werden, wenn etwas passiert. Haben Sie einen Risikomanagementplan. Wenn Sie darüber nachdenken, alles automatisch oder manuell zu erledigen, bewerten Sie die Risiken: Was passiert, wenn die Automatisierung anfängt, alles umzustellen? Führt dies nicht zu einer noch schlimmeren Situation im Vergleich zu einem Unfall? Vielleicht ist es irgendwo notwendig, einen vernünftigen Kompromiss zwischen dem Einsatz von Automatisierung und der Reaktion des diensthabenden Ingenieurs zu finden, der das tatsächliche Bild beurteilt und versteht, ob vor Ort etwas geändert werden muss oder „ja, aber nicht jetzt“.
Ein vernünftiger Kompromiss zwischen Perfektionismus und echtem Aufwand, Zeit und Geld, die Sie für das Projekt aufwenden können, das Sie letztendlich haben werden.
Dieser Text ist eine aktualisierte und erweiterte Version des Berichts von Alexander Demidov auf der Konferenz .
Source: habr.com