Citymobil - ein Handbuch zur Verbesserung der Verfügbarkeit bei Unternehmenswachstum für Startups. Teil 5

Dies ist der letzte Teil der Serie, in dem beschrieben wird, wie wir unsere Serviceverfügbarkeit in Citymobil erhöhen (den vorherigen Teil können Sie hier lesen). Jetzt werde ich über eine weitere Art von Ausfällen und die Schlussfolgerungen sprechen, die wir daraus gezogen haben, wie wir den Entwicklungsprozess geändert haben und welche Automatisierung wir eingeführt haben.

1. Schlechte Veröffentlichung: Fehler

Dies ist die unangenehmste Art von Ausfällen und Zwischenfällen. Die einzige Art, die außer Beschwerden von Endbenutzern oder Geschäftsbenutzern keine sichtbaren Symptome aufweist. Deshalb kann ein solcher Vorfall, insbesondere ein kleiner, in der Produktion eine Weile unbemerkt bleiben.

Alle anderen Arten von Ausfällen ähneln mehr oder weniger "Bad Release: 500 interne Serverfehler". Das einzige ist, dass sie nicht durch eine Freigabe ausgelöst werden, sondern durch eine Arbeitslast, einen manuellen Betrieb oder ein externes Serviceproblem.

Um die Methode zu beschreiben, mit solchen Ausfällen umzugehen, sollten wir uns an einen alten Witz erinnern:

Ein Mathematiker und ein Physiker haben die gleiche Aufgabe: Wasser zu kochen. Sie erhalten einige Hilfsmittel: einen Herd, einen Wasserkocher, einen Wasserhahn mit Wasser, Streichhölzer. Beide füllen abwechselnd den Wasserkocher mit Wasser, schalten Gas ein und heizen den Wasserkocher auf. Dann wird die Aufgabe vereinfacht: Sie erhalten einen mit Wasser gefüllten Wasserkocher und einen bereits eingeschalteten Herd. Die Aufgabe ist die gleiche - Wasser kochen. Der Physiker stellt den Wasserkocher auf den Herd. Der Mathematiker leert den Wasserkocher, stellt das Gas ab und sagt: "Das Problem ist auf ein Problem reduziert, das bereits gelöst wurde." © anekdotov.net

Diese Art von Ausfall muss um jeden Preis auf "Bad Release: 500 interne Serverfehler" reduziert werden. Im Idealfall sollten Fehler genauso wie 500 Fehler protokolliert werden. Natürlich können Sie das Ereignis eines Fehlers nicht protokollieren, da Sie sonst keinen Fehler machen würden, wenn Sie könnten.

Eine der Ideen, um einen Fehler zu verfolgen, besteht darin, nach Spuren in der Datenbank zu suchen. Mithilfe dieser Traces können wir feststellen, dass ein Fehler vorliegt, und Warnungen senden. Wie können wir dazu beitragen? Wir haben begonnen, jeden großen Fehler zu untersuchen und Lösungen zu finden: Welche Art von Überwachung / SMS-Alarmierung kann erstellt werden, damit sich dieser Fehler sofort als 500-Fehler herausstellt? Hier sind einige Beispiele.

1.1. Beispiel für einen Ausfall aufgrund eines Fehlers

Plötzlich erhielten wir eine Vielzahl von Beschwerden von unseren Nutzern: Bestellungen, die über Apple Pay bezahlt wurden, konnten nicht geschlossen werden. Wir haben mit unseren Ermittlungen begonnen. Das Problem wurde in der Testumgebung reproduziert. Die Hauptursache wurde gefunden: Wir haben das Format des Ablaufdatums für Kreditkarten aktualisiert, da es von einem Zahlungsverarbeitungsdienst geändert wurde, aber wir haben es für Zahlungen über Apple Pay nicht korrekt ausgeführt. Daher wurden alle Apple Pay-Zahlungen abgelehnt. Wir haben es behoben, sobald wir über das Problem Bescheid wussten, es bereitgestellt und das Problem war behoben. Dieses Problem war jedoch 45 Minuten lang aktiv.

Infolge dieses Problems haben wir eine Reihe nicht erfolgreicher Apple Pay-Zahlungen überwacht und SMS- und IVR-Warnungen mit einem Schwellenwert ungleich Null erstellt (da einige nicht erfolgreiche Zahlungen vom Dienst als normal angesehen werden, z. B. wenn ein Kunde kein Geld auf seinem Konto hat oder ihre Kreditkarte ist gesperrt). Seit diesem Moment würden wir sofort von der Schwellenüberschreitung erfahren. Wenn eine neue Version Probleme bei der Apple Pay-Verarbeitung verursacht, werden wir dies aufgrund der Überwachung sofort feststellen und die Version innerhalb von 3 Minuten zurücksetzen (der Vorgang des manuellen Rollbacks ist in einem der vorherigen Artikel beschrieben). Früher waren es 45 Minuten Teilausfallzeit, jetzt sind es 3 Minuten. Gewinn!

1.2. Andere Beispiele

Ein Fehler in der Bestellliste. Wir haben eine Optimierung der Auftragsliste in der Treiber-App implementiert. Der Code hatte einen Fehler. Infolgedessen sahen die Fahrer manchmal die leere Bestellliste. Wir haben zufällig von diesem Fehler erfahren: Einer der Ingenieure spielte mit der Treiber-App und stieß auf dieses Problem. Wir haben die schlechte Version schnell identifiziert und sie wurde sofort zurückgesetzt. Aus diesem Grund haben wir basierend auf den Informationen aus der Datenbank ein Diagramm mit einer durchschnittlichen Anzahl von Bestellungen in der Liste erstellt. Dann haben wir uns diese Grafik von Monat zu Monat nachträglich angesehen. Wir haben kürzlich eine durch diesen Fehler verursachte Schlucht bemerkt und über eine SQL-Abfrage eine SMS-Warnung erstellt. Dieses Diagramm wird erstellt, wenn eine durchschnittliche Anzahl von Bestellungen in der Liste den unteren Schwellenwert überschreitet, der basierend auf dem Minimum für den aktuellen Monat festgelegt wurde.

Ein Fehler im Cachback. Wir haben die Cashback-Werbelogik des Benutzers geändert. Unter anderem haben wir es an die falsche Kundengruppe gesendet. Das Problem wurde behoben, der Graph des verschenkten Cashbacks wurde erstellt; Wir haben einen drastischen Anstieg festgestellt und festgestellt, dass dies noch nie zuvor passiert ist, und eine SMS-Warnung mit einem angemessenen Schwellenwert erstellt.

Wieder ein Fehler bei den Zahlungen. Die neue Version verursachte den Fehler - es würde ewig dauern, eine Bestellung aufzugeben, die Kartenzahlung funktionierte nicht, die Fahrer forderten die Kunden auf, in bar zu bezahlen. Wir haben das Problem durch Beschwerden im Call Center herausgefunden. Wir haben einen Fix bereitgestellt und eine Warnung für die Schließzeit von Bestellungen mit Schwellenwerten erstellt, die über die Analyse historischer Diagramme ermittelt wurde.

Wie Sie sehen, verwenden wir denselben Ansatz für die Behandlung aller Vorfälle dieser Art:

1. Wir erfahren etwas über ein Problem.
2. Wir beheben das Problem und finden einen Fehler im Code.
3. Wir reparieren es.
4. Wir ermitteln die Traces in der Datenbank (auch Traces finden Sie in Webserver-Protokollen oder in Kibana), die auf die Anzeichen des Problems hinweisen können.
5. Wir erstellen ein Diagramm dieser Spuren.
6. Wir gehen in die Vergangenheit und betrachten die Höhen und Tiefen in der Grafik.
7. Wir wählen einen guten Schwellenwert für eine Warnung.
8. Wenn das Problem erneut auftritt, werden wir sofort per SMS darüber informiert.

Was ist gut an dieser Methode: Ein Diagramm und eine Warnung lösen die gesamte große Gruppe von Problemen (Beispiele für Problemgruppen: Bestellungen können nicht geschlossen werden, zusätzliche Boni, Apple Pay-Zahlungen werden nicht ausgeführt usw.)

Schließlich haben wir als Teil unserer Engineering-Kultur Warnungen und Überwachung für jeden großen Fehler implementiert. Um diese Kultur nicht zu verlieren, haben wir sie nur ein wenig formalisiert. Wir zwangen uns, für jeden Ausfall einen Bericht zu erstellen. Der Bericht ist ein Formular, das mit Antworten auf die folgenden Fragen ausgefüllt ist: Grundursache, wie wir ihn behoben haben, Auswirkungen auf das Geschäft, Imbissbuden. Alle Felder sind obligatorisch. Wir mussten also feststellen, ob es uns gefallen hat oder nicht. Diese Prozessänderung wurde offensichtlich in Do's und Don't's niedergeschrieben.

2. Kotan

Unser Prozessautomatisierungsgrad stieg und wir entschieden, dass es Zeit war, eine Weboberfläche zu erstellen, die den aktuellen Status des Entwicklungsprozesses anzeigt. Wir haben dieses Webinterface "Kotan" genannt (vom russischen Wort "roll", "ausrollen" :-)

"Kotan" hat folgende Funktionalität:

Liste der Vorfälle . Es enthält die Liste aller in früheren Warnungen ausgelösten Ereignisse - je nachdem, was eine sofortige menschliche Reaktion erfordert. Für jeden Vorfall registrieren wir die Zeit, zu der er gestartet wurde, die Zeit, zu der er beendet war (falls er bereits beendet ist), einen Link zu einem Bericht (wenn der Vorfall beendet ist und ein Bericht vorliegt) und den Link zum Warnleitfaden, um zu sehen, welche Art von Warnung dieser Vorfall ist gehört zu.

Das Warnungsverzeichnis . Dies ist praktisch eine Liste aller Warnungen. Um es klarer zu machen, ist der Unterschied zwischen einer Warnung und einem Vorfall der folgende: Die Warnung ist wie eine Klasse, während der Vorfall - ein Objekt ist. Beispiel: "Anzahl von 500 Fehlern ist größer als 1" ist die Warnung. Und "die Anzahl von 500 Fehlern ist größer als 1 und sie sind an diesem Datum aufgetreten, zu diesem Zeitpunkt haben sie so lange gedauert" - ist ein Vorfall. Jede Warnung wird dem System manuell durch den oben beschriebenen Prozess hinzugefügt, nachdem ein bestimmtes Problem behoben wurde, das vom Warnsystem noch nie zuvor erkannt wurde. Ein solcher iterativer Ansatz garantiert ein geringes Risiko für falsch positive Warnungen (die keine Maßnahmen erfordern). Das Verzeichnis enthält einen vollständigen Berichtsverlauf für jede Art von Warnung. Das hilft, ein Problem schneller zu diagnostizieren: Sie erhalten eine Benachrichtigung, gehen zu "Kotan", klicken auf das Verzeichnis, überprüfen den gesamten Verlauf und erhalten eine Vorstellung davon, wo Sie tauchen können. Ein Schlüssel zur erfolgreichen Fehlerbehebung ist die Verfügbarkeit aller Informationen. Der Link zum Alert-Quellcode (um sicher zu sein, über welche Situation dieser Alert Sie informiert). Eine schriftliche Beschreibung der derzeit besten Methoden zur Bekämpfung dieser Warnung.

Berichte Dies sind alle Berichte in der Geschichte. Jeder Bericht enthält Links zu allen Vorfällen, mit denen er verknüpft ist (manchmal treten die Vorfälle in Gruppen auf; die Hauptursache ist dieselbe, und wir erstellen einen Bericht für die gesamte Gruppe), das Datum, an dem dieser Bericht verfasst wurde, das Bestätigungsflag für die Problemlösung und die meisten anderen Wichtig: die Grundursache, wie sie behoben wurde, Auswirkungen auf das Geschäft, Imbissbuden.

Liste der Imbissbuden . Jeder Imbiss hat eine Notiz, aus der hervorgeht, ob er implementiert wurde, noch implementiert wird oder nicht (mit einer Erklärung, warum nicht).

3. Was hat sich im Softwareentwicklungsprozess geändert?

Eine kritische Komponente zur Verbesserung der Verfügbarkeit ist ein Softwareentwicklungsprozess. Der Prozess ändert sich ständig. Das Ziel solcher Änderungen ist es, die Wahrscheinlichkeit von Vorfällen zu verringern. Die Entscheidungen zur Änderung des Prozesses sollten nicht abstrakt getroffen werden, sondern auf Erfahrungen, Fakten und Zahlen beruhen. Der Prozess darf nicht direkt nach unten aufgebaut werden, sondern von unten nach oben, wobei alle Teammitglieder aktiv teilnehmen, da viele Leiter des gesamten Teams besser sind als ein Leiter eines Managers. Der Prozess muss verfolgt und überwacht werden. Ansonsten macht es keinen Sinn, es zu haben. Die Teammitglieder müssen sich im Falle von Abweichungen gegenseitig korrigieren: Wer würde es sonst für sie tun? Es muss eine maximale Automatisierung geben, die sich um die Hauptfunktionen kümmert, da ein Mensch ständig Fehler macht, insbesondere bei kreativer Arbeit.

Um sicherzugehen, dass jeder Vorfall zum Mitnehmen ist, haben wir Folgendes getan:

• Jede Warnung blockiert automatisch die Releases.
• Wenn wir eine Abschlussbenachrichtigung erhalten (eine Textnachricht, die besagt, dass der Vorfall beendet ist), entsperren wir die Veröffentlichungen nicht sofort, sondern bieten stattdessen an, einen Unfallbericht zu erstellen.
• Ein Bericht muss die folgenden Informationen enthalten: die Grundursache eines Unfalls, wie er behoben wurde, geschäftliche Auswirkungen, Imbissbuden.
• Der Bericht wurde von dem Team verfasst, das den Unfall behoben hat. Diejenigen, die mit den vollständigen Informationen über den Unfall bewaffnet sind.
• Releases werden automatisch blockiert, bis ein solcher Bericht erstellt und genehmigt wird. Das motiviert das Team, sich schnell zu konzentrieren und direkt nach der Behebung eines Unfalls einen Bericht zu erstellen.
• Der Bericht muss von jemandem genehmigt werden, der nicht im Team ist, um sicherzustellen, dass der Bericht alle Informationen enthält, die zum Verständnis erforderlich sind.

Auf diese Weise haben wir einerseits Selbstdisziplin bei der Rettung jedes Vorfalls in der Geschichte erreicht und andererseits eine automatisierte Kontrolle bereitgestellt. Es ist jetzt unmöglich, keine Schlussfolgerungen zu ziehen oder keinen Bericht zu schreiben.

4. Anstelle eines Nachworts

Lassen Sie mich anstelle eines Epilogs kurz zusammenfassen, was wir im Softwareentwicklungsprozess geändert haben, um die Anzahl der verlorenen Reisen zu verringern.


Danke fürs Lesen bis zum Ende. Viel Glück für Ihr Geschäft! Ich wünsche Ihnen weniger verlorene Bestellungen, Transaktionen, Einkäufe, Reisen und alles, was für Sie entscheidend ist!