Während alle meinen Geburtstag feierten, habe ich bis zum Morgen am Cluster gearbeitet – und die Entwickler haben mir ihre Fehler zugeworfen.

Das ist die Geschichte, die meine Herangehensweise an die Arbeit im DevOps für immer verändert hat. Noch zu vor-COVID-Zeiten, lange bevor das alles begann, als wir mit den Jungs gerade erst darüber nachdachten, unser eigenes Unternehmen zu gründen und als Freelancer an zufälligen Aufträgen arbeiteten, erhielt ich in Telegram einen Vorschlag.

Das Unternehmen, das den Vorschlag eingereicht hatte, beschäftigte sich mit Datenanalytik. Täglich verarbeiteten sie Tausende von Anfragen. Sie kamen zu uns mit den Worten: "Leute, wir haben ClickHouse und möchten dessen Einrichtung und Installation automatisieren. Wir benötigen Ansible, Terraform, Docker und alles soll in Git gespeichert werden. Wir wollen ein Cluster aus vier Knoten mit zwei Replikaten in jedem."

Eine Standardanfrage, von denen es viele gibt, und wir suchten eine ebenso gute Standardlösung. Wir sagten "okay", und nach 2-3 Wochen war alles bereit. Sie akzeptierten unsere Arbeit und begannen, auf das neue ClickHouse-Cluster mit Hilfe unseres Tools umzuziehen.

Niemand wollte und konnte sich mit ClickHouse beschäftigen. Damals dachten wir, das sei ihr Hauptproblem, und deshalb gab der CTO des Unternehmens meinem Team die Anweisung, die Arbeit so weit wie möglich zu automatisieren, um nicht mehr selbst eingreifen zu müssen.

Wir begleiteten den Umzug, und es tauchten neue Aufgaben auf — Backups und Monitoring einzurichten. Zu diesem Zeitpunkt wechselte der CTO des Unternehmens zu einem anderen Projekt, sodass einer seiner Mitarbeiter, Leonid, unser neuer Ansprechpartner wurde. Leonid war kein besonders talentierter Typ. Ein einfacher Entwickler, der plötzlich als Verantwortlicher für ClickHouse eingesetzt wurde. Anscheinend war dies seine erste Führungsposition, und die plötzliche Verantwortung verursachte bei ihm eine gewisse Eitelkeit.

Gemeinsam machten wir uns an die Backups. Ich schlug vor, die Rohdaten sofort zu sichern. Einfach die Daten zu nehmen, zu zippen und elegant in eine Art S3 zu laden. Rohdaten sind Gold. Es gab auch eine andere Möglichkeit — die Tabellen in ClickHouse zu sichern, indem man ein Freeze und Kopieren anwendet. Aber Leonid hatte seine eigene Lösung.

Er erklärte, dass wir einen zweiten Cluster für ClickHouse benötigen. Von nun an würden wir Daten auf zwei Cluster schreiben — den Haupt- und den Backup-Cluster. Ich sagte ihm, Leonid, das wird kein Backup sein — sondern eine aktive Replikation. Wenn Daten in der Produktion verloren gehen, wird es bei deinem Backup dasselbe sein.

Aber Leonid hielt fest am Steuer fest und weigerte sich, auf meine Argumente zu hören. Wir stritten lange im Chat, aber es half nichts — Leonid war der Verantwortliche im Projekt, wir waren nur die angestellten Jungs von der Straße.

Wir überwachten den Zustand des Clusters und erhielten nur eine Vergütung für die Arbeit der Administratoren. Reines Administrieren von ClickHouse, ohne in die Daten einzugreifen. Der Cluster war erreichbar, die Festplatten waren in Ordnung, die Nodes funktionierten einwandfrei.

Wir ahnten noch nicht, dass wir diesen Auftrag aufgrund eines schrecklichen Missverständnisses innerhalb ihres Teams erhalten hatten.

Der Leiter war unzufrieden, weil ClickHouse langsam lief und manchmal Daten verloren gingen. Er gab seinem CTO die Aufgabe, das Problem zu klären. Dieser klärte es, soweit er konnte, und kam zu dem Schluss, dass ClickHouse einfach automatisiert werden musste — und das war alles. Aber wie sich bald herausstellte, benötigten sie ganz gewiss kein DevOps-Team.

All dies stellte sich als sehr schmerzhaft heraus. Und das ärgerlichste war, dass es an meinem Geburtstag passierte.

Freitagabend. Ich hatte einen Tisch in meiner Lieblingsweinbar reserviert und meine Freunde eingeladen.

Kurz bevor wir aufbrechen wollten, bekamen wir die Aufgabe, einen Alternativen zu erstellen. Das haben wir erledigt, alles war in Ordnung. Der Alternativvorschlag wurde akzeptiert, ClickHouse hat bestätigt. Wir waren schon auf dem Weg zur Bar, als uns mitgeteilt wurde, dass Daten fehlen. Nach einer Überprüfung schien alles vorhanden zu sein. Und dann gingen wir feiern.

Im Restaurant war es wie an einem typischen Freitagabend laut. Nach dem Bestellen von Getränken und Essen machten wir es uns auf den Couchmöbeln bequem. Währenddessen trudelten die Nachrichten in meinem Slack langsam ein. Irgendetwas war mit fehlenden Daten. Ich dachte mir, dass der Morgen weiser ist als der Abend, besonders heute.

Gegen elf fingen sie an, uns anzurufen. Es war der Geschäftsführer des Unternehmens… „Wahrscheinlich will er mich gratulieren“, dachte ich sehr unsicher, nahm den Hörer ab.

Und ich hörte etwas in der Art: „Ihr habt unsere Daten versaut! Ich bezahle euch, aber nichts funktioniert! Ihr wart für die Backups verantwortlich und habt keinen einzigen Schritt unternommen! Lasst uns das reparieren!“ — nur noch grober.

— Weißt du was, verpiss dich! Heute ist mein Geburtstag, und jetzt werde ich feiern und mich nicht um eure Anfängerprojekte kümmern, die aus Mist und Stöcken bestehen!

So habe ich es natürlich nicht gesagt. Stattdessen holte ich meinen Laptop heraus und machte mich an die Arbeit.

Nein, ich habe wirklich eingehend nachgehakt! Ich habe sarkastisch in den Chat geschrieben: „Hab ich nicht gesagt?“ — denn das Backup, das kein echtes Backup war, hat natürlich nichts gerettet.

Wir haben uns mit den Jungs überlegt, wie wir die Aufnahme manuell stoppen und alles überprüfen können. Wir haben tatsächlich festgestellt, dass ein Teil der Daten nicht geschrieben wurde.

Wir haben die Aufnahme gestoppt, die Anzahl der Ereignisse gezählt, die dort über den Tag gespeichert sind. Wir haben weitere Daten hinzugefügt, von denen nur ein Drittel nicht gespeichert wurde. Drei Shards mit jeweils zwei Replikaten. Wenn du 100.000 Zeilen einfügst — werden 33.000 nicht gespeichert.

Es herrschte totale Verwirrung. Jeder schickte den anderen der Reihe nach zum Teufel: Zuerst war Leon dran, gefolgt von mir selbst und dem Firmengründer. Nur der neu beigetretene CTO versuchte, unsere Calls mit Geschrei und unsere Nachrichten in Richtung Problemlösung zu lenken.

Was tatsächlich geschah — das verstand niemand.

Wir waren total perplex, als wir merkten, dass ein Drittel aller Daten nicht nur nicht gespeichert wurde — sie gingen verloren! Es stellte sich heraus, dass in der Firma so verfahren wurde: Nach dem Einfügen wurden die Daten unwiderruflich gelöscht, die Ereignisse gingen massenhaft verloren. Ich stellte mir vor, wie Sergey all das in entgangene Rubel umwandelt.

Mein Geburtstag wurde ebenfalls im Müll entsorgt. Wir saßen in einer Bar und entwickelten Ideen, während wir versuchten, das geworfene Rätsel zu lösen. Der Grund für den Ausfall von Clickhouse war nicht offensichtlich. Vielleicht liegt es am Netzwerk, vielleicht an den Linux-Einstellungen. Es könnte fast alles sein; viele Hypothesen wurden genannt.

Ich habe keinen Entwickler-Eid geleistet, aber die Jungs am anderen Ende der Leitung im Stich zu lassen, wäre unhöflich gewesen – auch wenn sie uns für alles verantwortlich machten. Ich war mir zu 99 % sicher, dass das Problem nicht in unseren Lösungen, nicht auf unserer Seite lag. Der 1 %ige Zweifel, dass wir doch einen Fehler gemacht haben könnten, nagte an mir. Aber egal, auf welcher Seite das Problem lag – es musste behoben werden. Die Kunden, egal wie sie waren, mit einem so schlimmen Datenleck im Stich zu lassen, wäre einfach zu grausam.

Bis drei Uhr morgens arbeiteten wir an einem Tisch im Restaurant. Wir fügten Events hinzu, führten Insert-Selects durch – und legten los, um die Lücken zu füllen. Wenn man Daten verloren hat, geht man so vor: Man nimmt die durchschnittlichen Daten der vorherigen Tage und fügt sie in die verlorenen ein.

Nachdem es drei Uhr morgens war, gingen mein Freund und ich zu mir nach Hause, bestellten Bier aus dem Getränkemarkt. Ich saß mit meinem Laptop und hatte Probleme mit ClickHouse, während mein Freund mir etwas erzählte. Nach einer Stunde war er beleidigt, weil ich arbeitete und nicht mit ihm Bier trank, und fuhr weg. Klassisch — ein Freund des DevOps.

Bis sechs Uhr morgens hatte ich die Tabelle neu erstellt, und die Daten fingen an einzugießen. Alles funktionierte ohne Verluste.

Danach wurde es schwierig. Alle beschuldigten sich gegenseitig des Datenverlusts. Wenn ein neuer Fehler aufgetreten wäre, bin ich mir sicher, hätte es eine Schießerei gegeben.

In diesen Auseinandersetzungen begannen wir endlich zu verstehen — im Unternehmen dachte man, wir seien die Leute, die mit Daten arbeiten und die Tabellenstruktur überwachen. Sie hatten die Administratoren mit den DB-Entwicklern verwechselt. Und kamen nicht als Administratoren, sondern völlig anders auf uns zu.

Ihre Hauptbeschwerde war — wie zum Teufel konntet ihr die Backups machen und das nicht richtig hinbekommen, ihr habt die Daten versaut. Und das alles mit Flüchen.

Ich wollte Gerechtigkeit. Ich grub die Korrespondenz aus und fügte alle Screenshots bei, auf denen Leonid mit aller Kraft darauf bestand, dass das Backup gemacht wird, wie es gemacht werden sollte. Nach meinem Anruf stellte sich ihr CTO auf unsere Seite. Auch Leonid gab schließlich seine Schuld zu.

Der Firmenleiter wollte seine Mitarbeiter jedoch nicht beschuldigen. Screenshots und Worte hatten keinen Einfluss auf ihn. Er war der Meinung, dass wir als Experten alle überzeugen und auf unserer Entscheidung bestehen sollten. Offensichtlich war es unsere Aufgabe, Lenya zu unterrichten, und das ohne ihn, den projectverantwortlichen Leiter, direkt zu kontaktieren, um all unsere Zweifel an der Backup-Strategie ihm gegenüber auszuräumen.

Der Chat war von verborgener und offener Aggression durchzogen. Ich wusste nicht, wie ich umgehen sollte. Alles war in einer Sackgasse gelandet. Und dann kam der einfachste Rat: schreibe in einer persönlichen Nachricht an den Leiter und vereinbare ein Treffen mit ihm. Vasja, die Leute im echten Leben sind nicht so frech wie im Chat. Auf meine Nachricht antwortete der Boss: Komm vorbei, kein Problem.

Das war das unangenehmste Treffen meiner Karriere. Mein Verbündeter vom Kunden — der CTO — konnte keine Zeit finden. Auf dem Weg zum Treffen war ich allein mit dem Boss und Lenya.

Immer wieder spielte ich unseren möglichen Dialog im Kopf durch. Ich schaffte es, viel zu früh zu kommen, eine halbe Stunde vorher. Der Stress begann, ich rauchte zehn Zigaretten. Ich wusste, jetzt bin ich ganz allein. Ich kann sie nicht überzeugen. Und betrat den Aufzug.

Während ich nach oben fuhr, zündete ich so oft an, dass ich das Feuerzeug brach.

Letztendlich war Leon bei dem Treffen nicht anwesend. Aber wir haben mit dem Hauptverantwortlichen großartig über alles gesprochen! Sergej hat mir von seinem Schmerz erzählt. Er wollte nicht einfach nur „ClickHouse automatisieren“ – er wollte, dass die Abfragen funktionieren.

Ich habe keinen Bösewicht gesehen, sondern einen netten Kerl, der sich um sein Geschäft sorgt und 24/7 in der Arbeit steckt. Im Chat werden uns oft Schurken, Betrüger und Idioten präsentiert. Doch im echten Leben sind das ganz normale Menschen wie du.

Sergej benötigte nicht nur ein paar DevOps-Freiberufler. Das Problem, mit dem sie konfrontiert waren, war viel größer.

Ich habe gesagt, dass ich seine Probleme lösen kann — aber es ist eine ganz andere Arbeit, und dafür habe ich einen Bekannten, der ein DB-Experte ist. Hätten wir von Anfang an gewusst, dass es für sie wichtig ist, hätten wir viel vermeiden können. Es war zwar zu spät, aber wir haben verstanden, dass das Problem in der mangelhaften Datenverarbeitung lag und nicht in der Infrastruktur.

Wir haben uns die Hände geschüttelt, die Zahlung wurde um das Zweieinhalbfache erhöht, aber unter der Bedingung — ich übernehme die gesamte Verantwortung für ihre Daten und ClickHouse. Im Aufzug habe ich mich mit dem besagten DB-Experten Max in Verbindung gesetzt und ihn in die Arbeit eingebunden. Es war nötig, den gesamten Cluster neu zu strukturieren.

Im angenommenen Projekt gab es eine Menge Probleme. Angefangen mit dem erwähnten „Backup“. Es stellte sich heraus, dass dieser „Backup“-Cluster nicht isoliert war. Dort wurden alle möglichen Tests durchgeführt, manchmal sogar im Produktionsbetrieb.

Die internen Entwickler haben ihren eigenen benutzerdefinierten „Data-Inserter“ entwickelt. Er funktionierte so: Er kombinierte Dateien, führte ein Skript aus und lud die Daten in eine Tabelle. Das Hauptproblem war jedoch, dass eine enorme Datenmenge für eine einfache Anfrage verarbeitet wurde. Die Anfrage joine die Daten sekundengenau. Alles für eine einzige Zahl — die Summe des Tages.

Die internen Entwickler verwendeten das Analysetool nicht korrekt. Sie gingen in Grafana, schrieben ihre eigenen Anforderungen. Diese luden Daten für zwei Wochen. Das Ergebnis war ein schöner Graph. In Wirklichkeit lief die Datenanfrage jedoch alle 10 Sekunden. Alles häufte sich in einer Warteschlange, da ClickHouse die Verarbeitung einfach nicht bewältigen konnte. Hier lag die Hauptursache. In Grafana funktionierte nichts, die Anfragen standen in der Warteschlange und es kamen ständig alte, nicht relevante Daten an.

Wir haben den Cluster neu konfiguriert und das Inserieren überarbeitet. Die internen Entwickler haben ihren „Inserter“ neu geschrieben, und er begann, die Daten korrekt zu sharden.

Max hat eine umfassende Überprüfung der Infrastruktur durchgeführt. Er hat einen Plan für den Übergang zu einer vollwertigen Backend-Lösung skizziert. Doch das genügte dem Unternehmen nicht. Sie warteten auf das magische Geheimnis von Max, das es ermöglichen würde, weiterhin auf alte Weise, aber effizient zu arbeiten. Das Projekt wurde nach wie vor von Leonja geleitet, der nichts dazugelernt hatte. Von all dem Vorgeschlagenen wählte er erneut seine bevorzugte Alternative. Wie immer war es die kühnste Entscheidung. Leonja war der Meinung, dass sein Unternehmen einen besonderen Weg eingeschlagen hatte – einen steinigen, voller Eisberge.

Genau damit trennten wir uns – wir haben getan, was wir konnten.

Mit den gesammelten Erfahrungen, geprägt von dieser Geschichte, haben wir unser eigenes Geschäft gegründet und einige Prinzipien für uns formuliert. Heute beginnen wir unsere Arbeit niemals mehr so wie damals.

Nach diesem Projekt trat Dibiayschik Max zu uns, und wir arbeiten immer noch hervorragend zusammen. Der Fall mit Clickhouse hat uns gelehrt, vor Beginn der Arbeit eine vollständige und gründliche Infrastrukturprüfung durchzuführen. Wir verstehen, wie alles funktioniert, und nehmen dann die Aufgaben an. Hätten wir früher sofort mit der Wartung der Infrastruktur begonnen, so führen wir jetzt zuerst ein einmaliges Projekt durch, das hilft, sie wieder in einen funktionsfähigen Zustand zu versetzen.

Ja, wir meiden Projekte mit einer miserablen Infrastruktur. Selbst wenn es viel Geld kostet oder als Gefälligkeit. Es ist nicht vorteilhaft, kranke Projekte zu betreuen. Dieses Bewusstsein hat uns helfen, zu wachsen. Entweder ein einmaliges Projekt zur Instandsetzung der Infrastruktur und danach ein Wartungsvertrag, oder wir lassen es einfach. An einem weiteren Eisberg vorbei.

P.S. Wenn Sie Fragen zu Ihrer Infrastruktur haben, scheuen Sie sich nicht, eine Anfrage zu stellen..

haben wir zweimal im Monat kostenlose Audits, vielleicht ist Ihr Projekt eines davon.

Quelle: habr.com