IT knowledge base
CTRL+F per cercare la tua parola chiave

Debito tecnico. Tutti dicono "impossibile", ma io dico che lo farò

Molto spesso si afferma drammaticamente e pateticamente che è meglio non produrre il debito tecnico - allora non lo si può eliminare. Sì, senza di essa, ovviamente, è meglio. Ma le conseguenze possono ancora essere eliminate e il capo del comitato di programma, Artem Kalichkin, ha condiviso la sua esperienza in quest'area alla conferenza DevOpsConf 2020 .
Potresti chiedere, cosa ha a che fare il debito tecnico con la conferenza DevOps? Puoi parlare di questo, ad esempio, come parte di un ricevimento a buffet DevOps, ma è un concetto così ampio? Abbiamo appreso che Artem si riferisce al debito tecnico come a tutti i cambiamenti e miglioramenti, modifiche infrastrutturali e cambiamenti di processo, cambiamenti nelle strutture del team volti a eliminare le lacune - che sono stati fatti (consapevolmente o meno) come parte del lancio di prodotti e funzionalità e che nel tempo interferirà notevolmente con la vita ...
E poiché queste cose non possono essere risolte senza una salda e sicura coesione tra i reparti di produzione e operazioni, si scopre che questa storia riguarda direttamente DevOps.

Come oso?

Perché sto parlando di questo, qual è il mio diritto? Il fatto è che ho 16 anni della mia vita legati alle operazioni, alla produzione e al debito tecnico in un modo o nell'altro:

Fino al 2004 ho lavorato come programmatrice Java in varie aziende che si occupano di sviluppo software personalizzato, e col tempo ho cominciato a sentirmi, mi scuso per la metafora, una “madre surrogata”. Faccio nascere una specie di prodotto, lo regalo e poi non ne conosco il destino. Questo mi ha reso molto triste, perché volevo conoscere il lato negativo della vita del prodotto: come ciò che creo vive nella produzione. Ho trovato questa opportunità nella compagnia aerea Siberia (allora S7 si chiamava così). Sono arrivato lì come analista di sistemi e ho lasciato la posizione di vicedirettore per l'IT. Mi occupavo dell'implementazione dei prodotti software, dell'introduzione e dell'implementazione di nuove infrastrutture in - ovviamente - produzione.
Nell'aviazione, già in quegli anni, il grado di dipendenza dall'automazione era molto alto. Questa è una delle industrie più avanzate da questo punto di vista - almeno negli anni 2000 era davanti al resto del mondo in questo. Ad esempio, nel 2006, i biglietti stampati sono stati cancellati in tutto il mondo, sono rimasti solo quelli elettronici. E l'attività aeronautica stessa influenza direttamente i processi aziendali, il destino delle persone, per tutta la nostra vita. L'arresto di questi sistemi e infrastrutture porta a conseguenze disastrose per un numero enorme di persone: si tratta di ritardi nelle partenze e problemi con la registrazione. Quindi ho smesso di dormire la notte anche allora. Da 16 anni dormo la notte, rabbrividendo, perché devo garantire la vita dei servizi in produzione, cosa che non si sopporta in alcun modo.
Ma nel tempo, ho ancora capito che voglio occuparmi non solo di operazioni, cioè non solo di problemi operativi, ma anche lo sviluppo è vicino a me. Volevo occuparmi dell'intero ciclo produttivo, che ho trovato presso il Center for Financial Technologies - nell'ambito dei servizi in cui lavoro ora, forniamo un ciclo di produzione completo: dall'idea alla produzione (compresa la produzione stessa), fornitura e disponibilità.
Qui però è diventato ancora più difficile dormire, perché questo è fintech. Non è così semplice, ma i ritardi nella velocità dei pagamenti stanno già causando giusta rabbia tra i clienti. È impossibile parlare di perdita, danno o incoerenza dei dati - questo è in linea di principio inaccettabile con informazioni finanziarie e dati personali (come nelle compagnie aeree, ovviamente).
Dal 2018 sono diventato il direttore tecnico del servizio Faktura.ru - questa è una banca Internet per persone fisiche e giuridiche. E a tutto il resto, il fattore di carico elevato è stato aggiunto al mio bagaglio, ovvero 10000+ tps, afflusso improvviso di utenti e attività dell'utente completamente folle, incomprensibilmente correlate, in produzione. Questa è la mia vera vita ora: sono responsabile sia della produzione che del funzionamento.
E strada facendo, ho sempre lottato per la qualità del prodotto, perché mi piace ancora dormire la notte. Ho lottato per garantire che il tempo e gli sforzi siano dedicati al miglioramento della qualità del prodotto e all'eliminazione delle lacune tecnologiche che sono inevitabili in un modo o nell'altro nelle fasi del progetto.
E voglio condividere questa esperienza, la mia riflessione e le conclusioni a cui sono arrivato dopo 16 lunghi anni, soprattutto sulla base degli ultimi 3 anni in cui ho lavorato a Faktura.ru. Qui sono riuscito a implementare una combinazione interessante, per così dire: una cascata di approcci, e finalmente ho avuto un'idea di come fare il debito tecnico. E questa struttura a cascata è la cosa di cui voglio parlarvi.

Debito tecnico: di chi è?

Ma per cominciare, alla radice del problema, perché parliamo di debito tecnico? Perché siamo molto offesi dal fatto che l'azienda non dedichi tempo a questo. Questo è solo un filo rosso che attraversa tutti i rapporti, gli incontri, le comunicazioni tra sviluppatori e operazioni: un'attività malvagia, cattiva e spaventosa non alloca tempo per lavorare con il debito tecnico. Sorge anche una giusta domanda: "Hanno bisogno di qualità?!" Guardando al futuro, dirò: "Nessuno ha bisogno di qualità", ma svelerò questa idea un po' più tardi, lascia che ti bombardi per ora.
Per analizzare questa situazione, pensiamo: perché gli affari ci fanno questo? E per ottenere una risposta, devi pensare al fatto, ma in generale, il debito tecnico è di chi è il mal di testa? Di chi è?

Dopo anni di partecipazione a tutto questo, capisco che siamo come Frodo, che ha offerto a tutti un anello: aiutami a portare questo fardello! Ci aspettiamo che l'azienda voglia (esattamente voglia), in modo che ci accogliamo il debito tecnico. Ma la causa principale del nostro malinteso con il business è che non lo vuole mai. Per noi, questa è un'interessante sfida ingegneristica, un modo per migliorare l'eccellenza del prodotto o anche un meccanismo per aumentare l'orgoglio per il nostro prodotto. E per gli affari, è sempre un ostacolo, un male inevitabile (o necessità) su cui sprecare.
Immagina di essere salito su un taxi e il tassista ha chiesto: "Passerò all'autolavaggio?"

In questa situazione, sei un'azienda e il tassista siamo noi, gli sviluppatori. Sei indignato: “Com'è?! Pago soldi per il tempo di viaggio e tu vai all'autolavaggio! " Al che il tassista risponde ragionevolmente:
- Non vuoi guidare in un'auto pulita che ha un buon profumo?
- Accidenti, certo che voglio! Ma sto aspettando questo per impostazione predefinita e non sono pronto per andare all'autolavaggio per questo ora!
Ecco come ci percepisce un'azienda con un debito tecnico, come un'offerta per visitare un autolavaggio. Per avere un salone pulito o un salone di lusso, scelgo la categoria appropriata quando ordino un taxi. Nella fase di ordinazione, sono pronto a investire in esso, ma non sono pronto per andare all'autolavaggio. Perché, come ho detto prima, nessuno ha bisogno della qualità. Ma è previsto per impostazione predefinita.
Questo è un dato di fatto e devi procedere da questo. È impossibile accettare e non andare all'autolavaggio, andarci a spese del nostro tempo - ci esauriremo. Cosa fare? Il business è una locomotiva, ha bisogno di caratteristiche, vendite e clienti. La vendita del debito tecnico a un'azienda attraverso il nostro "desiderio" e "desiderio" è impossibile. Ma puoi motivare la tua attività in un altro modo.
Durante il mio viaggio, ho formato tre categorie di motivazione aziendale per "acquistare" debito tecnico:
  • Indifferenza "audace". Quando c'è un ricco investitore, la SEO può permettersi al loro team di sviluppo questi strani smanettoni (ragazzi, ragazze) a cui piacciono alcune delle loro cose: "Beh, lascia che lo facciano! La cosa principale è che il prodotto è realizzato e che lo spirito di squadra è wow, che tutto è fantastico e che siamo il miglior ufficio del mondo". Questo è uno stile libero cool, che, dal mio punto di vista, porta spesso al disastro, perché il debito tecnico richiede pragmatismo. Quando non siamo pragmatici, creiamo un'architettura Leviatana pseudo-cool.
  • Paura. Si tratta di uno dei modelli più efficaci, diffusi ed efficienti per "vendere" il debito tecnico. Di che tipo di "voglia" possiamo parlare qui quando fa paura? Si tratta di quando un gallo arrosto ha beccato - quando è successo qualcosa, il cliente è andato via a causa di un guasto, è stato colpito dai negozi - e tutto questo è dovuto a scarsa qualità, freni o qualcos'altro. Ma anche vendere stupidamente attraverso la paura è un male: la speculazione della paura lavora contro la fiducia. Devi vendere con attenzione e nel modo più onesto possibile, non cercando di abbinare la situazione ai progetti desiderati, ma scegliendo quelli che hanno davvero bisogno di essere affrontati. E gradualmente muoviti verso la formazione della motivazione successiva.
  • La fiducia è quando un'azienda ti dà tutto il tempo di cui hai bisogno per far fronte al debito tecnico. Sì, arcobaleno, unicorni, che vita meravigliosa! È vero, la fiducia funziona e viene mantenuta solo quando sei scrupolosamente piccolo rispetto alla quota totale e prendi questo tempo nel modo più pragmatico possibile. In caso contrario, la fiducia viene distrutta. Inoltre, non si accumula. Questo è un processo costante che va a ondate: la fiducia aumenta e poi svanisce. Pertanto, è impossibile raggiungere l'altopiano della fiducia per rilassarsi. No, questo è il nostro lavoro costante con te, almeno i team leader e i CTO.
E poi ti racconterò la mia esperienza, cosa ne faccio e cosa succede a me e al mio meraviglioso team.

Quanto è profonda la tana del coniglio?

Quando sono arrivato al servizio 3 anni fa, avevo bisogno di capire quanto fosse profonda la tana del coniglio, cioè quanto di questo stesso debito tecnico. Che sia, lo sapevo dalle statistiche delle richieste, comprese quelle di aziende e partner. Avevo bisogno di capire con cosa avevo a che fare in generale. Questo è un primo passo normale e obbligatorio nel processo di lavoro con il debito tecnico: non è necessario affrettarsi a fare la prima cosa che si trova, è necessario analizzare la situazione nel suo insieme.
Sulla base di ciò che ho visto allora, ho avuto il presupposto che uno dei problemi alla radice fosse un sacco di coesione del codice, cioè un accoppiamento molto forte. Ora coinvolgo meno tutti in questo processo, ma poi ho riunito l'intero team di produzione per stabilire quali livelli vogliamo evidenziare nella nostra suite di applicazioni.
La nostra applicazione aveva almeno 80 componenti diversi (distribuzioni, non installazioni). E, dopo averli scomposti in strati (per capire dove stiamo violando i principi di isolamento, ruolo, ecc.), Abbiamo costruito insieme il seguente quadro:

Vedendola, mi sono reso conto che le mie supposizioni erano corrette: abbiamo davvero un accoppiamento abbastanza forte. Questo metodo è anche utile per guardare il tuo sistema nel suo insieme dal punto di vista della sua organizzazione complessiva, poiché dire semplicemente che abbiamo un backend, un frontend e uno storage non è un'ontologia, ma il percorso molto diretto verso un forte accoppiamento. E qui puoi vedere i livelli, che ti permetteranno di formare una sorta di ontologia della piattaforma.
Dopo aver chiarito la situazione, abbiamo dovuto in qualche modo affrontarla.

Fase 1. "Squadre virtuali"

Io, così intelligente, ho capito che avrei fatto finta che tutti avessero tempo, e ho formato una "squadra virtuale" attorno a ciascun componente: "Ragazzi, chi assumerà quale componente? Dai i tuoi suggerimenti su come migliorarlo." Ma per non strisciare lungo l'albero ed essere a fuoco, abbiamo formulato tutti insieme i criteri per ottimizzare la prima fase:
  • Connessione debole;
  • Scalabilità conveniente;
  • Semplice connessione di nuovi sviluppatori (principi semplici e comprensibili: cosa si può fare esattamente in questo componente e cosa no, più l'isolamento del codice che non può essere "toccato" da tutti);
  • Possibilità di "esporre" un'API esterna dove necessario;
  • Disponibilità dello stack tecnologico proposto;
  • ottimizzazioni QuickWin nelle soluzioni attuali;
  • Facilità di monitoraggio e risoluzione dei problemi;
  • Audit + principi di purezza della licenza;
  • Principi di versionamento e deprecazione.
Naturalmente, questo non era un punto focale, ma un insieme di criteri per quasi tutti gli aspetti dello sviluppo del software. L'intero elenco può essere sostituito con una frase: "Ripara tutto". Questa fase si è conclusa con un fallimento, nel senso che non è successo nulla. Abbiamo fatto pochissimi progressi nell'implementare alcune delle cose, perché ho cercato di pianificarle attraverso l'arretrato comune. I compiti erano fangosi e incomprensibili, nella nostra lingua, che il prodotto non voleva affatto capire. Sono stati messi al lavoro manualmente: se io, come responsabile tecnico, sono arrivato alla pianificazione, ho inserito qualcosa nell'arretrato, ma no, non lo è. E mi sono subito reso conto che era difficile per me e per il team, inoltre i conflitti e le controversie erano in costante crescita.
Poi sono passato alla seconda fase.

Fase 2. "Techdolg - è mio"

Come primo passo, ho concordato con l'amministratore delegato del nostro servizio che avremmo introdotto quote di arretrato: spendiamo il 70% sulle funzionalità aziendali, il 15% sull'eliminazione dei difetti e il 15% sullo stesso debito tecnico.
In secondo luogo, nella fase precedente, mi sono reso conto che se tutti rispondono a una domanda, nessuno risponde a questa domanda. Questa non è affatto un'affermazione turchese, non mi piace nemmeno io, ma il contrario richiede un livello di maturità e di lavoro di squadra molto alto, e nelle condizioni di conflitti che si verificavano allora, era prematuro parlarne. Così ho deciso di formare un istituto di piombo tecnologico.
Ma non ho solo nominato una persona come responsabile tecnico del componente. Ho esposto il più possibile le mie aspettative e determinato il loro percorso di sviluppo (e cosa dovrebbe fare il responsabile tecnico) e li ho anche resi responsabili della situazione in produzione. Se il tuo componente sta scherzando in produzione, allora non sono gli OPS che non dormono e tu non dormi, ma non dormi insieme e stai cercando di risolvere la situazione:

E così ci mettiamo in viaggio: ci sono indizi tecnologici, ad es. responsabile e c'è una quota del 15% per il debito tecnico, i.e. c'è tempo. Ma com'era alla fine la realtà?
La prima cosa che abbiamo riscontrato è stata che abbiamo fintech, compliance, separazione dei compiti, cioè non ho e non posso avere accesso alla produzione per definizione. E allo stesso tempo dico: "Ragazzi, siete responsabili della situazione in produzione!"

Dai i log alle persone!

Quando ritieni le persone responsabili, dai loro uno strumento. E questa è la prima cosa che abbiamo fatto insieme agli OPS: fornire i registri ai responsabili tecnici in modo che possano vedere i registri dei loro componenti in battaglia. E abbiamo avuto un'esperienza davvero collaborativa: il nostro primo passo in DevOps, in cui le operazioni e lo sviluppo lavorano insieme. L'operazione prevedeva il trasferimento dei log (Kibana, ecc.), mentre lo sviluppo era necessario per assicurarsi che nei log non vi fossero informazioni sensibili (dati personali, ecc.)

5% - già, considera te stesso fortunato ...

La realtà è che nonostante la quota del 15%, in ogni sprint ci sono dei business critici, delle iniezioni urgenti, perché "Il partner deve farlo adesso o se ne andrà!" Ovviamente, prima di tutto, questo stesso debito tecnologico viene eliminato dallo sprint - di conseguenza, abbiamo avuto sprint con lo 0%. C'erano anche il 15%, ma in media il debito tecnico era solo del 5-8%. Questo è un grosso problema, perché il programmatore non può sapere quanto tempo dovrà implementare.
Da parte mia, ho cercato di aiutare questa situazione, aleggiando instancabilmente come un avvoltoio su tutte le squadre. Abbiamo imparato come raccogliere metriche dettagliate per ogni sprint, di conseguenza ho esaminato il fatto dello sprint e il trigger "sprint hacking" è stato importante per me:

Lo sprint hacking è quando la quota del debito tecnologico viene sistematicamente violata. Se la quota non viene raggiunta in uno sprint, ciò non significa che tutto vada male, anzi, ci sono situazioni diverse e devi essere flessibile. Ma quando questo si ripeteva sistematicamente, raccoglievo prodotti, imprecavo e spiegavo quanto fosse importante e inaccettabile, perché alla fine la quota era stata concordata. Era il mio lavoro quotidiano spostare il processo in quel modello.
E in realtà si è mosso, ma ora credo che questo approccio abbia i suoi, e significativi, inconvenienti.

Limiti dell'approccio


I prodotti sono abituati al fatto che il backlog è tutto loro e si accordano su tutti i compiti: "La quota è buona, ma solo noi decidiamo cosa farà la squadra in questa quota di debito tecnico!" E quando i ragazzi sono venuti con compiti (ricordate la forte connessione), come il refactoring, che devono essere rimossi i boilerplate, gli spaghetti rimossi, ecc., Hanno ricevuto una reazione logica: "Cosa?! Qual è il boilerplate? E c'è una specie di cucina-sala da pranzo qui? Di cosa stiamo parlando ?! "
Di conseguenza, i compiti sono stati sostituiti da quelli che possono essere attribuiti al debito tecnico, ma che sono stati condizionatamente vantaggiosi per il prodotto. Pertanto, ho dovuto prendere una posizione dura e dire: “Techdolg è mio! E sostengo che sarà incluso nel debito tecnico di ogni team di prodotto nella quota del debito tecnico per ogni sprint. E per te lui è una scatola nera".
Questo è il modo in cui abbiamo vissuto. Sebbene la vita e il lavoro fossero normali, la sfiducia è diventata sempre più forte: quando facciamo qualcosa e non lo diciamo a nessuno - questo, e questa volta non viene sprecato in attività lavorative, allora tutti non capiscono quale risultato portiamo.

Dato che le statistiche sull'utilizzo della quota di debito tecnico stavano saltando, ovviamente, ci siamo trovati di fronte al fatto che non potevamo fare grandi argomenti. Inoltre, argomenti di grandi dimensioni richiedono spesso la partecipazione di più team. Anche questo era impossibile, perché nel nostro paese ogni team di prodotto è orientato al proprio prodotto e vive nelle proprie realtà: è impossibile combinarli su un argomento complesso.

Inoltre, nessuno ha incluso la produzione negli sprint: non hanno sprint e arretrati come la produzione. Sono inondati di attività di produzione, ma questo non era incluso nei piani generali. E quando lo sviluppo è arrivato con qualcosa fatto all'interno di quei piccoli pezzi di debito tecnico da implementare in produzione, potrebbe marinare a lungo nelle richieste di OPS. Poiché i ragazzi non avevano davvero tempo e sono carichi di compiti per mancini, vengono tirati e interferiscono con il loro lavoro.
Ma nonostante tutti gli aspetti negativi di questo approccio, siamo riusciti a ottenere molto:

Cosa abbiamo ottenuto

Aumento della massa muscolare negli autotest

Avendo sostanzialmente scremato l'intero processo di CI, lo abbiamo reso civile, di cui non ci vergogniamo. Il grafico mostra come è stato ridotto il costo della regressione.

Aver implementato con successo il controllo del codice spaghetti in molti componenti

Abbiamo realizzato la modularizzazione, ridotto i boilerplate e questo è tutto ciò che non viene affatto venduto all'azienda. Questi compiti non possono essere venduti a un'azienda nemmeno per paura. Se le tue lacune tecnologiche nel prodotto contengono tali problemi e devi risolverli (se lo sono, devono essere fatti prima), allora non hai nemmeno bisogno di provare a venderli. Questo può essere fatto solo attraverso il modello "Techdolg - He's Mine", solo attraverso una quota. Ho visto tentativi molte volte e ho provato a farlo da solo in modo diverso nella prima fase - non ne è venuto fuori nulla.
È vero, il lavoro in questa modalità non può durare a lungo. Questa è una carta bianca limitata che ti dà la leadership, fidandoti di te come CTO e leader del team. Se rimani nel modello della scatola nera, il tuo dovrà affrontare una catastrofe: conflitto, isteria e, nelle peggiori tradizioni delle storie aziendali, può essere il licenziamento. È necessaria una storia breve con una scatola nera, ma deve essere finita molto rapidamente.
Dopo un po' di tempo (circa un anno), mi sono mosso verso l'idea che fosse ora di aprirsi e uscire nel mondo.

Fase numero 3. Progetto "legittimo"

Quindi abbiamo avviato la fase 3 - un progetto "legittimo" per lavorare sul debito tecnico. Si presumeva che ci stessimo allontanando da una quota chiusa, pianificando attraverso un product backlog comune (ovvero, i prodotti accettano che questi progetti debbano essere realizzati) e andando su una vendita netta. Per fare in modo che ciò accada, facciamo due cose:
  • Ho ristretto il più possibile la portata del lavoro che abbiamo iniziato a fare nell'ambito di questo progetto;
  • Ha formulato specifiche aspettative sostanziali su ciò per cui lotteremo nella produzione. Era un rifiuto totale dell'idealismo, perché i nostri compiti dovrebbero essere davvero il più pragmatici possibile, comprensibili e utili al servizio da un punto di vista aziendale.
Un punto importante è che abbiamo una certa illusione che stiamo cercando di calcolare il valore aziendale dal debito tecnico, anche se questo è molto raramente possibile. E se riesci ancora a contarlo, allora abbiamo un debito tecnico da incubo!
Il valore positivo funziona meglio per il business rispetto al valore negativo. Se dici: "Questo cliente se ne andrà, porta così tanti soldi", quindi finché non se ne andrà, non funzionerà. Non è un valore aziendale. Inoltre, la cultura del lavoro con i rischi, soprattutto in Russia, non è ancora molto alta, quindi la modalità è attivata: "Fino a quando non te ne vai, non c'è perdita". Inoltre, non deve mostrare valore aziendale. Dove è possibile mostrare - mostrare, ma puoi mostrare il valore tecnologico, solo dovrebbe essere effettivamente calcolato.

Manuale per la vendita del debito tecnico!

Ho presentato l'intero flusso di lavoro di vendita di questa fase nel diagramma:

Scelta dell'area di interesse degli sforzi (solo uno)

Poiché qui c'è una vendita per paura, scegliamo l'area che bombarda davvero e colpisce la tua attività. Le aree possono essere completamente diverse: accessibilità, velocità delle revisioni, sicurezza nell'esecuzione di test ed esperimenti A / B, costo della revisione: un numero enorme di aree e argomenti.
Nel mio caso la scelta è caduta sull'accessibilità, perché è stata ascoltata dall'azienda e ha avuto un certo impatto sul nostro servizio. È molto importante non essere disperso e scegliere solo un argomento: ognuno di essi è gigantesco e puoi scrivere una tesi su ciascuno.

Fare un'analisi integrale: quanto è profonda una tana di coniglio

Ho analizzato le statistiche sulla disponibilità e le statistiche sugli incidenti per l'anno e ho anche condotto un'analisi dettagliata di tutti i post-mortem per tutte le situazioni che si sono verificate durante l'anno. Successivamente, ho formato una comprensione di alto livello di ciò su cui dobbiamo lavorare nel modo più tecnico possibile, ma ancora una volta in dettaglio.
Ad esempio, abbiamo una situazione in cui, in caso di guasto, caduta, è molto difficile per noi ripartire sotto carico. Relativamente parlando, "mangiamo" la coda più velocemente di quanto abbiamo tempo per avviare tutte le connessioni.
La prima regola dell'accessibilità non è cercare di costruire un sistema che sarà sempre disponibile, ma essere preparati al verificarsi di un incidente. Questo è ciò che dobbiamo garantire.
La seconda domanda e seconda regola fondamentale della scuola dell'accessibilità è l'accordo sul degrado: qualcosa accadrà un giorno, e devi essere pronto a preservare il tuo servizio, magari a costo di abbandonare alcune funzionalità che fornisci - e disattivandolo , sarai in grado di volare più lontano. Questa è una storia classica chiamata accordo di degrado. Questo accordo deve essere sostenuto, anche a livello di programma.
Il terzo problema è legato al monitoraggio e all'osservabilità: questa è la rapida localizzazione delle fonti degli incidenti, oltre al tempo necessario per rilevare una reazione. Se hai molti test di sbattimento, attiverai il "Ragazzo - lupi, lupi!" e smetti di fidarti del tuo monitoraggio. Se nei tuoi test sulla produzione ci sono istruzioni per una reazione del service desk del tipo: "Se non si spegne dopo 5 minuti, chiama", allora non stai monitorando la situazione in produzione. Il test dovrebbe essere il più inequivocabile possibile: "Se ha preso fuoco, significa che c'è un problema da qualche parte, corriamo!"

Decomposizione per l'analisi dei componenti

Per fare ciò, in ogni direzione, per ogni componente, abbiamo formato cosa faremo esattamente: dove trascinare la mesh di servizio, come scuotere il monitoraggio e su quali basi. Qui è elencato il 15%, ma in realtà ci sono molti miglioramenti del software, un ottimo argomento con le vetrine (ottenere dati popolari attraverso le vetrine).
Ok, l'abbiamo sistemato, ma di per sé non è ancora in vendita. Per poter ora uscire e mostrarlo apertamente, per ogni progetto di questa fase noi

Formuliamo indicatori tematici e quantitativi

Abbiamo molta paura degli indicatori quantitativi: come si può misurare la qualità del lavoro degli sviluppatori in termini quantitativi? Abbiamo molti argomenti contro gli indicatori quantitativi, ma non dovremmo prenderli a testa alta, così come il valore non dovrebbe essere percepito solo come valore aziendale. Possono essere formulati, ad esempio, come “non più di X falsi positivi”. È possibile elencare un insieme specifico di componenti per i quali è fondamentale garantire le versioni canary o il rollback garantito delle patch. La disponibilità complessiva, ovviamente, dovrebbe essere quantificabile - questo è un must.

Proteggere i progetti

Con questa serie di progetti pragmatici, le metriche e i risultati più comprensibili a cui dobbiamo arrivare, sono andato a mollare: “Ragazzi, ho bisogno di una quota di debito tecnico. Ho bisogno che tu includa questi progetti nel tuo pool di progetti, per velocizzarli, in modo che vadano in pianificazione generale su una base completamente legale insieme alle attività aziendali. "
È stato ascoltato, l'abbiamo fatto e ha funzionato. Sembra essere come nel video su come disegnare un gufo: "Disegna un ovale e due trattini", e alla fine - magia - si è scoperto un gufo! Ma la magia è che devi archiviare l'intero progetto e trascinarlo fino alla fine. Non è facile fare alcune cose in questa direzione, ma per portarle al risultato finale, cioè è indispensabile raggiungere gli indicatori quantitativi dichiarati e mostrarli. Questo è lo stesso abisso che non può essere saltato al 95%. Devi saltarci sopra completamente.

Vantaggi dell'approccio

E così siamo andati a "saltare" (oltre l'abisso), e nel complesso lo stiamo facendo con successo - ora siamo al secondo round di questo progetto. Cioè, abbiamo trascinato il primo pool di progetti, concordato il secondo pool di progetti. Cosa è cambiato?

Costruire fiducia

Se ci fermiamo e mostriamo numeri reali, la fiducia aumenta notevolmente attraverso l'apertura. Ma la verità è, ovviamente, che le vendite arrivano attraverso la paura. Questo piolo non può essere evitato. Ma non c'è bisogno di temere o vergognarsi neanche di questo. La cosa principale è non speculare con paura, ma analizzare davvero, come ho mostrato in diverse fasi (analisi integrale, analisi delle componenti).

Trascinando argomenti "lunghi"

Dato che questi sono ora progetti legalizzati, possiamo sincronizzarci tra i team e trascinare argomenti molto lunghi. Alcuni argomenti, suddivisi in fasi, sono stati svolti in sequenza da sprint a sprint. Monitoriamo regolarmente (una volta alla settimana) come parte di questo progetto come parte di un team tecnologico e capiamo chi è dove (in quale fase). Questa è l'informazione più aperta e trasparente: lo stato di avanzamento dei progetti e gli stati attuali sono pubblicati e disponibili per i prodotti (e tutti coloro che vogliono vedere).

OPS nel progetto

La cosa più importante è che ci siamo resi conto che abbiamo bisogno di rifare molte cose sia nell'infrastruttura che nel processo di roll-out - e le OPS sono state esplicitamente incluse in questo progetto. A mio avviso, questo è più DevOps che Kubernetes e Docker: quando gli OPS insieme agli sviluppatori discutono su come modificare l'architettura di un componente e gli sviluppatori discutono con gli OPS su come modificare al meglio l'infrastruttura. Nonostante il fatto che abbiamo Infrastructure-as-Code basato su Ansible, e a causa dello stack tecnologico Docker, un po' (e che viene utilizzato principalmente nei processi CI, in battaglia è molto piccolo per i nuovi componenti), questo picco, questa collaborazione è anche uno strumento che puoi usare e con cui lavorare. D'altra parte, da solo non è DevOps, poiché DevOps è proprio un modello di lavoro.

Perché non l'ho fatto subito?

Qui torniamo a quello che ho detto alla fine della Fase 2: prima non avrebbe funzionato. Perché ciò che abbiamo trascinato nella fase 2 - quel codice di spaghetti che abbiamo arato, quei test di costruzione muscolare e processi di CI che spalano - non sarebbe possibile vendere all'azienda in termini di indicatori misurabili. Quella situazione non era associata a nessuna paura particolare, e il nostro argomento standard: "Abbiamo visto per molto tempo, perché il codice degli spaghetti" - nessuno dell'azienda ascolta: "Sì, i programmatori piagnucolano sempre!" Pertanto, non potevamo trascinare quella storia attraverso questo approccio.
Dal mio punto di vista, se la tua piattaforma tecnologica richiede una rielaborazione infrastrutturale così profonda, allora la fase 2 - la modalità scatola nera - non puoi evitare. Devi andarci, ma essere pronto non solo a svolazzare costantemente come un aquilone, ma anche a chiudere questo negozio abbastanza velocemente da non perdere la fiducia della tua attività.

Qual'è il risultato?

Disponibilità del servizio (agosto e settembre 2020) = 100%:

  • Se confrontiamo con le situazioni che esistevano prima di agosto e dove non era al 100%, il tempo per eliminare gli incidenti è diminuito.
  • Ora non ci troviamo in una situazione di thread occupati, quando non capiamo affatto dove sta succedendo e perché.
  • Ora è molto più facile per noi riavviare con il clustering onnipresente, implementare patch, funzionalità, ecc.
  • È stato creato un substrato sistemico per garantire che l'accessibilità sia a un livello molto elevato. Anche se, come persona che ha trascorso 16 anni sull'accessibilità, sono convinto che non si possa parlare e aspettarsi che non ci saranno incidenti. Devi essere pronto per loro, adattandoti costantemente a loro.

Chiamate in corso

Cosa mi preoccupa adesso? Abbiamo un secondo round nella terza fase e credo che sia ora di finirlo: l'approccio di questa fase dopo il secondo round si esaurirà e dobbiamo cercare qualcosa di nuovo, un altro approccio.
Perché? Perché ora sto guardando:
  • Pressione locale sugli ingegneri nei team di prodotto e business per farlo, più velocemente, per creare nuovo debito tecnico.
  • Questo approccio, quando si progettano nuove soluzioni di integrazione tra i team, non ne garantisce la qualità.
  • Defocalizzazione delle iniezioni di debito tecnico. Gli stessi responsabili della tecnologia hanno iniziato a dire: "Ho questo nel mio progetto, ma ora è più importante fare questo debito tecnologico". Vedo come abbiamo iniziato a soccombere e a perdere la concentrazione.
  • La fiducia... ricomincia a fluttuare: "Non è chiaro cosa stia succedendo nel progetto". Nonostante il fatto che tutto sia aperto, i prodotti stanno iniziando a dirlo: la stanchezza si è accumulata e alcune funzionalità aziendali stanno aspettando dietro le quinte. È necessario non solo entrare nella fase della fiducia, è necessario mantenere costantemente questa fase.

Quindi come si costruisce la fiducia?

  • Conferma dell'esperienza (fit => drag!) Hai davvero bisogno di vivere in un regime che solo il 100% salta l'abisso.
  • Flessibilità e adattabilità (supporto per MVP, A/B, ipotesi, isolamento @code). Pur insistendo sulla qualità della soluzione, è necessario fornire flessibilità, rendendosi conto che se "ricodifichiamo" qui ora, può influire sull'intero modulo. Dobbiamo capire come isolare il "codice merda" per testare ipotesi e qualcos'altro. Questo è il nostro compito con voi, nessuno lo farà per noi, e non c'è nessuno da incolpare per il fatto che la nostra architettura non lo consente. Solo noi stessi possiamo cambiarlo - e dobbiamo cambiarlo.
  • Il risultato è misurabile. Quando abbiamo criteri trasparenti su ciò che non possiamo scendere al di sotto e su come miglioriamo, e quando siamo pronti a muoverci, adattandoci alla situazione aziendale, otteniamo questa stessa fiducia.
Nella vita reale, dovremo ripetere questo ciclo costantemente, perché poi ricompaiono i fumi. Facciamo tutti qualcosa di completamente incomprensibile per gli affari, e questo è normale 3 è il nostro orgoglio ingegneristico che siamo così incomprensibili e complessi. Ma è per questo che ci vuole una così grande quantità di lavoro:

conclusioni

Come voglio concludere il mio discorso:
  • Nessuno ha davvero bisogno della qualità... Perché tutti si aspettano la qualità predefinita .
  • Il programmatore non è in galera, nessuno lo giustizierà e nessuno gli farà del male fisicamente. L'ammortamento non è praticamente praticato da nessuna parte: non ho mai lavorato in un'azienda in cui lo fosse. Ma cosa costringe un programmatore a scrivere codice errato? Decide di farlo da solo . Forza il suo stato interiore: "Dal momento che non mi dai il tempo di scrivere bene, allora scriverò direttamente a g... oh!" Ma quando il tempo stringe, puoi scrivere un po' peggio, ma comunque codice buono e di alta qualità. Criteri appropriati ti aiuteranno a farlo. E già dipendono da noi, questa è la nostra responsabilità.
  • Non importa come percepiamo il fatto che un'azienda non alloca tempo per il debito tecnico, questa non è una scusa per non lavorarci. Devi cercare di eliminare il debito tecnologico e garantire costantemente la qualità del prodotto, qualunque cosa accada: questa è la nostra responsabilità diretta , il nostro lavoro diretto con te, almeno, direttori tecnici, responsabili tecnici e persone che ne sono responsabili.

Il 28 gennaio alle 19:00 ora di Mosca ti aspettiamo al meetup online congiunto di Ontico e Deutsche Telekom IT Solutions: DevOps Life Cycle . La partecipazione è gratuita, è necessaria la registrazione
Relatori - ingegneri e responsabili tecnici di Deutsche Telekom IT Solutions:

  • Lev Goncharov - Lead Expert Software Engineer
  • Konstantin Grigel - Lead Configuration Manager Expert
  • Vladimir Muravyov - Responsabile della configurazione principale


Imparerai come Deutsche Telekom IT Solutions trova i colli di bottiglia, utilizza le metriche, cerca soluzioni per diversi casi e prepara IAC. Parleremo dei cicli di vita dei prodotti e discuteremo dei problemi che sorgono a diverse iterazioni dei cicli di vita, delle pipeline e dei flussi di lavoro e degli approcci per risolverli.
E alla DevOpsConf 2021, continuiamo ad accettare richieste di report. La conferenza si svolgerà dal 20 al 21 maggio al Radisson Slavyanskaya.
Aspettiamo le vostre candidature !