Ausgereifte DevOps: Griechische Tragödie in drei Akten

Die Tragödie (aus der deutschen Tragödie aus der lateinischen Tragoedia aus dem anderen Griechischen τραγωδία) ist ein Kunstgenre, das auf einer Bühne inszeniert werden soll, auf der die Handlung die Figuren zu einem katastrophalen Ausgang führt.

Die meisten Tragödien sind in Versen geschrieben. Diese Tragödie wurde von Baruch Sadogursky ( @jbaruch ) und Leonid Igolnik ( @ligolnik ) geschrieben. Wenn wir in großem Umfang über DevOps sprechen, was ist das dann nur eine Tragödie?

Dieser Artikel ist durch die Schwere des Realismus gekennzeichnet und zeigt die Realität einer großen Entwicklung am deutlichsten, wie eine Reihe interner Widersprüche. Es enthüllt die tiefsten Konflikte der Realität in einer äußerst intensiven und gesättigten Form und erhält den Wert eines künstlerischen Symbols.

Und jetzt spielen wir Belinsky zu Ende und begrüßen den Schnitt! Es gibt Text und Video. Nimm keine Geiseln!





Wie Sie wissen, liebten die Griechen Venn-Diagramme. Und wir zeigen Ihnen bis zu drei - und alles über DevOps.


Es gibt eine traditionelle Beschreibung von DevOps - dies ist der Schnittpunkt der Bereiche Betrieb, Entwicklung und Qualitätssicherung. Es ist historisch interessant, dass dort später die Qualitätssicherung hinzugefügt wurde.


Aber heute werden wir über etwas anderes sprechen - die Schnittstelle von Technologie, Prozess und Menschen. Informationen darüber, was Sie mit all diesen drei Komponenten tun müssen, um DevOps zu erhalten.

Vergleichen Sie nun zwei weitere Diagramme:



Manchmal passiert es.

Pentagon Inc.

Beginnen wir die Geschichte mit einer mythischen Firma namens Pentagon, die sich mit Kreditkartentransaktionen befasst.

Akt I - Feuerwehrleute

Leute . Das Unternehmen nimmt gerade seine Arbeit auf und hat drei Ingenieure. Alle drei stammten von derselben Verteidigungsfirma. Die Jungs sind klug genug, also haben sie alles: JavaScript, Node, React, Docker, Microservices.


Prozess . Wie könnte der Prozess aussehen, wenn drei Personen in einem Team sind? Kanban: entweder auf einem Stück Papier oder Trello. Die Jungs sind schlau und verstehen, dass QS von Anfang an erforderlich ist, daher TDD-, Unit- und Integrationstests. Keine Operationen, alle haben Wurzeln.


Werkzeuge Dementsprechend für drei Personen, die gerade etwas ansprechen : JIRA , GitHub , Travis CI usw.


Lassen Sie uns darüber sprechen, wie diese Leute auf diesem schönen Stapel leben. Erstens, wie bei guten Startups - wir sägen, sägen ein Produkt und warten auf den ersten Kunden.


Plötzlich geschah ein Wunder - eine Organisation, die die besten Konferenzen im postsowjetischen Raum organisiert, beschloss, diesen Leuten zu vertrauen und ihre Transaktionen über sie durchzuführen.


Was macht ein echtes Startup, wenn es seinen ersten Client bekommt? Feiern! Und irgendwo gegen drei Uhr nachts, wenn sich alles in einem besonderen Zustand befindet, ruft der Kunde an und sagt, dass nichts funktioniert.


Natürlich vor allem Panik!


Der nächste Schritt ist zu kämpfen! Wir schauen uns zum Beispiel die Protokolle an.


Wir schauten, schauten, es stellte sich heraus, dass einer unserer drei Helden - Vasya, der nach dem Festival nach Hause gekommen war, seine kleine Idee begangen hatte. Wir erinnern uns, dass nach dem Festschreiben und dem Bestehen der Tests alles in die Produktion fliegt.

Nun, wer von uns hat die Produktion nicht gescheitert? Wir werden Vasya nicht beschuldigen. Führen Sie einen Rollback zum vorherigen Commit durch. Es wird nicht gehen! Aus irgendeinem Grund gibt es nicht genügend Bibliotheken, die als linkes Pad bezeichnet werden.


Für diejenigen, die nicht wissen, was mit dem linken Pad passiert ist, erzählen wir. Am 23. März 2016 brach die Hälfte des Internets zusammen . Im Allgemeinen fügt das Left-Pad-Modul in JavaScript einfach Leerzeichen auf der linken Seite der Zeilen ein. Und die Hälfte des Internets hing direkt oder transitiv von diesem Modul ab. Der Autor von left-pad hat es irgendwie geschafft, sich mit den Besitzern des zentralen npm-Repositorys zu streiten, also ging er einfach von ihnen weg und nahm alle seine Entwicklungen auf. npm ist im Allgemeinen ein mysteriöses System: Sie überprüfen nicht nur, wenn Sie ein neues Modul zum Herunterladen hinzufügen, sondern auch alle alten Module.

So geht der Kampf gegen das Feuer immer wieder weiter. Und die Probleme sind immer die gleichen.

Akt II - Feueralarminstallateure

Unternehmensnachrichten: Teig aufgezogen, einen Investor gefunden, 27 Mitarbeiter eingestellt, einer davon mit operativem Hintergrund. 100 Kunden erschienen und sogar technischer Support.


Der Prozess muss dementsprechend auch ein Upgrade erhalten. Es erschienen normale Scrum-Erkundungstests. Wir haben festgestellt, dass NoOps überhaupt nicht existiert, weil es Ops gibt (wenn die Architektur ohne Server ist, ist der Server immer noch da, er gehört einfach nicht Ihnen). Da es falsch ist, das gesamte Team nachts aufzuwecken, ist ein Entwickler auf Abruf erschienen.


Dementsprechend wurde der Werkzeugsatz erweitert. Zumindest ist die Wissensdatenbank erschienen, da es jetzt einen Begleiter gibt, der irgendwo nach Informationen suchen muss. Eine weitere Neuheit ist JFrog Artifactory : Ein System, mit dem Sie speichern können, was gestern angedockt wurde, damit Sie problemlos einen Rollback durchführen können (die Lektion mit dem linken Pad war nicht umsonst), anstatt sie erneut zu erstellen . Wir haben ein System zum Sammeln und Suchen von Protokollen eingerichtet. Pingdom wurde hinzugefügt - bezauberndes Überwachungssystem: Sie geben ihm eine URL und erfahren, ob es funktioniert oder abgestürzt ist.


Zu diesem Zeitpunkt sammelten sie wieder Geld. Also stellen wir fest. Freitag, drei Uhr morgens, ruft der Kunde an. Etwas funktioniert nicht: Visa und MasterCard passen, American Express jedoch nicht.


Und wie reagiert der Support zuerst, wenn ein Kunde um drei Uhr morgens anruft? Panik!

Dann rufen wir den Begleiter an. Ratet mal, wer Dienst hat? Natürlich, Vasya! Ratet mal, in welchem ​​Zustand sich Vasya befindet. Ja Aber Vasya reißt sich zusammen, schaut sich an, welche Unterstützung ihn geschickt hat, und sagt, dass er damit verdächtig vertraut ist und dies bereits getan hat. Deshalb nimmt und repariert Vasya einfach. Jeder wird ausschlafen. Die Nachbesprechung beginnt am Montag.


Hier ist ein Beispiel für ein bestimmtes Dokument, das wir für die Wissensdatenbank erstellen, damit es schnell gefunden werden kann, wenn sich etwas wiederholt. Außerdem wird es manchmal Kunden gezeigt:


Das Dokument zeigt die Hauptüberschriften, Gründe, Merkmale und eine Liste der Ereignisse an. Die Symptome müssen angegeben werden. Es wird eine technische Beschreibung gegeben, was genau kaputt gegangen ist und wie es behoben werden kann. Der wichtigste Teil des Dokuments ist der Hauptgrund, warum etwas gefallen ist.

Im Fall von Vasya ist die Protokollwarteschlange übergelaufen. Sie müssen die Kreditkartentransaktionen löschen und außerdem die Größe erhöhen. Zum Beispiel bei 42!

Ein solches Verfahren ist sehr gut für die interne kontinuierliche Verbesserung geeignet und garantiert die Installation derselben "Rauchmelder". Der zweite Grund, warum dieses Dokument wichtig ist, ist der Bericht an den Kunden. Einige Dienste veröffentlichen die Gründe dafür, nachdem sie eine Weile „gelegen“ haben.


Manchmal stellt sich das Problem als so katastrophal heraus, dass es sich nicht lohnt, darüber zu sprechen.

In GitLab hat im Februar 2017 eine Person eine Produktionsdatenbank gelöscht. Hier ist die Analyse, die GitLab hochgeladen hat:


Irgendwo gibt es also ein Backup, nur niemand weiß wo. Dann wurden Backups gefunden, die sich jedoch als leer herausstellten. Ja, es gibt einen Basis-Dump. Aber es wurde in einer anderen Version von Postgres hergestellt, daher passt es nicht. Wir haben Schnappschüsse, aber sie haben keine Datenbank. Die Replikation von S3 funktionierte aufgrund fehlender Daten ebenfalls nicht.

Daher funktionierten fünf verschiedene Techniken zum Sichern von Daten nicht. Wir glauben, dass dies nicht veröffentlicht werden kann, da ihnen sonst niemand vertrauen wird. Aber je nachdem, wie Sie darüber sprechen, kann der Kunde vergeben. Richtig, nur einmal.


Übrigens hat der Typ, der es getan hat, eine Beförderung bekommen. Außerdem änderte er seinen Twitter-Status in Database (Remove) Specialist bei GitLab .

Akt III - Höhepunkt

Was passiert also in unserem Unternehmen? Sie sammelten wieder Geld, stellten eine Menge Leute ein - jetzt haben wir fünf Einsatzingenieure und eine Person, die sich mit Leistung beschäftigt. Es gibt einen Chefarchitekten. Ein Kundenerfolgsteam ist erschienen, das alle Branchen abdeckt, die möglicherweise Unterstützung benötigen. Sie werden verlangsamt, damit der Rest des Teams weiterarbeiten kann. Oft gibt es in einem solchen Team eine Gruppe, die Beziehungen zu Ops oder Support aufbauen kann, und in regelmäßigen Abständen müssen Sie Ingenieure auf Scrum, Sprint oder für einen Monat einstellen. Das Unternehmen wuchs, ein Anwalt, ein Finanzdirektor erschien. Der Kundenstamm ist auf 1000 angewachsen.


Wenn das Team wächst, muss sich der Entwicklungsprozess ändern.

SAFE erschien - ein Framework, das erklärt, was zu tun ist, wenn es viele Teams oder Entwicklungszentren gibt - mehr als eines. Die Anzahl der Prozesse, die in Safe vorhanden sind, kann ein Pferd töten, aber wenn nur alle gleichzeitig ausgeführt werden können. Wenn Sie nur die Teile wegnehmen, die in dieser Phase der Unternehmensentwicklung benötigt werden, sollte alles in Ordnung sein.

Systemtests werden angezeigt, wenn große Teams bestimmte Anforderungen haben oder wenn Sie ein großes System haben, aus dem Sie etwas erstellen müssen. Einzelne Scrum-Teams können ihre Systeme gut testen, aber jemand sollte dafür verantwortlich sein, dass das gesamte System in der Produktion zusammengebaut wird.

Was ist mit Ops Team? Wie gesagt, es gibt zwei Möglichkeiten, DevOps auszuführen. Das erste ist für das Buch und für Anweisungen von Netflix, Google und Twitter. Die zweite ist im wirklichen Leben, wo nicht allen Ingenieuren die Wurzel in der Produktion anvertraut werden kann.

Eskalationspfad ist ein wichtiges Konzept, mit dem Sie jedes Problem zu einem bestimmten Zeitpunkt lösen können, da sich am Ende des Eskalationspfads das Mobiltelefon eines CEO befindet, nach einem Anruf, bei dem alle Probleme innerhalb von 5 Stunden 58 Minuten verschwinden.

SOC II - eine Reihe von Standards, die der Anbieter dem Kunden zur Verfügung stellt. Diese Standards bestätigen, dass das Unternehmen über bestimmte Sicherheitslösungen und Ansätze zur Arbeitsteilung verfügt.

Rückstand - eine Liste von Problemen, die behoben werden müssen, um das System zu verbessern. Normalerweise wird der hintere Architekt zum Hauptarchitekten, der die Anforderungen des Systems und die Anforderungen des Produkts berücksichtigen und diese Aufgaben priorisieren muss.


Natürlich werden auch die Werkzeuge verbessert.


Es gibt mehr Neuigkeiten. Vasya wurde befördert. Er ist jetzt VP of Engineering.

Freitag, Samstag, Sonntag vergeht - nichts kommt. Alles arbeitet. Jeder steht unter Schock. Montag kommt, ein Anwalt kommt zu Vasya und sagt, dass er auf einer Konferenz von Anwälten war und dort von LGPL 2.2 gehört hat. Vasya hat keine Ahnung, ob sie LGPL 2.2 haben.


Die Leute haben lange gearbeitet und dann LGPL 2.2 gefunden. Müssen schneiden. Aber dies wird von einem gesunden Teil des Systems herausgeschnitten, und niemand hat die Veröffentlichung morgen abgesagt. Nun, nichts, damit befasst.


Der Fondsdirektor kommt zu Vasya:

• Wie viel Geld brauchen Sie für Server und Produktion? Das Budget für das nächste Jahr aufstellen ...
• 42 - sagt Vasya.

Wir haben auch dieses Problem gelöst.


Sie kommen zu Vasya und sagen, dass es einen potenziellen Kunden gibt, aber er befürchtet, dass wir noch nie einen so großen Kunden hatten, und möchte überzeugt sein, dass es gut sein wird. Wir wissen aus der Geschichte, dass zu diesem Zeitpunkt alle gestorben sind.


Aber da wir ein Happy End haben müssen, haben wir es mit der griechischen Tragödie verbunden.

Epilog - Proaktive Verbesserung

Lassen Sie uns nun über die letzte Phase der Skalierung von DevOps - Proactive Improvement sprechen. Es geht um Brandschutz.

Menschen verändern sich nicht. Aber mit dem Prozess - sehr.


Da wir einen Performance Engineer haben, muss dieser das System irgendwie überwachen. Lizenz- und Sicherheitsmanagement erschienen. Proaktive Leistung - Jetzt beobachten wir genau, wo sich die Schlüsselindikatoren bewegen, und reparieren Dinge, bevor ein großes Feuer beginnt. Wenn Sie ein Produkt skalieren, ist es ratsam, etwas zu haben, das besagt: Wenn Sie einen Microservice haben möchten, sollte es zumindest Standardüberwachung, Protokolle usw. haben.

Dementsprechend gibt es Tools, die all dies unterstützen. Ein Tool zur Lizenz- und Sicherheitsüberwachung ist beispielsweise JFrog Xray . Blazemeter - da es jetzt eine proaktive Leistung gibt, müssen Sie irgendwie eine Last erzeugen. Es entstehen Dinge wie die Service-Virtualisierung, mit der Sie Scheinobjekte für Remote-APIs verwenden können, da nicht jeder Anbieter, mit dem Sie zusammenarbeiten, eine Test-API bereitstellen kann.

Parsen

Lassen Sie uns einige Ereignisse aus früheren Handlungen analysieren.

Erinnern Sie sich an den Fall, als Vasily ein Budget mit einem Finger am Himmel plante? Bei der Arbeit an einem unserer Produkte wollten wir herausfinden, wofür Ressourcen ausgegeben wurden. Nachdem wir alles gruppiert haben, was sich im Backlog befand, haben wir dieses Diagramm erhalten:



Wir haben fälschlicherweise gedacht, dass wir 80% für Big Feature A ausgeben - tatsächlich sind es nur 13%. Gleichzeitig gehen bis zu 34% an, um das Licht an zu halten - Dinge, die in Produkten getan werden müssen: Fehler reparieren, Bibliotheken aktualisieren usw.

Tatsächlich gibt es nur eine objektive Metrik für die Produktqualität: die Kundenzufriedenheit, die sich in Aufforderungen zur Unterstützung äußert.

Zweites Beispiel. Wir haben alle Kritikalitätsfehler behoben:


65% der Tickets gehören zu den ersten Kritikalitätsstufen. Ist das ein Albtraum?

Nehmen Sie nun dieselben Daten und betrachten Sie sie aus einem anderen Blickwinkel.


Jetzt spiegelt das Diagramm die Situation nach der Nachbesprechung wider. Es stellte sich heraus, dass 52% der Tickets vom Ingenieur unter Verwendung der bereitgestellten Informationen geschlossen wurden, dh er schrieb an den Support, was sie nicht wussten. Nur etwa 20% der Tickets wurden mit einer Codeänderung geschlossen. Somit stellt sich heraus, dass F & E nicht schuld ist. Nicht einmal die Unterstützung ist schuld. Tatsächlich fehlte uns die Ausbildung - und Vasya schickte, wie der Vizepräsident für Ingenieurwesen, nachdem er gesehen hatte, wie viel Zeit er mit allerlei Unsinn verbringt, eine Reihe von Ingenieuren, um den Support zu schulen.

Die Jungs haben die Dokumentation in Engpässen korrigiert, die Protokolle korrigiert. Infolgedessen verschwand das Stück, das viel Entwicklerzeit in Anspruch nahm.

Schlussfolgerungen

In allen Phasen, von der Brandbekämpfung über die Installation von Alarmen bis hin zur proaktiven Problemlösung, müssen viele Prozesse, Personen, Spezialisten, Ansätze und Tools installiert werden. All dies kann nicht an einem Tag erledigt werden. Darüber hinaus werden einige Dinge in einigen Entwicklungsstadien nicht benötigt.

Es ist wichtig zu verstehen, dass bei Menschen, Prozessen und Werkzeugen ständig Verbesserungen erforderlich sind.


Was genau verbessert werden muss, wird uns helfen, genau die Zahlen herauszufinden, über die wir gesprochen haben. Nur auf der Grundlage dieser Daten können wir die richtigen Entscheidungen darüber treffen, wo Zeit investiert und was vorangebracht werden soll.

Und vergessen Sie nicht die beiden Grundprinzipien von DevOps:

• Sie bauen es - Sie besitzen es.
  
• Schmerz ist lehrreich.
  

Bereits am nächsten Sonntag werden Baruch und Leonid auf der DevOops 2018 in St. Petersburg einen Bericht „#DataDrivenDevOps“ vorlegen. Komm, es wird viele interessante Dinge geben: Hier sind die Berichte , hier ist John Willis und hier ist eine Party mit BoFs und Karaoke . Warten auf euch!