Ecco una storia che ha cambiato per sempre il mio approccio al lavoro DevOps. Anche prima del Covid, molto tempo fa, quando io e i ragazzi stavamo solo pensando alla nostra attività e lavorando come freelance su incarichi casuali, mi è arrivata una proposta su Telegram.
L'azienda che ha scritto si occupava di analisi dei dati. Ogni giorno elaborava migliaia di richieste. Sono venuti da noi dicendo: ragazzi, abbiamo ClickHouse e vogliamo automatizzarne la configurazione e l'installazione. Vogliamo Ansible, Terraform, Docker e che tutto questo venga archiviato in Git. Vogliamo un cluster di quattro nodi con due repliche in ciascuno.
Richiesta standard, ce ne sono decine, e serve una soluzione standard ugualmente valida. Abbiamo detto 'ok', e dopo 2-3 settimane tutto era pronto. Hanno accettato il lavoro e hanno iniziato a migrare verso il nuovo cluster di ClickHouse con il nostro strumento.
Nessuno di loro voleva e sapeva occuparsi di ClickHouse. All'epoca pensavamo che fosse questo il loro problema principale, quindi il CTO dell'azienda ha semplicemente dato il via libera alla mia squadra per automatizzare il lavoro il più possibile, in modo da non doverci più mettere le mani.
Abbiamo seguito la migrazione, si sono presentate altre sfide: configurare backup e monitoraggio. In quel momento, il CTO di quella azienda è passato a un altro progetto, lasciandoci come comandante uno dei suoi: Leonid. Leònid non era proprio un ragazzo dotato. Un semplice sviluppatore a cui era stato improvvisamente dato il comando su ClickHouse. Sembrava che fosse il suo primo incarico di gestione, e l'onore che ne era derivato gli aveva dato una malattia da celebrità.
Insieme ci siamo messi al lavoro sui backup. Ho proposto di eseguire il backup dei dati di origine immediatamente. Prenderli, zipparli ed elegantemente archiviarli in qualche S3. I dati di origine sono oro. C'era anche un'altra opzione: eseguire il backup delle stesse tabelle in ClickHouse, tramite freeze e copia. Ma Leònid ha inventato la sua soluzione.
Ha annunciato 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 che, Leònid, non si tratterà di un backup, ma di una replica attiva. E se i dati iniziano a perdersi in produzione, ciò che avrai nel tuo backup sarà lo stesso.
Ma Leònid si è aggrappato saldamente al timone e ha rifiutato di ascoltare i miei argomenti. Abbiamo discusso a lungo nella chat, ma non c'era nulla da fare: Leònid stava conducendo il progetto, noi eravamo solo ragazzi assunti dalla strada.
Abbiamo monitorato lo stato del cluster e abbiamo addebitato solo il lavoro degli amministratori. Amministrazione pura di ClickHouse senza intromissioni nei dati. Il cluster era disponibile, i dischi a posto, i nodi in ordine.
Non avevamo ancora sospettato di aver ricevuto questo ordine a causa di una grave incomprensione all'interno del loro team.
Il dirigente era scontento del fatto che ClickHouse funzionasse lentamente e che a volte i dati andassero persi. Ha incaricato il suo CTO di indagare. Quest'ultimo ha fatto il possibile e ha concluso che era sufficiente automatizzare ClickHouse — e tutto qui. Ma come si è scoperto presto — avevano bisogno di ben altro che di un team di DevOps.
Tutto questo è emerso in modo molto, molto doloroso. E la cosa più frustrante è stata che è successo nel giorno del mio compleanno.
Venerdì sera. Avevo prenotato un tavolo nel mio wine bar preferito e ho chiamato i miei amici.
Quasi prima di uscire ci arriva un compito per fare un alter, lo facciamo, tutto ok. L'alter è andato, ClickHouse ha confermato. Ci eravamo già messi in cammino verso il bar, quando ci scrivono che mancano dei dati. Abbiamo controllato — sembrava che ci fosse tutto. E siamo andati a festeggiare.
Il ristorante era rumoroso come al solito il venerdì. Dopo aver ordinato da bere e mangiare, ci siamo sistemati sui divanetti. Per tutto questo tempo il mio Slack veniva intasato da messaggi. Scrivevano qualcosa sulla mancanza di dati. Ho pensato — domani è un giorno migliore. Soprattutto oggi.
Verso le undici hanno iniziato a chiamare. Era il dirigente dell'azienda… "Probabilmente ha deciso di farmi gli auguri", ho pensato con molta incertezza, rispondendo al telefono.
E ho sentito qualcosa tipo: "Avete perso i nostri dati! Vi pago, ma nulla funziona! Eravate responsabili dei backup e non avete fatto niente! Metteteli a posto!" — solo in modo ancora più scortese.
— Sai cosa, vaffanculo! Oggi è il mio compleanno e ora berrò, non mi metterò a risolvere le vostre stupidaggini da principianti.
Ecco come non ho reagito. Invece, ho preso il laptop e mi sono messo al lavoro.
No, stavo esplodendo, stavo esplodendo rabbiosamente! Scrivevo nel chat messaggi sarcastici tipo "lo avevo detto" — perché il backup, che di backup non aveva nulla, ovviamente non ha salvato niente.
Io e i ragazzi abbiamo trovato un modo per fermare manualmente la registrazione e controllare tutto. Abbiamo effettivamente verificato che parte dei dati non veniva scritta.
Abbiamo interrotto la registrazione, calcolato il numero di eventi che ci sono stati in un giorno. Abbiamo caricato altri dati, di cui solo un terzo non è stato registrato. Tre shard con 2 repliche. Se inserisci 100.000 righe, 33.000 non si registrano.
C'era un completo caos. Tutti si mandavano a quel paese a turno: il primo a farlo è stato Lenya, seguito da me e dal fondatore dell'azienda. Solo il CTO appena entrato cercava di riportare le nostre chiamate e le chat all’ordine per trovare una soluzione al problema.
Nessuno capiva realmente cosa stesse succedendo.
Noi ragazzi siamo rimasti sbalorditi quando abbiamo capito che un terzo di tutti i dati non solo non veniva registrato, ma si perdeva! Si scoprì che nel lavoro dell'azienda era così: dopo l'inserimento i dati venivano eliminati irreversibilmente, e gli eventi si perdeva a tonnellate. Mi sono immaginato come Sergei stesse convertendo tutto questo in rubli non guadagnati.
Anche il mio compleanno finiva nei rifiuti. Eravamo seduti al bar a generare idee, cercando di risolvere l'enigma lanciato. La causa del crollo di ClickHouse non era evidente. Forse era la rete, forse le impostazioni di Linux. Follia, sono emerse abbastanza ipotesi.
Non avevo prestato giuramento da sviluppatore, ma lasciare i ragazzi dall'altra parte del filo era scortese, anche se ci accusavano di tutto. Ero sicuro al 99% che il problema non fosse nei nostri interventi, dalla nostra parte. L'1% di possibilità che fossimo stati noi a sbagliare, però, mi bruciava di preoccupazione. Ma qualunque fosse il lato del problema, dovevamo risolverlo. Lasciare i clienti, qualunque fossero, con una tale perdita di dati era troppo crudele.
Fino alle tre del mattino abbiamo lavorato al tavolo del ristorante. Aggiungevamo eventi, insert select, e ci siamo messi a riempire i buchi. Quando perdi dei dati, si fa così: prendi i dati medi dei giorni precedenti e li inserisci nei dati persi.
Dopo le tre del mattino, il mio amico ed io siamo andati a casa mia, abbiamo ordinato birra dall'alcomarket. Io ero seduto con il laptop e i problemi di ClickHouse, mentre il mio 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, quando un amico del DevOps si fa sentire.
Entro le 6 del mattino avevo ricreato la tabella da capo e i dati hanno cominciato a fluire. Tutto ha funzionato senza perdite.
Dopo è stato difficile. Tutti si accusavano della perdita di dati. Se fosse successo un nuovo bug, sono sicuro che sarebbe iniziata una guerra.
In queste situazioni ci siamo finalmente resi conto che in azienda pensavano che fossimo quelli che lavorano con i dati e si occupano della struttura delle tabelle. Hanno confuso gli amministratori con i DBA. E sono venuti a chiedere informazioni a noi, non come amministratori.
La loro principale lamentela era: come mai, eravate responsabili dei backup e non li avete fatti correttamente, avete perso i dati. E tutto ciò con insulti e parolacce.
Volevo giustizia. Ho riesumato la corrispondenza e allegato tutti gli screenshot, dove Leonid insiste con tutte le sue forze nel fare il backup che era stato eseguito. Il loro CTO è intervenuto a nostro favore dopo la mia telefonata. Alla fine, anche Lenya ha riconosciuto le sue colpe.
Il capo dell'azienda, al contrario, non voleva dare la colpa ai suoi. Gli screenshot e le parole non lo colpirono. Pensava che, essendo degli esperti, avremmo dovuto convincere tutti e insistere nelle nostre decisioni. Evidentemente, faceva parte del nostro compito insegnare a Lenya e, inoltre, bypassarlo, essendo lui il capo progetto, per arrivare al principale e scaricare su di lui tutte le nostre riserve sui backup.
La chat traboccava di odio, aggressività celata e non. Non sapevo cosa fare. Tutto era giunto a un punto morto. E qui mi hanno consigliato il modo più semplice: scrivere in privato al capo e pianificare un incontro. Vasya, le persone non sono così arroganti nella vita reale come in chat. Alla mia risposta, il capo ha risposto: vieni, non c'è problema.
È stato l'incontro più difficile della mia carriera. Il mio alleato dal cliente, il CTO, non ha potuto trovare tempo. Andavo all'incontro con il capo e con Lyosha.
Rivoltavo nella mia mente il possibile dialogo. Sono riuscito ad arrivare con largo anticipo, mezz'ora prima. C'era ansia, ho fumato 10 sigarette. Capivo, tutto, ero totalmente solo. Non sarei riuscito a convincerli. E sono entrato nell'ascensore.
Nel mentre che salivo, strofinando il accendino, l'ho rotto.
Alla fine, Leonid non era presente all'incontro. E noi abbiamo parlato benissimo di tutto con il principale! Sergey mi ha parlato del suo dolore. Voleva non 'automatizzare ClickHouse', ma voleva che 'le query funzionassero'.
Non ho visto un idiota, ma un bravo ragazzo, preoccupato per la sua attività, immerso nel lavoro 24/7. La chat spesso disegna per noi cattivi, traditori e sciocchi. Ma nella vita, sono persone come te.
Sergey non aveva bisogno di un paio di DevOps assunti. Il problema che avevano si è rivelato molto più grande.
Ho detto che posso risolvere i suoi problemi, ma è un lavoro completamente diverso e ho un conoscente DB engineer per questo. Se avessimo saputo fin dall'inizio che si trattava di questa situazione per loro, avremmo evitato molto. È tardi, ma abbiamo capito che il problema risiedeva in un lavoro con i dati scadente, e non nell'infrastruttura.
Ci siamo stretti la mano, il nostro compenso è stato aumentato di due volte e mezzo, ma a condizione che io prenda in carico completamente tutto il lavoro con i loro dati e ClickHouse. In ascensore ho contattato quel DB engineer Max e l'ho coinvolto nel lavoro. Dovevamo riesaminare l'intero cluster.
C'era un sacco di spazzatura nel progetto approvato. A partire dal già citato "backup". Si è scoperto che questo stesso cluster di "backup" non era isolato. Su di esso testavano di tutto, a volte addirittura lo mettevano in produzione.
Gli sviluppatori interni hanno creato il loro 'inseritore' di dati personalizzato. Funzionava così: elaborava file, eseguiva uno script e scaricava i dati in una tabella. Ma il problema principale era che un'enorme quantità di dati veniva richiesta per una semplice query. La query univa i dati al secondo. Tutto per un'unica cifra — il totale per giorno.
Gli sviluppatori interni utilizzavano in modo errato lo strumento di analisi. Andavano su Grafana, scrivevano la loro query grandiosa. Questa estraeva dati per 2 settimane. Ottenevano un grafico bello. Ma in realtà la richiesta di dati avveniva ogni 10 secondi. Tutto ciò si accumulava in coda, poiché ClickHouse non riusciva a gestire l'elaborazione. Qui risiedeva la vera causa. In Grafana niente funzionava, le query rimanevano in attesa, arrivavano costantemente vecchi dati non aggiornati.
Abbiamo riconfigurato il cluster e riprogettato l'inserimento. Gli sviluppatori interni hanno riscritto il loro 'inseritore', e ha iniziato a shardare i dati correttamente.
Max ha effettuato un audit completo dell'infrastruttura. Ha redatto un piano per la transizione a un backend completo. Ma questo non ha soddisfatto l'azienda. Aspettavano da Max un segreto magico che permettesse di lavorare nel vecchio modo, ma in modo efficace. Il progetto era ancora sotto la responsabilità di Leonid, che non aveva imparato nulla. Di tutto ciò che era stato proposto, ha nuovamente scelto la sua alternativa. Come sempre, era la più esclusiva... decisione audace. Leonid credeva che la sua azienda seguisse un percorso speciale. Accidentato e pieno di iceberg.
In sostanza, ci siamo salutati così — abbiamo fatto ciò che potevamo.
Con le teste piene di lividi, saggiati da questa esperienza, abbiamo aperto la nostra attività e stabilito alcuni principi per noi stessi. Oggi non iniziamo mai un lavoro come allora.
Dopo questo progetto, il DB specialist Max si è unito a noi e lavoriamo ancora benissimo insieme. Il caso con ClickHouse ci ha insegnato a condurre un audit completo e approfondito dell'infrastruttura prima di iniziare il lavoro. Comprendiamo come funziona tutto e solo dopo accettiamo i compiti. In passato, se ci fossimo lanciati subito a gestire l'infrastruttura, ora prima realizziamo un progetto a pagamento che ci aiuta a capire come metterla in uno stato operativo.
E sì, evitiamo i progetti con infrastrutture scadenti. Anche se ci sono molti soldi coinvolti, anche se per amicizia. Gestire progetti problematici non conviene. La consapevolezza di questo ci ha aiutato a crescere. O un progetto a pagamento per sistemare l'infrastruttura e poi un contratto di assistenza, oppure semplicemente ci passiamo oltre. Oltre a un altro iceberg.
P.S. Quindi, se avete domande sulla vostra infrastruttura, .
Abbiamo 2 audit gratuiti al mese, forse il vostro progetto sarà uno di questi.
Fonte: habr.com
