Get best of the week

Die Geschichte des Dodo-Vogels aus der Gattung Phoenix. Der große Fall von Dodo IS

Jedes Jahr am 21. April erinnern wir uns an die Geschichte des großen Falls von Dodo IS im Jahr 2018. Die Vergangenheit ist ein grausamer, aber fairer Lehrer. Es lohnt sich, sich daran zu erinnern, die Lektionen zu wiederholen, das gesammelte Wissen an neue Generationen weiterzugeben und dankbar auf das zu verweisen, was wir geworden sind. Unter dem Schnitt möchten wir Ihnen eine Geschichte darüber erzählen und Schlussfolgerungen teilen. Sie können dem Feind nicht einmal eine solche Situation wünschen.




Große Herbstgeschichte


Tag 1. Der Unfall, der uns Millionen Rubel gekostet hat


Am Samstag, den 21. April 2018, fiel das Dodo IS-System aus. Fiel sehr schlecht. Mehrere Stunden lang konnten unsere Kunden weder über die Website noch über die mobile Anwendung eine Bestellung aufgeben. Die Anzahl der Anrufe beim Call Center ist so hoch geworden, dass die automatische Stimme des Anrufbeantworters sagt: "Wir rufen in 4 Stunden zurück."



An diesem Tag erlebten wir einen der schwersten Stürze von Dodo IS. Das Schlimmste war, dass wir am Tag zuvor die erste TV-Werbekampagne des Bundes mit einem Budget von 100 Millionen Rubel gestartet haben. Es war eine großartige Veranstaltung für Dodo Pizza. Das IT-Team war auch gut auf die Kampagne vorbereitet. Wir haben die Bereitstellung automatisiert und vereinfacht - jetzt können wir mit Hilfe einer einzigen Schaltfläche in TeamCity einen Monolithen in 12 Ländern bereitstellen. Wir haben nicht alles Mögliche getan und es deshalb vermasselt.

Die Werbekampagne war unglaublich. Wir haben 100-150 Bestellungen pro Minute erhalten. Das waren gute Nachrichten. Die schlechte Nachricht: Dodo IS konnte einer solchen Belastung nicht standhalten und starb. Wir haben die Grenze der vertikalen Skalierung erreicht und konnten keine Bestellungen mehr bearbeiten. Das System war etwa drei Stunden lang instabil und erholte sich regelmäßig, fiel jedoch sofort wieder ab. Jede Minute Ausfallzeit kostete uns Zehntausende Rubel, ohne den Respektverlust verärgerter Kunden zu berücksichtigen. Das Entwicklungsteam hat alle im Stich gelassen: Kunden, Partner, Leute in Pizzerien und ein Callcenter.



Wir hatten keine andere Wahl, als die Ärmel hochzukrempeln und uns hinzusetzen, um die Situation zu korrigieren. Seit Sonntag (22. April) haben wir im harten Modus gearbeitet, wir hatten nicht das Recht, einen Fehler zu machen.

Das Folgende ist unsere Zusammenfassung der Erfahrungen, wie wir uns in einer solchen Situation befinden und wie wir später daraus herauskommen können. Freunde, macht keine Fehler.

Zwei Fehler, die den Domino-Effekt ausgelöst haben


Es lohnt sich, damit zu beginnen, wie alles begann und wo wir es vermasselt haben.



Am Samstag, den 21.04.2008, gegen 17:00 Uhr, stellten wir fest, dass die Anzahl der Sperren in der Datenbank zu steigen begann - ein Vorbote von Problemen. Wir hatten ein Runbook bereit zu lösen, da wir verstanden hatten, woher diese Schlösser kamen.

Alles lief schief, nachdem das Runbook zweimal fehlgeschlagen war. Für ein paar Minuten normalisierte sich die Basis wieder und begann dann wieder, an Schlössern zu ersticken. Leider hatte die Master-Datenbank rollback_on_timeout 600 Sekunden, weshalb sich alle Sperren angesammelt haben. Dies ist die erste wichtige Datei in dieser Geschichte. Ein einfaches Setup könnte alles speichern.

Dann gab es Versuche, das System auf viele Arten wieder zum Leben zu erwecken, von denen keine erfolgreich war. Bis wir feststellten, dass es einen Unterschied im Schema des Auftragseingangs in der mobilen Anwendung und auf der neuen Website gibt. Nachdem wir sie der Reihe nach gekürzt hatten, konnten wir verstehen, wo sich die Löcher im alten Bestellschema befinden.

Das Auftragsannahme-System wurde vor langer Zeit geschrieben. Zu diesem Zeitpunkt wurde es bereits verarbeitet und auf der neuen Website dodopizza.ru eingeführt. Es wurde nicht in der mobilen Anwendung verwendet. Anfänglich waren die Gründe für die Schaffung eines neuen Bestellschemas rein geschäftliche Regeln, Leistungsprobleme standen nicht einmal auf der Tagesordnung. Dies ist die zweite wichtige Datei - wir kannten die Grenzen unseres Systems nicht.

Tag 2. Unfallbeseitigung


Die Reaktion des Teams war sehr aufschlussreich. Unsere Tankstelle schrieb einen Beitrag über Slack, und alle kamen am nächsten Tag - am 22. April begannen die Arbeiten um 8:30 Uhr morgens. Niemand musste überredet oder gebeten werden, an seinem freien Tag zu kommen. Jeder hat alles verstanden: Was unterstützt werden muss, hilft mit seinen Händen, mit seinem Kopf beim Testen, bei der Abfrageoptimierung und bei der Infrastruktur. Einige kamen sogar mit der ganzen Familie! Die Leute aus benachbarten Teams, die nichts mit IT zu tun hatten, kamen mit Essen ins Büro, und das Callcenter brachte für alle Fälle zusätzliche Kräfte mit. Alle Teams vereint in einem einzigen Ziel - aufzusteigen!



Ein neuer Empfang des Ordens war das Hauptziel am Sonntag, den 22. April. Wir haben verstanden, dass der Höchststand der Bestellungen mit dem Samstag vergleichbar wäre. Wir hatten die strengste Frist - um 17 Uhr wird eine neue Flut von Bestellungen fallen.

An diesem Tag handelten wir gemäß dem Plan „um sicherzustellen, dass er nicht fällt“, den wir am Vorabend des 21. Tages am späten Abend ausgearbeitet hatten, als wir das System bereits angehoben und verstanden hatten, was passiert war. Der Plan wurde bedingt in zwei Teile geteilt:

  1. Implementierung des Schemas mit einer neuen Reihenfolge in der mobilen Anwendung.
  2. Optimierung des Auftragserstellungsprozesses.

Durch die Implementierung dieser Dinge können wir sicher sein, dass Dodo IS nicht fallen wird.

Wir bestimmen die Front von Arbeit und Arbeit


Die Implementierung des Schemas mit einer neuen Bestellung in einer mobilen Anwendung hatte höchste Priorität. Wir hatten keine genauen Zahlen für das gesamte Schema, aber in einigen Teilen, der Anzahl und Qualität der Abfragen an die Datenbank, haben wir fachmännisch verstanden, dass dies zu einer Steigerung der Produktivität führen würde. Ein Team von 15 Personen arbeitete Tag für Tag an der Aufgabe.

Obwohl in der Tat die Einführung eines neuen Bestellschemas, haben wir vor dem Herbst vom 04.21 begonnen., Aber den Deal nicht abgeschlossen. Es gab immer noch aktive Fehler und die Aufgabe hing in einem halbaktiven Zustand.

Das Team teilte die Regression in Teile auf: Regression von zwei mobilen Plattformen plus Pizzeria-Management. Wir haben viel Zeit manuell damit verbracht, Test-Pizzerien vorzubereiten, aber eine klare Trennung half dabei, die manuelle Regression zu parallelisieren.

Sobald eine Änderung eingeführt wurde, wurde sie sofort in der Vorproduktionsumgebung bereitgestellt und sofort getestet. Das Team war immer in Kontakt miteinander, sie saßen wirklich nur in einem großen Raum mit Treffpunkten. Die Jungs von Nischni Nowgorod und Syktyvkar waren auch immer in Kontakt. Wenn es einen Stecker gab, entschied er sich sofort.

Normalerweise bringen wir schrittweise neue Funktionen heraus: 1 Pizzeria, 5 Pizzerien, 10 Pizzerien, 20 Pizzerien usw. schrittweise im gesamten Netzwerk. Dieses Mal mussten wir entschlossener handeln. Wir hatten keine Zeit - um 17 Uhr begann ein neuer Höhepunkt. Wir konnten es einfach nicht verfehlen, es zu fangen.

Gegen 15:00 Uhr wurde das Update auf die Hälfte des Netzwerks übertragen (dies sind ungefähr 200 Pizzerien). Um 15:30 Uhr stellten wir sicher, dass alles gut funktionierte und schalteten das gesamte Netzwerk ein. Funktionenumschaltungen, schnelle Bereitstellungen, in Teile zerlegte Regression und eine feste API halfen dabei.

Der Rest des Teams befasste sich beim Erstellen eines Auftrags mit verschiedenen Optimierungsoptionen. Das neue Schema war nicht ganz neu, es verwendete immer noch den alten Teil. Adressen speichern, Aktionscodes anwenden, Bestellnummern generieren - diese Teile waren und sind üblich. Ihre Optimierung wurde entweder darauf reduziert, die SQL-Abfragen selbst neu zu schreiben oder sie im Code zu entfernen oder ihre Aufrufe zu optimieren. Etwas ging in den asynchronen Modus, etwas, wie sich herausstellte, wurde mehrmals anstelle von einem aufgerufen.

Das Infrastruktur-Team hat sich verpflichtet, einen Teil der Komponenten getrennten Instanzen zuzuweisen, um die Last nicht zu überschreiten. Unsere Hauptproblemkomponente war die Legacy-Fassade, die zur Legacy-Basis führte. Alle Arbeiten waren ihm gewidmet, einschließlich der Aufteilung der Instanzen.

Organisieren Sie den Prozess


Am Morgen hatten wir die einzige Synchronisation des Tages, brachen in Teams auf und gingen zur Arbeit.

Zuerst haben wir das gesamte Protokoll der Änderungen und Aufgaben direkt in Slack geführt, da es zunächst nicht so viele Aufgaben gab. Aber ihre Zahl wuchs, und so zogen wir schnell nach Trello. Die konfigurierte Integration zwischen Slack und Trello hat jede Statusänderung im Puzzle gemeldet.

Darüber hinaus war es uns wichtig, das gesamte Produktionsänderungsprotokoll zu sehen. Die elektronische Version befand sich in Trello, die Backup-Version befand sich in Form von Karten auf der Infrastrukturplatine. Für den Fall, dass etwas schief gehen sollte, mussten wir schnell herausfinden, welche Änderungen rückgängig gemacht werden müssen. Die vollständige Regression galt nur für das Schema mit einer neuen Reihenfolge, der Rest der Änderungen wurde loyaler getestet.

Die Aufgaben flogen mit hoher Geschwindigkeit zur Produktion. Insgesamt haben wir das System an diesem Tag 15 Mal aktualisiert. Den Jungs wurden Teststände eingesetzt, einer pro Team. Entwicklung, schnelle Überprüfung, Bereitstellung in der Produktion.

Neben dem Haupt-CTO-Prozess traf Sasha Andronov ständig auf Teams mit der Frage „Wie kann man helfen?“. Dies half, die Bemühungen neu zu verteilen und keine Zeit zu verlieren, weil jemand nicht daran dachte, um Hilfe zu bitten. Semi-manuelles Entwicklungsmanagement, ein Minimum an Ablenkungen und Arbeit bis an die Grenzen.

Nach diesem Tag war es notwendig, mit dem Gefühl auszugehen, dass wir alles getan haben, was wir konnten. Und noch mehr. Und wir haben es geschafft! Um 15:30 Uhr wurde ein neues Schema für den Empfang einer Bestellung für eine mobile Anwendung im gesamten Netzwerk eingeführt. Hackathon-Modus, unter 20 Bereitstellungen pro Produktion und Tag!

Der Abend des 22. April war ruhig und klar. Weder Stürze noch ein einziger Hinweis ist, dass das System möglicherweise schlecht ist.

Gegen 22 Uhr versammelten wir uns wieder und skizzierten einen wöchentlichen Aktionsplan. Einschränkung, Leistungstests, asynchrone Reihenfolge und vieles mehr. Es war ein langer Tag und es standen lange Wochen bevor.

Wiedergeburt


Die Woche vom 23. April war höllisch. Danach sagten wir uns, dass wir unser Bestes zu 200% gegeben und alles getan hatten, was wir konnten.

Wir mussten Dodo IS retten und beschlossen, eine medizinische Analogie anzuwenden. Im Allgemeinen ist dies der erste reale Fall der Verwendung einer Metapher (wie in der ursprünglichen XP), die wirklich dazu beigetragen hat, zu verstehen, was geschah:

  • Wiederbelebung - wenn Sie einen sterbenden Patienten retten müssen.
  • Behandlung - wenn Symptome vorliegen, der Patient aber noch lebt.




Reanimation


Die erste Stufe der Wiederbelebung ist das Standard-Runbook zur Wiederherstellung des Systems im Falle eines Ausfalls gemäß einigen Parametern. Eine Sache ist gefallen - wir tun es, diese ist gefallen - wir tun es und so weiter. Im Falle eines Absturzes finden wir schnell das gewünschte Runbook, alle liegen auf GitHub und sind nach Problemen strukturiert.

Die zweite Stufe der Wiederbelebung ist die Beschränkung von Bestellungen. Wir haben diese Praxis aus unseren eigenen Pizzerien übernommen. Wenn viele Bestellungen in der Pizzeria abgeladen werden und sie verstehen, dass sie sie nicht schnell kochen können, stehen sie 5 Minuten lang im Stopp. Nur um die Bestellposition zu löschen. Wir haben ein ähnliches Schema für Dodo IS erstellt. Wir haben beschlossen, dass wir, wenn es wirklich schlimm wird, das allgemeine Limit aktivieren und den Kunden sagen, Jungs, Jungs, 5 Minuten, und wir werden Ihre Bestellung entgegennehmen. Wir haben diese Maßnahme für alle Fälle entwickelt, sie jedoch nie angewendet. Nicht nützlich. Und nett.

Behandlung


Um mit der Behandlung beginnen zu können, muss eine Diagnose gestellt werden. Daher haben wir uns auf Leistungstests konzentriert. Ein Teil des Teams sammelte mit GoReplay ein echtes Lastprofil aus der Produktion. Ein Teil des Teams konzentrierte sich auf synthetische Tests auf der Bühne.

Synthesetests spiegelten nicht das tatsächliche Lastprofil wider, gaben jedoch Anlass zu Verbesserungen und zeigten einige Schwachstellen im System. Kurz zuvor haben wir beispielsweise den MySQL-Connector von Oracle auf einen neuen verschoben . In der Version des Connectors gab es einen Fehler bei Pooling-Sitzungen, der dazu führte, dass die Server einfach an die Decke der CPU gingen und keine Anfragen mehr bedienten. Wir haben dies mit Bühnentests reproduziert, konzipiert und sind leise in Produktion gegangen. Es gab ein Dutzend solcher Fälle.

Wenn sie die Ursachen der Probleme diagnostizieren und identifizieren, werden sie punktuell korrigiert. Wir haben ferner verstanden, dass unser idealer Weg der asynchrone Empfang einer Bestellung ist. Wir haben begonnen, es in einer mobilen Anwendung einzuführen.

Höllenwochen: Prozessorganisation


Ein Team von 40 Mitarbeitern arbeitete an einem einzigen großen Ziel - der Stabilisierung des Systems. Alle Teams haben zusammengearbeitet. Sie wissen nicht, was Sie tun sollen? Helfen Sie anderen Teams. Die Konzentration auf bestimmte Ziele half dabei, nicht besprüht zu werden und keinen Unsinn zu machen, der für uns unnötig war.



Dreimal am Tag gab es eine Synchronisation, ein übliches Stand-up wie bei einem klassischen Scrum. Für 40 Personen. Nur zweimal in drei Wochen (für fast 90 Synchronisierungen) trafen wir uns nicht 30 Minuten. Die längste Synchronisierung dauerte 57 Minuten. Obwohl sie normalerweise 20-30 Minuten dauerten.

Das Ziel der Synchronisierungen: zu verstehen, wo Hilfe benötigt wird und wann wir diese oder jene Aufgaben in die Produktion bringen werden. Die Jungs schlossen sich in Projektteams zusammen, wenn sie die Hilfe der Infrastruktur brauchten, kam eine Person genau dort, alle Probleme wurden schnell gelöst, weniger Diskussion war mehr eine Frage.

Abends bereitete unser Forschungs- und Entwicklungslabor Essen für die Entwickler für den Abend vor, um die Jungs zu unterstützen. Verrückte Pizzarezepte, Hühnerflügel, Kartoffeln! Das war unwirklich cool! Diese Unterstützung hat die Jungs so sehr wie möglich motiviert.



In einem solchen Non-Stop-Modus zu arbeiten war verdammt schwierig. Am Mittwoch, dem 25. April, gegen 17 Uhr, wandte sich Oleg Blokhin, einer unserer Entwickler, an CTO, der am Samstag ohne Unterbrechung gerechnet hat. In seinen Augen lag unmenschliche Müdigkeit: "Ich bin nach Hause gegangen, ich kann es nicht mehr ertragen." Er schlief gut und am nächsten Tag war herzhaft. So kann man den Allgemeinzustand vieler Leute beschreiben.

Der nächste Samstag, der 28. April (es war ein Arbeitssamstag für alle in Russland) war ruhiger. Wir konnten nichts ändern, wir haben das System beobachtet, die Jungs haben sich ein wenig vom Tempo ausgeruht. Alles verlief leise. Die Ladung war nicht so groß, aber es war. Sie überlebten ohne Probleme, und dies gab Vertrauen, dass wir den richtigen Weg gingen.

Die zweite und dritte Woche nach dem Sturz waren bereits ruhiger, das höllische Tempo bis zum späten Abend war vorbei, aber der allgemeine Prozess des Kriegsrechts blieb bestehen.

Nächster Tag X: Krafttest


Am nächsten Tag war X am 9. Mai! Jemand saß zu Hause und überwachte den Status des Systems. Diejenigen von uns, die spazieren gingen, nahmen Laptops mit, um voll bewaffnet zu sein, wenn etwas schief ging. Sasha Andronov, unsere Tankstelle, ging näher an den Abendgipfel einer der Pizzerien heran, um bei Problemen alles persönlich zu sehen.

An diesem Tag erhielten wir 91500 Bestellungen in Russland (zu dieser Zeit das zweite Ergebnis in der Geschichte des Dodo). Es gab nicht den geringsten Hinweis auf ein Problem. Der 9. Mai hat bestätigt, dass wir auf dem richtigen Weg sind! Fokus auf Stabilität, Leistung, Qualität. Die Prozessumstrukturierung hat uns weiter erwartet, aber das ist eine ganz andere Geschichte.

Retro Great Fall und 6 Praktiken


In kritischen Situationen werden bewährte Verfahren entwickelt, die auf eine ruhige Zeit übertragen werden können und sollten. Fokussierung, teamübergreifende Hilfe, schnelle Bereitstellung in der Produktion, ohne auf eine vollständige Regression zu warten. Wir haben mit Retro begonnen und dann das Prozess-Framework entwickelt.



Die ersten beiden Tage vergingen in einer Diskussion über Praktiken. Wir haben uns nicht das Ziel gesetzt, "um 2 Uhr eine Retrospektive zu machen". Nach einer solchen Situation waren wir bereit, uns die Zeit zu nehmen, um unsere Ideen und unseren neuen Prozess im Detail zu erarbeiten. Alle haben teilgenommen. Jeder, der auf die eine oder andere Weise an den Restaurierungsarbeiten beteiligt war.



Infolgedessen gab es 6 wichtige Praktiken, über die ich ausführlicher sprechen möchte.

  1. Top N . , . Product Owners , , , . . , . , , , . , . N – Lead Time .
  2. . . -, , . , , , . .
  3. . , « » . , . , , . , - . Dodo IS. .
  4. Pull Request. , Pull Request, - . . , , , , - . , . , . 15 .
  5. Performance- — . performance- . , . Performance- . baseline , PR . , .
  6. Performance . — . , , -, , , . . , .



1.

21.04.2018 – Dodo IS. ?


(Site Reliability Engineering): . , .

(Site Reliability Engineering, Product Owner Dodo IS): . , , .

auth’, . . , .

, () :



. , .

. , . . -. , , . - , , . , -, , .

. redis, . . - , . .

Dodo IS . . , . , , , , . , — .

. « ». « , » .

- ?


:

– . . . , . . .

:

. , . ( ), - . .

. :

  1. .
  2. .
  3. , .

?



:

, , , .

:

, , . , .

? ?



: , – .

:

  1. — . - - .

    , . 2018 , PerformanceLab, .
  2. , . Less-.
  3. . 2018 -, . , . - 2018 .
  4. async . , 21.04.2018 . , . async.
  5. . , SaveOrder async-await. , . : , LF, 20 . , . , . !

    , , , .

    , , . — -. .
  6. . , (, ). , . «» . nginx , - , .

    : innodb_lock_wait_timeout = 5; innodb_rollback_on_timeout = ON. . , , , , .

, ?


:

  1. , , , . , .
  2. , .
  3. , , , . – .

:

  1. .
  2. . , , -. .
  3. . , - , .

, ?


:

«» , «». , , . .

:

, . , , . .

2. , (Dodo IS Architect)
— , . , — .

, , . , (, , ) .

IT-. Dodo IS, . …

X , . . Dodo IS , , , . , , , . . 146%, . , Dodo IS ?

, . , , . , . , !

, . « »: 11- , , 2 . «» . 3-4 , . , . .

, , . . Dodo IS , « ». ! ( ).

, Dodo IS , . Dodo IS . « », , . ( ), loadtest, , .

More articles:


All Articles