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

Hier ist die Geschichte, die für immer meine Herangehensweise an die Arbeit als DevOps verändert hat. Noch in der Zeit vor COVID, lange bevor es soweit kam, als wir Jungs gerade erst daran dachten, unser eigenes Unternehmen zu gründen und zufällige Aufträge als Freelancer annehmen, erhielt ich einen Vorschlag per Telegram.

Das Unternehmen, das schrieb, beschäftigte sich mit Datenanalyse. Täglich verarbeiteten sie Tausende von Anfragen. Sie kamen zu uns mit den Worten: ‚Jungs, wir haben ClickHouse und möchten dessen Konfiguration und Installation automatisieren. Wir möchten Ansible, Terraform, Docker, und dass alles in Git gespeichert wird. Wir möchten ein Cluster aus vier Knoten mit jeweils zwei Replikaten.‘

Eine Standardanfrage, wie es sie dutzendfach gibt, und wir brauchten eine ebenso gute Standardlösung. Wir sagten ‚okay‘, und nach 2-3 Wochen war alles bereit. Sie nahmen die Arbeit an und begannen, auf das neue ClickHouse-Cluster mit unserem Tool zu migrieren.

Niemand in ihrem Team wollte sich mit ClickHouse beschäftigen und konnte es auch nicht. Damals dachten wir, das sei ihr Hauptproblem, und daher gab der CTO des Unternehmens meinem Team den Auftrag, die Arbeit so weit wie möglich zu automatisieren, damit er sich nie wieder darum kümmern müsse.

Wir begleiteten die Migration, und es tauchten weitere Aufgaben auf – Backups und Monitoring einzurichten. Zu diesem Zeitpunkt war der CTO des Unternehmens auf ein anderes Projekt gewechselt und überließ uns als Kommandeur einen seiner Leute – Leonid. Leonid war kein besonders begabter Typ. Ein einfacher Entwickler, der plötzlich als Hauptverantwortlicher für ClickHouse eingesetzt wurde. Es schien, als wäre dies seine erste Ernennung, etwas zu leiten, und ihm kam der ins Übermaß ausgeglichene Ruhm zu Kopf.

Gemeinsam machten wir uns an die Backups. Ich schlug vor, die ursprünglichen Daten sofort zu sichern. Einfach nehmen, zippen und elegant in einen S3-Store hochladen. Die Ursprungdaten sind Gold wert. Es gab auch eine andere Möglichkeit – die Tabellen in ClickHouse zu sichern, indem man einen Freeze und eine Kopie verwendet. Aber Leonid hatte seine eigene Lösung.

Er erklärte, dass wir ein zweites ClickHouse-Cluster benötigten. Und von nun an würden wir die Daten auf zwei Cluster – das Haupt- und das Backup-Cluster – schreiben. Ich sagte ihm, Leonid, das wird kein Backup, sondern eine aktive Replik. Und wenn Daten in der Produktion verloren gehen, wird das Backup die gleichen Probleme haben.

Aber Leonid hielt fest am Steuer und weigerte sich, meinen Argumenten zuzuhören. Wir stritten lange im Chat, aber es half nichts – Leonid leitete das Projekt, wir waren nur die engagierten Jungs von der Straße.

Wir haben den Zustand des Clusters überwacht und nur für die Arbeit der Administratoren bezahlt. Reines Clickhouse-Administration ohne Eingriffe in die Daten. Der Cluster war verfügbar, die Festplatten in Ordnung, die Knoten in Ordnung.

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

Der Leiter war unzufrieden, dass Clickhouse langsam arbeitet und manchmal Daten verloren gehen. Er beauftragte seinen CTO, sich darum zu kümmern. Dieser machte, was er konnte, und kam zu dem Schluss, dass Clickhouse einfach automatisiert werden muss – und das war's. Aber wie sich bald herausstellte, brauchten sie ganz andere Spezialisten als DevOps.

Das alles stellte sich als sehr schmerzhaft heraus. Und das Ärgerlichste, es war an meinem Geburtstag.

Freitagabend. Ich hatte einen Tisch in meiner Lieblings-Weinbar reserviert und meine Freunde eingeladen.

Kurz vor dem Ausgehen bekamen wir die Aufgabe, ein Alter zu machen, wir erledigten es, alles war in Ordnung. Der Alter war bestanden, Clickhouse hatte bestätigt. Wir waren bereits auf dem Weg zur Bar, als uns geschrieben wurde, dass Daten fehlen. Wir haben gezählt – es schien alles da zu sein. Und sind feiern gegangen.

Im Restaurant war es freitags laut. Wir bestellten Getränke und Essen und machten es uns auf den Sofas bequem. Währenddessen wurde mein Slack langsam mit Nachrichten überflutet. Sie schrieben etwas über fehlende Daten. Ich dachte mir – der Morgen ist weiser als der Abend. Besonders an einem Tag wie heute.

Gegen elf fingen sie bereits an zu telefonieren. Es war der Geschäftsführer… „Wahrscheinlich wollte er mir gratulieren“, dachte ich sehr unsicher und nahm ab.

Und ich hörte so etwas wie: „Ihr habt unsere Daten verloren! Ich bezahle euch, aber nichts funktioniert! Ihr wart für die Backups verantwortlich und habt nichts gemacht! Lasst uns das reparieren!“ – nur noch grober.

— Weißt du was, verpiss dich! Ich habe heute Geburtstag und jetzt werde ich trinken, anstatt mich mit euren Junior-Kram aus Mist und Stöcken zu beschäftigen!

So habe ich es nicht gesagt. Stattdessen holte ich mein Laptop und machte mich an die Arbeit.

Nein, ich war wütend, ich war höllisch wütend! Ich postete sarkastische „Ich habe es doch gesagt“-Nachrichten in den Chat – denn das Backup, das kein echtes Backup war, hatte natürlich nichts gerettet.

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

Die Aufzeichnung wurde gestoppt, und die Anzahl der Events, die dort am Tag angefallen sind, wurde gezählt. Es wurden weitere Daten eingetragen, von denen nicht einmal ein Drittel gespeichert wurde. Drei Shards mit 2 Replikaten. Du fügst 100.000 Zeilen ein — 33.000 werden nicht gespeichert.

Es herrschte völliges Chaos. Alle schickten sich gegenseitig zum Teufel: Zuerst ging Leon dorthin, gefolgt von mir selbst und dem Gründer des Unternehmens. Nur der neu hinzugekommene CTO versuchte, unsere Anrufe mit Geschrei und unsere Korrespondenz in Richtung Problemlösung zu lenken.

Was tatsächlich passierte, verstand niemand.

Wir Jungs waren einfach völlig perplex, als wir begriffen, dass ein Drittel aller Daten nicht nur nicht gespeichert wurde — sie gingen verloren! Es stellte sich heraus, die Ordnung im Unternehmen war so: Nach dem Einfügen wurden die Daten unwiderruflich gelöscht, die Events gingen massenhaft verloren. Ich stellte mir vor, wie Sergey all das in versäumte Rubel umrechnet.

Mein Geburtstag wurde ebenfalls im Müll entsorgt. Wir saßen in einer Bar und generierten Ideen, während wir versuchten, das aufgeworfene Rätsel zu lösen. Der Grund für den Rückgang des ClickHouse war nicht offensichtlich. Vielleicht ist es das Netzwerk, vielleicht liegen die Probleme an den Linux-Einstellungen. Ach, alles mögliche, Hypothesen wurden genug geäußert.

Ich legte kein Entwickler-Eid ab, aber es wäre unhöflich gewesen, die Jungs am anderen Ende der Leitung im Stich zu lassen — selbst wenn sie uns die Schuld gaben. Ich war mir zu 99 % sicher, dass das Problem nicht in unseren Lösungen lag, nicht auf unserer Seite. Der 1 %ige Zweifel, dass wir doch einen Fehler gemacht haben, brachte mich in unruhige Gedanken. Aber egal auf welcher Seite das Unglück lag — es musste behoben werden. Die Kunden, egal wie sie waren, mit einem so schweren Datenleck im Stich zu lassen, war zu hart.

Bis drei Uhr morgens arbeiteten wir am Tisch im Restaurant. Wir fügten Events hinzu, insert select — und füllten die Lücken. Wenn du Daten verloren hast, macht man es so — du nimmst die Durchschnittsdaten der vorherigen Tage und fügst sie in die verlorenen ein.

Nach drei Uhr morgens gingen mein Freund und ich zu mir nach Hause und bestellten Bier aus dem Spirituosenladen. Ich saß mit dem Laptop und den Problemen von ClickHouse, während mein Freund mir etwas erzählte. Schließlich war er nach einer Stunde verletzt, weil ich arbeitete und nicht mit ihm Bier trank, und fuhr nach Hause. Klassisch — war für eine Weile der Freund eines DevOps.

Bis 6 Uhr morgens hatte ich die Tabelle neu erstellt, und die Daten begannen zu fließen. Alles funktionierte ohne Verluste.

Danach wurde es schwierig. Jeder beschuldigte den anderen wegen des Datenverlusts. Wenn ein neuer Bug auftrat, bin ich mir sicher, wäre eine Schießerei losgegangen.

In diesem Chaos haben wir endlich angefangen zu verstehen – die Firma dachte, wir seien die Leute, die mit Daten arbeiten und die Tabellensstruktur im Auge behalten. Sie haben die Admins mit den DBAs verwechselt. Und kamen dazu, uns auf eine Weise zu fragen, die nicht gerade die der Admins war.

Ihre Hauptbeschwerde war – wie zur Hölle, ihr wart für die Backups verantwortlich und habt sie nicht richtig gemacht, habt die Daten vermasselt. Und das alles mit einer Menge Flüchen.

Ich wollte Gerechtigkeit. Ich habe die Korrespondenz ausgegraben und alle Screenshots angehängt, wo Leonid mit aller Kraft darauf bestand, dass genau das Backup gemacht wird, das erstellt wurde. Ihr CTO stellte sich nach meinem Telefonat auf unsere Seite. Auch Lenya gab später seine Schuld zu.

Der Chef der Firma hingegen wollte seine Leute nicht beschuldigen. Screenshots und Worte hatten keinen Einfluss auf ihn. Er war der Meinung, dass wir, da wir Experten sind, alle überzeugen und auf unserer Entscheidung bestehen sollten. Offenbar gehörte es zu unserer Aufgabe, Lenya zu schulen und zudem, ohne ihn – der als Projektleiter eingesetzt wurde – zum Hauptverantwortlichen zu gehen und ihm persönlich all unsere Zweifel an dem Konzept der Backups mitzuteilen.

Der Chat war durchzogen von Hass, sowohl versteckter als auch offener Aggression. Ich wusste nicht, wie ich reagieren sollte. Alles war in eine Sackgasse geraten. Und dann wurde mir der einfachste Weg geraten – dem Leiter eine private Nachricht zu schreiben und ein Treffen mit ihm zu vereinbaren. Vasya, die Leute sind im echten Leben nicht so dreist wie im Chat. Auf meine Nachricht antwortete der Chef: Komm vorbei, kein Problem.

Das war das furchtbarste Treffen in meiner Karriere. Mein Verbündeter vom Kunden – der CTO – konnte keine Zeit finden. Ich fuhr zum Treffen mit dem Chef und Lenya.

Immer wieder durchging ich in Gedanken unseren möglichen Dialog. Ich schaffte es, stark zu früh zu kommen, eine halbe Stunde. Nervös begann ich zu rauchen und rauchte 10 Zigaretten. Ich wusste, alles – ich bin ganz allein. Ich würde sie nicht überzeugen können. Und betrat den Aufzug.

Während ich nach oben fuhr, zündete ich so heftig mit meinem Feuerzeug, dass ich es kaputt machte.

Am Ende war Lenya beim Treffen nicht da. Aber wir haben hervorragend mit dem Hauptverantwortlichen gesprochen! Sergey erzählte mir von seinem Schmerz. Er wollte nicht "ClickHouse automatisieren" – er wollte, "dass die Abfragen funktionieren".

Ich sah keinen Bösewicht, sondern einen netten Kerl, der sich um sein Geschäft sorgt und rund um die Uhr arbeitet. Der Chat zeichnet uns oft als Bösewichte, Betrüger und Trottel. Aber im echten Leben sind das genau die gleichen Menschen wie du.

Sergey benötigte nicht nur ein paar DevOps, die eingestellt wurden. Das Problem, das sie hatten, war viel größer.

Ich sagte, dass ich seine Probleme lösen kann – es ist nur eine ganz andere Aufgabe, und dafür habe ich einen Bekannten, der DB-Engineering macht. Hätten wir von Anfang an gewusst, dass dies für sie ist, hätten wir viel vermeiden können. Es ist spät, aber wir haben verstanden, dass das Problem in der mangelhaften Datenarbeit lag und nicht in der Infrastruktur.

Wir haben uns die Hände geschüttelt, unsere Bezahlung wurde um das Zweieinhalbfache erhöht, aber unter der Bedingung — ich übernehme den gesamten Aufwand mit ihren Daten und Clickhouse. Im Aufzug schrieb ich mit dem besagten DB-Engineer Max und schloss ihn in die Arbeit ein. Es musste der gesamte Cluster umgebaut werden.

Im angenommenen Projekt gab es einen Haufen Quatsch. Begonnen mit dem erwähnten "Backup". Es stellte sich heraus, dass dieser "Backup"-Cluster nicht isoliert war. Alle möglichen Tests wurden darauf durchgeführt, manchmal wurde es sogar in die Produktion eingeführt.

Die internen Entwickler haben ihren eigenen benutzerdefinierten "Daten-Insertor" erfunden. Er arbeitete so: Er batchte Dateien, startete ein Skript und schüttete die Daten in eine Tabelle. Aber das Hauptproblem war, dass eine riesige Menge an Daten für eine einzige einfache Anfrage benötigt wurde. Die Anfrage verband die Daten sekündlich. Alles für eine Zahl – die Summe des Tages.

Die internen Entwickler verwendeten das Analysewerkzeug nicht korrekt. Sie gingen zu Grafana, schrieben ihre königliche Anfrage. Diese lud Daten von zwei Wochen herunter. Es entstand ein schöner Graph. In Wirklichkeit wurde die Datenanfrage jedoch alle 10 Sekunden ausgeführt. Das sammelte sich in einer Warteschlange, da Clickhouse die Verarbeitung einfach nicht bewältigte. Dort verbarg sich die Hauptursache. In Grafana funktionierte nichts, die Anfragen standen in der Warteschlange, ständig kamen alte, irrelevante Daten.

Wir haben den Cluster neu konfiguriert und das Einfügen umgestaltet. Die internen Entwickler haben ihren "Insertor" neu geschrieben, und er begann, die Daten korrekt zu sharden.

Max führte ein vollständiges Audit der Infrastruktur durch. Er entwarf einen Plan für den Übergang zu einem vollständigen Backend. Aber das genügte dem Unternehmen nicht. Sie erwarteten von Max das magische Geheimnis, das es ermöglicht, auf die alte Weise, aber effizienter zu arbeiten. Das Projekt wurde weiterhin von Leonid geleitet, der nichts gelernt hatte. Von dem, was vorgeschlagen wurde, wählte er wieder seine Alternative. Wie immer war das die gewagteste... mutige Entscheidung. Leonid glaubte, seine Firma hätte einen besonderen Weg. Mit vielen Hindernissen und voll von Eisbergen.

Eigentlich trennten wir uns damit — wir haben getan, was wir konnten.

Mit vielen Erfahrungen, die wir aus dieser Geschichte gewonnen haben, haben wir unser Unternehmen gegründet und einige Grundsätze für uns aufgestellt. Jetzt beginnen wir unsere Arbeit niemals so wie damals.

Der DBA Max ist nach diesem Projekt zu uns gestoßen, und wir arbeiten seitdem hervorragend zusammen. Das Projekt mit ClickHouse hat uns gelehrt, vor Beginn der Arbeit eine vollständige und gründliche Prüfung der Infrastruktur durchzuführen. Wir verstehen, wie alles funktioniert, und nehmen dann die Aufgaben an. Und wenn wir früher sofort angefangen hätten, die Infrastruktur zu betreuen, machen wir jetzt zuerst ein einmaliges Projekt, das uns hilft zu verstehen, wie man sie in einen funktionsfähigen Zustand bringt.

Ja, wir meiden Projekte mit schlechter Infrastruktur. Selbst wenn es viel Geld bringt, selbst wenn es aus Freundschaft ist. Kranke Projekte zu führen, ist unprofitabel. Diese Erkenntnis hat uns zum Wachsen gebracht. Entweder ein einmaliges Projekt zur Instandsetzung der Infrastruktur und danach einen Wartungsvertrag, oder wir lassen es einfach bleiben. Vorübergehend an einem weiteren Eisberg vorbei.

P.S. Wenn Sie Fragen zu Ihrer Infrastruktur haben, lassen Sie gerne eine Anfrage da.

Wir haben 2 kostenlose Audits pro Monat, vielleicht ist gerade Ihr Projekt darunter.

Quelle: habr.com