Ecco una storia che ha cambiato per sempre il mio approccio al lavoro devops. Ai tempi pre-Covid, molto, molto prima di loro, quando io e i ragazzi stavamo semplicemente pianificando la nostra attività e lavorando come freelance su ordini casuali, un'offerta è caduta nel mio carrello.
La società che ha scritto questo era una società di analisi dei dati. Ha elaborato migliaia di richieste ogni giorno. Sono venuti da noi con le parole: ragazzi, abbiamo ClickHouse e vogliamo automatizzarne la configurazione e l'installazione. Vogliamo che Ansible, Terraform, Docker e tutto il resto siano archiviati in Git. Vogliamo un cluster di quattro nodi con due repliche ciascuno.
È una richiesta standard, ce ne sono decine e serve una soluzione standard altrettanto valida. Abbiamo detto “ok” e dopo 2-3 settimane tutto era pronto. Hanno accettato il lavoro e hanno iniziato a spostarsi in un nuovo cluster Clickhouse utilizzando la nostra utility.
Nessuno voleva o sapeva come armeggiare con Clickhouse. Poi abbiamo pensato che quello fosse il loro problema principale, e quindi la stazione di servizio dell’azienda ha semplicemente dato il via libera alla mia squadra per automatizzare il più possibile il lavoro, in modo da non andarci mai più io stesso.
Abbiamo accompagnato il trasloco, sono sorti altri compiti: impostare backup e monitoraggio. Nello stesso momento, la stazione di servizio di questa compagnia si è fusa con un altro progetto, lasciandoci con uno dei nostri, Leonid, come comandante. Lenya non era un ragazzo molto dotato. Un semplice sviluppatore che è stato improvvisamente messo a capo di Clickhouse. Sembra che questo fosse il suo primo incarico di gestire qualcosa, e l'onore travolgente lo ha fatto sentire esterrefatto.
Insieme iniziamo a fare i backup. Ho suggerito di eseguire subito il backup dei dati originali. Basta prenderlo, comprimerlo e gettarlo elegantemente in qualche c3. I dati grezzi sono oro. C'era un'altra opzione: eseguire il backup delle tabelle stesse in Clickhouse, utilizzando il blocco e la copia. Ma Lenya ha trovato la sua soluzione.
Ha annunciato che abbiamo bisogno di un secondo cluster Clickhouse. E d'ora in poi scriveremo i dati su due cluster: quello principale e quello di backup. Gli dico, Lenya, che non sarà un backup, ma una replica attiva. E se i dati iniziano a perdere in produzione, lo stesso accadrà sul tuo backup.
Ma Lenya ha afferrato forte il volante e si è rifiutata di ascoltare le mie argomentazioni. Abbiamo chiacchierato a lungo con lui nella chat, ma non c'era niente da fare: Lenya era responsabile del progetto, eravamo solo ragazzi assunti dalla strada.
Abbiamo monitorato lo stato del cluster e addebitato solo il lavoro degli amministratori. Pura amministrazione Clickhouse senza entrare nei dati. Il cluster era disponibile, i dischi andavano bene, i nodi andavano bene.
Non sapevamo di aver ricevuto questo ordine a causa di un terribile malinteso all'interno del loro team
Il manager era scontento del fatto che Clickhouse fosse lento e che talvolta i dati venissero persi. Ha affidato alla sua stazione di servizio il compito di capirlo. Ha capito come meglio poteva e ha concluso che dovevamo solo automatizzare la Clickhouse: tutto qui. Ma come fu presto chiaro, non avevano affatto bisogno di una squadra di devop.
Tutto ciò si è rivelato molto, molto doloroso. E la cosa più offensiva era che era il giorno del mio compleanno.
Venerdì sera. Ho prenotato presso la mia enoteca preferita e ho invitato gli amici.
Quasi prima di partire riceviamo l'incarico di creare un altare, lo completiamo, è tutto ok. Alter superato, clickhouse confermato. Stiamo già andando al bar e ci scrivono che non ci sono dati sufficienti. Abbiamo calcolato che tutto sembra essere sufficiente. E sono partiti per festeggiare.
Il ristorante era rumoroso di venerdì. Dopo aver ordinato cibo e bevande, ci siamo rilassati sui divani. Per tutto questo tempo, il mio tempo libero è stato lentamente inondato di messaggi. Hanno scritto qualcosa sulla mancanza di dati. Ho pensato: la mattina è più saggia della sera. Soprattutto oggi.
Verso le undici cominciarono a chiamare. Era il capo dell'azienda... "Probabilmente ha deciso di congratularsi con me", ho pensato con molta esitazione e ho preso il telefono.
E ho sentito qualcosa del tipo: “Hai incasinato i nostri dati! Ti pago, ma non funziona niente! Eri responsabile dei backup e non hai fatto nulla! Risolviamolo!" - solo ancora più rude.
- Sai una cosa, levati dal cazzo! Oggi è il mio compleanno, e ora berrò e non mi impegnerò nei tuoi prodotti fatti in casa di giugno con schifezze e bastoncini!
Questo è quello che non ho detto. Invece, ho tirato fuori il mio portatile e mi sono messa al lavoro.
No, ho bombardato, ho bombardato da morire! Ha riversato nella chat un caustico "te l'avevo detto" - perché il backup, che non era affatto un backup, ovviamente non ha salvato nulla.
I ragazzi e io abbiamo capito come interrompere manualmente la registrazione e controllare tutto. In realtà ci siamo assicurati che alcuni dati non fossero scritti.
Abbiamo smesso di registrare e contato il numero di eventi che c'erano ogni giorno. Hanno caricato più dati, di cui solo un terzo non è stato registrato. Tre frammenti con 2 repliche ciascuno. Inserisci 100.000 righe: 33.000 non vengono registrate.
C'era completa confusione. Tutti si dicevano a turno di andare a fanculo: Lenya è andata lì per prima, seguita da me e dal fondatore dell'azienda. Solo la stazione di servizio che ha aderito ha cercato di deviare le nostre telefonate e la nostra corrispondenza per trovare una soluzione al problema.
Nessuno capiva cosa stesse realmente accadendo
Io e i ragazzi siamo rimasti semplicemente sbalorditi quando ci siamo resi conto che un terzo di tutti i dati non solo non erano stati registrati, ma erano andati perduti! Si è scoperto che l'ordine in azienda era il seguente: dopo l'inserimento, i dati venivano cancellati irrevocabilmente, gli eventi venivano sprecati in batch. Ho immaginato come Sergei avrebbe convertito tutto questo in rubli perduti.
Anche il mio compleanno è stato gettato nella spazzatura. Ci siamo seduti al bar e abbiamo generato idee, cercando di risolvere il puzzle che ci era stato lanciato. La ragione della caduta di Clickhouse non era ovvia. Forse è la rete, forse sono le impostazioni di Linux. Sì, qualunque cosa tu voglia, ci sono state abbastanza ipotesi.
Non ho prestato giuramento allo sviluppatore, ma è stato disonesto abbandonare i ragazzi dall'altra parte della linea, anche se ci incolpavano di tutto. Ero sicuro al 99% che il problema non risiedesse nelle nostre decisioni, non da parte nostra. L’1% di possibilità che avessimo commesso un errore bruciava di ansia. Ma non importa da quale parte si trovassero i problemi, bisognava risolverli. Lasciare i clienti, non importa chi siano, con una fuga di dati così terribile è troppo crudele.
Lavoravamo al tavolo del ristorante fino alle tre del mattino. Abbiamo aggiunto eventi, inserito la selezione e siamo partiti per colmare le lacune. Quando si sbagliano i dati si fa così: si prendono i dati medi dei giorni precedenti e li si inserisce in quelli sbagliati.
Dopo le tre del mattino, io e il mio amico siamo andati a casa mia e abbiamo ordinato una birra al mercato degli alcolici. Ero seduto con un laptop e problemi con Clickhouse, un amico mi stava dicendo qualcosa. Di conseguenza, dopo un'ora si è offeso perché stavo lavorando e non bevevo birra con lui, e se n'è andato. Classico: ero amico di Devops.
Alle 6 del mattino ho ricreato nuovamente la tabella e i dati hanno iniziato a inondarsi. Tutto ha funzionato senza perdite.
Poi è stato difficile. Tutti si incolpavano a vicenda per la perdita di dati. Se si fosse verificato un nuovo bug, sono sicuro che ci sarebbe stata una sparatoria
In questi scontri abbiamo finalmente iniziato a capire: l'azienda pensava che noi fossimo quelli che lavorano con i dati e monitorano la struttura delle tabelle. Hanno confuso gli amministratori con i rivenditori. E sono venuti a chiederci una cosa diversa dagli amministratori.
La loro lamentela principale è: che diavolo, eri responsabile dei backup e non li hai eseguiti correttamente, hai continuato a sprecare i dati. E tutto questo con i tappetini riavvolgibili.
Volevo giustizia. Ho recuperato la corrispondenza e ho allegato gli screenshot di tutti, dove Leonid con tutte le sue forze li costringe a fare il backup che è stato fatto. La loro stazione di servizio si è schierata dalla nostra parte dopo la mia telefonata. Più tardi Lenya ha ammesso la sua colpa.
Il capo dell'azienda, al contrario, non voleva incolpare i suoi stessi collaboratori. Schermate e parole non hanno avuto alcun effetto su di lui. Credeva che, poiché qui eravamo esperti, dovessimo convincere tutti e insistere sulla nostra decisione. Apparentemente, il nostro compito era insegnare a Lenya e, inoltre, aggirare lui, che era stato nominato responsabile del progetto, per arrivare alla cosa principale e riversargli personalmente tutti i nostri dubbi sul concetto di backup.
La chat trasudava odio, aggressività nascosta e palese. Non sapevo cosa fare. Tutto è fermo. E poi mi hanno consigliato il modo più semplice: scrivere un messaggio personale al manager e fissare un incontro con lui. Vasya, le persone nella vita reale non sono così veloci come lo sono in chat. Il capo ha risposto al mio messaggio: vieni, nessuna domanda.
È stato l'incontro più spaventoso della mia carriera. Il mio alleato del cliente, STO, non è riuscito a trovare il tempo. Sono andato all'incontro con il capo e Lena.
Più e più volte ho rivisto nella mia testa il nostro possibile dialogo. Sono riuscito ad arrivare molto presto, mezz'ora prima. Ho cominciato ad innervosirmi, ho fumato 10 sigarette, ho capito, ecco, sono solo, cazzo. Non riuscirò a convincerli. Ed entrò nell'ascensore.
Mentre si alzava, colpì così forte l'accendino che lo ruppe.
Di conseguenza, Lenya non era presente alla riunione. E abbiamo avuto una bella conversazione su tutto con il capo! Sergei mi ha parlato del suo dolore. Non voleva "automatizzare Clickhouse", voleva "far funzionare le query".
Non ho visto una capra, ma un bravo ragazzo, preoccupato per i suoi affari, immerso nel lavoro 24 ore su 7, XNUMX giorni su XNUMX. La chat spesso ci attira cattivi, mascalzoni e persone stupide. Ma nella vita queste sono persone proprio come te.
Sergei non aveva bisogno di un paio di devop da assumere. Il problema che avevano si era rivelato molto più grande.
Ho detto che avrei potuto risolvere i suoi problemi: è semplicemente un lavoro completamente diverso e ho un amico che lavora per questo. Se avessimo saputo fin dall'inizio che questo era un affare per loro, avremmo evitato molto. È tardi, ma ci siamo resi conto che il problema risiedeva nella pessima gestione dei dati, non nell'infrastruttura.
Ci siamo stretti la mano, ci hanno aumentato lo stipendio due volte e mezza, ma a condizione che io prenda per me tutto il pasticcio con i loro dati e Clickhouse. Nell'ascensore, ho comunicato con lo stesso DI Max e l'ho messo in contatto con il lavoro. È stato necessario spalare l'intero ammasso.
C'era molta spazzatura nel progetto adottato. A cominciare dal citato “backup”. Si è scoperto che questo stesso cluster di “backup” non era isolato. Hanno testato tutto, a volte anche mettendolo in produzione.
I nostri sviluppatori interni hanno creato il proprio inseritore di dati personalizzato. Ha lavorato in questo modo: ha raggruppato i file, ha eseguito lo script e ha unito i dati in una tabella. Ma il problema principale era che per una semplice richiesta veniva accettata un'enorme quantità di dati. La richiesta unisce i dati ogni secondo. Tutto per amore di un numero: l'importo giornaliero.
Gli sviluppatori interni hanno utilizzato lo strumento di analisi in modo errato. Andarono alla grafana e scrissero la loro richiesta reale. Ha caricato i dati per 2 settimane. Si è rivelato un bellissimo grafico. Ma in realtà la richiesta di dati avveniva ogni 10 secondi. Tutto questo si accumulava in coda perché Clickhouse semplicemente non eliminava l'elaborazione. È qui che si nascondeva il motivo principale. In Grafana non funzionava nulla, le richieste erano in coda e arrivavano costantemente dati vecchi e irrilevanti.
Abbiamo riconfigurato il cluster, rifatto l'inserimento. Gli sviluppatori interni hanno riscritto il loro "inseritore" e ha iniziato a suddividere i dati correttamente.
Max ha condotto un audit completo dell'infrastruttura. Ha delineato un piano per la transizione verso un backend a tutti gli effetti. Ma questo non andava bene all'azienda. Si aspettavano da Max un segreto magico che avrebbe permesso loro di lavorare alla vecchia maniera, ma solo in modo efficiente. Lenya era ancora responsabile del progetto e non ha imparato nulla. Da tutto ciò che gli veniva offerto, scelse nuovamente la sua alternativa. Come sempre, questa è stata la decisione più selettiva... coraggiosa. Lenya credeva che la sua azienda avesse un percorso speciale. Spinoso e pieno di iceberg.
In realtà è lì che ci siamo lasciati: abbiamo fatto quello che potevamo.
Pieni di conoscenza e saggezza derivanti da questa storia, abbiamo aperto la nostra attività e formato diversi principi per noi stessi. Non inizieremo mai a lavorare nello stesso modo di allora.
DJ Max si è unito a noi dopo questo progetto e lavoriamo ancora alla grande insieme. Il caso Clickhouse mi ha insegnato come condurre un audit completo e approfondito dell'infrastruttura prima di iniziare il lavoro. Comprendiamo come funziona tutto e solo allora accettiamo i compiti. E se prima ci affrettavamo immediatamente a mantenere l'infrastruttura, ora realizziamo prima un progetto una tantum che ci aiuta a capire come riportarla in condizioni di lavoro.
E sì, evitiamo progetti con infrastrutture scadenti. Anche se per tanti soldi, anche se per amicizia. Non è redditizio portare avanti progetti malati. Capire questo ci ha aiutato a crescere. O un progetto una tantum per mettere in ordine l'infrastruttura e poi un contratto di manutenzione, oppure voliamo via. Oltre un altro iceberg.
PS Quindi, se hai domande sulla tua infrastruttura, .
Abbiamo 2 audit gratuiti al mese, forse il tuo progetto sarà uno di questi.
Fonte: habr.com