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

Dies ist ein zweiter Artikel aus einer Reihe "Citymobil - ein Handbuch zur Verbesserung der Verfügbarkeit bei Unternehmenswachstum für Startups". Den ersten Teil können Sie hier lesen. Lassen Sie uns weiter darüber sprechen, wie wir die Verfügbarkeit von Citymobil-Diensten verbessert haben. Im ersten Artikel haben wir gelernt, wie man die verlorenen Fahrten zählt. Ok, wir zählen sie. Was jetzt? Jetzt, da wir mit einem verständlichen Instrument zur Messung der verlorenen Fahrten ausgestattet sind, können wir zum interessantesten Teil übergehen - wie verringern wir Verluste? Ohne unser derzeitiges Wachstum zu verlangsamen! Da es uns so vorkam, als ob der Löwenanteil der technischen Probleme, die den Reiseverlust verursachten, etwas mit dem Backend zu tun hatte, beschlossen wir, unsere Aufmerksamkeit zunächst auf den Backend-Entwicklungsprozess zu richten. Wenn ich vor mir selbst springe, werde ich sagen, dass wir Recht hatten - das Backend wurde zum Hauptschauplatz des Kampfes um die verlorenen Reisen.

1. Wie der Entwicklungsprozess funktioniert

Die Probleme werden normalerweise durch die Codebereitstellung und andere manuelle Aktionen verursacht. Die Dienste, die nie von Hand geändert und berührt werden, funktionieren manchmal auch nicht. Dies ist jedoch eine Ausnahme, die nur die Regel bestätigt.

Nach meiner Erfahrung war die interessanteste und ungewöhnlichste Ausnahme die folgende. Bereits 2006, als ich bei einem der kleinen Webmail-Dienste arbeitete, gab es ein Gateway, das den gesamten Datenverkehr übertrug und sicherstellte, dass die IP-Adressen nicht auf den schwarzen Listen standen. Der Dienst funktionierte auf FreeBSD und es funktionierte gut. Aber eines Tages hörte es einfach auf zu arbeiten. Ratet mal warum? Die Festplatte in diesem Computer ist ausgefallen (seit einiger Zeit haben sich fehlerhafte Blöcke gebildet, und das Unvermeidliche ist passiert), und dies ist drei Jahre vor dem Servicefehler geschehen. Mit der ausgefallenen Festplatte war alles am Leben. Und dann entschied sich FreeBSD aus nur sich selbst bekannten Gründen plötzlich, die ausgefallene Festplatte zu beheben, und hielt infolgedessen an.

Als ich ein Kind war, 10-12 Jahre alt, ging ich mit meinem Vater in den Wald und hörte einen Satz von ihm, den ich nie vergaß: "Alles, was Sie tun müssen, um das Lagerfeuer am Brennen zu halten, ist, es nicht zu berühren." Ich glaube, die meisten von uns können sich an eine Situation erinnern, in der wir dem bereits brennenden Feuer etwas Holz zugeführt haben und es ohne Grund erlischt.

Das Fazit ist, dass die Probleme durch manuelle Handlungen des Menschen entstehen. Zum Beispiel, wenn Sie dem bereits gut brennenden Lagerfeuer Holz zuführen und so den Sauerstoff abschneiden und das Feuer töten oder indem Sie den Code mit Fehlern in die Produktion einsetzen. Um zu verstehen, was die Serviceprobleme verursacht, müssen wir daher die Funktionsweise des Bereitstellungs- und Entwicklungsprozesses verstehen.

In Citymobil war der Prozess vollständig entwicklungsorientiert und wie folgt organisiert:

• 20-30 Veröffentlichungen pro Tag.
  
• Entwickler führen die Bereitstellung selbst durch.
  
• Schnelles Testen in der Testumgebung durch den Entwickler.
  
• Minimale automatisierte / Unit-Tests, minimale Überprüfung.
  

Die Entwickler arbeiteten unter rauen Bedingungen ohne QS-Unterstützung mit einem enormen Fluss sehr wichtiger Aufgaben aus dem Produktteam und den Experimenten. Sie arbeiteten so intensiv und konsequent wie möglich, lösten schwierige Aufgaben auf einfache Weise, stellten sicher, dass aus Code keine Spaghetti wurden, verstanden Geschäftsproblematik, behandelten Änderungen verantwortungsbewusst und machten schnell Rückgängigmachen, was nicht funktionierte. Hier gibt es nichts Neues. Bei Mail.Ru gab es vor 8 Jahren eine ähnliche Situation, als ich dort anfing zu arbeiten. Wir haben Mail.ru Cloud schnell und einfach gestartet, kein Auftakt. Wir würden unseren Prozess später ändern, um eine bessere Verfügbarkeit zu erreichen.

Ich wette, Sie haben das selbst bemerkt: Wenn es keine Hindernisse gibt, wenn es nur Sie und die Produktion sind, wenn Sie eine schwere Last der Verantwortung tragen - tun Sie Wunder. Ich habe so eine Erfahrung gemacht. Vor langer Zeit war ich so ziemlich der einzige Entwickler bei Newmail.Ru Webmail-Dienst (er wurde vor einiger Zeit erworben und dann heruntergefahren); Ich habe die Bereitstellung selbst durchgeführt und Produktionstests auch an mir selbst über if (!strcmp(username, "danikin")) { … some code… } . Ich war also mit dieser Situation vertraut.

Es würde mich nicht wundern, wenn ich herausfinden würde, dass ein solcher „schneller und schmutziger“ Ansatz von vielen erfolgreichen und nicht erfolgreichen Startups verwendet wurde, aber alle von einer Leidenschaft angetrieben - dem Wunsch nach schnellem Geschäftswachstum und Marktanteilen.

Warum hatte Citymobil einen solchen Prozess? Anfangs gab es nur sehr wenige Entwickler. Sie hatten eine Weile für das Unternehmen gearbeitet und kannten Code und Geschäft sehr gut. Der Prozess funktionierte unter diesen Bedingungen ideal.

2. Warum ist eine Verfügbarkeitsbedrohung aufgetreten?

Das Wachstum der Investitionen in die Produktentwicklung, das durch unsere Produktpläne verursacht wurde, wurde aggressiver und wir begannen, mehr Entwickler einzustellen. Die Anzahl der Bereitstellungen pro Tag nahm zu, aber natürlich nahm ihre Qualität ab, da die neuen Mitarbeiter unter Feldbedingungen in das System und das Geschäft eintauchen mussten. Die Zunahme der Anzahl der Entwickler führte nicht nur zu einem linearen, sondern auch zu einem quadratischen Rückgang der Verfügbarkeit (die Anzahl der Bereitstellungen nahm linear zu und die Qualität einer durchschnittlichen Bereitstellung ging linear zurück, sodass "linear" * "linear" = "quadratisch").

Offensichtlich konnten wir so nicht weitermachen. Der Prozess wurde einfach nicht für diese neuen Bedingungen entwickelt. Wir mussten es jedoch ohne Kompromisse bei der Markteinführung ändern. Das heißt, 20 bis 30 Veröffentlichungen pro Tag werden beibehalten (wenn man bedenkt, dass ihre Anzahl mit dem Wachstum des Teams zunehmen würde). Wir sind schnell gewachsen, haben viele Experimente durchgeführt, die Ergebnisse umgehend ausgewertet und neue Experimente durchgeführt. Wir haben schnell Produkt- und Geschäftshypothesen getestet, daraus gelernt und neue Hypothesen aufgestellt, die wir umgehend erneut getestet haben und so weiter. Unter keinen Umständen würden wir langsamer werden. Darüber hinaus wollten wir Entwickler schneller beschleunigen und einstellen. Unsere auf das Geschäftswachstum ausgerichteten Maßnahmen stellten also eine Verfügbarkeitsbedrohung dar, aber wir hatten absolut nicht die Absicht, diese Maßnahmen zu ändern.

3. Ok, die Aufgabe ist eingestellt, der Prozess ist klar. Was kommt als nächstes?

Erfahrung in der Arbeit beim Mail.Ru-E-Mail-Dienst und in der Mail.Ru-Cloud, wo die Verfügbarkeit zu einem bestimmten Zeitpunkt an erster Stelle stand, wo die Bereitstellungen einmal pro Woche stattfanden, wo alles durch automatisierte Tests und Unit-Tests abgedeckt wurde Der Code wurde mindestens einmal überprüft, aber manchmal sogar dreimal sah ich mich einer völlig anderen Situation gegenüber.

Man könnte meinen, alles sei ganz einfach: Wir könnten den Mail.Ru-E-Mail- / Cloud-Prozess bei Citymobil replizieren und so die Serviceverfügbarkeit erhöhen. Wie sie jedoch sagen - der Teufel steckt im Detail:

1. Die Bereitstellungen in Mail.Ru E-Mail / Cloud werden einmal pro Woche und nicht 30 Mal am Tag durchgeführt. Bei Citymobil wollten wir die Menge der Veröffentlichungen nicht opfern.
   
2. In Mail.Ru E-Mail / Cloud wird der Code durch Auto- / Unit-Tests abgedeckt, und wir hatten bei Citymobil weder Zeit noch Ressourcen dafür. Wir haben all unsere Backend-Entwicklungsanstrengungen in Hypothesen und Produktverbesserungstests gesteckt.
   

Trotzdem waren wir in Bezug auf Backend-Entwickler unterbesetzt, obwohl sie umgehend eingestellt wurden (ein besonderer Dank geht an die Citymobil-Personalvermittler - die besten Personalvermittler der Welt! Ich denke, es wird einen separaten Artikel über unseren Rekrutierungsprozess geben). Es gab also keine Möglichkeit, Probleme zu testen und zu überprüfen, ohne sich zu verlangsamen.

4. Wenn Sie nicht wissen, was Sie tun sollen, lernen Sie aus Fehlern

Was ist so magisch, dass wir es bei Citymobil gemacht haben? Wir haben uns entschlossen, aus Fehlern zu lernen. Die Methode zur Verbesserung des Service aus Fehlern zu lernen ist so alt wie die Zeit. Wenn das System gut funktioniert, ist es gut. Wenn das System nicht gut funktioniert, ist es auch gut, da wir aus Fehlern lernen können. Einfacher gesagt als ... Eigentlich kann es auch leicht gemacht werden. Der Schlüssel ist, ein Ziel zu setzen.

Wie haben wir gelernt? Zuerst haben wir begonnen, die Informationen über jeden einzelnen großen und kleinen Ausfall religiös aufzuschreiben. Um ehrlich zu sein, hatte ich zunächst wirklich keine Lust dazu, da ich auf ein Wunder hoffte und dachte, dass die Ausfälle einfach von selbst aufhören würden. Offensichtlich hörte nichts auf. Die neue Realität erforderte gnadenlos einige Änderungen.

Wir haben damit begonnen, alle Ausfälle in einer Google Text & Tabellen-Tabelle zu protokollieren. Für jeden Ausfall gab es folgende Kurzinformationen:

• Datum, Uhrzeit, Dauer;
  
• die Grundursache;
  
• Was wurde getan, um das Problem zu beheben?
  
• geschäftliche Auswirkungen (Anzahl verlorener Reisen, andere Ergebnisse);
  
• Imbissbuden.
  

Für jeden großen Ausfall haben wir eine separate große Datei mit einer detaillierten minutengenauen Beschreibung vom Beginn des Ausfalls bis zum Ende des Ausfalls erstellt: Was wir getan haben, welche Entscheidungen getroffen wurden. Es wird normalerweise als Obduktion bezeichnet. Wir würden die Links zu diesen Obduktionen in die allgemeine Tabelle aufnehmen.

Es gab einen Grund für die Erstellung einer solchen Datei: Schlussfolgerungen zu ziehen, die darauf abzielen, die Anzahl der verlorenen Fahrten zu verringern. Es war sehr wichtig, sehr genau zu sagen, was "die Grundursache" und was "die Imbissbuden" sind. Die Bedeutung dieser Wörter ist klar; Jeder kann sie jedoch anders verstehen.

5. Beispiel für einen Ausfall, aus dem wir gelernt haben

Die Hauptursache ist ein Problem, das behoben werden muss, um solche Unfälle in Zukunft zu vermeiden. Und Schlussfolgerungen - die Möglichkeiten, die Grundursache zu beseitigen oder die Wahrscheinlichkeit ihres Wiederauftretens zu verringern.
Die Grundursache ist immer tiefer als es scheint. Die Imbissbuden sind immer komplizierter als sie scheinen. Sie sollten niemals mit angeblich gefundenen Ursachen zufrieden sein und niemals mit angeblichen Aussagen zufrieden sein, damit Sie sich nicht entspannen und bei dem stehen bleiben, was richtig zu sein scheint. Diese Unzufriedenheit erzeugt einen Funken für die weitere Analyse.

Lassen Sie mich ein Beispiel aus der Praxis geben: Wir haben Code bereitgestellt, alles ist ausgefallen, wir haben ihn zurückgesetzt, alles hat wieder funktioniert. Was ist die Hauptursache des Problems? Sie würden sagen: Bereitstellung. Wenn Sie keinen Code bereitgestellt hätten, wäre kein Unfall aufgetreten. Also, was ist der Imbiss: keine Bereitstellungen mehr? Das ist kein sehr guter Imbiss. Also war das höchstwahrscheinlich nicht die Grundursache, wir müssen tiefer graben. Bereitstellung mit einem Fehler. Das ist die Grundursache? In Ordnung. Wie beheben wir das? Sie würden sagen, indem Sie testen. Welche Art von Tests? Zum Beispiel - vollständiger Regressionstest aller Funktionen. Dies ist ein guter Imbiss, erinnern wir uns daran. Aber wir müssen die Verfügbarkeit hier und jetzt erhöhen, bevor wir den vollständigen Regressionstest implementieren. Wir müssen noch tiefer graben. Bereitstellung mit einem Fehler, der durch Debug-Druck in der Datenbanktabelle verursacht wurde; Wir haben die Datenbank überlastet und sie ist unter der Last ausgefallen. Das klingt besser. Jetzt wurde klar, dass uns selbst ein vollständiger Regressionstest nicht vor diesem Problem bewahren wird. Da es in der Testdatenbank keine ähnliche Arbeitslast wie in der Produktionsarbeitslast gibt.

Was ist die Hauptursache für dieses Problem, wenn wir noch tiefer graben? Wir mussten mit Ingenieuren sprechen, um das herauszufinden. Es stellte sich heraus, dass sich der Ingenieur daran gewöhnt hatte, dass die Datenbank jede Arbeitslast bewältigen konnte. Aufgrund des rasanten Anstiegs der Arbeitslast konnte die Datenbank zu diesem Zeitpunkt jedoch nicht mit dem umgehen, was sie am Tag zuvor bewältigt hatte. Nur sehr wenige von uns hatten die Möglichkeit, mit einer monatlichen Wachstumsrate von 50% für die Projekte zu arbeiten. Für mich war das zum Beispiel das erste Projekt dieser Art. Nachdem Sie sich in ein solches Projekt gestürzt haben, beginnen Sie, neue Realitäten zu verstehen. Sie werden nie wissen, dass es da draußen ist, bis Sie darauf stoßen.

Der Techniker hat den richtigen Weg gefunden, um das Problem zu beheben: Der Debug-Druck muss in einer Datei erfolgen, die über ein Cron-Skript in einem Thread in die Datenbank geschrieben werden soll. Falls zu viel Debug gedruckt wird, fällt die Datenbank nicht aus. Debug-Daten werden einfach früher oder später angezeigt. Dieser Ingenieur hat offensichtlich aus seinem Fehler gelernt und wird es nicht wieder schaffen. Aber auch andere Ingenieure sollten darüber Bescheid wissen. Wie? Sie müssen erzählt werden. Wie kann man sie zum Zuhören bringen? Indem wir ihnen die ganze Geschichte von Anfang bis Ende erzählen, die Konsequenzen darlegen und eine korrekte Vorgehensweise vorschlagen; und auch durch Zuhören und Beantworten ihrer Fragen.

6. Was können wir noch aus diesem Fehler oder "Do's & Don'ts" lernen?

Ok, lassen Sie uns diesen Ausfall weiter analysieren. Das Unternehmen wächst rasant, neue Ingenieure kommen hinzu. Wie werden sie aus diesem Fehler lernen? Sollen wir jedem neuen Ingenieur davon erzählen? Offensichtlich wird es immer mehr Fehler geben - wie bringen wir alle dazu, daraus zu lernen? Die Antwort ist fast klar: Erstellen Sie eine Do's and Don'ts-Datei. Wir werden alle Imbissbuden in diese Datei schreiben. Wir zeigen diese Datei allen unseren neuen Ingenieuren und auch allen unseren derzeitigen Ingenieuren in einem Arbeitsgruppen-Chat jedes Mal, wenn die Do's & Don'ts aktualisiert werden, und fordern alle dringend auf, sie erneut zu lesen (um die alten Informationen aufzufrischen und die zu sehen neue).

Man könnte sagen, dass nicht jeder sorgfältig lesen wird. Man könnte sagen, dass die Mehrheit es gleich nach dem Lesen vergessen wird. Und Sie hätten in beiden Punkten Recht. Sie können jedoch nicht leugnen, dass jemandem etwas im Kopf bleibt. Und das ist gut genug. Nach Erfahrung von Citymobil nehmen die Ingenieure diese Datei sehr ernst und die Situationen, in denen einige Lektionen vergessen wurden, traten sehr selten auf. Die Tatsache, dass die Lektion vergessen wurde, kann als Problem angesehen werden. Wir sollten eine Schlussfolgerung ziehen und die Details analysieren, um herauszufinden, wie wir in Zukunft etwas ändern können. Diese Art des Grabens führt zu genaueren und genaueren Formulierungen in Do's und Don'ts.

Das Mitnehmen aus dem oben beschriebenen Ausfall: Erstellen Sie eine Do's and Don'ts-Datei; Schreiben Sie alles, was wir darin gelernt haben, zeigen Sie die Datei dem gesamten Team, fordern Sie jeden Neuling auf, sie zu studieren, und ermutigen Sie die Leute, Fragen zu stellen.

Allgemeiner Rat, den wir aus der Ausfallüberprüfung abgeleitet haben: Wir sollten keine Wortkombination "Scheiße passiert" verwenden. Sobald Sie es laut aussprechen, entscheidet jeder, dass nichts getan werden muss. Es sind keine Schlussfolgerungen erforderlich, da Menschen immer Fehler gemacht haben, jetzt Fehler machen und diese in Zukunft machen werden. Anstatt diesen Satz zu sagen, sollten Sie daher eine bestimmte Schlussfolgerung ziehen. Eine Schlussfolgerung - ist vielleicht ein kleiner, aber immer noch ein Schritt in Richtung einer Verbesserung des Entwicklungsprozesses, der Überwachungssysteme und der automatisierten Tools. Solche kleinen Schritte führen zu einem stabileren Service!

7. Anstelle des Nachworts

In weiteren Abschnitten werde ich über Arten von Ausfällen in Citymobil sprechen und auf jede Art von Ausfall eingehen. Ich erzähle Ihnen auch von den Schlussfolgerungen, die wir zu den Ausfällen gezogen haben, wie wir den Entwicklungsprozess geändert haben und welche Automatisierung wir eingeführt haben. Bleib dran!