Hè cunnisciutu chì a cumpetenza di u CTO hè pruvata solu a seconda volta chì eseguisce stu rolu. Perchè hè una cosa di travaglià in una cumpagnia per parechji anni, evoluzione cun ella è, essendu in u stessu cuntestu culturale, riceve gradualmente più rispunsabilità. È hè un altru per vene direttamente in a pusizioni di direttore tecnicu in una sucietà cù bagaglii legati è una mansa di prublemi pulitamente spazzati sottu u tappettu.

In questu sensu, l'esperienza di Leon Fire, chì hà sparte DevOpsConf, micca esattamente unicu, ma multiplicatu da a so sperienza è u nùmeru di diversi roli chì hà sappiutu pruvà annantu à u cursu di 20 anni, hè assai utile. Sottu à u cut hè una cronologia di l'avvenimenti più di 90 ghjorni è assai storii chì sò divertenti per riri quandu succede à qualchissia altru, ma chì ùn sò micca cusì divertenti per affruntà in persona.

Leone parla assai culurita in russo, perchè se avete 35-40 minuti, vi cunsigliu di vede u video. Versione di testu per salvà u tempu quì sottu.

A prima versione di u rapportu era una descrizzione ben strutturata di travaglià cù e persone è i prucessi, chì cuntene cunsiglii utili. Ma ella ùn hà micca trasmessu tutte e sorprese chì anu scontru in a strada. Per quessa, aghju cambiatu u formatu è prisentatu i prublemi chì spuntavanu davanti à mè cum'è un jack-in-the-box in a nova cumpagnia, è i metudi per risolve in ordine cronologicu.

Un mese prima

Cum'è parechje storii boni, questu hà cuminciatu cù l'alcohol. Eramu à pusà cù l'amichi in un bar, è cum'è s'aspittava à mezu à i specialisti in l'informatica, tutti pienghjenu per i so prublemi. Unu di elli avia appena cambiatu di travagliu è parlava di i so prublemi cù a tecnulugia, è cù e persone, è cù a squadra. Più aghju intesu, più aghju capitu ch'ellu duverebbe solu ingaghjami, perchè questi sò i tipi di prublemi chì aghju risoltu per l'ultimi 15 anni. L'aghju dettu cusì, è u ghjornu dopu avemu scontru in un ambiente di travagliu. A cumpagnia hè stata chjamata Strategie d'Insegnamentu.

Teaching Strategies hè un capu di u mercatu in curriculum per i zitelli assai ghjovani da a nascita à trè anni. A cumpagnia tradiziunale di "paper" hà digià 40 anni, è a versione SaaS digitale di a piattaforma hè 10. Relativamente pocu tempu, u prucessu di adattazione di a tecnulugia digitale à i normi di a cumpagnia hà iniziatu. A versione "nova" hè stata lanciata in 2017 è era quasi cum'è a vechja, solu chì hà travagliatu peghju.

A cosa più interessante hè chì u trafficu di sta cumpagnia hè assai prevedibile - da u ghjornu à u ghjornu, da l'annu à l'annu, pudete predichendu chjaramente quantu persone venenu è quandu. Per esempiu, trà 13 è 15 ore di sera, tutti i zitelli in kindergarten vanu à lettu è i prufessori cumincianu à inserisce l'infurmazioni. È questu succede ogni ghjornu, salvu i weekend, perchè quasi nimu travaglia in weekend.

Fighjendu un pocu avanti, aghju nutatu chì aghju cuminciatu u mo travagliu durante u periodu di u trafficu annuale più altu, chì hè interessante per diversi motivi.

A piattaforma, chì pareva esse solu 2 anni, avia una pila peculiar: ColdFusion & SQL Server da 2008. ColdFusion, se ùn cunnosci micca, è più prubabilmente ùn cunnosci micca, hè una impresa PHP chì hè ghjunta à a mità di l'anni 90, è da tandu ùn aghju mancu intesu parlà. Ci era ancu: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ma u monolitu principale curria in ColdFusion è SQL Server.

Problemi

Più aghju parlatu cù l'impiegati di l'impresa nantu à u travagliu è ciò chì i prublemi sò stati scontri, più aghju realizatu chì i prublemi ùn sò micca solu di natura tecnica. Va bè, a tecnulugia hè vechja - è ùn anu micca travagliatu, ma ci sò stati prublemi cù a squadra è cù i prucessi, è a cumpagnia cuminciò à capisce questu.

Tradizionalmente, i so tecnichi s'assittavanu in u cantonu è anu fattu un travagliu. Ma più è più affari cuminciaru à passà per a versione digitale. Dunque, in l'ultimu annu prima ch'e aghju cuminciatu à travaglià, i novi apparsu in a cumpagnia: u cunsigliu di direzzione, CTO, CPO è direttore QA. Questu hè, a cumpagnia hà cuminciatu à investisce in u settore di a tecnulugia.

Tracce di un legatu pisanti ùn eranu micca solu in i sistemi. A cumpagnia avia prucessi legati, persone legati, cultura legata. Tuttu chistu avia da esse cambiatu. Pensu chì definitivamente ùn saria micca noioso, è decisu di pruvà.

Dui ghjorni nanzu

Dui ghjorni prima di principià un novu travagliu, aghju ghjuntu à l'uffiziu, cumpletu l'ultimi documenti, scontru cù a squadra, è scupertu chì a squadra era in difficultà cù un prublema in quellu tempu. Era chì u tempu mediu di carica di a pagina hà saltatu à 4 seconde, vale à dì 2 volte.

A ghjudicà da u graficu, qualcosa hè accadutu chjaramente, è ùn hè micca chjaru ciò chì. Hè risultatu chì u prublema era a latenza di a rete in u centru di dati: a latenza di 5 ms in u centru di dati hè diventata in 2 s per l'utilizatori. Ùn sapia micca perchè questu hè accadutu, ma in ogni casu hè diventatu cunnisciutu chì u prublema era in u centru di dati.

Primu ghjornu

Dui ghjorni passanu è u mo primu ghjornu di travagliu aghju scupertu chì u prublema ùn era micca andatu.

Per dui ghjorni, e pagine di l'utilizatori caricate in media in 4 seconde. Mi dumandu s'ellu anu trovu quale hè u prublema.

- Iè, avemu apertu un bigliettu.
- è?
- Bè, ùn ci anu ancu rispostu.

Allora aghju realizatu chì tuttu ciò chì m'era statu dettu prima era solu una piccula punta di l'iceberg chì avia da cumbatte.

Ci hè una bona citazione chì si adatta assai bè:

"A volte per cambià a tecnulugia avete da cambià l'urganizazione".

Ma dapoi ch'e aghju cuminciatu à travaglià in u tempu più occupatu di l'annu, aghju avutu à guardà e duie opzioni per risolve u prublema: prestu è à longu andà. È cuminciate cù ciò chì hè criticu avà.

Tre Figlie Tre

Cusì, a carica dura 4 seconde, è da 13 à 15 i più grandi cimi.

U terzu ghjornu durante stu periodu di tempu, a velocità di scaricamentu pareva cusì:

Da u mo puntu di vista, nunda hà travagliatu. Da u puntu di vista di tutti l'altri, andava un pocu più lentu di u solitu. Ma solu ùn succede micca cusì - hè un prublema seriu.

Aghju pruvatu à cunvince a squadra, à quale anu rispostu chì simpricimenti avianu bisognu di più servitori. Questu, sicuru, hè una suluzione à u prublema, ma ùn hè micca sempre l'unicu è più efficace. Aghju dumandatu perchè ùn ci era micca abbastanza servitori, quale era u voluminu di trafficu. Aghju extrapolatu i dati è truvaru chì avemu apprussimatamente 150 richieste per seconda, chì, in principiu, cade in limiti raghjone.

Ma ùn devemu micca scurdatu chì prima di ottene a risposta ghjusta, avete bisognu di dumandà a quistione ghjusta. A mo prossima dumanda era: quanti servitori frontend avemu? A risposta "mi ha sconvoltu un pocu" - avemu avutu 17 servitori di frontend!

- Mi vergogna di dumandà, ma 150 divisu da 17 dà circa 8 ? Dici chì ogni servitore permette 8 richieste per seconda, è se dumane ci sò 160 richieste per seconda, avemu bisognu di 2 più servitori ?

Di sicuru, ùn avemu micca bisognu di servitori supplementari. A suluzione era in u codice stessu, è nantu à a superficia:

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

Ci era una funzione getCurrentClass(), perchè tuttu in u situ travaglia in u cuntestu di una classa - hè cusì. È per questa una funzione in ogni pagina ci era 200+ dumande.

A suluzione stu modu era assai sèmplice, ùn avete mancu bisognu di riscrive qualcosa: solu ùn dumandà micca a stessa infurmazione di novu.

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

Eru assai cuntentu perchè decisu chì solu u terzu ghjornu aghju trovu u prublema principali. Ingenu cum'è eru, questu era solu unu di parechji prublemi.

Ma risolviri stu primu prublema abbandunò u graficu assai più bassu.

À u listessu tempu, avemu fattu altre ottimisazioni. Ci era parechje cose in vista chì puderia esse riparatu. Per esempiu, in u stessu terzu ghjornu, aghju scupertu chì ci era una cache in u sistema dopu à tuttu (in prima aghju pensatu chì tutte e dumande venenu direttamente da a basa di dati). Quandu pensu à una cache, pensu à Redis standard o Memcached. Ma eru l'unicu chì pensava cusì, perchè quellu sistema hà utilizatu MongoDB è SQL Server per caching - u stessu da quale i dati sò stati appena leghje.

Ghjornu deci

A prima settimana aghju trattatu i prublemi chì avianu da esse risolti avà. In qualchì locu in a seconda settimana, sò ghjuntu à u stand-up per a prima volta per cumunicà cù a squadra, per vede ciò chì succeva è cumu si passava tuttu u prucessu.

Qualcosa interessante hè statu scupertu novu. A squadra era custituita da: sviluppatori 18; 8 tester; 3 amministratori; 2 architetti. E tutti anu participatu à rituali cumuni, vale à dì, più di 30 persone venenu à u stand-up ogni matina è dicenu ciò chì anu fattu. Hè chjaru chì a riunione ùn hà micca pigliatu 5 o 15 minuti. Nimu hà intesu à nimu perchè tutti travaglianu nantu à diversi sistemi. In questa forma, 2-3 biglietti per ora per una sessione di grooming era digià un bonu risultatu.

A prima cosa chì avemu fattu hè divisu a squadra in parechje linee di prudutti. Per e diverse sezioni è sistemi, avemu attribuitu squadre separati, chì includenu sviluppatori, testatori, gestori di prudutti è analisti di cummerciale.

In u risultatu, avemu:

• Riduzzione di stand-up è manifestazioni.
• Cunniscenza di u sughjettu di u pruduttu.
• Un sensu di pruprietà. Quandu a ghjente hà avutu per tinker cù i sistemi tuttu u tempu, sapianu chì qualcunu altru più prubabilmente hà da travaglià cù i so bug, ma micca elli stessi.
• Cullaburazione trà gruppi. Inutili, QA ùn hà micca cumunicatu assai cù i programatori prima, u pruduttu hà fattu u so propiu, etc. Avà anu un puntu cumuni di rispunsabilità.

Avemu principarmenti focu annantu à l'efficienza, a produtividade è a qualità - questi sò i prublemi chì avemu pruvatu à risolve cù a trasfurmazioni di a squadra.

U ghjornu undici

In u prucessu di cambià a struttura di a squadra, aghju scupertu cumu cuntà StoryPoints. 1 SP era uguale à un ghjornu, è ogni bigliettu cuntene SP per u sviluppu è QA, vale à dì almenu 2 SP.

Cumu aghju scupertu questu?

Avemu trovu un bug: in unu di i rapporti, induve a data di iniziu è di fine di u periodu per quale u rapportu hè necessariu hè inseritu, l'ultimu ghjornu ùn hè micca cunsideratu. Questu hè, in un locu in a dumanda ùn ci era micca <=, ma solu <. Mi sò dettu chì questu hè trè Story Points, vale à dì Ghjorni di 3.

Dopu questu avemu:

• U sistema di classificazione Story Points hè statu rivedutu. Avà correzioni per bug minori chì ponu esse passati rapidamente attraversu u sistema ghjunghjenu à l'utilizatore più veloce.
• Avemu cuminciatu à unisce i biglietti cunnessi per u sviluppu è a prova. Prima, ogni bigliettu, ogni bug era un ecosistema chjusu, micca ligatu à nunda d'altru. U cambiamentu di trè buttoni in una pagina puderia esse trè biglietti diffirenti cù trè prucessi di QA diffirenti invece di una prova automatizzata per pagina.
• Avemu cuminciatu à travaglià cù i sviluppatori nantu à un approcciu per stima i costi di u travagliu. Trè ghjorni per cambià un buttone ùn hè micca divertente.

Ghjornu vintisimu

In un locu in a mità di u primu mese, a situazione si stabilizeghja un pocu, aghju capitu ciò chì succedeva in fondu, è digià cuminciatu à guardà in u futuru è pensate à suluzioni à longu andà.

Obiettivi à longu andà:

• Piattaforma amministrata. Centinaie di richieste in ogni pagina ùn sò micca serii.
• Tendenze prevedibili. Ci sò stati picchi di trafficu periodicu chì à u primu sguardu ùn anu micca correlate cù altre metriche - avemu bisognu di capisce perchè questu hè accadutu è amparà à predichendu.
• Espansione di a piattaforma. L'affari hè in constantemente crescente, più è più utilizatori venenu, è u trafficu cresce.

In u passatu si diceva spessu: "Riscrivemu tuttu in [lingua / quadru], tuttu funziona megliu!"

In a maiò parte di i casi, questu ùn funziona micca, hè bonu se a riscrittura funziona. Dunque, avemu bisognu di creà una roadmap - una strategia specifica chì illustra passu per passu cumu si ghjunghjeranu i scopi di l'affari (ciò chì faremu è perchè), chì:

• riflette a missione è i scopi di u prugettu;
• priurità i scopi principali;
• cuntene un calendariu per ottene elli.

Prima di questu, nimu ùn avia parlatu à a squadra di u scopu di qualsiasi cambiamenti esse fattu. Questu hè bisognu di e metriche di successu ghjustu. Per a prima volta in a storia di a cumpagnia, avemu stabilitu KPIs per u gruppu tecnicu, è questi indicatori sò stati ligati à l'urganisazione.

Vale à dì, i KPI di l'urganizazione sò supportati da e squadre, è i KPI di a squadra sò supportati da i KPI individuali. Altrimenti, se i KPI tecnologichi ùn coincidenu micca cù l'urganisazione, allora tutti tiranu a manta nantu à elli stessi.

Per esempiu, unu di i KPI di l'urganisazione aumenta a quota di mercatu per mezu di novi prudutti.

Cumu pudete sustene u scopu di avè più prudutti novi?

• Prima, vulemu passà più tempu à sviluppà novi prudutti invece di riparà i difetti. Questa hè una suluzione logica chì hè faciule da misurà.
• Siconda, vulemu sustene un aumentu di u voluminu di transazzione, perchè più grande hè a quota di mercatu, più utilizatori è, per quessa, più trafficu.

Allora i KPI individuali chì ponu esse eseguiti in u gruppu seranu, per esempiu, in u locu induve venenu i difetti principali. Se vi cuncentrate specificamente in questa sezione, pudete assicurà chì ci sò assai menu difetti, è poi u tempu per sviluppà novi prudutti è di novu per sustene i KPIs di l'urganisazione aumenterà.

Cusì, ogni decisione, cumpresu u codice di riscrittura, deve sustene l'ugettivi specifichi chì a cumpagnia hà stabilitu per noi (crescita urganisazione, funzioni novi, reclutamentu).

Duranti stu prucessu, una cosa interessante hè ghjunta à a luce, chì hè diventata nutizie micca solu per i tecnichi, ma in generale in a cumpagnia: tutti i biglietti deve esse focu annantu à almenu un KPI. Questu hè, se un pruduttu dice chì vole fà una nova funzione, a prima dumanda deve esse dumandata: "Quale KPI supporta sta funzione?" Se no, allora scusate - pare cum'è una funzione inutile.

Trenta ghjornu

À a fine di u mese, aghju scupertu un'altra sfumatura: nimu in u mo squadra Ops hà mai vistu i cuntratti chì entremu cù i clienti. Pudete dumandà perchè avete bisognu di vede i cuntatti.

• Prima, perchè i SLA sò specificati in cuntratti.
• Siconda, i SLA sò tutti diffirenti. Ogni cliente hè vinutu cù i so bisogni, è u dipartimentu di vendita hà firmatu senza circà.

Un'altra sfumatura interessante hè chì u cuntrattu cù unu di i più grandi clienti dichjara chì tutte e versioni di u software supportatu da a piattaforma deve esse n-1, vale à dì micca l'ultima versione, ma a penultima.

Hè chjaru quantu eramu luntanu da n-1 se a piattaforma era basata nantu à ColdFusion è SQL Server 2008, chì ùn era più supportatu in tuttu in u lugliu.

Ghjornu quarantacinque

Intornu à a mità di u secondu mese aghju avutu abbastanza tempu per pusà è fà valorebracciuaerial cumpletamente per tuttu u prucessu. Quessi sò i passi necessarii chì deve esse pigliatu, da a creazione di un pruduttu à a consegna à u cunsumadore, è anu da esse descritte in u più dettagliu pussibule.

Scuprite u prucessu in picculi pezzi è vede ciò chì piglia troppu tempu, ciò chì pò esse ottimizatu, migliuratu, etc. Per esempiu, quantu tempu ci vole à una dumanda di produttu per passà per u grooming, quandu ghjunghje à un bigliettu chì un sviluppatore pò piglià, QA, etc. Allora guardate ogni passu individuale in dettagliu è pensate à ciò chì pò esse ottimisatu.

Quandu aghju fattu questu, duie cose mi anu attiratu l'ochju:

• altu percentualità di i biglietti tornati da QA à i sviluppatori;
• pull request recensioni pigliò troppu longu.

U prublema era chì questi eranu cunclusioni cum'è: Pare chì piglià assai tempu, ma ùn simu sicuru di quantu tempu.

"Ùn pudete micca migliurà ciò chì ùn pudete micca misurà".

Cumu ghjustificà quantu seria u prublema hè? Perdi ghjorni o ore?

Per misurà questu, avemu aghjustatu un paru di passi à u prucessu Jira: "prontu per dev" è "prontu per QA" per misurà quantu tempu ogni bigliettu aspetta è quante volte torna à un certu passu.

Avemu ancu aghjustatu "in rivista" per sapè quanti biglietti sò in media per rivisione, è da questu pudete cumincià à ballà. Avemu avutu metrica di u sistema, avà aghjustatu novi metriche è cuminciamu à misurà:

• Efficienza di prucessu: prestazione è pianificata / consegnata.
• Qualità di prucessu: numeru di difetti, difetti da QA.

Aiuta veramente à capisce ciò chì va bè è ciò chì ùn hè micca bè.

Cinquantesimu ghjornu

Questu hè tuttu, sicuru, bonu è interessante, ma versu a fine di u secondu mese hè accadutu qualcosa chì, in principiu, era previsible, ancu s'ellu ùn m'aspittava micca una tale scala. A ghjente hà cuminciatu à lascià perchè l'alta direzzione era cambiata. A nova ghjente hè ghjunta in a gestione è hà cuminciatu à cambià tuttu, è i vechji abbandunonu. È di solitu in una cumpagnia chì hè parechji anni, tutti sò amici è tutti si cunnosci.

Questu era previstu, ma a scala di i licenziamenti era inespettata. Per esempiu, in una settimana, dui capi di squadra anu presentatu simultaneamente e so dimissioni di a so propria vuluntà. Per quessa, aghju avutu micca solu scurdà di altri prublemi, ma fucalizza nantu criendu una squadra. Questu hè un prublema longu è difficiuli di risolve, ma duverebbe esse trattatu perchè vulia salvà a ghjente chì restava (o a maiò parte di elli). Era necessariu di reagisce d'una manera à u fattu chì a ghjente si n'andò per mantene a morale in a squadra.

In teoria, questu hè bonu: vene una nova persona chì hà una carta bianca completa, chì pò evaluà e cumpetenze di a squadra è rimpiazzà u persunale. In fatti, ùn pudete micca solu purtà novi persone per tanti mutivi. L'equilibriu hè sempre necessariu.

• Vechju è novu. Avemu bisognu di mantene i vechji chì ponu cambià è sustene a missione. Ma à u listessu tempu, avemu bisognu di purtà u sangue novu, ne parleremu un pocu dopu.
• Esperienza. Aghju parlatu assai cun boni juniors chì eranu ansiosi è vulianu travaglià cun noi. Ma ùn li pudia piglià perchè ùn ci era micca abbastanza anziani per sustene i juniors è agisce cum'è mentori per elli. Era necessariu di primu reclutà a cima è solu dopu a ghjuventù.
• Carota è bastone.

Ùn aghju micca una bona risposta à a quistione di ciò chì hè u equilibriu ghjustu, cumu mantene, quante persone per mantene è quantu spinghje. Questu hè un prucessu puramente individuale.

Cinquantu ghjornu

Aghju cuminciatu à guardà attentamente à a squadra per capisce quale aghju avutu, è una volta mi ricurdò:

"A maiò parte di i prublemi sò prublemi di e persone".

Aghju trovu chì a squadra in quantu - sia Dev sia Ops - hà trè grandi prublemi:

• Soddisfazione cù u statu attuale di l'affari.
• Mancanza di rispunsabilità - perchè nimu ùn hà mai purtatu i risultati di u travagliu di l'interpreti per influenzà l'affari.
• A paura di cambià.

U cambiamentu ti porta sempre fora di a vostra zona di cunfortu, è i più ghjovani sò, più dispiacenu u cambiamentu perchè ùn capiscenu micca perchè è ùn capiscenu micca cumu. A risposta più cumuna chì aghju intesu hè: "Ùn avemu mai fattu questu". Inoltre, hà ghjuntu à u puntu di l'assurdità cumpleta - i più minimi cambiamenti ùn puderanu micca esse senza chì qualcunu sia indignatu. E quantu i cambiamenti anu affettatu u so travagliu, a ghjente hà dettu: "No, perchè? Questu ùn funziona micca ".

Ma ùn pudete micca megliu senza cambià nunda.

Aviu avutu una conversazione assulutamente assurda cù un impiigatu, li aghju dettu e mo idee per ottimisazione, à quale m'hà dettu:
- Oh, ùn avete micca vistu ciò chì avemu avutu l'annu passatu !
- Allora?
"Avà hè assai megliu cà era."
- Allora, ùn si pò micca megliu ?
- Per chì ?

Bona dumanda - perchè? Hè cum'è s'ellu hè megliu avà chè era, allora tuttu hè abbastanza bè. Questu porta à una mancanza di rispunsabilità, chì hè assolutamente normale in principiu. Cumu l'aghju dettu, u gruppu tecnicu era un pocu à u latu. A cumpagnia hà cridutu chì duverebbe esse, ma nimu ùn hà mai stabilitu i standard. U supportu tecnicu ùn hà mai vistu u SLA, cusì era abbastanza "accettabile" per u gruppu (è questu m'hà colpitu u più):

• 12 seconde di carica;
• 5-10 minuti di downtime per ogni versione;
• A risoluzione di i prublemi critichi dura ghjorni è settimane;
• mancanza di persunale di serviziu 24x7 / on-call.

Nimu hà mai pruvatu à dumandà perchè ùn a facemu micca megliu, è nimu hà mai capitu chì ùn deve micca esse cusì.

Comu bonus, ci era un altru prublema: mancanza di sperienza. L'anziani partenu, è a squadra ghjovana restante hà crisciutu sottu u regime precedente è hè stata avvelenata da questu.

In più di tuttu questu, a ghjente era ancu a paura di fallu è pareva incompetente. Questu hè spressu in u fattu chì, prima, elli in nisun casu ùn hà dumandatu aiutu. Quante volte avemu parlatu cum'è un gruppu è individualmente, è aghju dettu: "Fate una dumanda se ùn sapete micca fà qualcosa". Sò cunfidendu in mè stessu è sapemu chì possu risolve ogni prublema, ma duverà tempu. Dunque, se possu dumandà à qualchissia chì sà cumu risolve in 10 minuti, vi dumandà. A menu sperienza chì avete, più paura di dumandà perchè pensate chì sarete cunsideratu incompetente.

Stu timore di dumandà dumande si manifesta in modi interessanti. Per esempiu, dumandate: "Cumu fate cù questu compitu?" - "Mancanu un paru d'ore, aghju digià finitu." U ghjornu dopu avete dumandatu di novu, avete a risposta chì tuttu hè bè, ma ci era un prublema, serà definitu pronta à a fine di u ghjornu. Un altru ghjornu passa, è finu à ch'è tù sì appiccicatu à u muru è furzatu à parlà à qualchissia, questu cuntinueghja. Una persona vole risolve u prublema stessu; crede chì s'ellu ùn u risolve micca ellu stessu, serà un grande fallimentu.

Hè per quessa i sviluppatori anu inflatatu l'estimi. Era quella stessa anecdota, quand'elli discutevanu un certu compitu, m'anu datu una figura cusì chì eru assai surprised. À quale m'hà dettu chì in l'estimazioni di u sviluppatore, u sviluppatore include u tempu chì u bigliettu serà tornatu da QA, perchè trovanu l'errore quì, è u tempu chì u PR hà da piglià, è u tempu mentre e persone chì duveranu rivisione. serà occupatu - vale à dì tuttu, tuttu ciò chì hè pussibule.

Siconda, e persone chì anu a paura di appare incompetenti overanalyze. Quandu dite esattamente ciò chì deve esse fattu, cumencia: "No, è s'ellu ci pensemu quì?" In questu sensu, a nostra cumpagnia ùn hè micca unica; questu hè un prublema standard per i ghjovani.

In risposta, aghju introduttu e seguenti pratiche:

• Regula 30 minuti. Se ùn pudete micca risolve u prublema in una meza ora, dumandate à qualchissia per aiutà. Questu travaglia cù varii gradi di successu, perchè e persone ùn anu micca dumandatu, ma almenu u prucessu hà cuminciatu.
• Eliminate tuttu ma l'essenza, in l'estimazione di a scadenza per cumpiendu un compitu, vale à dì, cunsiderà solu quantu tempu ci vole à scrive u codice.
• Apprendimentu permanente per quelli chì overanalyze. Hè solu un travagliu constante cù e persone.

Ghjornu sessanta

Mentre facia tuttu questu, era ora di calculà u budgetu. Di sicuru, aghju trovu assai cose interessanti induve avemu passatu i nostri soldi. Per esempiu, avemu avutu un rack sanu in un centru di dati separatu cù un servitore FTP, chì era utilizatu da un cliente. Risultava chì "... avemu spustatu, ma ellu ferma cusì, ùn avemu micca cambiatu". Era 2 anni fà.

D'interessu particulari era a fattura per i servizii di nuvola. Credu chì u mutivu principalu di a fattura alta nuvola hè i sviluppatori chì anu accessu illimitatu à i servitori per a prima volta in a so vita. Ùn ci anu micca bisognu di dumandà: "Per piacè dà un servitore di teste", ponu piglià elli stessi. In più, i sviluppatori volenu sempre custruisce un sistema cusì cool chì Facebook è Netflix seranu ghjilosi.

Ma i sviluppatori ùn anu micca sperienza in l'acquistu di servitori è l'abilità di determinà a dimensione necessaria di i servitori, perchè ùn avianu micca bisognu prima. È di solitu ùn capiscenu micca bè a diffarenza trà scalabilità è prestazione.

I risultati di l'inventariu:

• Avemu lasciatu u listessu centru di dati.
• Avemu terminatu u cuntrattu cù servizii di log 3. Perchè avemu avutu 5 di elli - ogni sviluppatore chì hà cuminciatu à ghjucà cù qualcosa hà pigliatu un novu.
• 7 sistemi AWS sò stati chjusi. In novu, nimu hà firmatu i prughjetti morti; tutti cuntinueghjanu à travaglià.
• Costi di software ridotti da 6 volte.

Ghjornu settanta cinque

U tempu passava, è in dui mesi è mezu aghju avutu à scuntrà cù u cunsigliu di direzzione. U nostru cunsigliu di direttori ùn hè micca megliu o peghju chè l'altri; cum'è tutti i cunsiglii di direzzione, vole sapè tuttu. E persone investenu soldi è volenu capisce quantu ciò chì facemu si mette in i KPIs stabiliti.

U cunsigliu di direzzione riceve assai infurmazioni ogni mese: u numeru di l'utilizatori, a so crescita, i servizii chì utilizanu è cumu, u rendiment è a produtividade, è infine, a velocità media di carica di pagina.

L'unicu prublema hè chì crede chì a media hè pura male. Ma hè assai difficiule di spiegà questu à u cunsigliu di direzzione. Sò abituati à uperà cù numeri aggregati, è micca, per esempiu, a diffusione di i tempi di carica per seconda.

Ci era parechji punti interessanti in questu sensu. Per esempiu, aghju dettu chì avemu bisognu di sparte u trafficu trà servitori web separati secondu u tipu di cuntenutu.

Questu hè, ColdFusion passa per Jetty è nginx è lancia e pagine. E l'imaghjini, JS è CSS passanu per un nginx separatu cù e so cunfigurazioni. Questa hè una pratica abbastanza standard chì parlu hà scrittu un paru d'anni fà. In u risultatu, l'imaghjini caricanu assai più veloce, è ... a velocità media di carica hè aumentata da 200 ms.

Questu hè accadutu perchè u graficu hè custruitu nantu à e dati chì venenu cù Jetty. Questu hè, u cuntenutu veloce ùn hè micca inclusu in u calculu - u valore mediu hà saltatu. Questu era chjaru per noi, ridiamu, ma cumu pudemu spiegà à u cunsigliu di direzzione perchè avemu fattu qualcosa è e cose peghju da 12% ?

Ghjornu ottanta cinque

À a fine di u terzu mesi, aghju realizatu chì ci era una cosa chì ùn avia micca cuntatu à tuttu: u tempu. Tuttu ciò chì aghju parlatu piglia tempu.

Questu hè u mo veru calendariu settimanale - solu una settimana di travagliu, micca assai occupatu. Ùn ci hè abbastanza tempu per tuttu. Dunque, di novu, avete bisognu di recrutà e persone chì vi aiuteranu à trattà cù i prublemi.

cunchiusioni

Ùn hè micca tuttu. In questa storia, ùn aghju micca ancu ghjuntu à cumu avemu travagliatu cù u pruduttu è pruvatu à sintonizà l'onda generale, o cumu avemu integratu u supportu tecnicu, o cumu risolvemu altri prublemi tecnichi. Per esempiu, aghju amparatu abbastanza per accidenti chì nantu à e più grande tavule in a basa di dati ùn avemu micca aduprà SEQUENCE. Avemu una funzione auto-scritta nextID, è ùn hè micca usatu in una transazzione.

Ci era un milione di cose simili chì pudemu parlà per un bellu pezzu. Ma u più impurtante chì ci vole à dì hè a cultura.

Hè a cultura o a mancanza di questu chì porta à tutti l'altri prublemi. Cerchemu di custruisce una cultura induve a ghjente:

• ùn sò micca paura di fallimenti;
• amparà da i sbagli;
• cullaburazione cù altre squadre;
• piglià l'iniziativa;
• piglià a rispunsabilità;
• accoglie u risultatu cum'è un scopu;
• celebrà u successu.

Cù questu tuttu u restu venerà.

Leon Fire nant'à twitter, romania è quì medie.

Ci hè duie strategie in quantu à u legatu: evità di travaglià cun ellu à tutti i costi, o superà bravamente e difficultà assuciate. Avemu c DevOpsConf Pigliemu a seconda strada, cambiendu prucessi è approcci. Unisciti à noi fratii, mailing list и telegramma, è inseme implementeremu una cultura DevOps.

Source: www.habr.com