Questa è la storia che ha cambiato per sempre il mio approccio al lavoro di DevOps. Ancora nei tempi pre-COVID, molto prima di tutto questo, quando io e i ragazzi stavamo appena iniziando la nostra attività e lavoravamo come freelance su progetti casuali, mi è arrivata una proposta su Telegram.
L'azienda che ce l'ha inviata si occupava di analisi dei dati. Loro elaboravano ogni giorno migliaia di richieste. Ci hanno contattato dicendo: ragazzi, abbiamo ClickHouse e vogliamo automatizzare la sua configurazione e installazione. Vogliamo Ansible, Terraform, Docker e che tutto questo sia ospitato su Git. Vogliamo un cluster di quattro nodi con due repliche in ciascuno.
Una richiesta standard, di quelle che se ne vedono a decine, e serve una soluzione standard altrettanto valida. Abbiamo detto 'ok' e dopo 2-3 settimane tutto era pronto. Hanno approvato il lavoro e hanno iniziato a migrare sul nuovo cluster di ClickHouse con il nostro strumento.
Nessuno di loro voleva e sapeva come gestire ClickHouse. All'epoca pensavamo che questo fosse il loro problema principale, e quindi il CTO dell’azienda ha dato il via libera al mio team per automatizzare il più possibile il lavoro, in modo da non doverci più mettere le mani.
Abbiamo assistito nel trasferimento e sono emerse altre necessità: impostare backup e monitoraggio. In quel momento, il CTO di questa azienda ha lasciato per un altro progetto, affidandoci come comandante uno dei suoi — Leonid. Leonid non era un ragazzo particolarmente brillante. Un semplice sviluppatore a cui era stata improvvisamente assegnata la responsabilità di ClickHouse. Sembra che questo fosse il suo primo incarico di guida e, davanti a tale onore, gli è venuta la sindrome da star.
Insieme ci siamo messi a lavorare sui backup. Ho suggerito di eseguire immediatamente il backup dei dati di origine. Semplicemente prendere, comprimere e caricare elegantemente su qualche S3. I dati di origine sono oro. C’era anche un’altra opzione: eseguire il backup delle tabelle in ClickHouse, utilizzando il freeze e la copia. Ma Leonid ha concepito la sua soluzione.
Ha dichiarato che avevamo bisogno di un secondo cluster di ClickHouse. E d’ora in poi scriveremo i dati su due cluster: quello principale e quello di backup. Gli ho detto, Leonid, questo non sarà un backup — ma una replica attiva. E se i dati cominciano a andare persi in produzione, anche nel tuo backup succederà la stessa cosa.
Ma Leonid si è aggrappato saldamente al volante e ha rifiutato di ascoltare le mie argomentazioni. Abbiamo a lungo litigato in chat, ma non c'era nulla da fare: Leonid gestiva il progetto e noi eravamo solo dei ragazzi assunti dalla strada.
Noi monitoravamo lo stato del cluster e addebitavamo solo il lavoro degli amministratori. Solo amministrazione di ClickHouse senza intrometterci nei dati. Il cluster era accessibile, i dischi erano in ordine, i nodi andavano bene.
Non sospettavamo ancora di aver ricevuto questo incarico a causa di un terribile malinteso all'interno del loro team.
Il responsabile era insoddisfatto del fatto che ClickHouse funzionasse lentamente e che a volte i dati andassero persi. Ha assegnato al suo CTO il compito di risolvere la questione. Quest'ultimo ha fatto del suo meglio e ha concluso che dovevano semplicemente automatizzare ClickHouse — e tutto sarebbe andato bene. Ma come si scoprì poco dopo — avevano bisogno di tutt'altro che di un team DevOps.
Tutto questo è emerso in modo molto, molto doloroso. E la cosa più frustrante è che è successo nel giorno del mio compleanno.
Venerdì sera. Ho prenotato un tavolo nel mio bar di vini preferito e ho chiamato gli amici.
Pochi minuti prima della scadenza, ci è arrivata la richiesta di creare un'alternativa, l'abbiamo fatta, tutto ok. L'alternativa è passata, ClickHouse ha confermato. Eravamo già pronti per andare al bar e ci scrivono che mancano dei dati. Abbiamo controllato: sembrava ci fosse tutto. E siamo andati a festeggiare.
Al ristorante c'era un gran rumore, tipico del venerdì. Dopo aver ordinato da bere e da mangiare, ci siamo buttati sui divani. Per tutto il tempo, il mio Slack veniva inondato di messaggi. Scrivevano qualcosa sulla mancanza di dati. Ho pensato che 'domani è un altro giorno'. Specialmente oggi.
Verso le undici hanno iniziato a telefonare. Era il direttore dell'azienda... 'Probabilmente vuole congratularsi con me', ho pensato con poca certezza, rispondendo al telefono.
E ho sentito qualcosa del tipo: 'Avete perso i nostri dati! Vi pago, ma non funziona nulla! Eravate responsabili dei backup e non avete fatto niente! Dovete sistemare tutto!' — solo in modo ancora più brusco.
— Sai che ti dico, vai a quel paese! Oggi è il mio compleanno e ora berrò, non mi occupo delle vostre creazioni dilettantesche di cartone!
Non ho detto così. Invece, ho preso il laptop e sono tornato al lavoro.
No, ho bombardato, ho bombardato tantissimo! Ho riempito la chat di pungenti "te l'avevo detto" — perché il backup, che non era affatto un backup, ovviamente non ha salvato nulla.
Con i ragazzi abbiamo trovato il modo di fermare manualmente la registrazione e controllare tutto. Ci siamo veramente accertati che parte dei dati non venisse registrata.
Abbiamo fermato la registrazione, conteggiato il numero di eventi che erano lì per un giorno. Abbiamo aggiunto altri dati, di cui solo un terzo non è stato registrato. Tre shard con 2 repliche. Inserendo 100.000 righe — 33.000 non vengono registrate.
C'era una completa confusione. Tutti si mandavano a quel paese a turno: il primo ad andarci è stato Lenya, seguito da me e dal fondatore dell'azienda. Solo il nuovo CTO cercava di farci allontanare dalle chiamate con urla e di risolvere il problema.
Cosa stesse succedendo realmente — nessuno lo capiva.
Io e i ragazzi siamo rimasti senza parole quando abbiamo capito che un terzo di tutti i dati non solo non veniva registrato — andava perso! Si è scoperto che l'ordine in azienda era tale: dopo l'inserimento, i dati venivano cancellati senza possibilità di recupero, e gli eventi si perdevano a grappoli. Ho immaginato come Sergey trasforma tutto questo in rubli non guadagnati.
Anche il mio compleanno è stato spedito nella spazzatura. Eravamo seduti al bar a generare idee, cercando di risolvere un rebus lanciato. La causa della caduta di ClickHouse non era ovvia. Forse era la rete, forse le impostazioni di Linux. Qualsiasi cosa, le ipotesi erano state piuttosto numerose.
Non avevo prestato giuramento come sviluppatore, ma abbandonare i ragazzi dall'altra parte del filo era scorretto, anche se ci incolpavano di tutto. Ero sicuro al 99% che il problema non fosse nelle nostre soluzioni, ma dalla nostra parte. L'1% di possibilità che avessimo effettivamente sbagliato mi divorava d'ansia. Ma indipendentemente da dove si trovasse il guaio, dovevamo risolverlo. Lasciare i clienti, qualunque fossero, con una così grave perdita di dati era troppo crudele.
Fino alle tre del mattino abbiamo lavorato al tavolino del ristorante. Aggiungevamo eventi, insert select – e via a riempire i vuoti. Quando perdi i dati, si agisce così: prendi i dati medi dei giorni precedenti e li inserisci nei dati persi.
Dopo le tre del mattino, io e un amico siamo andati da me, abbiamo ordinato una birra dal negozio di alcolici. Io ero seduto con il laptop e i problemi di ClickHouse, mentre l'amico mi raccontava qualcosa. Alla fine, dopo un'ora, si è offeso perché stavo lavorando e non bevevo birra con lui, e se n'è andato. Classico: essere l'amico del DevOps.
Entro le 6 del mattino avevo ricreato la tabella da zero e i dati hanno iniziato a fluire. Tutto ha funzionato senza perdite.
Poi è stato difficile. Tutti si accusavano a vicenda per la perdita di dati. Se fosse successo un nuovo bug, sono sicuro che sarebbe iniziata una sparatoria.
In queste discussioni abbiamo finalmente cominciato a capire: in azienda pensavano che fossimo quelli che lavoravano con i dati e si occupavano della struttura delle tabelle. Hanno scambiato gli amministratori con i DBA. E sono venuti a chiederci cose senza trattarci come amministratori.
La loro principale accusa era: che diavolo, voi eravate responsabili dei backup e non li avete fatti correttamente, avete perso i dati. E tutto questo con insulti a non finire.
Volevo giustizia. Ho ritrovato la corrispondenza e ho allegato screenshot dove Leonid ci spinge a fare il backup in modo corretto, come era stato fatto. Il loro CTO si è schierato dalla nostra parte dopo la mia telefonata. Anche Leonid ha poi riconosciuto il suo errore.
Il capo dell'azienda, al contrario, non voleva incolpare i suoi. Schermate e parole non avevano effetto su di lui. Credeva che, dato che eravamo esperti, dovessimo convincere tutti e insistere sulla nostra decisione. A quanto pare, il nostro compito era insegnare a Lenya e, in più, bypassarlo, dato che era stato designato come responsabile del progetto, per arrivare al principale e fargli personalmente sapere tutti i nostri dubbi sulla concezione dei backup.
Il chat si permeava di odio, aggressività nascosta e palese. Non sapevo come comportarmi. Eravamo arrivati a un punto morto. E qui mi è stato consigliato il modo più semplice: scrivere in privato al responsabile e organizzare un incontro con lui. Vasya, le persone nella vita reale non sono così sfacciate come in chat. Il mio messaggio ha ricevuto una risposta dal capo: vieni, nessun problema.
È stato l'incontro più scomodo della mia carriera. Il mio alleato dal cliente — il CTO — non è riuscito a trovare tempo. Stavo andando all'incontro con il capo e Lenya.
Ripetevo nella mia testa il possibile dialogo più e più volte. Riuscii ad arrivare con largo anticipo, mezz'ora prima. È iniziata l'ansia, ho fumato 10 sigarette. Capivo, tutto — ero, cazzo, solo. Non sarei riuscito a convincerli. E ho fatto un passo nell'ascensore.
Mentre saliva, grattando con l'accendino, l'ho rotto.
Alla fine, Leon non era presente all'incontro. E abbiamo parlato alla grande di tutto con il principale! Sergey mi ha raccontato del suo problema. Non voleva "automatizzare ClickHouse" — voleva che le query funzionassero.
Non ho visto un capro espiatorio, ma un bravo ragazzo che si preoccupa per la sua attività, immerso nel lavoro 24/7. Spesso le chat ci dipingono dei villain, dei cattivi e degli scemi. Ma nella vita sono persone come te.
Sergey non aveva bisogno di un paio di devops a noleggio. Il problema che avevano si è rivelato molto più grande.
Ho detto che potevo risolvere i suoi problemi, ma era un lavoro completamente diverso e avevo un DBA di fiducia per quello. Se solo avessimo saputo inizialmente che questo affare era per loro, avremmo evitato molte cose. È tardi, ma abbiamo capito che il problema era nella scarsa gestione dei dati, non nell'infrastruttura.
Ci siamo stretti la mano, la nostra tariffa è stata aumentata di due volte e mezzo, ma con la condizione che io mi occupi assolutamente di tutto il loro lavoro con i dati e ClickHouse. In ascensore ho contattato quel DBA, Max, e l'ho coinvolto nel lavoro. Dovevamo ristrutturare completamente il cluster.
C'erano un sacco di problemi nel progetto accettato, a partire dal menzionato "backup". Si è scoperto che quel "cluster di backup" non era isolato. Era usato per testare di tutto, a volte addirittura in produzione.
Gli sviluppatori interni hanno creato il loro "inseritore" di dati personalizzato. Funzionava così: raggruppava i file, eseguiva uno script e univa i dati in una tabella. Ma il problema principale era che una quantità enorme di dati veniva elaborata per una semplice richiesta. La richiesta univa i dati per ogni secondo. Tutto per ottenere un numero — il totale della giornata.
Gli sviluppatori interni hanno utilizzato in modo errato lo strumento di analisi. Andavano in Grafana, scrivevano la loro complessa query. Questa estraeva dati per due settimane. Ne risultava un grafico bellissimo. Ma in realtà, la richiesta di dati veniva inviata ogni 10 secondi. Tutto questo si accumulava in coda, poiché ClickHouse semplicemente non riusciva a gestire l'elaborazione. Qui si nascondeva la ragione principale. In Grafana, nulla funzionava, le richieste erano in coda e arrivavano costantemente dati obsoleti.
Abbiamo riconfigurato il cluster e riadattato l'inserimento. Gli sviluppatori interni hanno riscritto il loro "inseritore" e ora riesce a shardare i dati correttamente.
Max ha condotto un'analisi completa dell'infrastruttura. Ha delineato un piano per la transizione a un backend completo. Ma questo non è stato soddisfacente per l'azienda. Aspettavano da Max un segreto magico che permettesse di lavorare come prima, ma in modo efficace. Il progetto era sempre sotto la supervisione di Leon, che non aveva imparato nulla. Tra tutte le opzioni proposte, ha scelto di nuovo la sua alternativa. Come sempre, è stata la scelta più audace... La soluzione più audace. Leon credeva che la sua azienda seguisse un percorso speciale. Difficile e pieno di iceberg.
In fondo, è così che ci siamo salutati — abbiamo fatto ciò che potevamo.
Con le esperienze accumulate e arricchiti da questa storia, abbiamo aperto la nostra attività e stabilito per noi alcuni principi. Ora non iniziamo mai più un lavoro come allora.
Dibièyschik Max si è unito a noi dopo questo progetto, e lavoriamo ancora bene insieme. Il caso con ClickHouse ci ha insegnato a condurre un audit completo e approfondito dell'infrastruttura prima di iniziare il lavoro. Ci immergiamo nel funzionamento di tutto e solo dopo accettiamo i compiti. E se prima ci eravamo precipitati a gestire l'infrastruttura, ora facciamo prima un progetto sporadico che aiuta a capire come portarla in uno stato operativo.
E sì, evitiamo progetti con infrastrutture scadenti. Anche se offrono grandi somme, anche se per amicizia. Gestire progetti malati non è redditizio. La consapevolezza di questo ci ha aiutato a crescere. O un progetto sporadico per sistemare l'infrastruttura, seguito da un contratto di assistenza, oppure semplicemente lo ignoriamo. Ignoriamo un altro iceberg.
P.S. Quindi, se avete domande sulla vostra infrastruttura, .
Abbiamo 2 audit gratuiti al mese, e forse il vostro progetto sarà tra quelli.
Fonte: habr.com
