Oto historia, która na zawsze zmieniła moje podejście do pracy w DevOps. Jeszcze w czasach przed COVID-em, dawno, dawno temu, kiedy z chłopakami dopiero myśleliśmy o własnym biznesie i freelancowaliśmy przy przypadkowych projektach, dostałem jedno zapytanie na Telegramie.
Firma, która się tym zajmowała, prowadziła analitykę danych. Codziennie przetwarzała tysiące zapytań. Skontaktowali się z nami z wiadomością: chłopaki, mamy ClickHouse i chcemy zautomatyzować jego konfigurację i instalację. Chcemy Ansible, Terraform, Dockera, a wszystko to ma być w Gicie. Chcemy klastra z czterema węzłami, po dwie repliki w każdym.
Standardowa prośba, takich jest dziesiątki, a rozwiązanie takie samo, dobre jak zawsze. Powiedzieliśmy 'okej' i po 2-3 tygodniach wszystko było gotowe. Przyjęli naszą pracę i zaczęli przenosić się na nowy klaster ClickHouse'a z pomocą naszego narzędzia.
Nikt w ich firmie nie chciał i nie potrafił pracować z ClickHouse'em. Wtedy myśleliśmy, że to ich główny problem, więc CTO firmy po prostu polecił mojemu zespołowi maksymalnie zautomatyzować pracę, aby nigdy więcej nie musieli tam zaglądać.
Towarzyszyliśmy w przeprowadzce, pojawiły się inne zadania — skonfigurować kopie zapasowe i monitoring. W tym momencie CTO tej firmy przeszedł na inny projekt, zostawiając nas z jednym z jego podwładnych — Leonidem. Leonia był chłopakiem nieco mniej uzdolnionym. Zwykły programista, który nagle został szefem od ClickHouse'a. Wydaje się, że to było jego pierwsze powołanie do kierowania czymś, a z nadmiaru zaszczytu pojawiła się u niego choroba gwiazdorska.
Razem wzięliśmy się za kopie zapasowe. Proponowałem, żeby backupować od razu dane źródłowe. Po prostu brać, zipować i elegancko wrzucać na jakiś S3. Dane źródłowe to złoto. Był też inny wariant — aby backupować same tabele w ClickHouse'u przy użyciu zamrożenia i kopiowania. Ale Leonid wymyślił swoje rozwiązanie.
Ogłosił, że potrzebujemy drugiego klastra ClickHouse'a. Od teraz będziemy pisać dane na dwa klastry — główny i zapasowy. Mówię mu, Leonid, to wyjdzie nie backup — a aktywna replika. Jeśli dane zaczną znikać na produkcji, na twoim backupie będzie to samo.
Ale Leonid mocno trzymał się steru i odmówił słuchania moich argumentów. Długo się z nim kłóciłem na czacie, ale nie było nic do zrobienia — Leonid rządził na projekcie, my byliśmy po prostu wynajętymi chłopakami z ulicy.
Obserwowaliśmy stan klastra i pobieraliśmy opłatę tylko za pracę administratorów. Czyste administrowanie ClickHouse bez wkraczania w dane. Klaster był dostępny, dyski w porządku, węzły działały poprawnie.
Jeszcze nie podejrzewaliśmy, że otrzymaliśmy to zlecenie w wyniku strasznego nieporozumienia w ich zespole.
Kierownik był niezadowolony, że ClickHouse działa wolno i czasami dane się gubią. Powierzył swojemu CTO zadanie rozwiązania problemu. Ten, jak mógł, zajął się sprawą i doszedł do wniosku, że wystarczy zautomatyzować ClickHouse – i to wszystko. Jak się wkrótce okazało, potrzebowali zupełnie innego zespołu devops.
Wszystko to okazało się bardzo, bardzo bolesne. A najgorsze, to był mój dzień urodzin.
Piątek, wieczór. Zarezerwowałem stolik w ulubionym barze winowym i zaprosiłem kumpli.
Prawie przed wyjściem dostajemy zadanie zrobić alternatywę, wykonujemy, wszystko w porządku. Alternatywa przeszła, ClickHouse potwierdził. Już planowaliśmy wyjście do baru, a tu piszą, że brakuje danych. Policzyliśmy – wszystko się zgadza. I poszliśmy świętować.
W restauracji było typowo piątkowo hałaśliwie. Zamawiając napitki i jedzenie, rozsiadaliśmy się na kanapach. Cały czas mój Slack niespodziewanie zalewały wiadomości. Piszli coś o brakujących danych. Pomyślałem – co będzie, to będzie. Szczególnie dzisiaj.
Blisko jedenastej zaczęli już dzwonić. To był kierownik firmy… „Na pewno postanowił mnie pogratulować”, pomyślałem bardzo niepewnie i odebrałem telefon.
I usłyszałem coś w stylu: „Zmarnowaliście nasze dane! Płacę wam, a nic nie działa! Odpowiadaliście za kopie zapasowe i nie zrobiliście nic! Naprawiajcie!” – tylko jeszcze grubiej.
– Wiesz co, idź do diabła! Dzisiaj są moje urodziny, teraz będę pić, a nie zajmować się waszymi amatorskimi wynalazkami z gówna i patyków!
Tak tego nie powiedziałem. Zamiast tego wyjąłem laptopa i zabrałem się do pracy.
Nie, byłem wściekły, byłem strasznie wściekły! Sypałem w czat z ironicznymi „mówiłem” – bo kopia zapasowa, która wcale nie była kopią zapasową, oczywiście, nic nie uratowała.
Wymyśliliśmy z chłopakami, jak ręcznie zatrzymać zapis i wszystko sprawdzić. Rzeczywiście upewniliśmy się, że część danych nie jest zapisywana.
Zatrzymaliśmy nagrywanie, policzyliśmy liczbę zdarzeń, które tam leżą przez dzień. Dodaliśmy jeszcze danych, z których tylko jedna trzecia została zarejestrowana. Trzy shard'y po 2 repliki. Wstawiasz 100.000 wierszy – 33.000 nie jest zapisywanych.
Panował kompletny chaos. Wszyscy na przemian wysyłali siebie nawzajem na ...: najpierw poszedł tam Leń, potem ja sam i założyciel firmy. Tylko dopiero co przybyły CTO próbował wyciągnąć nasze rozmowy telefoniczne z krzykami i korespondencję w poszukiwaniu rozwiązania problemu.
Nikt tak naprawdę nie wiedział, co się działo.
Z chłopakami był zszokowani, kiedy zdaliśmy sobie sprawę, że jedna trzecia wszystkich danych nie tylko nie była zapisywana – po prostu ginęła! Okazało się, że porządek w firmie był taki: po wstawieniu dane były nieodwracalnie usuwane, zdarzenia znikały partami. Wyobraziłem sobie, jak Siergiej przelicza to wszystko na utracone ruble.
Moje urodziny również poszły na śmieci. Siedzieliśmy w barze i generowaliśmy pomysły, próbując rozszyfrować rzucony rebus. Przyczyna spadku Clickhouse'a nie była oczywista. Może to sieć, może to kwestia ustawień Linuksa. W zasadzie, wszystko mogło być przyczyną, hipotez padło wystarczająco dużo.
Nie złożyłem przysięgi programisty, ale porzucenie chłopaków po drugiej stronie kabla byłoby nie w porządku – nawet jeśli obwiniali nas za wszystko. Byłem w 99% pewien, że problem leży nie w naszych rozwiązaniach, nie po naszej stronie. 1% szansy, że to jednak my się pomyliliśmy, palił niepokojem. Ale niezależnie od tego, po której stronie tkwił problem – trzeba to było naprawić. Zostawianie klientów, jakimi by nie byli, z tak poważnym wyciekiem danych – to zbyt okrutne.
Pracowaliśmy do trzeciej rano przy stoliku w restauracji. Dodawaliśmy zdarzenia, insert select – i zaczęliśmy wypełniać luki. Kiedy straciłeś dane, postępujesz tak – bierzesz średnie dane z poprzednich dni i wstawiasz je w stracone.
Po trzeciej rano poszliśmy z kumplem do mnie do domu, zamówiliśmy piwko z sklepu monopolowego. Siedziałem z laptopem i problemami Clickhouse'a, a kumpel coś mi opowiadał. W rezultacie, po godzinie obraził się, że pracuję, a nie piję piwa z nim i odjechał. Klasyka – był przyjacielem devopsa.
Do szóstej rano na nowo stworzyłem tabelę i dane zaczęły się zalewać. Wszystko zaczęło działać bez strat.
Dalej było ciężko. Wszyscy obwiniali się nawzajem o utratę danych. Gdyby pojawił się nowy błąd, jestem pewien, że zaczęłaby się strzelanina.
W tych kłótniach w końcu zaczęliśmy rozumieć - w firmie myśleli, że jesteśmy tymi facetami, którzy pracują z danymi i pilnują struktury tabel. Pomyliłem administratorów z DBA. I przyszli pytać nas, jakbyśmy byli administratorami.
Ich główna pretensja - jakie do diabła, odpowiadaliście za kopie zapasowe i nie zrobiliście ich dobrze, straciliśmy dane. I to wszystko z przekleństwami.
Chciałem sprawiedliwości. Wykopałem korespondencję i dołączyłem wszystkie zrzuty ekranu, gdzie Leonid ze wszystkich sił namawiał na zrobienie takiej kopii zapasowej, jaka została wykonana. Ich CTO stanął po naszej stronie po moim telefonie. Później Lenya przyznał się do winy.
Kierownik firmy, przeciwnie, nie chciał obwiniać swoich. Zrzuty ekranu i słowa na niego nie działały. Uważał, że skoro jesteśmy ekspertami, to powinniśmy przekonać wszystkich i upierać się przy swoim rozwiązaniu. Wygląda na to, że naszym zadaniem było nauczenie Lenyi i przy tym, omijając go, wyjaśnienie głównemu wszystkiego, co myślimy o koncepcji kopii zapasowych.
Czata była przesiąknięta nienawiścią, ukrytą i jawną agresją. Nie wiedziałem, co robić. Wszystko utknęło w martwym punkcie. I wtedy ktoś polecił mi najprostszy sposób - napisać bezpośrednio do kierownika i umówić się na spotkanie. Własia, ludzie w życiu nie są tacy bezczelni, jak w czacie. Na moją wiadomość szef odpowiedział: przyjedź, nie ma sprawy.
To było najdziwniejsze spotkanie w mojej karierze. Mój sojusznik z klienta - CTO - nie mógł znaleźć czasu. Na spotkanie jechałem do szefa i Leny.
Raz za razem przewracałem w głowie nasz możliwy dialog. Udało mi się przyjechać znacznie wcześniej, na pół godziny. Zaczęły się nerwy, wypaliłem 10 papierosów. Rozumiałem, że wszystko - jestem sam. Nie uda mi się ich przekonać. I wszedłem do windy.
Podczas wjazdu tak pstryknąłem zapalniczką, że ją złamałem.
W efekcie Léna na spotkaniu nie było. I świetnie porozmawialiśmy ze szefem! Sergiej opowiedział mi o swoim bólu. Nie chciał "automatyzować ClickHouse" - chciał "żeby zapytania działały".
Nie zobaczyłem w nim kozła ofiarnego, a dobrego faceta, który przeżywał za swój biznes, zanurzonego w pracy 24/7. Czata często przedstawia nam złoczyńców, drań i głupków. Ale w życiu to tacy sami ludzie, jak Ty.
Sergiej nie potrzebował tylko dwóch devopsów w pracy. Problem, który mieli, okazał się znacznie większy.
Powiedziałem, że mogę rozwiązać jego problemy - to po prostu zupełnie inna praca, a dla niej mam znajomego DBA. Gdybyśmy początkowo wiedzieli, że to zadanie dla nich, moglibyśmy uniknąć wielu trudności. Za późno, ale zrozumieliśmy, że problem leżał w kiepskiej pracy z danymi, a nie w infrastrukturze.
Uścisnęliśmy sobie dłonie, a wynagrodzenie wzrosło nam dwukrotnie, ale pod warunkiem - biorę na siebie cały kłopot z ich danymi i ClickHouse'em. W windzie skontaktowałem się z tym samym DBA, Maxem, i włączyłem go do pracy. Musiałem przekształcić cały klaster.
W przyjętym projekcie było mnóstwo szaleństw. Zaczynając od wspomnianego „backup’u”. Okazało się, że ten sam klaster „backup’owy” nie był izolowany. Testowano tam wszystko, czasem nawet uruchamiano w produkcji.
Prowadzący deweloperzy stworzyli swoje własne „wstawiające” narzędzie danych. Działało to tak: zbierało pliki, uruchamiało skrypt i wstawiało dane do tabeli. Głównym problemem było to, że ogromna ilość danych była przetwarzana dla jednego najprostsze zapytania. Zapytanie łączyło dane sekundowo. Wszystko dla jednej liczby - sumy dziennej.
Deweloperzy niewłaściwie korzystali z narzędzia do analityki. Wchodzili do Grafany, pisali swoje 'królewskie' zapytanie. Wyświetlało dane za 2 tygodnie. Powstawał piękny wykres. Ale w rzeczywistości zapytanie danych trwało co 10 sekund. Wszystko to gromadziło się w kolejce, ponieważ ClickHouse po prostu nie radził sobie z przetwarzaniem. Tu właśnie kryła się główna przyczyna. W Grafanie nic nie działało, zapytania stały w kolejce, stale przychodziły stare, nieaktualne dane.
Przeorganizowaliśmy klaster, przerobiliśmy wstawianie. Deweloperzy przepisali swoje 'wstawiające' narzędzie i zaczęło ono poprawnie shardować dane.
Max przeprowadził pełny audyt infrastruktury. Opracował plan przejścia na pełnoprawny backend. Ale to nie zadowoliło firmy. Oczekiwali od Maxa magicznego sekretu, który pozwoli pracować w stary sposób, ale efektywnie. Za projekt wciąż odpowiadał Leńka, który niczego się nie nauczył. Z całej propozycji znów wybrał swoją alternatywę. Jak zawsze, była to najbardziej wyrazista... odważna decyzja. Leńka uważał, że jego firma ma szczególną drogę. Ciernistą i pełną lodowców.
Właściwie na tym się rozstaliśmy - zrobiliśmy, co mogliśmy.
Z pełnymi doświadczeniami, mądrzejsi o tę historię, otworzyliśmy własny biznes i sformułowaliśmy dla siebie kilka zasad. Teraz nigdy nie zaczynamy pracy tak, jak wtedy.
Dibiwacz Max dołączył do nas po tym projekcie i wciąż świetnie razem pracujemy. Case z ClickHouse nauczył nas przeprowadzać pełny i gruntowny audyt infrastruktury przed rozpoczęciem pracy. Zgłębiamy, jak wszystko działa, a dopiero potem przyjmujemy zadania. Gdybyśmy wcześniej od razu ruszyli do obsługi infrastruktury, to teraz najpierw realizujemy projekt jednorazowy, który pomaga zrozumieć, jak przywrócić ją do stanu roboczego.
I tak, omijamy projekty z kiepską infrastrukturą. Nawet za duże pieniądze, nawet w ramach przyjaźni. Prowadzenie chorych projektów jest nieopłacalne. Świadomość tego pomogła nam rozwinąć się. Albo jednorazowy projekt na uporządkowanie infrastruktury, a potem umowa na serwis, albo po prostu przechodzimy obok. Obok kolejnego góry lodowej.
P.S. Więc jeśli masz pytania dotyczące swojej infrastruktury, .
Mamy 2 darmowe audyty miesięcznie, być może to właśnie Twój projekt będzie w ich liczbie.
Źródło: habr.com
