È noto che la competenza del CTO viene messa alla prova solo la seconda volta che svolge questo ruolo. Perché una cosa è lavorare per diversi anni in un’azienda, evolvere con essa e, trovandosi nello stesso contesto culturale, ricevere via via sempre più responsabilità. Ed è tutta un'altra cosa entrare direttamente nella posizione di direttore tecnico di un'azienda con un bagaglio di eredità e un mucchio di problemi accuratamente nascosti sotto il tappeto.

In questo senso, l'esperienza di Leon Fire, che ha condiviso DevOpsConf, non proprio unico, ma moltiplicato per la sua esperienza e per la quantità di ruoli diversi che è riuscito a cimentarsi nel corso di 20 anni, è molto utile. Sotto il taglio c'è una cronologia degli eventi nell'arco di 90 giorni e molte storie di cui è divertente ridere quando accadono a qualcun altro, ma che non sono così divertenti da affrontare di persona.

Leon parla in russo in modo molto colorito, quindi se hai 35-40 minuti, ti consiglio di guardare il video. Versione testuale per risparmiare tempo qui sotto.

La prima versione del rapporto era una descrizione ben strutturata del lavoro con persone e processi, contenente raccomandazioni utili. Ma non ha trasmesso tutte le sorprese incontrate lungo la strada. Pertanto, ho cambiato il formato e ho presentato i problemi che mi si presentavano davanti come un jack-in-the-box nella nuova azienda, e i metodi per risolverli in ordine cronologico.

Un mese prima

Come molte belle storie, questa è iniziata con l'alcol. Eravamo seduti con gli amici in un bar e, come previsto tra gli specialisti IT, tutti piangevano per i loro problemi. Uno di loro aveva appena cambiato lavoro e stava parlando dei suoi problemi con la tecnologia, con le persone e con il team. Più ascoltavo, più mi rendevo conto che avrebbe dovuto semplicemente assumermi, perché questi sono i tipi di problemi che ho risolto negli ultimi 15 anni. Gliel'ho detto e il giorno dopo ci siamo incontrati in un ambiente di lavoro. La società si chiamava Teaching Strategies.

Teaching Strategies è leader di mercato nel curriculum per bambini molto piccoli dalla nascita ai tre anni di età. La tradizionale azienda “cartacea” ha già 40 anni e la versione digitale SaaS della piattaforma ne ha 10. Relativamente recentemente è iniziato il processo di adattamento della tecnologia digitale agli standard aziendali. La “nuova” versione è stata lanciata nel 2017 ed era quasi come quella vecchia, solo che funzionava peggio.

La cosa più interessante è che il traffico di questa azienda è molto prevedibile: di giorno in giorno, di anno in anno, puoi prevedere molto chiaramente quante persone arriveranno e quando. Ad esempio, tra le 13 e le 15 tutti i bambini dell'asilo vanno a letto e gli insegnanti iniziano a inserire le informazioni. E questo accade tutti i giorni, tranne i fine settimana, perché nei fine settimana quasi nessuno lavora.

Guardando un po’ avanti, noto che ho iniziato il mio lavoro nel periodo di maggior traffico annuale, il che è interessante per vari motivi.

La piattaforma, che sembrava avere solo 2 anni, aveva uno stack particolare: ColdFusion e SQL Server del 2008. ColdFusion, se non lo sai, e molto probabilmente non lo sai, è un PHP aziendale uscito a metà degli anni '90, e da allora non ne ho più sentito parlare. Inoltre c'erano: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ma il monolite principale funzionava su ColdFusion e SQL Server.

Problematica

Più parlavo con i dipendenti dell'azienda del lavoro e dei problemi riscontrati, più mi rendevo conto che i problemi non erano solo di natura tecnica. Ok, la tecnologia è vecchia e non ci hanno lavorato, ma ci sono stati problemi con il team e con i processi e l'azienda ha iniziato a capirlo.

Tradizionalmente, i loro tecnici sedevano in un angolo e svolgevano qualche tipo di lavoro. Ma sempre più affari iniziarono a passare alla versione digitale. Pertanto, nell'ultimo anno prima di iniziare a lavorare, ne sono comparsi di nuovi in ​​azienda: consiglio di amministrazione, CTO, CPO e direttore QA. Cioè, l'azienda ha iniziato a investire nel settore tecnologico.

Le tracce di una pesante eredità non erano solo nei sistemi. L’azienda aveva processi legacy, persone legacy, cultura legacy. Tutto questo doveva essere cambiato. Ho pensato che sicuramente non sarebbe stato noioso e ho deciso di provarlo.

Due giorni prima

Due giorni prima di iniziare un nuovo lavoro, sono arrivato in ufficio, ho compilato gli ultimi documenti, ho incontrato il team e ho scoperto che in quel momento il team era alle prese con un problema. Il tempo medio di caricamento della pagina è salito a 4 secondi, ovvero 2 volte.

A giudicare dal grafico, è chiaramente successo qualcosa e non è chiaro cosa. Si è scoperto che il problema era la latenza di rete nel data center: una latenza di 5 ms nel data center si è trasformata in 2 s per gli utenti. Non sapevo perché fosse successo, ma in ogni caso si è saputo che il problema era nel data center.

Primo giorno

Passarono due giorni e nel mio primo giorno di lavoro scoprii che il problema non era scomparso.

Per due giorni, le pagine degli utenti sono state caricate in media in 4 secondi. Chiedo se hanno scoperto qual è il problema.

- Sì, abbiamo aperto un ticket.
- e?
- Beh, non ci hanno ancora risposto.

Poi ho capito che tutto quello che mi era stato detto prima era solo la piccola punta dell'iceberg contro cui dovevo combattere.

C'è una bella citazione che si adatta molto bene a questo:

“A volte per cambiare tecnologia bisogna cambiare organizzazione.”

Ma poiché ho iniziato a lavorare nel periodo più impegnativo dell'anno, ho dovuto considerare entrambe le opzioni per risolvere il problema: sia quella rapida che quella a lungo termine. E inizia da ciò che è fondamentale in questo momento.

Terzo giorno

Quindi, il caricamento dura 4 secondi e da 13 a 15 i picchi più grandi.

Il terzo giorno durante questo periodo di tempo, la velocità di download era simile a questa:

Dal mio punto di vista, non ha funzionato proprio nulla. Dal punto di vista di tutti gli altri, stava andando un po' più lentamente del solito. Ma semplicemente non succede così: è un problema serio.

Ho provato a convincere il team, al quale hanno risposto che avevano semplicemente bisogno di più server. Questa, ovviamente, è una soluzione al problema, ma non sempre è l’unica e la più efficace. Ho chiesto perché non c'erano abbastanza server, qual era il volume del traffico. Ho estrapolato i dati e ho scoperto che abbiamo circa 150 richieste al secondo, il che, in linea di principio, rientra entro limiti ragionevoli.

Ma non dobbiamo dimenticare che prima di ottenere la risposta giusta, bisogna porre la domanda giusta. La mia domanda successiva è stata: quanti server frontend abbiamo? La risposta “mi ha un po’ sconcertato”: avevamo 17 server frontend!

— Mi vergogno a chiederlo, ma 150 diviso 17 fa circa 8? Stai dicendo che ogni server consente 8 richieste al secondo e se domani ci saranno 160 richieste al secondo avremo bisogno di altri 2 server?

Ovviamente non avevamo bisogno di server aggiuntivi. La soluzione era nel codice stesso e in superficie:

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

C'era una funzione getCurrentClass(), perché tutto sul sito funziona nel contesto di una classe, esatto. E per questa funzione su ogni pagina c'erano Oltre 200 richieste.

La soluzione in questo modo era molto semplice, non dovevi nemmeno riscrivere nulla: bastava non chiedere più 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é ho deciso che solo il terzo giorno avevo riscontrato il problema principale. Ingenuo com'ero, questo era solo uno dei tanti problemi.

Ma la risoluzione di questo primo problema ha fatto scendere il grafico molto più in basso.

Allo stesso tempo, stavamo apportando altre ottimizzazioni. C'erano molte cose in vista che potevano essere risolte. Ad esempio, lo stesso terzo giorno ho scoperto che dopo tutto c'era una cache nel sistema (all'inizio pensavo che tutte le richieste provenissero direttamente dal database). Quando penso a una cache, penso a Redis o Memcached standard. Ma ero l'unico a pensarla così, perché quel sistema utilizzava MongoDB e SQL Server per la memorizzazione nella cache, lo stesso da cui venivano appena letti i dati.

Decimo giorno

La prima settimana ho affrontato problemi che dovevano essere risolti subito. Da qualche parte nella seconda settimana, sono venuto allo stand-up per la prima volta per comunicare con la squadra, per vedere cosa stava succedendo e come stava andando l'intero processo.

Si è scoperto di nuovo qualcosa di interessante. Il team era composto da: 18 sviluppatori; 8 tester; 3 dirigenti; 2 architetti. E tutti hanno partecipato a rituali comuni, cioè più di 30 persone sono venute allo stand-up ogni mattina e hanno raccontato quello che hanno fatto. È chiaro che la riunione non è durata 5 o 15 minuti. Nessuno ha ascoltato nessuno perché tutti lavorano su sistemi diversi. In questa forma, 2-3 biglietti all'ora per una sessione di toelettatura erano già un buon risultato.

La prima cosa che abbiamo fatto è stata dividere il team in diverse linee di prodotti. Per sezioni e sistemi diversi, abbiamo assegnato team separati, che includevano sviluppatori, tester, product manager e analisti aziendali.

Di conseguenza abbiamo ottenuto:

• Ridurre stand-up e manifestazioni.
• Conoscenza del soggetto del prodotto.
• Un senso di proprietà. Quando le persone armeggiavano continuamente con i sistemi, sapevano che molto probabilmente qualcun altro avrebbe dovuto lavorare con i loro bug, ma non loro stessi.
• Collaborazione tra gruppi. Inutile dire che prima il QA non comunicava molto con i programmatori, il prodotto faceva le sue cose, ecc. Ora hanno un punto di responsabilità comune.

Ci siamo concentrati principalmente su efficienza, produttività e qualità: questi sono i problemi che abbiamo cercato di risolvere con la trasformazione del team.

Undicesimo giorno

Nel processo di modifica della struttura del team, ho scoperto come contare StoriaPunteggio. 1 SP equivaleva a un giorno e ogni ticket conteneva SP sia per lo sviluppo che per il QA, ovvero almeno 2 SP.

Come l'ho scoperto?

Abbiamo riscontrato un bug: in uno dei report, dove viene inserita la data di inizio e fine del periodo per il quale è necessario il report, l'ultimo giorno non viene preso in considerazione. Cioè da qualche parte nella richiesta non c'era <=, ma semplicemente <. Mi è stato detto che si tratta di tre Story Points 3 giorni.

Dopodiché:

• Il sistema di valutazione dei Punti Storia è stato rivisto. Ora le correzioni per bug minori che possono essere rapidamente trasmessi attraverso il sistema raggiungono l'utente più velocemente.
• Abbiamo iniziato a unire i ticket correlati per lo sviluppo e il test. In precedenza, ogni ticket, ogni bug era un ecosistema chiuso, non legato a nient'altro. La modifica di tre pulsanti su una pagina avrebbe potuto comportare tre ticket diversi con tre diversi processi di QA invece di un test automatizzato per pagina.
• Abbiamo iniziato a lavorare con gli sviluppatori su un approccio alla stima dei costi della manodopera. Tre giorni per cambiare un pulsante non sono divertenti.

Ventesimo giorno

Da qualche parte a metà del primo mese, la situazione si è leggermente stabilizzata, ho capito cosa stava succedendo sostanzialmente e ho già iniziato a guardare al futuro e a pensare a soluzioni a lungo termine.

Obiettivi a lungo termine:

• Piattaforma gestita. Centinaia di richieste su ogni pagina non sono serie.
• Tendenze prevedibili. Si verificavano picchi di traffico periodici che a prima vista non erano correlati ad altri parametri: dovevamo capire perché ciò accadeva e imparare a prevederlo.
• Espansione della piattaforma. Il business è in costante crescita, arrivano sempre più utenti e il traffico è in aumento.

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

Nella maggior parte dei casi questo non funziona, è positivo se la riscrittura funziona. Pertanto, avevamo bisogno di creare una roadmap, una strategia specifica che illustri passo dopo passo come verranno raggiunti gli obiettivi aziendali (cosa faremo e perché), che:

• riflette la missione e gli obiettivi del progetto;
• dà priorità agli obiettivi principali;
• contiene un programma per raggiungerli.

Prima di ciò, nessuno aveva parlato con il team dello scopo di eventuali modifiche apportate. Ciò richiede le giuste metriche di successo. Per la prima volta nella storia dell’azienda abbiamo fissato dei KPI per il gruppo tecnico e questi indicatori sono stati legati a quelli organizzativi.

Cioè, i KPI organizzativi sono supportati dai team e i KPI del team sono supportati dai KPI individuali. Altrimenti, se i KPI tecnologici non coincidono con quelli organizzativi, allora ognuno si mette la coperta addosso.

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

Come puoi sostenere l'obiettivo di avere più nuovi prodotti?

• Innanzitutto, vogliamo dedicare più tempo allo sviluppo di nuovi prodotti invece che alla correzione dei difetti. Questa è una soluzione logica facile da misurare.
• In secondo luogo, vogliamo sostenere un aumento del volume delle transazioni, perché maggiore è la quota di mercato, maggiore è il numero degli utenti e, di conseguenza, del traffico.

Quindi i KPI individuali che possono essere eseguiti all'interno del gruppo saranno, ad esempio, nel luogo da cui provengono i principali difetti. Se ti concentri specificamente su questa sezione, puoi assicurarti che ci siano molti meno difetti e quindi aumenterà il tempo per lo sviluppo di nuovi prodotti e di nuovo per il supporto dei KPI organizzativi.

Pertanto, ogni decisione, inclusa la riscrittura del codice, deve supportare gli obiettivi specifici che l'azienda ci ha prefissato (crescita organizzativa, nuove funzionalità, reclutamento).

Durante questo processo è venuta alla luce una cosa interessante, che è diventata una novità non solo per i tecnici, ma in generale per l'azienda: tutti i ticket devono essere focalizzati su almeno un KPI. Cioè, se un prodotto dice di voler creare una nuova funzionalità, la prima domanda dovrebbe essere posta: “Quale KPI supporta questa funzionalità?” In caso contrario, scusa: sembra una funzionalità non necessaria.

Trenta giorni

Alla fine del mese ho scoperto un’altra sfumatura: nessuno nel mio team operativo ha mai visto i contratti che stipuliamo con i clienti. Potresti chiedere perché hai bisogno di vedere i contatti.

• Innanzitutto perché gli SLA sono specificati nei contratti.
• In secondo luogo, gli SLA sono tutti diversi. Ogni cliente è arrivato con le sue esigenze e il reparto vendite ha firmato senza guardare.

Un'altra sfumatura interessante è che il contratto con uno dei maggiori clienti prevede che tutte le versioni software supportate dalla piattaforma debbano essere n-1, cioè non l'ultima versione, ma la penultima.

È chiaro quanto saremmo lontani dall’n-1 se la piattaforma fosse basata su ColdFusion e SQL Server 2008, che a luglio non era più supportato.

Giorno quarantacinque

Verso la metà del secondo mese ho avuto abbastanza tempo per sedermi e fare APPREZZIAMOruscellomappatura completamente per l'intero processo. Questi sono i passaggi necessari da compiere, dalla creazione di un prodotto alla consegna al consumatore, e devono essere descritti nel modo più dettagliato possibile.

Suddividi il processo in piccole parti e vedi cosa richiede troppo tempo, cosa può essere ottimizzato, migliorato, ecc. Ad esempio, quanto tempo impiega una richiesta di prodotto per essere sottoposta a grooming, quando raggiunge un ticket che uno sviluppatore può prendere, QA, ecc. Quindi guardi ogni singolo passaggio in dettaglio e pensi a cosa può essere ottimizzato.

Quando l'ho fatto, due cose hanno attirato la mia attenzione:

• alta percentuale di ticket restituiti dal QA agli sviluppatori;
• Le revisioni delle richieste pull hanno richiesto troppo tempo.

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

"Non puoi migliorare ciò che non puoi misurare."

Come giustificare la gravità del problema? Si perdono giorni o ore?

Per misurarlo, abbiamo aggiunto un paio di passaggi al processo Jira: "pronto per lo sviluppo" e "pronto per il QA" per misurare quanto tempo attende ciascun ticket e quante volte ritorna a un determinato passaggio.

Abbiamo anche aggiunto “in revisione” per sapere quanti sono in media i biglietti da rivedere, e da questo si può iniziare a ballare. Avevamo metriche di sistema, ora abbiamo aggiunto nuove metriche e abbiamo iniziato a misurare:

• Efficienza del processo: prestazioni e pianificate/consegnate.
• Qualità del processo: numero di difetti, difetti da QA.

Aiuta davvero a capire cosa sta andando bene e cosa non sta andando bene.

Cinquantesimo giorno

Tutto questo, ovviamente, è buono e interessante, ma verso la fine del secondo mese è successo qualcosa che, in linea di principio, era prevedibile, anche se non mi aspettavo una scala del genere. La gente ha cominciato ad andarsene perché era cambiato il top management. Nuove persone entrarono nella direzione e iniziarono a cambiare tutto, mentre quelle vecchie se ne andarono. E di solito in un'azienda che esiste da diversi anni, tutti sono amici e tutti si conoscono.

Questo era previsto, ma la portata dei licenziamenti era inaspettata. Ad esempio, in una settimana due team leader hanno rassegnato le dimissioni contemporaneamente e di loro spontanea volontà. Pertanto, ho dovuto non solo dimenticare altri problemi, ma concentrarmi su di essi creando una squadra. Questo è un problema lungo e difficile da risolvere, ma andava affrontato perché volevo salvare le persone rimaste (o la maggior parte di loro). Era necessario in qualche modo reagire al fatto che le persone se ne andavano per mantenere il morale nella squadra.

In teoria va bene così: entra una nuova persona che ha piena carta bianca, che può valutare le competenze del team e sostituire il personale. In effetti, non puoi semplicemente coinvolgere nuove persone per tanti motivi. C'è sempre bisogno di equilibrio.

• Vecchio e nuovo. Dobbiamo trattenere gli anziani che possono cambiare e sostenere la missione. Ma allo stesso tempo bisogna portare nuova linfa, di questo ne parleremo più avanti.
• Esperienza. Ho parlato molto con bravi ragazzi che erano entusiasti e volevano lavorare con noi. Ma non potevo assumerli perché non c’erano abbastanza senior per supportare i junior e fungere da mentori per loro. È stato necessario reclutare prima i vertici e solo dopo i giovani.
• Carota e bastone.

Non ho una buona risposta alla domanda su quale sia il giusto equilibrio, come mantenerlo, quante persone mantenere e quanto spingere. Questo è un processo puramente individuale.

Giorno cinquantuno

Ho cominciato a guardare da vicino la squadra per capire chi avevo, e ancora una volta mi sono ricordato:

"La maggior parte dei problemi sono problemi delle persone."

Ho scoperto che il team in quanto tale, sia Dev che Ops, ha tre grossi problemi:

• Soddisfazione per la situazione attuale.
• Mancanza di responsabilità - perché nessuno ha mai portato i risultati del lavoro degli artisti ad influenzare il business.
• Paura del cambiamento.

Il cambiamento ti porta sempre fuori dalla tua zona di comfort, e più i giovani lo sono, più detestano il cambiamento perché non capiscono perché e non capiscono come. La risposta più comune che ho sentito è: "Non l'abbiamo mai fatto". Inoltre, si è arrivati ​​​​al punto di totale assurdità: il minimo cambiamento non poteva avvenire senza che qualcuno si indignasse. E non importa quanto i cambiamenti abbiano influenzato il loro lavoro, la gente diceva: “No, perché? Questo non funzionerà."

Ma non puoi migliorare senza cambiare nulla.

Ho avuto una conversazione assolutamente assurda con un dipendente, gli ho raccontato le mie idee per l'ottimizzazione, al quale mi ha detto:
- Oh, non hai visto cosa avevamo l'anno scorso!
- E allora?
“Adesso è molto meglio di prima”.
- Quindi non può andare meglio?
- Perché?

Bella domanda: perché? È come se adesso fosse meglio di prima e poi tutto andasse abbastanza bene. Ciò porta ad una mancanza di responsabilità, che in linea di principio è assolutamente normale. Come ho detto il gruppo tecnico è rimasto un po' in disparte. L'azienda credeva che dovessero esistere, ma nessuno ha mai fissato gli standard. Il supporto tecnico non ha mai visto lo SLA, quindi era abbastanza “accettabile” per il gruppo (e questo mi ha colpito di più):

• Caricamento in 12 secondi;
• 5-10 minuti di inattività per ogni versione;
• La risoluzione dei problemi critici richiede giorni e settimane;
• mancanza di personale in servizio 24 ore su 7, XNUMX giorni su XNUMX/di guardia.

Nessuno ha mai provato a chiedersi perché non lo facciamo meglio, e nessuno si è mai reso conto che non deve essere così.

Come bonus, c'era un altro problema: mancanza di esperienza. Gli anziani se ne andarono e il resto della squadra giovane crebbe sotto il regime precedente e ne fu avvelenato.

Oltre a tutto ciò, le persone avevano anche paura di fallire e di apparire incompetenti. Ciò si esprime nel fatto che, in primo luogo, loro in nessun caso ha chiesto aiuto. Quante volte abbiamo parlato in gruppo e individualmente e ho detto: "Fai una domanda se non sai come fare qualcosa". Ho fiducia in me stesso e so che posso risolvere qualsiasi problema, ma ci vorrà del tempo. Pertanto, se posso chiedere a qualcuno che sa come risolverlo in 10 minuti, lo chiederò. Meno esperienza hai, più hai paura di chiedere perché pensi che sarai considerato incompetente.

Questa paura di fare domande si manifesta in modi interessanti. Ad esempio, chiedi: "Come stai andando con questo compito?" - "Mancano un paio d'ore, sto già finendo." Il giorno dopo lo chiedi di nuovo, ottieni la risposta che va tutto bene, ma c'era un problema, sarà sicuramente pronto entro la fine della giornata. Passa un altro giorno e finché non vieni inchiodato al muro e costretto a parlare con qualcuno, questo continua. Una persona vuole risolvere un problema da sola; crede che se non lo risolve da sola, sarà un grande fallimento.

Ecco perché gli sviluppatori hanno gonfiato le stime. È stato lo stesso aneddoto, quando stavano discutendo di un certo compito, mi hanno dato una cifra tale che sono rimasto molto sorpreso. Al che mi è stato detto che nelle stime dello sviluppatore, lo sviluppatore include il tempo in cui il ticket verrà restituito dal QA, perché lì troveranno errori, e il tempo che impiegherà il PR, e il tempo in cui le persone che dovrebbero revisionarlo sarà occupato, cioè tutto, qualunque cosa sia possibile.

In secondo luogo, le persone che hanno paura di apparire incompetenti analizzare eccessivamente. Quando dici cosa bisogna fare esattamente, inizia: "No, e se ci pensassimo qui?" In questo senso la nostra azienda non è unica, questo è un problema tipico dei giovani.

In risposta, ho introdotto le seguenti pratiche:

• Regola 30 minuti. Se non riesci a risolvere il problema in mezz'ora, chiedi aiuto a qualcuno. Funziona con vari gradi di successo, perché le persone ancora non chiedono, ma almeno il processo è iniziato.
• Elimina tutto tranne l'essenza, nello stimare la scadenza per il completamento di un'attività, cioè considerare solo quanto tempo ci vorrà per scrivere il codice.
• L'apprendimento permanente per coloro che analizzano troppo. È solo un lavoro costante con le persone.

Sessantesimo giorno

Mentre facevo tutto questo, era giunto il momento di capire il budget. Naturalmente, ho trovato molte cose interessanti su come abbiamo speso i nostri soldi. Ad esempio, avevamo un intero rack in un data center separato con un server FTP, utilizzato da un client. Si è scoperto che "... ci siamo trasferiti, ma lui è rimasto così, non l'abbiamo cambiato". È stato 2 anni fa.

Di particolare interesse è stata la fattura per i servizi cloud. Credo che il motivo principale dell'elevata fattura del cloud siano gli sviluppatori che hanno accesso illimitato ai server per la prima volta nella loro vita. Non hanno bisogno di chiedere: "Per favore, dammi un server di prova", possono prenderselo da soli. Inoltre, gli sviluppatori vogliono sempre costruire un sistema così interessante da far ingelosire Facebook e Netflix.

Ma gli sviluppatori non hanno esperienza nell'acquisto di server e la capacità di determinare la dimensione richiesta dei server, perché prima non ne avevano bisogno. E di solito non capiscono bene la differenza tra scalabilità e prestazioni.

Risultati dell'inventario:

• Abbiamo lasciato lo stesso data center.
• Abbiamo risolto il contratto con 3 servizi di registro. Perché ne avevamo 5: ogni sviluppatore che ha iniziato a giocare con qualcosa ne ha preso uno nuovo.
• 7 sistemi AWS sono stati chiusi. Ancora una volta, nessuno ha fermato i progetti morti; tutti hanno continuato a lavorare.
• Costi software ridotti di 6 volte.

Giorno settantacinque

Il tempo passò e in due mesi e mezzo dovevo incontrare il consiglio di amministrazione. Il nostro consiglio di amministrazione non è né migliore né peggiore degli altri; come tutti i consigli di amministrazione vuole sapere tutto. Le persone investono denaro e vogliono capire quanto ciò che facciamo rientra nei KPI prefissati.

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

L’unico problema è che credo che la media sia puro male. Ma è molto difficile spiegarlo al consiglio di amministrazione. Sono abituati a operare con numeri aggregati e non, ad esempio, con la diffusione dei tempi di caricamento al secondo.

C'erano alcuni spunti interessanti a questo proposito. Ad esempio, ho detto che dobbiamo dividere il traffico tra server web separati a seconda del tipo di contenuto.

Cioè, ColdFusion passa attraverso Jetty e nginx e lancia le pagine. E immagini, JS e CSS passano attraverso un nginx separato con le proprie configurazioni. Questa è una pratica abbastanza standard di cui sto parlando ho scritto un paio d'anni fa. Di conseguenza, le immagini si caricano molto più velocemente e... la velocità media di caricamento è aumentata di 200 ms.

Ciò è accaduto perché il grafico è costruito in base ai dati forniti con Jetty. Cioè, il contenuto veloce non è incluso nel calcolo: il valore medio è aumentato. Questo per noi era chiaro, abbiamo riso, ma come spiegare al consiglio di amministrazione perché abbiamo fatto qualcosa e le cose sono peggiorate del 12%?

Giorno ottantacinque

Alla fine del terzo mese mi resi conto che c’era una cosa su cui non avevo affatto contato: il tempo. Tutto ciò di cui ho parlato richiede tempo.

Questo è il mio vero calendario settimanale: solo una settimana lavorativa, non molto impegnativa. Non c'è abbastanza tempo per tutto. Pertanto, ancora una volta, devi reclutare persone che ti aiuteranno ad affrontare i problemi.

conclusione

Non è tutto. In questa storia non sono nemmeno riuscito a capire come abbiamo lavorato con il prodotto e cercato di sintonizzarci con l'onda generale, o come abbiamo integrato il supporto tecnico o come abbiamo risolto altri problemi tecnici. Ad esempio, ho imparato quasi per caso che non utilizziamo le tabelle più grandi del database SEQUENCE. Abbiamo una funzione autoscritta nextIDe non viene utilizzato in una transazione.

C'erano un milione di altre cose simili di cui avremmo potuto parlare a lungo. Ma la cosa più importante che ancora va detta è la cultura.

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

• non hanno paura dei fallimenti;
• imparare dagli errori;
• collaborare con altri team;
• prendere l'iniziativa;
• assumersi la responsabilità;
• accogliere il risultato come un traguardo;
• festeggiare il successo.

Con questo arriverà tutto il resto.

Leone Fuoco in twitter, facebook e medie.

Esistono due strategie riguardo all’eredità: evitare di lavorarci a tutti i costi o superare coraggiosamente le difficoltà associate. Noi c DevOpsConf Noi stiamo percorrendo la seconda strada, cambiando processi e approcci. Unisciti a noi su youtube, lista di posta и telegrammae insieme implementeremo una cultura DevOps.

Fonte: habr.com