È risaputo che le competenze di un CTO vengono verificate solo dopo il secondo incarico in questo ruolo. Infatti, è una cosa lavorare per diversi anni all'interno di un'azienda, evolvendo con essa e, mantenendosi nello stesso contesto culturale, assumendosi gradualmente maggiori responsabilità. È completamente differente arrivare direttamente al ruolo di CTO in un'azienda con un bagaglio di legacy e una serie di problemi messi sotto il tappeto.

In questo senso, l'esperienza di Leon Feuer, che ha condiviso durante la DevOpsConf, non è esattamente unica, ma moltiplicata per l'esperienza e il numero di vari ruoli che ha ricoperto negli ultimi 20 anni, risulta molto utile. Di seguito, la cronologia degli eventi degli ultimi 90 giorni e molte storie divertenti, che fanno sorridere quando accadono ad altri, ma che non sono affatto piacevoli quando si vivono in prima persona.

Leon narra in modo molto vivace 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 utili raccomandazioni. Tuttavia, non catturava tutte le sorprese incontrate lungo il cammino. Pertanto, ho cambiato formato e ho esposto i problemi che si presentavano nella nuova azienda, come un genio fuori dalla lampada, e i metodi per risolverli in ordine cronologico.

Un mese prima

Come molte belle storie, anche questa è iniziata con l'alcol. Eravamo seduti al bar con conoscenti e, come spesso accade tra i professionisti IT, ciascuno condivideva le proprie lamentele. Uno di loro aveva appena cambiato lavoro e raccontava le sue difficoltà sia con la tecnologia che con le persone e con il team. Più lo ascoltavo, più mi rendevo conto che doveva semplicemente assumere me, perché questo tipo di problemi li avevo risolti negli ultimi 15 anni. Glielo dissi, e il giorno dopo ci incontrammo già in un contesto di lavoro. L'azienda si chiamava Teaching Strategies.

Teaching Strategies è un leader nel mercato dei programmi educativi per bambini in età prescolare — dalla nascita fino ai tre anni. L'azienda tradizionale "cartacea" esiste da circa 40 anni, mentre la versione digitale SaaS della piattaforma è attiva da 10. Recentemente è iniziato il processo di adattamento della tecnologia digitale agli standard aziendali. La "nuova" versione è stata lanciata nel 2017 ed era simile alla precedente, ma con prestazioni inferiori.

La cosa più interessante è che il traffico di questa azienda è molto prevedibile — giorno dopo giorno, anno dopo anno, è possibile fare previsioni molto precise su quante persone arriveranno e quando. Ad esempio, tra le 13:00 e le 15:00 tutti i bambini nei nidi vanno a dormire, mentre gli insegnanti iniziano a inserire informazioni. E ciò accade ogni giorno, tranne nei fine settimana, perché nei fine settimana quasi nessuno lavora.

In anticipo, vorrei notare che ho iniziato a lavorare durante il periodo di maggior traffico annuale, il che è interessante per vari motivi.

Una piattaforma che sembrava avere solo 2 anni presentava uno stack piuttosto particolare: ColdFusion e SQL Server del 2008. ColdFusion, se non lo sapete, e probabilmente non lo sapete, è un enterprise PHP che è emerso alla metà degli anni '90, e da allora non ne ho 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 membri dell'azienda riguardo al lavoro e ai problemi che incontravano, più capivo che le difficoltà non erano solo di natura tecnica. Va bene, la tecnologia è vecchia — ne ho viste di peggio, ma ci sono stati problemi con il team e con i processi, e l'azienda stava cominciando a rendersene conto.

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

Le tracce di un pesante retaggio non erano soltanto nei sistemi. In azienda c'erano processi legacy, persone legacy, cultura legacy. Tutto questo doveva essere cambiato. Ho pensato che non sarebbe stato affatto noioso e ho deciso di provarci.

Due giorni prima

Due giorni prima dell'inizio del nuovo lavoro, sono arrivato in ufficio, ho riempito gli ultimi documenti, ho conosciuto il team e ho scoperto che in quel momento stavano affrontando un problema. Si trattava del fatto che il tempo medio di caricamento delle pagine era salito a 4 secondi, il che significa il doppio.

Dalla grafica, era chiaro che era successo qualcosa, e non si capiva bene cosa. Si è scoperto che il problema era legato alla latenza di rete nel data center: una latenza di 5 ms si trasformava in 2 secondi per gli utenti. Non sapevo perché fosse successo, ma in ogni caso si è saputo che il problema era nel data center.

Giorno uno

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

Per due giorni, per gli utenti le pagine si caricavano in media in 4 secondi. Chiedo se hanno trovato 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 finora era solo la punta dell'iceberg, con cui bisogna confrontarsi.

C'è una citazione che si adatta molto a questa situazione:

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

Ma poiché ho iniziato a lavorare nel periodo più impegnativo dell'anno, dovevo considerare entrambe le soluzioni: quella rapida e quella a lungo termine. E iniziare dalle cose critiche al momento.

Terzo giorno

Quindi, il caricamento dura 4 secondi, e tra le 13 e le 15 ci sono i picchi più alti.

Nel terzo giorno, in quel lasso di tempo, la velocità di caricamento era così:

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

Ho cercato di convincere il team, ma mi è stato risposto che servivano semplicemente più server. Questa è sicuramente una soluzione al problema, ma non è sempre l'unica e la più efficace. Ho chiesto perché mancassero server e quale fosse il volume di traffico. Ho estrapolato i dati e ho scoperto che abbiamo circa 150 richieste al secondo, il che rientra nei limiti ragionevoli.

Ma non dobbiamo dimenticare che, prima di ottenere una risposta corretta, bisogna porre la domanda giusta. La mia domanda successiva è stata: quanti server frontend abbiamo? La risposta mi ha "un po' sorpreso": avevamo 17 server frontend!

— Mi vergogno a chiedere, 150 diviso 17 fa circa 8? Vuole dire che ogni server gestisce 8 richieste al secondo, e se domani avremo 160 richieste al secondo, avremo bisogno di altri 2 server?

Certamente, non avevamo bisogno di server aggiuntivi. La soluzione si trovava nel codice, 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 a questa funzione, su ogni pagina, corrispondevano 200+ richieste.

La soluzione era così semplice che non c'era nemmeno bisogno di riscrivere nulla: bastava non richiedere nuovamente le stesse informazioni.

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

Ero molto felice, perché pensavo di aver trovato il problema principale già al terzo giorno. Quanto ero naïf, era solo uno dei tanti problemi.

Ma la soluzione a questo primo problema ha abbassato molto il carico di lavoro.

Nel frattempo, stavamo lavorando ad altre ottimizzazioni. C'erano molte cose visibili che potevano essere sistemate. Ad esempio, nello stesso terzo giorno, scoprii che c'era un cache nel sistema (inizialmente pensavo che tutte le richieste provenissero direttamente dal database). Quando penso al caching, immagino i tradizionali Redis o Memcached. Ma solo io lo pensavo, perché per il caching in quel sistema venivano utilizzati MongoDB e SQL Server — lo stesso da cui erano stati appena letti i dati.

Giorno dieci

Nella prima settimana ho affrontato problemi da risolvere immediatamente. Intorno alla seconda settimana, sono andato per la prima volta a una riunione di stand-up per confrontarmi con il team, vedere cosa stava succedendo e come procedeva tutto il processo.

È emersa di nuovo un'interessante scoperta. Il team era composto da: 18 sviluppatori; 8 tester; 3 manager; 2 architetti. E tutti partecipavano ai rituali comuni, quindi più di 30 persone venivano allo stand-up ogni mattina e raccontavano cosa avevano fatto. È chiaro che l'incontro non durava 5 o 15 minuti. Nessuno ascoltava l'altro, perché tutti lavoravano su sistemi diversi. In queste condizioni, avere 2-3 ticket in un'ora durante una sessione di grooming era già un buon risultato.

La prima cosa che abbiamo fatto è stata suddividere il team in più linee di prodotto. Per diverse sezioni e sistemi, abbiamo creato team separati che includevano sviluppatori, tester, product manager e analisti di business.

Il risultato ottenuto è stato:

• Una riduzione degli stand-up e delle riunioni.
• Conoscenza approfondita del prodotto.
• Senso di appartenenza. Un tempo, quando le persone cambiavano spesso i sistemi, sapevano che probabilmente avrebbero dovuto affrontare i bug di qualcun altro, non i propri.
• Collaborazione tra i gruppi. È superfluo dire che il QA non comunicava molto con gli sviluppatori; il product manager si occupava delle proprie questioni, ecc. Ora hanno un punto di responsabilità comune.

Principalmente, ci siamo concentrati su efficienza, prestazioni e qualità: sono questi i problemi che abbiamo cercato di affrontare trasformando il team.

Giorno undici

Durante il cambiamento della struttura del team, ho scoperto come vengono conteggiati StoryPoints. 1 SP era pari a un giorno, e ogni ticket conteneva SP sia per lo sviluppo che per il QA, quindi almeno 2 SP.

Come l'ho scoperto?

Abbiamo trovato un bug: in uno dei report, dove vengono inserite le date di inizio e fine per il periodo richiesto, non viene considerato l'ultimo giorno. Quindi, in qualche parte della query c'era un < invece di un <=. Mi hanno detto che questo equivale a tre Story Points, cioè 3 giorni.

Dopo di che, abbiamo:

• Rivista la nostra sistema di valutazione dei Story Points. Ora la correzione delle piccole anomalie, che possono essere rapidamente trasmesse attraverso il sistema, raggiunge più velocemente l'utente.
• Abbiamo iniziato a raggruppare i ticket correlati per sviluppo e test. Prima, ogni ticket e ogni bug erano un ecosistema a sé stante, non legato a nessun altro. Cambiare tre pulsanti su una pagina poteva richiedere tre ticket diversi con tre processi di QA distinti invece di un solo test automatico sulla pagina.
• Abbiamo iniziato a collaborare con gli sviluppatori per quanto riguarda la stima degli sforzi. Tre giorni per cambiare un pulsante non è affatto divertente.

Giorno ventesimo

Verso la metà del primo mese, la situazione si è stabilizzata leggermente; ho capito cosa stava accadendo 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 accettabili.
• Tendenze prevedibili. Ci sono stati picchi di traffico periodici che a prima vista non correlavano con altre metriche — dovevamo capire perché accadesse e imparare a prevederlo.
• Espansione della piattaforma. Il business è in continua espansione, ci sono sempre più utenti e il traffico aumenta.

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

Nella maggior parte dei casi, questo non funziona; è già un buon risultato se il nuovo codice funziona. Per questo motivo, dovevamo creare una roadmap — una strategia chiara che illustra passo dopo passo come raggiungeremo gli obiettivi aziendali (cosa faremo e perché), che:

• riflette la missione e gli obiettivi del progetto;
• prioritizza gli obiettivi principali;
• contiene una tempistica per il raggiungimento di questi obiettivi.

Fino ad ora, nessuno aveva mai parlato con il team riguardo allo scopo di qualsiasi cambiamento. Serve avere indicatori di successo appropriati. Per la prima volta nella storia dell'azienda, abbiamo stabilito KPI per il gruppo tecnico, legando questi indicatori agli obiettivi organizzativi.

Ciò significa che gli KPI organizzativi sono supportati dai team, mentre gli KPI dei team sono supportati dai singoli membri. Altrimenti, se gli KPI tecnologici non coincidono con quelli organizzativi, ognuno tira la coperta dalla propria parte.

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

Come possiamo supportare l'obiettivo di avere più nuovi prodotti?

• In primo luogo, vogliamo dedicare più tempo allo sviluppo di nuovi prodotti anziché correggere difetti. Questa è una soluzione logica e facilmente misurabile.
• In secondo luogo, vogliamo sostenere un incremento del volume delle transazioni, perché maggiore è la quota di mercato, maggiore è il numero di utenti e, di conseguenza, anche il traffico.

Quindi, gli KPI individuali che possono essere eseguiti all'interno del gruppo saranno, ad esempio, riferiti al luogo da cui provengono i principali difetti. Focalizzandosi specificamente su questa sezione, possiamo ridurre significativamente il numero di difetti, aumentando così il tempo dedicato allo sviluppo di nuovi prodotti e, ancora una volta, al supporto degli KPI organizzativi.

Pertanto, ogni decisione, incluso riscrivere il codice, deve sostenere gli obiettivi specifici che l'azienda ci ha posto (crescita dell'organizzazione, nuove funzionalità, reclutamento).

Durante questo processo è emersa una cosa interessante, che è diventata una novità non solo per i tecnici, ma in tutta l'azienda: tutti i ticket devono essere orientati almeno a un KPI. Quindi se il product manager dice che vuole fare una nuova funzione, la prima domanda dovrebbe essere: «Quale KPI supporta questa funzione?» Se nessuno, allora scusate — sembra che questa funzione non sia necessaria.

Trentesimo giorno

Alla fine del mese, ho scoperto un'altra sfumatura: nessuno del mio team Ops aveva mai visto i contratti che stipuliamo con i clienti. Potreste chiedere, a cosa serve vedere i contratti.

• Innanzitutto, perché negli accordi sono specificati gli SLA.
• In secondo luogo, gli SLA variano. Ogni cliente arriva con le proprie esigenze, e il dipartimento vendite firmava senza guardare.

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

È chiaro quanto fossimo lontani da n-1, dato che la piattaforma era su ColdFusion e SQL Server del 2008, che a luglio non sono stati più supportati affatto.

Quarantacinquesimo giorno

Verso la metà del secondo mese, ho trovato abbastanza tempo per sedermi e fare valuestreammapping un'analisi completa dell'intero processo. Questi sono passaggi fondamentali da compiere, dalla creazione del prodotto alla sua consegna al consumatore, e devono essere dettagliati il più possibile.

Dividi il processo in piccole sezioni e osserva cosa richiede troppo tempo, cosa può essere ottimizzato, migliorato, ecc. Ad esempio, quanto tempo impiega una richiesta dal prodotto, passando attraverso il grooming, fino a diventare un ticket che il sviluppatore può prendere, QA, ecc. Esamina in dettaglio ogni singolo passaggio e rifletti su cosa può essere ottimizzato.

Quando lo stavo facendo, sono emerse due questioni:

• un'alta percentuale di ticket restituiti da QA agli sviluppatori;
• le revisioni delle pull request richiedevano troppo tempo.

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

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

Come giustificare quanto sia seria la problematica? Fa perdere giorni o ore?

Per misurare questo, sono stati aggiunti alcuni passaggi nel processo Jira: "pronto per sviluppo" e "pronto per QA", per monitorare quanto tempo ogni ticket aspetta e quante volte torna a un determinato passaggio.

Abbiamo anche aggiunto "in revisione", per sapere quanto tempo in media i ticket rimangono in revisione, da cui partire. Avevamo metriche di sistema, ora abbiamo aggiunto nuove metriche e abbiamo iniziato a misurare:

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

Questo aiuta davvero a capire cosa funziona e cosa no.

Giorno cinquantesimo

Tutto ciò è certamente interessante, ma verso la fine del secondo mese è successo ciò che era prevedibile, anche se non immaginavo una portata del genere. Le persone hanno iniziato a andarsene, perché ci sono stati cambiamenti nella direzione. Sono arrivate nuove persone nei vertici che hanno iniziato a cambiare tutto, e i vecchi si sono dimessi. Di solito, in un’azienda che esiste da diversi anni, tutti sono amici e si conoscono tra loro.

Era prevedibile, ma ciò che ha sorpreso è stata l'ampiezza dei licenziamenti. Per esempio, in una settimana, due team leader hanno contemporaneamente presentato le dimissioni. Ho dovuto quindi non solo dimenticare altri problemi, ma concentrarmi su la creazione del team. È un problema lungo e difficile da risolvere, ma era necessario affrontarlo, perché volevamo mantenere le persone rimaste (o la maggior parte di esse). Era importante rispondere alla situazione per sostenere il morale del team.

In teoria è ottimo: arriva una nuova persona, che ha carta bianca, in grado di valutare le competenze del team e sostituire le risorse. In pratica, non è così semplice per molte ragioni. Serve sempre un equilibrio.

• Tra vecchio e nuovo. Dobbiamo mantenere le persone esperte che possono adattarsi e sostenere la missione. Ma allo stesso tempo, è fondamentale portare nuove energie, di questo parleremo più avanti.
• Ho avuto molte conversazioni con bravi junior che erano appassionati e desiderosi di unirsi al nostro team. Tuttavia, non ho potuto assumerli perché non c'erano abbastanza senior per supportarli e fungere da mentori. Prima dovevamo reclutare i senior e solo dopo i giovani.
• Frustrazione e gratificazione.

Non ho una risposta chiara su quale sia il giusto equilibrio, come mantenerlo, quanti membri lasciare e quanto premere. È un processo puramente individuale.

Il cinquantunesimo giorno

Ho iniziato a osservare il team per capire chi avevo a disposizione e ho ricordato ancora una volta:

«La maggior parte dei problemi sono problemi di persone».

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

• Soddisfazione con la situazione attuale.
• Mancanza di responsabilità — perché nessuno ha mai collegato i risultati del lavoro degli esecutori all'impatto sul business.
• Paura del cambiamento.

I cambiamenti ci portano sempre fuori dalla nostra zona di comfort, e più le persone sono giovani, meno amano i cambiamenti, perché non comprendono il perché e il come. La risposta più comune che ho sentito è: «Non lo abbiamo mai fatto in questo modo». Si è arrivati persino all'assurdo, dove anche il minimo cambiamento non passava senza che qualcuno si indignasse. E non importava quanto questi cambiamenti riguardassero il loro lavoro, le persone dicevano: «No, perché? Non funzionerà».

Ma non si può diventare migliori senza cambiare nulla.

Ho avuto una conversazione assolutamente ridicola con un collaboratore, gli stavo raccontando le mie idee per l'ottimizzazione, e lui mi ha risposto:
— Ah, non hai visto cosa avevamo lo scorso anno!
— E allora?
— Ora è molto meglio di prima.
— Quindi, non può essere ancora meglio?
— Perché mai?

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

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

Nessuno ha mai cercato di chiedere perché non potessimo farlo meglio, e nessuno ha mai capito che non dovrebbe essere così.

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

A tutto questo, le persone temevano anche il fallimento e di sembrare incompetenti. Questo si traduce nel fatto che, per prima cosa, in nessun caso chiedevano aiuto. Quante volte abbiamo parlato in gruppo e individualmente, e io dicevo: «Fai la domanda se non sai come fare qualcosa». Sono sicuro di me 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ò. Meno esperienza hai, più hai paura di chiedere, perché pensi che ti considereranno incompetente.

Questa paura di porre domande si manifesta in modi interessanti. Ad esempio, chiedi: «Come va con questo compito?» — «Mancano un paio d'ore, sto quasi finendo». Il giorno dopo chiedi di nuovo, ricevi risposta che va tutto bene, ma c'è un piccolo problema, che sarà sicuramente risolto entro la fine della giornata. Passa un altro giorno e finché non fai pressione e non costringi qualcuno a parlare, tutto continua in questo modo. La persona vuole risolvere il problema da sola, pensa che se non lo fa di persona, sarà un grande fallimento.

Ecco perché gli sviluppatori sovrastimano le stime. Era un bel aneddoto, quando si discuteva di un certo compito, mi è stata fornita una cifra che mi ha sorpreso molto. A cui mi è stato risposto che nelle stime lo sviluppatore include anche il tempo che il ticket trascorrerà in QA, perché lì trovare errori, e il tempo necessario per il PR, e il tempo in cui le persone che devono visionarlo sono occupate — insomma, tutto quello che è possibile.

In secondo luogo, le persone che temono di sembrare incompetenti, analizzano eccessivamenteQuando si parla di cosa esattamente deve essere fatto, inizia: «No, e se pensassimo qui?» In questo senso, la nostra azienda non è unica, è un problema standard della gioventù.

In risposta, ho introdotto le seguenti pratiche:

• Regola delle 30 minuti. Se dopo mezz'ora non riesci a risolvere il problema, chiedi aiuto a qualcuno. Funziona con successo variabile, perché la gente comunque non chiede, ma almeno il processo è avviato.
• Escludere tutto tranne l'essenziale, nella valutazione dei tempi di esecuzione del compito, quindi considera solo quanto tempo ci vorrà per scrivere il codice.
• Apprendimento continuo per coloro che analizzano eccessivamente. È semplicemente un lavoro costante con le persone.

Giorno sessantottesimo

Mentre mi occupavo di tutto ciò, era giunto il momento di esaminare il budget. Certamente, ho trovato molte cose interessanti su come spendevamo i soldi. Ad esempio, avevamo un'intera rack in un centro dati separato, su cui era installato un server FTP, utilizzato da un solo cliente. Si è scoperto che «… ci stavamo trasferendo e lui è rimasto lì, non l'abbiamo sostituito». Era due anni fa.

Un particolare interesse suscitava la fattura per i servizi cloud. Sono convinto che la principale causa dell'alto costo dei servizi cloud siano i programmatori, i quali hanno per la prima volta accesso illimitato ai server. Non devono più chiedere: «Posso avere un server di test, per favore?»; possono prenderlo direttamente. Inoltre, i programmatori vogliono sempre costruire sistemi così avanzati da far invidia a Facebook e Netflix.

Tuttavia, i programmatori non hanno esperienza nell'acquisto di server e nella determinazione della dimensione adeguata dei server, perché non ne avevano mai avuto bisogno prima. E di solito non comprendono appieno la differenza tra scalabilità e prestazioni.

Risultati dell'inventario:

• Usciti da un data center.
• Rescissi i contratti con 3 servizi di log. Avevamo 5 in totale — ogni programmatore che iniziava a sperimentare ne prendeva uno nuovo.
• Spente 7 istanze AWS. Ancora una volta, i progetti abbandonati non sono stati fermati; continuavano a funzionare.
• Ridotto le spese per il software di 6 volte.

Settantacinquesimo giorno

Il tempo passava e dopo due mesi e mezzo dovevo incontrare il consiglio di amministrazione. Il nostro consiglio non è migliore né peggiore di altri; come tutti i consigli di amministrazione, vuole sapere tutto. Le persone investono denaro e desiderano comprendere come ciò che facciamo si allinei con gli KPI stabiliti.

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

Il problema è che considero la media un vero male. Ma spiegarlo al consiglio di amministrazione è molto difficile. Sono abituati a lavorare con numeri aggregati, non con la distribuzione del tempo di caricamento in secondi, ad esempio.

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

Cioè, ColdFusion passa attraverso Jetty e nginx e genera le pagine. Le immagini, JS e CSS vengono gestiti da un nginx separato con le proprie configurazioni. Questa è una pratica abbastanza standard, di cui ne ho parlato ancora un paio di anni fa. Di conseguenza, le immagini si caricano molto più velocemente e … la velocità media di caricamento è aumentata di 200 ms.

Questo è successo perché il grafico è basato su dati provenienti da Jetty. Cioè, il contenuto veloce non è considerato — la media è schizzata. Ci era chiaro, abbiamo riso, ma come spiegare al consiglio di amministrazione perché abbiamo fatto qualcosa che ha portato a un peggioramento del 12%?

Ottantacinquesimo giorno

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.

Questo è il mio vero calendario della settimana — solo una settimana lavorativa, non troppo intensa. Non ho tempo per tutto. Quindi di nuovo è necessario assumere persone che possano aiutare a gestire i problemi.

Conclusione

Questo non è tutto. In questo racconto non sono nemmeno arrivato a come abbiamo lavorato con il prodotto e cercato di allinearci, o come abbiamo integrato il supporto tecnico, o come abbiamo affrontato altri problemi tecnici. Ad esempio, ho scoperto per pura coincidenza che nelle tabelle più grandi del database non utilizziamo SEQUENCE. Abbiamo una funzione scritta a mano nextID, e non viene utilizzata nella transazione.

Ci sono state ancora 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 mancanza, 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;
• dimostrano iniziativa;
• si assumono la responsabilità;
• accettano il risultato come obiettivo;
• celebrano il successo.

Con questo, tutto il resto seguirà.

Leon Fire su twitter, facebook e su medium.

Relativamente al legacy ci sono due strategie: evitare a tutti i costi di lavorare con esso, oppure affrontare coraggiosamente le difficoltà associate. Noi stiamo DevOpsConf seguendo la seconda strada, cambiando processi e approcci. Unisciti a noi su youtube, newsletter e telegram, e implementiamo insieme la cultura DevOps.

Fonte: habr.com