Dit is het verhaal dat mijn benadering van DevOps voor altijd heeft veranderd. Al vóór de covid-periode, heel lang geleden, toen mijn vrienden en ik net ons bedrijf begonnen en freelance werk deden op random opdrachten, ontving ik een voorstel via Telegram.
Het bedrijf dat ons heeft benaderd, was bezig met data-analyse. Dagelijks verwerkten ze duizenden verzoeken. Ze kwamen bij ons met de woorden: jongens, we hebben ClickHouse en we willen de configuratie en installatie automatiseren. We willen Ansible, Terraform, Docker en dat alles in Git houden. We willen een cluster van vier knooppunten, elk met twee replicas.
Een standaardverzoek, zoals er tientallen zijn, en we hebben een even goed standaardoplossing nodig. We zeiden 'oké' en na 2-3 weken was alles klaar. Ze hebben het werk goedgekeurd en begonnen met de overstap naar de nieuwe ClickHouse-cluster met behulp van onze tool.
Niemand daar wilde of kon met ClickHouse werken. Toen dachten we dat dit hun belangrijkste probleem was, en daarom gaf de CTO van het bedrijf mijn team de opdracht om het werk zo veel mogelijk te automatiseren, zodat ze daar nooit meer zelf mee bezig hoefden te zijn.
We hielpen bij de verhuizing, er ontstonden andere taken — het instellen van back-ups en monitoring. Op datzelfde moment vertrok de CTO van het bedrijf naar een ander project, waardoor een van zijn medewerkers — Leonid — onze commandant werd. Léon was niet bepaald een briljante jongen. Een gewone ontwikkelaar die plotseling werd aangewezen als leider van ClickHouse. Het lijkt wel zijn eerste aanstelling om iets te leiden, en van de plotselinge eer kreeg hij een beetje een sterallure.
Samen begonnen we met de back-ups. Ik stelde voor om meteen de oorspronkelijke gegevens te back-uppen. Gewoon nemen, zippen en op een elegante manier in een of andere S3 te stoppen. Oorspronkelijke gegevens zijn goud waard. Er was ook een andere optie — de tabellen in ClickHouse back-uppen met behulp van freeze en kopiëren. Maar Léon bedacht zijn eigen oplossing.
Hij verklaarde dat we een tweede ClickHouse-cluster nodig hadden. En voortaan zouden we data op twee clusters schrijven — het primaire en het back-up cluster. Ik zei tegen hem, Léon, dat wordt geen back-up, maar een actieve replica. En als er gegevens verloren gaan in de productie, zal het op je back-up hetzelfde zijn.
Maar Leonya hield stevig vast aan het stuur en weigerde naar mijn argumenten te luisteren. We hebben lang met elkaar gebakkeleid in de chat, maar het hielp niet — Leonya was de leider van het project, wij waren gewoon ingehuurde jongens van de straat.
We hielden het cluster in de gaten en rekenden alleen de werkuren van de beheerders aan. Pure administratie van ClickHouse zonder in de gegevens te duiken. Het cluster was beschikbaar, de schijven waren in orde, de nodes functioneerden goed.
We hadden nog geen idee dat we deze opdracht hadden gekregen door een vreselijk misverstand binnen hun team.
De leidinggevende was ontevreden omdat ClickHouse traag werkte en er soms gegevens verloren gingen. Hij gaf zijn CTO de opdracht om het op te lossen. Deze deed wat hij kon en concludeerde dat ze ClickHouse gewoon moesten automatiseren — en dat was het. Maar zoals later bleek, hadden ze helemaal geen DevOps-team nodig.
Dit alles bleek heel pijnlijk te zijn. En het meest vervelende was dat het op mijn verjaardag gebeurde.
Vrijdagavond. Ik had een tafeltje gereserveerd in mijn favoriete wijnbar en had mijn vrienden uitgenodigd.
Bijna vlak voor vertrek kregen we de taak om een alter te maken, die we uitvoerden, alles was in orde. De alter ging door, ClickHouse bevestigde. We waren al klaar om naar de bar te gaan, maar we kregen te horen dat er gegevens ontbraken. We hebben het nagekeken — het leek alsof alles er was. En toen gingen we feestvieren.
In het restaurant was het vrijdagavond druk. We bestelden drankjes, eten, en vielen op de banken. Terwijl dat allemaal gebeurde, stroomden er langzaam berichten binnen op mijn Slack. Er werd iets geschreven over een tekort aan gegevens. Ik dacht — de ochtend is wijzer dan de avond. Vooral deze avond.
Rond elf uur begonnen ze al te bellen. Het was de leidinggevende van het bedrijf… 'Hij kan me vast komen feliciteren', dacht ik heel onzeker en nam op.
En ik hoorde iets in de trant van: 'Jullie hebben onze gegevens verknald! Ik betaal jullie, maar niets werkt! Jullie waren verantwoordelijk voor de back-ups, en jullie hebben helemaal niets gedaan! Laten we dit oplossen!' — maar nog grover.
— Weet je wat, ga maar naar de verdoemenis! Het is mijn verjaardag, en nu ga ik drinken in plaats van met jullie klotewerk bezig te zijn!
Zo heb ik het niet gezegd. In plaats daarvan pakte ik mijn laptop en ging aan het werk.
Nee, ik was woedend, ik was ontzettend woedend! Ik spuwde in de chat venige 'ik zei het toch' — omdat de back-up, die eigenlijk geen back-up was, natuurlijk helemaal niets redde.
Mijn vrienden en ik hebben een manier bedacht om handmatig de opname te stoppen en alles te controleren. We hebben echt vastgesteld dat een deel van de gegevens niet werd geschreven.
We hebben de opname gestopt, het aantal evenementen geteld dat daar voor de dag was. We hebben nog meer gegevens toegevoegd, waarvan slechts een derde niet werd opgeslagen. Drie shards met 2 replicas. Als je 100.000 rijen invoert, worden er 33.000 niet opgeslagen.
Er was volledige chaos. Iedereen stuurde elkaar afwisselend naar de hel: eerst ging Leon daarheen, daarna volgde ik zelf en de oprichter van het bedrijf. Alleen de net toegezegde CTO probeerde onze gesprekken met geschreeuw en correspondentie in de richting van een oplossing te leiden.
Wat er echt gebeurde, begreep niemand.
We waren helemaal versteld toen we beseften dat een derde van alle gegevens niet alleen niet werd opgeslagen — ze gingen verloren! Het bleek dat de orde in het bedrijf zo was: na invoer werden de gegevens onherroepelijk verwijderd, en evenementen gingen in bulk verloren. Ik stelde me voor hoe Sergey dit allemaal omzet in gemiste roebels.
Mijn verjaardag werd ook weggegooid. We zaten in de bar en genereerden ideeën, terwijl we probeerden de opgeworpen puzzel op te lossen. De reden voor het falen van Clickhouse was niet duidelijk. Misschien was het het netwerk, misschien de instellingen van Linux. Alles was mogelijk, er werden genoeg hypotheses geopperd.
Ik had niet de ontwikkelaarsbelofte afgelegd, maar het was onfatsoenlijk om de jongens aan de andere kant van de lijn in de steek te laten — zelfs al gaven ze ons de schuld. Ik was voor 99% zeker dat het probleem niet in onze oplossingen lag, niet aan onze kant. Die 1% kans dat we het toch verkeerd hadden, brandde van onrust. Maar hoe dan ook, deze situatie moest worden opgelost. Klanten, hoe ze ook waren, met zo'n vreselijke gegevensstroom achterlaten — dat was te wreed.
Tot drie uur 's nachts werkten we aan een tafel in het restaurant. We voegden evenementen toe, insert select — en gingen de gaten vullen. Wanneer je gegevens hebt verloren, doe je het zo — je neemt de gemiddelde gegevens van de voorgaande dagen en voegt ze toe aan de verloren gegevens.
Na drie uur zijn mijn vriend en ik naar mijn huis gegaan, en we bestelden wat bier uit de slijterij. Ik zat met mijn laptop en de problemen van Clickhouse, en mijn vriend vertelde me iets. Uiteindelijk werd hij na een uur boos omdat ik aan het werk was in plaats van bier met hem te drinken, en hij ging weg. Klassieker — een tijdje vriend van de DevOps geweest.
Tegen zes uur 's ochtends had ik de tabel opnieuw aangemaakt en begonnen de gegevens binnen te stromen. Alles werkte zonder verlies.
Het was moeilijk. Iedereen wees naar elkaar voor het verlies van gegevens. Als er weer een bug zou optreden, weet ik zeker dat er een beschieting zou beginnen.
In deze ruzies begonnen we eindelijk te begrijpen — in het bedrijf dachten ze dat wij de jongens waren die met gegevens werken en de structuur van tabellen in de gaten houden. Ze verwarren de admins met DBAs. En kwamen ons vragen, maar niet als admins.
Hun belangrijkste klacht was: hoe kan het dat jullie verantwoordelijk waren voor de back-ups en die niet goed hebben gemaakt, jullie hebben de gegevens verspild. En dat alles vol scheldwoorden.
Ik wilde rechtvaardigheid. Ik vond de correspondentie terug en voegde alle screenshots bij, waar Leonid vol overtuiging eiste dat de back-up zo werd gemaakt als hij was gemaakt. Hun CTO stond aan onze kant na mijn telefoontje. Daarna erkende Leon zijn schuld.
De bedrijfsleider daarentegen wilde zijn mensen niet de schuld geven. Screenshots en woorden deden hem niets. Hij dacht dat, aangezien wij experts waren, we iedereen moesten kunnen overtuigen en op onze beslissing moesten staan. Blijkbaar was het onze taak om Leon te onderwijzen en bovendien om langs hem, de aangewezen projectleider, naar de grote baas te gaan en al onze twijfels over het concept van de back-ups persoonlijk aan hem te uiten.
De chat droop van haat, zowel verborgen als onverbloemd agressief. Ik wist niet wat te doen. Het was vastgelopen. En hier kreeg ik het eenvoudigste advies — stuur een privébericht naar de leidinggevende en maak een afspraak met hem. Vasya, mensen in het echte leven zijn niet zo uitdagend als in de chat. Op mijn bericht antwoordde de baas: kom maar, geen probleem.
Het was de meest ongemakkelijke ontmoeting van mijn carrière. Mijn bondgenoot van de klant — de CTO — kon geen tijd vinden. Op de ontmoeting ging ik naar de baas en Leonid.
Herhaaldelijk draaide ik ons mogelijke gesprek in mijn hoofd. Ik arriveerde een half uur te vroeg. De zenuwen begonnen te stijgen, ik rookte wel 10 sigaretten. Ik begreep, het is voorbij — ik ben, verdomme, alleen. Ik kan ze niet overtuigen. En stapte de lift in.
Terwijl ik omhoog ging, speelde ik zo met mijn aansteker dat ik het brak.
Uiteindelijk was Leonid er niet op de bijeenkomst. Maar we hebben geweldig gesproken met de baas! Sergei vertelde me over zijn pijn. Hij wilde niet 'ClickHouse automatiseren' — hij wilde 'dat de verzoeken werkten'.
Ik zag geen schurk, maar een goede jongen die om zijn bedrijf geeft, 24/7 in zijn werk gedoken is. De chat tekent vaak schurken, slechteriken en domkoppen. Maar in het echte leven zijn het dezelfde mensen als jij.
Sergio had no need for a couple of DevOps hires. The problem they faced turned out to be much bigger.
I said I could solve his problems — it's just that it's an entirely different job, and I have a DB specialist for that. If we had initially known that this was the case for them, we would have avoided a lot. Late, but we realized that the problem lay in the poor data handling and not in the infrastructure.
We shook hands, and our payment was increased two and a half times, but on the condition that I take on all the hassle with their data and ClickHouse. In the elevator, I contacted that same DB specialist Max and brought him on board. We had to overhaul the entire cluster.
There was a lot of trash in the project that was accepted. Starting with the mentioned 'backup'. It turned out that this 'backup' cluster was not isolated. Everything was tested on it, sometimes even pushed to production.
The in-house developers created their custom data 'inserter'. It worked like this: it batched small files, ran a script, and dumped data into the table. But the main problem was that an enormous amount of data was accepted for a single simple query. The query was joining data per second. All for one single number — the total for the day.
The in-house developers incorrectly used the analytics tool. They went to Grafana, wrote their royal query. It fetched data for two weeks. A beautiful graph would result. But in reality, the data request was executed every 10 seconds. It all piled up in the queue since ClickHouse simply couldn't handle the processing. That was where the main issue lay. Nothing worked in Grafana; queries were stuck in the queue, constantly old irrelevant data was coming in.
We reconfigured the cluster and redesigned the insertion. The in-house developers rewrote their 'inserter', and it began to shard data correctly.
Max heeft een volledige audit van de infrastructuur uitgevoerd. Hij heeft een plan opgesteld voor de overgang naar een volwaardige backend. Maar dat voldeed niet aan de verwachtingen van het bedrijf. Ze hoopten dat Max een magisch geheim zou onthullen waarmee ze op de oude manier maar dan efficiënt konden werken. Het project werd nog steeds geleid door Leon, die niks had geleerd. Van alles wat werd voorgesteld, koos hij weer voor zijn alternatieve oplossing. Zoals altijd was het de meest selectieve... gedurfde beslissing. Leon was ervan overtuigd dat zijn bedrijf een speciale weg volgde. Een moeilijke en vol ijsbergen.
Eigenlijk is dat waar we uit elkaar zijn gegaan — we hebben gedaan wat we konden.
Met de nodige ervaring en wijsheid uit dit verhaal startten we ons eigen bedrijf en stelden we een aantal principes op. Tegenwoordig beginnen we nooit meer op dezelfde manier als toen.
De DBA Max voegde zich na dit project bij ons, en we werken nog steeds uitstekend samen. De case met ClickHouse leerde ons om voor de start van een project een volledige en grondige audit van de infrastructuur uit te voeren. We begrijpen hoe alles werkt voordat we taken aannemen. En als we vroeger meteen aan de slag waren gegaan met de infrastructuur, dan doen we nu eerst een eenmalig project dat helpt te begrijpen hoe deze in werking kan worden gesteld.
Ja, we vermijden projecten met slechte infrastructuren. Zelfs niet voor veel geld, zelfs niet uit vriendschap. Het is niet rendabel om zieke projecten te leiden. Dit besef heeft ons geholpen om te groeien. Of een eenmalig project om de infrastructuur in orde te brengen en daarna een onderhoudscontract, of we laten het gewoon voorbijgaan. Voorbij de volgende ijsberg.
P.S. Dus als je vragen hebt over je infrastructuur, .
We hebben 2 gratis audits per maand, mogelijk is jouw project wel een van hen.
Bron: habr.com
