È noto che la competenza di un CTO venga verificata solo alla seconda volta che ricopre questo ruolo. Infatti, è una cosa lavorare per anni in un'azienda, evolversi con essa, e, trovandosi sempre nello stesso contesto culturale, acquisire gradualmente maggiore responsabilità. È completamente diverso entrare direttamente nel ruolo di CTO in un'azienda con un bagaglio di criticità legate ai sistemi legacy e a una serie di problemi accuratamente nascosti sotto il tappeto.

In questo senso, l'esperienza di Leon Fayer, di cui ha parlato nel DevOpsConf, non è proprio unica, ma combinata con l'anzianità e il numero di ruoli diversi che ha ricoperto in 20 anni, è molto utile. Di seguito la cronologia degli eventi degli ultimi 90 giorni e molte storie divertenti, delle quali è piacevole ridere quando accadono a qualcun altro, ma non è così divertente affrontarle personalmente.

Leon racconta in modo molto vivido in russo, quindi se avete 35-40 minuti, vi consiglio di guardare il video. La versione testuale per risparmiare tempo è qui sotto.

La prima versione della relazione era una descrizione ben strutturata del lavoro con le persone e i processi, contenente raccomandazioni utili. Tuttavia, non trasmetteva tutte le sorprese incontrate lungo il cammino. Così ho cambiato formato e ho esposto i problemi che si presentavano nella nuova azienda, come un diavolo dalla lampada, e i metodi per risolverli in ordine cronologico.

Un mese prima di

Come molte belle storie, questa è iniziata con dell'alcol. Eravamo in un bar con degli amici, e com'era consuetudine tra i tecnici, ognuno lamentava i propri problemi. Uno di essi aveva appena cambiato lavoro e raccontava delle sue difficoltà sia con la tecnologia che con le persone e il team. Più lo ascoltavo, più capivo che doveva semplicemente assumermi, perché era esattamente questo tipo di problemi che avevo risolto negli ultimi 15 anni. Gli dissi così, e il giorno dopo ci incontrammo già in un contesto lavorativo. L'azienda si chiamava Teaching Strategies.

Teaching Strategies è leader nel mercato dei programmi educativi per bambini molto piccoli, da zero a tre anni. L'azienda tradizionale "cartacea" esiste da circa 40 anni, mentre la versione SaaS digitale della piattaforma ha dieci anni. Recentemente è iniziato il processo di adattamento della tecnologia digitale agli standard dell'azienda. La "nuova" versione è stata lanciata nel 2017 ed era quasi come la vecchia, solo che funzionava peggio.

La cosa più interessante è che il traffico di questa azienda è molto prevedibile: giorno dopo giorno, anno dopo anno, è possibile prevedere con precisione quante persone arriveranno e quando. Ad esempio, tra le 13:00 e le 15:00, tutti i bambini degli asili vanno a dormire, mentre gli insegnanti iniziano a inserire informazioni. E così succede ogni giorno, tranne nei weekend, perché nei weekend quasi nessuno lavora.

Anticipando un po', posso dire che ho iniziato a lavorare durante il periodo di maggiore traffico annuale, il che è interessante per vari motivi.

La piattaforma, che sembrava avere solo 2 anni, aveva un stack piuttosto peculiare: ColdFusion e SQL Server 2008. ColdFusion, se non lo sapete, e probabilmente non lo sapete, è una sorta di PHP enterprise, uscito a metà degli anni '90, e da allora non ne avevo mai più sentito parlare. C'erano anche: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ma il monolite principale funzionava su ColdFusion e SQL Server.

Problemi

Più parlavo con i dipendenti dell'azienda riguardo il lavoro e i problemi che si incontravano, più capivo che i problemi non erano solo di natura tecnica. Va bene, la tecnologia è vecchia — e abbiamo lavorato su tecnologia ancora più obsoleta, ma c'erano problemi con il team e con i processi, e l'azienda stava iniziando a capirlo.

Tradizionalmente, i tecnici erano relegati in un angolo a svolgere il loro lavoro. Ma sempre più business iniziava a passare attraverso la versione digitale. Pertanto, nell'ultimo anno prima del mio arrivo, sono emerse nuove figure in azienda: un consiglio di amministrazione, un CTO, un CPO e un QA director. Cioè, l'azienda ha iniziato a investire nel settore tecnologico.

Le tracce di un'eredità pesante non erano solo nei sistemi. In azienda c'erano processi legacy, persone legacy, cultura legacy. Tutto doveva essere cambiato. Ho pensato che sicuramente non mi sarei annoiato e ho deciso di provare.

Due giorni prima

Due giorni prima dell'inizio del nuovo lavoro, sono arrivato in ufficio, ho compilato gli ultimi documenti, ho incontrato il team e ho scoperto che il team stava affrontando un problema. Consisteva nel fatto che il tempo medio di caricamento delle pagine era salito a 4 secondi, cioè il doppio.

Dalla grafica, era chiaro che era successo qualcosa, anche se non si capiva cosa. Si era scoperto che il problema era nella latenza di rete nel data center: 5 ms di latenza nel data center si erano trasformati in 2 s per gli utenti. Non sapevo perché fosse successo, ma in ogni caso era emerso che il problema era nel data center.

Giorno uno

Sono passati due giorni e nel mio primo giorno di lavoro ho scoperto che il problema non era scomparso.

Per due giorni le pagine si caricavano in media in 4 secondi. Chiedo se hanno scoperto qual è il problema.

— Sì, abbiamo aperto un ticket.
— E?
— Beh, non ci hanno ancora risposto.

Qui ho capito che tutto ciò di cui mi avevano parlato prima era solo la punta dell'iceberg con cui dovevo confrontarmi.

C'è una bella citazione che si addice perfettamente a questo caso:

«A volte per cambiare la tecnologia è necessario cambiare l'organizzazione».

Ma dato che ho iniziato a lavorare nel periodo più trafficato dell'anno, dovevo considerare entrambi i modi di risolvere il problema: sia a breve termine che a lungo termine. E cominciare con ciò che era critico in quel momento.

Giorno tre

Quindi, il caricamento dura 4 secondi, e dalle 13:00 alle 15:00 ci sono i picchi maggiori.

Il terzo giorno, in quel lasso di tempo, la velocità di caricamento sembrava questa:

Dal mio punto di vista, nulla funzionava. Dal punto di vista degli altri, funzionava un po' più lentamente del solito. Ma non è normale che sia così — è un problema serio.

Ho cercato di convincere il team, ma mi hanno risposto che era necessario avere più server. Questo è sicuramente una soluzione al problema, ma non è sempre l'unica e la più efficace. Ho chiesto perché non ci fossero abbastanza server e quale fosse il volume di traffico. Ho estrapolato i dati e ho ottenuto che avevamo circa 150 richieste al secondo, il che rientra fondamentalmente nei limiti ragionevoli.

Ma non bisogna dimenticare che prima di ottenere la risposta giusta bisogna porre la domanda giusta. La mia domanda successiva era: quanti server frontend abbiamo? La risposta mi ha «un po' sorpreso» — avevamo 17 server frontend!

— Scusate se lo chiedo, 150 diviso 17 fa circa 8? Volete dire che ogni server gestisce 8 richieste al secondo e se domani ci saranno 160 richieste al secondo, avremo bisogno di altri 2 server?

Certo, non avevamo bisogno di server aggiuntivi. La soluzione si trovava nel codice stesso, ed era evidente:

var currentClass = classes.getCurrentClass();
return currentClass;

C'era una funzione getCurrentClass(), perché tutto sul sito funziona nel contesto della classe — è corretto. E su questa singola funzione ogni pagina riceveva 200+ richieste.

In questo modo, la soluzione era molto semplice, non serviva nemmeno riscrivere nulla: semplicemente non richiedere più volte la stessa informazione.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Ero estremamente felice, perché pensavo di aver trovato il problema principale solo al terzo giorno. Quanto ero ingenuo, era solo uno dei tanti problemi.

Ma la soluzione di questo primo problema ha abbassato ulteriormente il programma.

Nel frattempo, ci siamo occupati di altre ottimizzazioni. C'erano molte cose visibili che potevano essere sistemate. Ad esempio, nello stesso terzo giorno ho scoperto che c'era effettivamente una cache nel sistema (inizialmente pensavo che tutte le richieste provenissero direttamente dal database). Quando penso alla cache, immagino i tradizionali Redis o Memcached. Ma così pensavo solo io, perché per la cache in quel sistema venivano utilizzati MongoDB e SQL Server — lo stesso da cui erano appena stati letti i dati.

Giorno dieci

Nella prima settimana ho affrontato i problemi che dovevano essere risolti immediatamente. Intorno alla seconda settimana sono andato per la prima volta a un standup per interagire con il team, vedere cosa stava succedendo e come andava l'intero processo.

È di nuovo emerso qualcosa di interessante. Il team era composto da: 18 sviluppatori; 8 tester; 3 manager; 2 architetti. E tutti partecipavano ai rituali comuni, cioè più di 30 persone arrivavano ogni mattina allo standup e raccontavano cosa avevano fatto. È chiaro che l'incontro durava più di 5 o 15 minuti. Nessuno ascoltava, perché tutti lavoravano su sistemi diversi. In quella forma, 2-3 ticket all'ora durante la grooming session erano già un buon risultato.

La prima cosa che abbiamo fatto è stata dividere il team in più gruppi per linea di prodotto. Abbiamo creato team separati per diverse sezioni e sistemi, composti da sviluppatori, tester, product manager e business analyst.

Il risultato è stato:

• Riduzione degli standup e delle riunioni.
• Conoscenza approfondita del prodotto.
• Senso di appartenenza. Quando prima le persone venivano continuamente ruotate tra i sistemi, sapevano che sarebbero toccati a qualcun altro lavorare sui loro bug, ma non a loro stessi.
• Collaborazione tra i gruppi. Non è necessario dire che QA e programmatori prima non interagivano molto, il product faceva il proprio lavoro, e così via. Ora avevano un punto di responsabilità comune.

Ci siamo principalmente concentrati sull'efficienza, le prestazioni e la qualità: sono questi i problemi che abbiamo cercato di risolvere trasformando il team.

Giorno undici

Nel processo di cambiamento della struttura del team ho scoperto come vengono conteggiati StoryPoints. 1 SP corrispondeva a un giorno, e ogni ticket conteneva sia SP per lo sviluppo che per il QA, ovvero almeno 2 SP.

Come l'ho scoperto?

Abbiamo trovato un bug: in uno dei report, dove viene inserita la data di inizio e fine del periodo di cui si richiede il report, non viene considerato l'ultimo giorno. Quindi, da qualche parte nella query c'era un < invece di un <=. Mi è stato detto che questo valeva tre Story Points, ovvero 3 giorni.

Dopo di che abbiamo:

• Rivisto il sistema di valutazione degli Story Points. Ora la risoluzione di piccoli bug che possono essere rapidamente passati attraverso il sistema raggiunge più velocemente l'utente.
• Iniziato a unire ticket correlati per sviluppo e testing. Prima ogni ticket, ogni bug era un ecosistema isolato, non collegato a nient'altro. Cambiare tre pulsanti su una pagina poteva essere tre diversi ticket con tre diversi processi di QA invece di un unico test automatico sulla pagina.
• Abbiamo iniziato a collaborare con gli sviluppatori su un approccio per la valutazione degli sforzi. Tre giorni per cambiare un pulsante non è divertente.

Giorno venti

Verso la metà del primo mese la situazione si è leggermente stabilizzata, ho capito che cosa stava succedendo principalmente e ho già iniziato a guardare al futuro pensando a soluzioni a lungo termine.

Obiettivi a lungo termine:

• Piattaforma gestita. Centinaia di richieste su ogni pagina non sono serie.
• Tendenze prevedibili. Ci sono stati picchi di traffico periodici che, a prima vista, non correlevavano con altre metriche — era necessario capire perché ciò accadeva e imparare a prevederlo.
• Espansione della piattaforma. Il business cresce continuamente, arrivano sempre più utenti, il traffico aumenta.

In passato si diceva spesso: «Rifacciamo tutto in [linguaggio/framework], tutto funzionerà meglio!»

Nella maggior parte dei casi non funziona, è già un miracolo se il rifatto funziona. Quindi avevamo bisogno di creare una roadmap — una strategia concreta che illustra passo dopo passo come saranno raggiunti gli obiettivi aziendali (cosa faremo e perché), che:

• riflette la missione e gli obiettivi del progetto;
• prioritizza gli obiettivi principali;
• contiene un grafico dei loro risultati.

Prima di questo, nessuno aveva parlato con il team sul motivo per cui si apportano modifiche. Sono necessari indicatori di successo appropriati. Per la prima volta nella storia dell'azienda, abbiamo stabilito KPI per il team tecnico, legando questi indicatori agli obiettivi organizzativi.

In altre parole, i KPI organizzativi sono sostenuti dai team, mentre i KPI di team sono sostenuti dai singoli. Altrimenti, se i KPI tecnologici non coincidono con quelli organizzativi, ognuno tirerà la coperta dalla propria parte.

Ad esempio, uno dei KPI organizzativi è l'aumento della quota di mercato attraverso nuovi prodotti.

Cosa può sostenere l'obiettivo di avere più nuovi prodotti?

• Innanzitutto, vogliamo dedicare più tempo allo sviluppo di nuovi prodotti piuttosto che a riparare difetti. Questa è una decisione logica, facilmente misurabile.
• In secondo luogo, vogliamo sostenere l'aumento del volume delle transazioni, perché più è alta la quota di mercato, più saranno gli utenti e, di conseguenza, maggiore sarà il traffico.

Quindi, i KPI individuali, che possono essere attuati all'interno del gruppo, saranno, ad esempio, in quella sezione da cui provengono la maggior parte dei difetti. Se ci si concentra proprio su questa sezione, è possibile ridurre notevolmente i difetti, aumentando così il tempo per sviluppare nuovi prodotti e ancora una volta per sostenere i KPI organizzativi.

Pertanto, ogni decisione, incluso la riscrittura del codice, deve sostenere obiettivi specifici posti dall'azienda (crescita dell'organizzazione, nuove funzionalità, assunzioni).

Durante questo processo è emersa un'osservazione interessante, che è diventata una novità non solo per i tecnici, ma per l'intera azienda: tutti i ticket devono essere orientati almeno a un KPI. Cioè, se il product manager dice di voler realizzare una nuova funzionalità, la prima domanda dovrebbe essere: «Quale KPI supporta questa funzionalità?» Se nessuno, allora scusate - sembra che sia una funzionalità inutile.

Giorno trenta

Alla fine del mese, ho scoperto un altro dettaglio, che nessuno del mio team Ops aveva mai visto i contratti che concludiamo con i clienti. Potresti chiederti, perchè vedere i contratti.

• Innanzitutto, perché nei contratti sono scritti gli SLA.
• In secondo luogo, gli SLA sono tutti diversi. Ogni cliente aveva le proprie esigenze e il reparto vendite firmava senza guardare.

Un altro aspetto interessante è che nel contratto con uno dei clienti più grandi è scritto che tutte le versioni del software supportate dalla piattaforma devono essere n-1, quindi non l'ultima versione, ma la penultima.

È chiaro quanto fossimo lontani da n-1, considerando che la piattaforma era su ColdFusion e SQL Server 2008, che a luglio ha smesso di essere supportato del tutto.

Giorno quarantacinquesimo

Intorno alla metà del secondo mese ho trovato abbastanza tempo per sedermi e fare valuestreammapping l'intero processo. Questi sono i passaggi necessari da intraprendere, dalla creazione del prodotto alla consegna al consumatore, e devono essere dettagliati il più possibile.

Si suddivide il processo in piccoli pezzi e si osserva cosa richiede troppo tempo, cosa può essere ottimizzato, migliorato, ecc. Ad esempio, quanto tempo richiede una richiesta dal prodotto, passando per il grooming, fino a quando arriva al ticket che può essere preso dallo sviluppatore, QA, ecc. Si esamina ogni singolo passaggio e si pensa a cosa può essere ottimizzato.

Quando ho fatto questo, sono saltate all'occhio due cose:

• una percentuale elevata di ritorni di ticket da QA agli sviluppatori;
• le revisioni delle pull request richiedevano troppo tempo.

Il problema era che queste erano conclusioni del tipo: sembra che richieda molto tempo, ma non siamo sicuri di quanto precisamente.

«Non si può migliorare ciò che non si può misurare».

Come giustificare quanto sia grave il problema? Ci vogliono giorni o ore per affrontarlo?

Per misurarlo, abbiamo aggiunto alcuni passaggi al processo di Jira: «pronto per lo sviluppo» e «pronto per QA», per misurare quanto tempo ogni ticket aspetta e quante volte torna a un certo passaggio.

Inoltre, abbiamo aggiunto «in revisione» per sapere quanto tempo in media i ticket rimangono in revisione, e da lì muoverci. Avevamo già metriche sistemiche, adesso abbiamo aggiunto nuove metriche e cominciato a misurare:

• L'efficacia del processo: la produttività e pianificato/consegnato.
• La qualità del processo: il numero di difetti, difetti da QA.

Questo aiuta davvero a capire cosa sta funzionando bene e cosa no.

Giorno cinquantesimo

Tutto questo è certamente interessante, ma verso la fine del secondo mese è successo ciò che, in linea di principio, era prevedibile, anche se non mi aspettavo una tale portata. La gente ha iniziato ad andarsene, perché ai vertici sono arrivati nuovi individui che hanno cominciato a cambiare tutto, e i vecchi sono stati licenziati. Di solito, in un'azienda con diversi anni di vita, tutti sono amici e si conoscono bene.

Era prevedibile, ma l'entità dei licenziamenti è stata inaspettata. Ad esempio, in una settimana due team leader hanno contemporaneamente presentato le dimissioni volontarie. Pertanto, ho dovuto non solo dimenticare altri problemi, ma concentrarmi su la creazione di un team. È un problema lungo e difficile da risolvere, ma doveva essere affrontato, perché volevo mantenere le persone rimaste (o la maggior parte di esse). Era necessario reagire in qualche modo al fatto che le persone se ne erano andate, per mantenere alto il morale della squadra.

In teoria è positivo: arriva una nuova persona, che ha carta bianca e può valutare le competenze del team e sostituire il personale. In realtà, non si possono semplicemente portare nuove persone per molti motivi. C'è sempre bisogno di un equilibrio.

• Tra vecchio e nuovo. È necessario mantenere le persone esperte, che possono adattarsi e supportare la missione. Ma allo stesso tempo è importante portare nuova linfa, di cui parleremo più avanti.
• Esperienza. Ho parlato molto con buoni junior che erano motivati e volevano unirsi a noi. Ma non potevo assumerli, perché mancavano senior che potessero supportare i junior e fungere da mentori. Prima bisognava assemblare il vertice e solo dopo portare i giovani.
• Bastone e carota.

Non ho una buona risposta alla domanda su quale sia l'equilibrio corretto, come mantenerlo, quante persone lasciare e quanto pressare. È un processo puramente individuale.

Giorno cinquantuno

Ho cominciato a osservare la squadra per capire chi avevo e ho ricordato ancora una volta:

«La maggior parte dei problemi sono problemi con le persone».

Ho scoperto che nel team, sia tra i programmatori che tra gli Ops, ci sono tre grandi problemi:

• Soddisfazione per lo stato attuale delle cose.
• Mancanza di responsabilità – perché nessuno ha mai collegato i risultati del lavoro degli esecutori all'impatto sul business.
• Paura dei cambiamenti.

I cambiamenti portano sempre fuori dalla zona di comfort, e più le persone sono giovani, meno amano i cambiamenti, perché non capiscono il perché e non capiscono come. La risposta più comune che ho sentito è stata: "Non l'abbiamo mai fatto in questo modo". Alcune volte si è arrivati a situazioni completamente assurde: anche le minime modifiche non passavano senza che qualcuno si indignasse. E non importava quanto quelle modifiche riguardassero direttamente il loro lavoro, le persone dicevano: "No, perché? Non funzionerà".

Ma non si può diventare migliori senza cambiare nulla.

Ho avuto una conversazione completamente assurda con un collaboratore, stavo raccontando le mie idee per l'ottimizzazione, e lui mi ha detto:
"Ah, non hai visto cosa avevamo l'anno scorso!"
— E quindi?
"Adesso è molto meglio di com'era."
"Quindi, non può essere ancora meglio?"
"E perché?"

Una buona domanda — perché? Come se, se ora è meglio di com'era, tutto fosse già abbastanza buono. Questo porta a un'assenza di responsabilità, il che in realtà è assolutamente normale. Come ho detto, il gruppo tecnico era un po' ai margini. In azienda si pensava che dovessero esserci, ma nessuno ha mai stabilito standard.Nel supporto tecnico non avevano mai visto SLA, quindi per il gruppo era perfettamente "accettabile" (e questo mi ha colpito di più):

• 12 secondi di caricamento;
• 5-10 minuti di downtime per ogni rilascio;
• la risoluzione dei problemi critici richiede giorni e settimane;
• assenza di turni 24x7 / on-call.

Nessuno ha mai provato a chiedere perché non dovremmo fare le cose meglio, e nessuno ha mai capito che non dovrebbe essere così.

Come bonus, c'era un altro problema: mancanza di esperienza.I senior se ne sono andati, e il giovane team rimasto è cresciuto nel precedente regime ed è stato avvelenato da esso.

Tutto ciò, unito al fatto che le persone temevano di fallire e di sembrare incompetenti, si traduceva nel fatto che, prima di tutto, in nessun caso chiedevano aiuto.Quante volte abbiamo parlato nel gruppo e individualmente, e io dicevo: "Fai una domanda, se non sai come fare qualcosa". Ho fiducia in me stesso e so che posso risolvere qualsiasi problema, ma ci vorrà tempo. Quindi, se posso chiedere a qualcuno che sa come risolverlo in 10 minuti, lo farò. Più hai poca esperienza, più hai paura di chiedere, perché pensi che ti considereranno incompetente.

Questa paura di fare domande si manifesta in modi interessanti. Ad esempio, chiedi: «Come va con questo compito?» —«Mancano un paio d'ore, sto per finirlo». Il giorno dopo chiedi di nuovo, ricevi la risposta che va tutto bene, ma è sorto un piccolo problema, sarà pronto entro la fine della giornata. Passa un altro giorno e finché non lo metti alle strette e non lo costringi a parlare con qualcuno, è così che continua. L'individuo desidera risolvere il compito da solo, crede che se non lo risolverà da solo, sarà un grande fallimento.

È per questo che gli sviluppatori sovrastimano le valutazioni. È stata davvero una barzelletta quando si discuteva di un certo compito, mi è stata data una cifra tale che mi ha molto sorpreso. A cui mi è stato detto che nelle stime lo sviluppatore include anche il tempo che il ticket passerà attraverso il QA, perché lì troveranno errori, e il tempo che richiederà la PR, e il tempo in cui le persone che devono esaminarla saranno occupate — insomma, il tempo massimo possibile.

In secondo luogo, le persone che hanno paura di sembrare incompetenti, analizzano eccessivamente. Quando dici cosa bisogna fare esattamente, inizia: «No, e se pensassimo a questo qui?» In questo senso, la nostra azienda non è unica, è un problema standard dei giovani.

In risposta, ho introdotto le seguenti pratiche:

• La regola dei 30 minuti. Se dopo mezz'ora non riesci a risolvere il problema, chiedi aiuto a qualcuno. Funziona con successo variabile, perché la gente continua a non chiedere, ma almeno il processo è iniziato.
• Escludere tutto tranne l'essenziale, nella valutazione del tempo di esecuzione del compito, cioè considerare solo il tempo che ci vorrà per scrivere il codice.
• Apprendimento continuo per chi analizza eccessivamente. È semplicemente un lavoro costante con le persone.

Giorno sessantesimo

Mentre mi occupavo di tutto questo, è arrivato il momento di sistemare il budget. Certo, ho trovato molte cose interessanti su dove stavamo spendendo i soldi. Ad esempio, avevamo un intero rack in un data center separato, su cui c'era un server FTP, utilizzato da un solo cliente. Si è rivelato che «... ci stavamo trasferendo e lui è rimasto lì, non lo abbiamo sostituito». Era due anni fa.

Un particolare interesse ha destato la bolletta per i servizi cloud. Sono sicuro che la ragione principale dell'alto costo per i servizi cloud sia dovuta agli sviluppatori, che per la prima volta nella loro vita hanno accesso illimitato ai server. Non devono più chiedere: "Posso avere un server di prova, per favore?"; possono prenderlo da soli. Inoltre, gli sviluppatori desiderano sempre costruire un sistema così sofisticato da far invidia a Facebook e Netflix.

Ma gli sviluppatori non hanno esperienza nell'acquisto di server e non sanno come determinare la dimensione necessaria dei server, poiché non ne hanno mai avuto bisogno prima. Di solito, non comprendono appieno la differenza tra scalabilità e prestazioni.

Risultati dell'inventario:

• Sono usciti da un data center.
• Abbiamo rescindito il contratto con 3 servizi di log. Avevamo 5 servizi — ogni sviluppatore che iniziava a sperimentare prendeva un nuovo servizio.
• Abbiamo spento 7 sistemi AWS. Ancora una volta, nessuno ha fermato i progetti morti, continuavano tutti a funzionare.
• Abbiamo ridotto le spese per il software di 6 volte.

Settantaquinto giorno

Il tempo passava e dopo due mesi e mezzo dovevo incontrare il consiglio di amministrazione. Il nostro consiglio di amministrazione non è migliore né peggiore di altri, come tutti i consigli di amministrazione vuole sapere tutto. Le persone investono denaro e vogliono capire quanto ciò che stiamo facendo si allinea con gli obiettivi KPI stabiliti.

Il consiglio di amministrazione riceve molte informazioni ogni mese: numero di utenti, la loro crescita, quali servizi utilizzano e come, le prestazioni e la produttività, infine, la velocità media di caricamento delle pagine.

Il problema è che io considero che la media sia un male assoluto. Ma spiegarlo al consiglio di amministrazione è molto difficile. Sono abituati a lavorare con numeri aggregati, e non, ad esempio, con la dispersione dei tempi di caricamento in secondi.

In questo contesto ci sono stati momenti interessanti. Ad esempio, ho detto che era necessario suddividere il traffico tra i singoli server web a seconda del tipo di contenuto.

Cioè, ColdFusion passa attraverso Jetty e nginx e genera pagine. Mentre le immagini, JS e CSS passano attraverso un nginx separato con le proprie configurazioni. È una pratica abbastanza standard di cui ho parlato un paio di anni fa. Come risultato, le immagini vengono caricate molto più velocemente e ... la velocità media di caricamento è aumentata di 200 ms. scritto .

È successo perché il diagramma è costruito sulla base di dati provenienti da Jetty. Cioè, il contenuto veloce non viene considerato — la media è aumentata. Lo abbiamo capito, abbiamo riso, ma come spiegare al consiglio di amministrazione perché abbiamo fatto qualcosa che ha portato a un peggioramento del 12%?

Giorno ottantacinquesimo

Verso la fine del terzo mese ho capito che c'era una cosa su cui non avevo affatto fatto affidamento: il tempo. Ci vuole tempo per tutto ciò di cui ho parlato.

Questa è la mia vera agenda per la settimana: solo una settimana lavorativa, non molto intensa. Non c'è tempo per tutto. Quindi, ancora una volta, dobbiamo assumere persone che ci aiutino a gestire i problemi.

Conclusione

Questo non è tutto. In questa storia non ho nemmeno raggiunto il punto in cui abbiamo lavorato sul prodotto e abbiamo cercato di allinearci, oppure come abbiamo integrato il supporto tecnico, o come abbiamo risolto altri problemi tecnici. Ad esempio, ho scoperto per caso che nelle più grandi tabelle del database non utilizziamo Solo. Abbiamo una funzione scritta internamente nextID, e non viene utilizzata nella transazione.

C'erano un milione di cose simili di cui si potrebbe parlare a lungo. Ma la cosa più importante di cui vale la pena parlare è la cultura.

È proprio la cultura, o la sua assenza, che porta a tutti gli altri problemi. Stiamo cercando di costruire una cultura in cui le persone:

• non temono il fallimento;
• imparano dagli errori;
• collaborano con altri team;
• mostrano iniziativa;
• si assumono responsabilità;
• accettano il risultato come obiettivo;
• celebrano il successo.

Con questo, tutto il resto arriverà.

Leon Fire su twitter, facebook e su medium.

Per quanto riguarda il legacy, ci sono due strategie: evitarlo a tutti i costi o affrontare coraggiosamente le difficoltà associate. Noi stiamo DevOpsConf seguendo la seconda via, cambiando processi e approcci. Unisciti a noi su youtube, in una newsletter e telegram, e implementiamo insieme la cultura DevOps.

Fonte: habr.com