On teada, et CTO kompetentsi kontrollitakse vaid teisel korral, kui ta seda rolli täidab. Sest asi on selles, et töötada mitu aastat firmas, arendada koos temaga ja, olles endiselt samas kultuurikontekstis, saada järk-järgult rohkem vastutust, on üks asi. Ja hoopis teine on kohe tehnilise direktori ametisse astumine firmasse, millel on pärand ja hulk probleeme, mis on ettevaatlikult vaipa pühitud.

Selles mõttes on Leon Fayeri kogemus, millega ta jagas DevOpsConf, mitte just täiesti ainulaadne, kuid koos tema 20-aastase karjääri ja erinevate rollde arvuga, mida ta on suutnud endale võtta, on see väga kasulik. Allpool on 90 päeva sündmuste kronoloogia ja palju nördimusi, mille üle on hea naerda, kui need juhtuvad kellegi teisega, kuid millega pole nii lõbus silmitsi seista.

Leon räägib väga värvikalt vene keeles, seega kui sul on 35-40 minutit, soovitan videot vaadata. Tekstiversioon aja säästmiseks on allpool.

Esimene versioon ettekandest oli hästi struktureeritud kirjeldus inimeste ja protsessidega töötamisest, mis sisaldas kasulikke soovitusi. Kuid see ei edastanud kõiki teel ette tulnud üllatusi. Seetõttu muutsin formaati ja esitasin probleemid, millega ma uues firmas silmitsi seisime, nagu kuri vaim sulepeast, ja nende lahendamise meetodid ajalise järjekorra alusel.

Kuu aega enne

Nagu paljude headest lugudest, algas see alkoholiga. Istusime tuttavatega baaris ja nagu IT-spetsialistide seas tavaks, kurtis igaüks oma probleemide üle. Üks neist oli just tööd vahetanud ja rääkis oma tehnoloogia, inimeste ja meeskonna probleemidest. Mida kauem ma teda kuulasin, seda rohkem sain aru, et tal oleks vaja lihtsalt mind palgata, sest just selliste probleemidega olen ma viimased 15 aastat tegelenud. Nii ütlesin ma talle ja järgmisel päeval kohtusime juba ametlikus keskkonnas. Ettevõtte nimi oli Teaching Strategies.

Teaching Strategies on liider laste haridusprogrammidel, mis on suunatud väga varajases eas - sünnist kuni kolme aastani. Traditsiooniline „paberivaba” ettevõte on tegutsenud juba 40 aastat, samas kui digitaalne SaaS-versioon platvormist on olnud turul 10 aastat. Suhteliselt hiljuti algas digitaalsete tehnoloogiate kohandamine ettevõtte standardite juurde. „Uus” versioon käivitati 2017. aastal ja oli peaaegu sama, kuid töötas halvemini.

Huvitav on see, et selle ettevõtte liiklus on väga prognoositav — päevast päeva, aastast aastasse on võimalik väga täpselt ennustada, kui palju inimesi tuleb ja millal. Näiteks kell 13-15 lähevad kõik lapsed lasteaedades magama, samal ajal hakkavad õpetajad teavet sisestama. Ja see toimub iga päev, välja arvatud nädalavahetustel, kuna nädalavahetustel ei tööta peaaegu keegi.

Kuid juba ette mainides ütlen, et alustasin oma tööd ajal, mil oli kõige suurem aastane liiklus, mis on huvitav mitmel põhjusel.

Platvorm, mis oli olnud alles kaks aastat, omas omamoodi teknoloogilist kihi: ColdFusion & SQL Server 2008. ColdFusion, kui te ei tea — ja tõenäoliselt ei tea — on selline enterprise PHP, mis ilmus 90ndate keskpaiku, ja ma pole selle kohta pärast seda isegi midagi kuulnud. Samuti olid seal: Ruby, MySQL, PostgreSQL, Java, Go, Python. Kuid peamine monoliit töötas ColdFusioni ja SQL Serveriga.

Probleemid

Mida rohkem ma ettevõtte töötajatega rääkisin, seda rohkem sain aru, et probleemid ei olnud ainult tehnilise iseloomuga. Nojah, tehnoloogia on vana — ja pole midagi, millega pole töötatud, kuid olid probleemid meeskonna ja protsessidega ning ettevõte hakkas seda aru saama.

Traditsiooniliselt olid nende tehnikud nurgas ja tegelesid mingisuguse oma tööga. Kuid üha rohkem ja rohkem äri hakkas liikuma just läbi digitaalse versiooni. Seetõttu ilmus ettevõttes eelmisel aastal minu töö alguses uusi inimesi: juhatus, CTO, CPO ja QA-direktor. See tähendab, et ettevõte hakkas investeerima tehnoloogiasektorisse.

Raske pärandi jäljed olid olemas mitte ainult süsteemides. Ettevõttes olid legacy-protsessid, legacy-inimesed, legacy-kultuur. Kõike seda tuli muuta. Mõtlesin, et kindlasti ei hakka igav ja otsustasin proovida.

Kaks päeva enne

Kaks päeva enne uue töö algust tulin kontorisse, täitsin viimased dokumendid, tutvusin meeskonnaga ja avastasin, et sel ajal võitles meeskond probleemiga. Probleem seisnes selles, et lehtede keskmine laadimisaeg oli tõusnud 4 sekundini, mis tähendab kahekordset kasvu.

Graafiku põhjal oli selgelt midagi juhtunud, kuid ei olnud selge, mis. Selgus, et probleem oli network latency andmekeskuses: 5 ms latentsus andmekeskuses muutus 2 sekundiks kasutajatele. Miks see nii juhtus, ei teadnud ma, kuid igal juhul sai teada, et probleem on andmekeskuses.

Esimene päev

Kaks päeva hiljem avastasin ma oma esimesel tööl päeval, et probleem ei olnud kuhugi kadunud.

Kaks päeva laadis leht keskmiselt 4 sekundit. Küsin, kas oleme leidnud, mis probleem on.

— Jah, me avasime pileti.
— Ja?
— Noh, nad pole meile veel vastanud.

Siis mõistsin, et kõik, millest mulle varem räägiti, oli vaid jäämäe nähtav osa, millega tuleb tegeleda.

On hea tsitaat, mis sobib suurepäraselt selle olukorra jaoks:

„Mõnikord on tehnoloogia muutmiseks vaja muuta organisatsiooni.“

Kuna alustasin tööd kõige koormatud aastaaegadel, pidin vaatama mõlemaid probleemilahenduse varianti: nii kiiret kui ka pikaajalist. Ja alustama kõige kriitilisemast.

Kolmas päev

Nii, laadimine kestab 4 sekundit ja kella 13–15 on kõige suuremad tipud.

Kolmandal päeval nägi selle ajavahemiku laadimiskiirus välja nii:

Minu vaatenurgast ei töötanud üldse mitte midagi. Kõigi teiste jaoks töötas see natuke aeglasemalt kui tavaliselt. Kuid lihtsalt niimoodi ei juhtu — see on tõsine probleem.

Püüdsin meeskonda veenda, millele nad vastasid, et meil on lihtsalt rohkem servereid vajalikud. See on muidugi probleemilahendus, kuid mitte alati ainus ja kõige tõhusam. Küsin, miks serveritest puudu jääb, kui suur on liiklus. Ekstrapoleerisin andmed ja sain, et meil on umbes 150 päringut sekundis, mis on põhimõtteliselt mõistlikul tasemel.

Kuid ei tohi unustada, et enne õige vastuse saamist tuleb esitada õige küsimus. Minu järgmine küsimus oli: kui palju meil on frontend-servereid. Vastus hämmastas mind veidi — meil oli 17 frontend-serverit!

— Julgen küsida, kui jagada 150 17-ga, saame umbes 8? Tahtsite öelda, et iga server laseb läbi 8 päringut sekundis, ja kui homme on 160 päringut sekundis, vajame veel 2 serverit?

Muidugi ei olnud meil vajagi lisaseverid. Lahendus peitus koodis, veelgi enam, see oli pinnapealne:

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

Oli funktsioon getCurrentClass(), sest kõik saidil töötab klassi kontekstis — see on õige. Ja igaühe jaoks selle funktsiooni peal iga lehe jaoks tuli 200+ päringut.

Lahendus oli seega väga lihtne, ei olnud isegi vaja midagi ümber kirjutada: lihtsalt ei küsi sama teavet uuesti.

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

Olin väga rõõmus, sest arvasin, et leidsin peamise probleemi vaid kolmandal päeval. Kuidas ma olin naiivne, see oli vaid üks paljusid probleeme.

Kuid selle esimese probleemi lahendamine tõi graafiku palju madalamale.

Sama ajal tegelesime teiste optimeerimistega. Palju asju oli silma all, mida sai parandada. Näiteks avastasin kolmandal päeval, et süsteemis oli siiski vahemälu (esialgu arvasin, et kõik päringud tulevad otse andmebaasist). Kui mõtlen vahemälule, kujutan ette tavalisi Redis või Memcached. Kuid ainult mina mõtlesin nii, sest selle süsteemi vahemäluks kasutati MongoDB-d ja SQL Serverit — sama, millest andmed äsja loeti.

Kümnes päev

Esimese nädala veetsin probleemide otsimisega, mida tuli kohe lahendada. Kusagil teisel nädalal tulin esmakordselt stand-up'i, et suhelda meeskonnaga, näha, mis toimub ja kuidas kogu protsess kulgeb.

Taaskord avastasin midagi huvitavat. Meeskond koosnes: 18 arendajast; 8 testijast; 3 juhist; 2 arhitektist. Ja kõik nad osalesid üldistes rituaalides, st rohkem kui 30 inimest tuli iga hommik stand-up'ile ja rääkis, mida nad tegid. Selge, et kohtumine ei kestnud 5 ega 15 minutit. Keegi ei kuulnud kedagi, sest kõik töötasid erinevates süsteemides. Sel viisil 2-3 piletit tunni jooksul grooming session'il juba oli hea tulemus.

Esimene asi, mida me tegime, oli jagada meeskond mitmeks toodete rida pidi. Erinevate sektsioonide ja süsteemide jaoks eraldasime spetsiifilised meeskonnad, kuhu kuulusid arendajad, testijad, tootjajuhid ja ärianalüütikud.

Tulemuseks saime:

• Stand-upide ja koosolekute lühenemine.
• Tootealane teadmiste baasi.
• Omanditunne. Kui varem liikusid inimesed pidevalt süsteemide vahel, teadsid nad, et tõenäoliselt peavad kellegi teise vead lahendama, mitte ise.
• Koostöö gruppide vahel. Pole vaja öelda, et QA ja arendajad ei ole varem eriti suhelnud, tootearendaja tegi oma asja jne. Nüüd on neil ühine vastutuse koht.

Peamiselt keskendusime efektiivsusele, tootlikkusele ja kvaliteedile — need probleemid olid need, mida püüdsime lahendada meeskonna transformatsiooni kaudu.

Üheteistkümnes päev

Meeskonna struktuuri muutmise käigus avastasin, kuidas loendatakse LuguPunktid. 1 SP oli võrdsed ühe päevaga, ja iga pilet sisaldas SP-d nii arendamiseks kui ka QA-ks, st vähemalt 2 SP-d.

Kuidas ma seda avastasin?

Leidsime vea: ühes raportis, kus sisestatakse algus- ja lõppkuupäev, ei arvestata viimast päeva. See tähendab, et kusagil päringus oli mitte <=, vaid lihtsalt <. Mulle öeldi, et see on kolm Story Pointi, st 3 päeva.

Pärast seda me:

• Vaatasime üle Story Pointide hindamissüsteemi. Nüüd jõuavad väikeste vigade parandused, mida saab kiiresti süsteemi sisse viia, kiiremini kasutajani.
• Alustasime seotud piletite ühendamist arendamiseks ja testimiseks. Varem oli iga pilet, iga viga iseseisev ekosüsteem, mis ei olnud seotud millegi muuga. Kolme nupu muutmine ühel lehel võis olla kolm erinevat piletit kolme erineva QA-protsessiga, mitte üks automaatne test lehel.
• Hakkasime arendajatega töötama töömahtude hindamise lähenemise kallal. Kolm päeva, et muuta ühte nuppu — see ei ole naljakas.

Kakskümmend päev

Kusagil kuu esimeses pooles olukord veidi stabiliseerus, sain aru, mis põhimõtteliselt toimub, ja hakkasin juba tulevikku vaatama ja pikaajalisi lahendusi mõtlema.

Pikaajalised eesmärgid:

• Haldatav platvorm. Sadade päringute olemasolu igal lehel — see ei ole tõsiseltvõetav.
• Ettearvatavad trendid. Oli perioodilisi liikluse harjume, mis esmapilgul ei korreleerunud teiste mõõdikutega — pidime aru saama, miks nii juhtub ja õppima ennustama.
• Platvormi laiendamine. Äri kasvab pidevalt, kasutajaid tuleb üha rohkem, liiklus suureneb.

Varem öeldi sageli: "Kiri see kõik [keeles/raamistikes] üle, kõik hakkab parem liikuma!"

Enamikul juhtudel see ei toimi, on hea, kui ümber kirjutatud ikka töötab. Seetõttu pidime koostama teekaardi — konkreetse strateegia, mis illustreerib samm-sammult, kuidas saavutatakse ärieesmärke (mida me teeme ja miks), mis:

• peegeldab projekti missiooni ja eesmärke;
• prioriseerib peamised eesmärgid;
• sisaldab ajakava nende saavutamiseks.

Kuni selle hetkeni ei olnud keegi meeskonnaga rääkinud, milleks tehakse mingeid muutusi. Selle jaoks on vajalikud õiged edutegurid. Esmakordselt ettevõtte ajaloos seadsime tehnilistele meeskondadele KPI-d, sidudes need organisatsioonilistega.

See tähendab, et organisatsioonilised KPI-d toetavad meeskonnad ja meeskonna KPI-d toetavad juba individuaalsed. Vastupidisel juhul, kui tehnilised KPI-d ei kattu organisatsioonilistega, siis igaüks tõmbab teki enda peale.

Näiteks üks organisatsiooniline KPI on turuosa suurendamine uute toodete kaudu.

Mis toetab eesmärki omada rohkem uusi tooteid?

• Esiteks, me tahame kulutada rohkem aega uute toodete arendamisele selle asemel, et defekte parandada. See on loogiline lahendus, mida on lihtne mõõta.
• Teiseks, me tahame toetada tehingute arvu suurenemist, sest mida suurem on turuosa, seda rohkem on kasutajaid ja seega ka rohkem liiklust.

Siis võivad individuaalsed KPI-d, mis võivad grupis täituda, olla näiteks need kohad, kust peamised defektid tulevad. Kui keskenduda just sellele osale, saab defekte oluliselt vähendada, andes jälle aega uute toodete arendamiseks ja ka organisatsiooni KPI-de toetamiseks.

Seega peab iga otsus, sealhulgas koodi ümber kirjutamine, toetama konkreetseid eesmärke, mis ettevõte meile seadis (organisatsiooni kasv, uued funktsioonid, töötajate värbamine).

Selle protsessi käigus tuli välja huvitav asi, mis sai uudiseks mitte ainult tehnikutele, vaid ka kogu ettevõttes: kõik piletid peavad olema suunatud vähemalt ühele KPI-le. See tähendab, et kui tootejuht ütleb, et soovib luua uut funktsiooni, peab esimene küsimus olema: „Millist KPI-d see funktsioon toetab?” Kui ei ühtegi, siis vabandust — see näib olevat mittevajalik funktsioon.

Kolmekümnes päev

Kuu lõpus avastasin veel ühe detaili: keegi minu Ops-tiimist ei olnud kunagi näinud lepinguid, mille me klientidega sõlmisime. Võite küsida, miks lepinguid vaadata.

• Esiteks, kuna lepingutes on kirjeldatud SLA-d.
• Teiseks, SLA-d on kõik erinevad. Iga klient tuli oma nõuetega, aga müügiosakond allkirjastas need pilk peal.

Veel üks huvitav detail – ühe meie suurima kliendi lepingus on kirjas, et kõik platvormi toetatavad tarkvaraversioonid peavad olema n-1, st mitte kõige uuem versioon, vaid eelviimane.

On selge, kui kaugel me olime n-1-st, kui platvorm töötas ColdFusioni ja 2008. aasta SQL Serveriga, mida juulis enam ei toetatud.

Kümmend viies päev

Umbes teise kuu keskpaiku oli mul piisavalt aega, et istuda ja teha valuestreammapping kogu protsessi jaoks. Need on vajalikud sammud, mida tuleb teha tootearendusest kuni toote tarbijani toimetamiseni, ja need tuleb maksimaalselt detailselt üles kirjutada.

Jaga protsess väikesteks osadeks ja vaata, mis võtab liiga palju aega, mida saab optimeerida, täiustada jne. Näiteks, kui kaua võtab aega toote päring, selle läbimine grooming'is, kui see jõuab piletini, mille arendaja saab võtta, QA jne. Nii detailselt vaatad iga eraldi sammu ja mõtled, mida saab optimeerida.

Kui ma seda tegin, tõusid silma kaks asja:

• kõrge prosent piletite tagasivõtmiseks QA-st arendajatele;
• pull request'i ülevaated võtavad liiga palju aega.

Probleem oli selles, et need olid järeldused nagu: tundub, et see võtab palju aega, aga me ei ole kindlad, kui täpselt.

„Ei saa parandada seda, mida ei saa mõõta.“

Kuidas põhjendada, kui tõsine probleem on? Kas selle tõttu kulub päevi või tunde?

Selle mõõtmiseks lisasime paar sammu Jira-protsessi: „ready for dev“ ja „ready for QA“, et mõõta, kui kaua iga pilet ootab ja kui mitu korda see teatud sammu tagasi tuleb.

Lisasime ka „in review“, et teada, kui kaua keskmiselt piletid review's on, ja sellest edasi liikuda. Meil olid süsteemilised mõõdikud, nüüd lisasime uusi mõõdikud ja hakkasime mõõtma:

• Protsessi efektiivsus: tootlikkus ja planeeritud/toimetatud.
• Protsessi kvaliteet: defektide arv, defektid QA-st.

See tõesti aitab mõista, mis läheb hästi ja mis halvasti.

Viiskümmend esimene päev

See on muidugi kõik tore ja huvitav, kuid teise kuu lõpu lähenedes juhtus see, mis põhimõtteliselt oli prognoositud, kuigi ma ei oodanud sellist ulatust. Inimesed hakkasid lahkuma, kuna juhtimine muutus. Uued inimesed tulid juhtimine ja hakkasid kõike muutma, ja vanad lahkusid. Tavaline on, et ettevõttes, mis on tegutsenud juba mitu aastat, on kõik sõbrad ja kõik tunnevad üksteist.

See oli ootuspärane, kuid lahkumiste ulatus oli ootamatu. Näiteks esitasid kaks tiimijuhti ühel nädalal korraga lahkumisavalduse. Seetõttu pidin keskenduma mitte lihtsalt teistele probleemidele, vaid kollektiivi loomisele. See on pikk ja keeruline probleem, kuid sellega tuli tegeleda, kuna soov oli säilitada inimesi, kes olid jäänud (või enamiku neist). Pidi kuidagi reageerima sellele, et inimesed lahkusid, et hoida meeskonna moraali.

Teoreetiliselt on see hea: tuleb uus inimene, kellel on täiendav vabadus ja kes võib hinnata meeskonna oskusi ja asendada töötajad. Tegelikkuses ei saa lihtsalt uusi inimesi tuua väga paljusid põhjuseid. Alati on vajalik tasakaal.

• Vanade ja uute vahel. Peab säilitama vanu inimesi, kes saavad muutuda ja toetada missiooni. Kuid samal ajal tuleb tuua uut verd, millest räägime veidi hiljem.
• Kogemus. Olen palju rääkinud heade nooremate töötajatega, kes olid motiveeritud ja soovisid meie juurde tööle. Kuid ma ei saanud neid võtta, sest vanemaid ei olnud piisavalt, et toetada nooremaid ja olla nende mentoriteks. Esiteks pidi olema juhtkond ja alles siis noored.
• Kepi ja kommi.

Mul ei ole head vastust küsimusele, milline tasakaal on õige, kuidas seda hoida, kui inimesi jätta ja kui palju survet avaldada. See on puhtalt individuaalne protsess.

Viiskümmend teine päev

Alandasin ennast meeskonda jälgima, et mõista, kes mul on, ja meenutasin taas:

"Enamik probleeme on seotud inimestega."

Avastasin, et meeskonnas, nii arendajate kui ka Opside seas, on kolm suurt probleemi:

• Rahulolu praeguse olukorraga.
• Vastutuse puudumine — sest keegi pole kunagi seostanud soorituse tulemusi äri mõju.
• Muudatuste kartmine.

Muudatused viivad alati mugavustsoonist välja ning nooremad inimesed kipuvad muutusi rohkem kartma, kuna nad ei mõista, miks neid on vaja ja kuidas need toimivad. Kõige levinum vastus, mida ma kuulnud olen: «Me pole nii kunagi teinud». Tegelikult viib see täieliku absurdi juurde – isegi väiksemad muudatused ei möödunud ilma, et keegi ei protesteeriks. Ja ei olnud oluline, kui palju muudatused nende tööd mõjutasid, inimesed ütlesid: «Ei, miks? See ei toimi».

Aga ei saa paremaks muutuda, mitte midagi muutes.

Mul oli täiesti absurdne vestlus töötajaga, rääkisin talle oma ideedest optimeerimise kohta, mille peale ta ütles:
— Ah, sa ei ole näinud, mis meil eelmisel aastal oli!
— No ja mis siis?
— Praegu on palju parem kui oli.
— Kas siis ei saa veel paremaks?
— Miks?

Hea küsimus — miks? Nagu oleks, kui praegu on parem kui oli, siis on kõik piisavalt hea. See viib vastutuse puudumiseni, mis on põhimõtteliselt täiesti normaalne. Nagu ma ütlesin, tehniline meeskond oli veidi kõrval. Ettevõttes arvati, et nad peavad olema, aga keegi ei ole kunagi kehtestanud standardeid. Tugiteenuses pole kunagi SLA-d nähtud, seega oli grupile täiesti «vastuvõetav» (ja see šokeeris mind kõige rohkem):

• 12 sekundi laadimisaeg;
• 5-10 minutit seisakut iga väljaande ajal;
• kriitiliste probleemide lahendamine võtab päevi ja nädalat;
• 24/7 valve puudumine / reageerimise valmidus.

Keegi pole kunagi üritanud küsida, miks me ei saaks seda paremaks muuta, ja keegi ei ole kunagi mõistnud, et see ei peaks niimoodi olema.

Boonuseks oli veel üks probleem: kogemuse puudumine. Kogenud töötajad lahkusid ja jäänud noor meeskond kasvas eelmistes oludes ja oli selle tõttu saastatud.

Kõike seda kartisid inimesed ka ebaõnnestuda, et tunduda ebakompetentsed. See avaldub selles, et nad, esiteks, ei palu mingil juhul abiKui palju kordi oleme grupis ja individuaalselt rääkinud ning ma olen öelnud: „Küsi küsimus, kui sa ei tea, kuidas midagi teha.” Ma usun endasse ja tean, et suudan lahendada iga probleemi, kuid see võtab aega. Seetõttu, kui on võimalik küsida kellegilt, kes teab, kuidas seda 10 minutiga lahendada, küsin ma. Mida vähem sul on kogemusi, seda rohkem sa kardad küsimusi küsida, kuna arvad, et sind peetakse ebakompetentseks.

See hirm küsimiseks avaldub huvitaval viisil. Näiteks küsid: „Kuidas selle ülesandega on?” — „On jäänud paar tundi, juba lõpetan.” Järgmisel päeval küsid jälle, saad vastuse, et kõik on hästi, kuid tekkinud on üks probleem, et päeva lõpuks on see kindlasti valmis. Möödub veel päev ja seni, kuni sa kedagi nurka ei suru ja ei pane rääkima, jätkub kõik samamoodi. Inimene tahab ülesande ise lahendada, ta arvab, et kui ta ise ei lahenda, on see suur ebaõnnestumine.

Just seetõttu arendajad liialdasid hindamistega. See oli tõeline anekdoot, kui arutasime kindlat ülesannet ja mulle anti selline number, et olin väga üllatunud. Selle peale öeldi, et hindamistes arvestab arendaja ka aega, mille pilet QA-st tagasi tuleb, sest nad leiavad seal vigu, ja aega, mis kulub PR-ile, ja aega, mida kulutavad inimesed, kes peavad seda üle vaatama, kuna nad on hõivatud — ehk kõik, mis võimalik.

Teiseks, inimesed, kes kardavad tunduda ebakompetentsed, analüüsivad liigset. Kui ütled, mida konkreetselt on vaja teha, hakkab tulema: „Ei, aga mis siis, kui me siin mõtleme?” Selles mõttes ei ole meie ettevõte ainulaadne, see on noorte standardne probleem.

Vastuseks alustan järgmiste praktikate rakendamist:

• 30 minuti reegel. Kui poole tunni jooksul ei suuda probleemi lahendada, palu kellelgi abiks olla. See töötab varieeruva eduga, kuna inimesed ei küsi endiselt, kuid vähemalt protsess on alanud.
• Välistage kõik, välja arvatud olemus, ülesande täitmise tähtaegade hindamisel, st arvesta ainult seda, kui palju aega kulub koodi kirjutamiseks.
• Pidev õppimine neile, kes analüüsivad liigset. See on lihtsalt pidev töö inimestega.

Kuuekümnes päev

Kuna ma sellega kõik tegelesin, tuli aeg eelarvega tegelema hakata. Loomulikult leidsin ma palju huvitavat selle kohta, kuhu me raha kulutasime. Näiteks oli meil eraldi andmekeskuses terve riiul, millel seisis üks FTP-server, mida kasutas üks klient. Selgus, et „... me kolisime, aga ta jäi nii, me ei vahetanud seda“. See oli kaks aastat tagasi.

Eriti huvitav oli arve pilveteenuste eest. Olen kindel, et suures arves pilveteenuste osas on peamine põhjus arendajad, kellel on esmakordselt elus piiramatud juurdepääs serveritele. Neil ei ole vaja küsida: „Palun andke mulle testserver“, — nad saavad ise võtta. Lisaks sellele tahavad arendajad alati ehitada nii lahedat süsteemi, et Facebook ja Netflix õgardavad.

Aga arendajatel ei ole kogemust serverite ostmisel ja oskust määrata vajalikke serverite suurusi, kuna nad pole seda varem vajanud. Ja tavaliselt ei mõista nad täiesti vahet, mille vahel on scalability ja performance.

Inventuuri tulemused:

• Läksime ühest andmekeskusest välja.
• Tähtsustasime koostöö lõpetamist kolme logiteenuse pakkujaga. Sest meil oli neid viis — iga arendaja, kes alustas millegagi mängimist, võttis uue.
• Ketasime 7 AWS-süsteemi. Jällegi, surnud projekte ei peatatud, nad kõik jätkasid tööd.
• Vähendasime tarkvara kulusid kuus korda.

Seitsmekümne viies päev

Aeg kulges ja kahe ja poole kuu pärast pidin kohtuma juhatusega. Meie juhatus ei ole paremini ega halvemini kui teised, nad tahavad teada kõike. Inimesed investeerivad raha ja tahavad mõista, kuivõrd see, mida me teeme, sobib seatud KPI-dega.

Juhatus saab iga kuu palju teavet: kasutajate arv, nende kasv, milliseid teenuseid nad kasutavad ja kuidas, tootlikkus ja lõpuks lehe keskmine laadimisaeg.

Probleem on vaid selles, et ma arvan, et keskmine arv on puhas paha. Kuid juhatusele on seda väga raske selgitada. Nad on harjunud töötama aggregeeritud numbritega, mitte näiteks laadimisaega sekundites.

Sellega seoses olid huvitavad hetked. Näiteks ütlesin, et liiklus tuleb jagada eraldi veebiserverite vahel sõltuvalt sisu tüübist.

See, ColdFusion goes through Jetty and nginx and serves the pages. Images, JS, and CSS are handled by a separate nginx with their own configurations. This is quite a standard practice, which I kirjutatud only considered a couple of years ago. As a result, images load much faster, and ... the average loading speed increased by 200 ms.

This happened because the chart is based on data coming from Jetty. So, quick content isn't included in the calculation — the average spike increased. We understood this, laughed about it, but how do we explain to the board why something we did got worse by 12%?

The eighty-fifth day

By the end of the third month, I realized that there was one thing I hadn’t counted on at all — time. Everything I was talking about requires time.

This is my actual calendar for the week — just a working week, not very busy. There isn't enough time for everything. So again, we need to hire people who can help solve the problems.

Kokkuvõte

This is not everything. In this story, I haven't even gotten to how we worked with the product and tried to calibrate to the same wavelength, or how we integrated technical support, or how we solved other technical issues. For example, I accidentally discovered that with the largest tables in the database, we aren't using JÕUD. We have a custom function nextID, and it's not used in a transaction.

There were a million similar things to talk about. But the most important thing still to mention is culture.

It’s culture, or its absence, that leads to all other problems. We are trying to build a culture where people:

• aren't afraid of failures;
• learn from mistakes;
• collaborate with other teams;
• show initiative;
• take responsibility;
• welcome results as a goal;
• celebrate success.

With this, everything else will come.

Leon Fire on twitter, facebook ja medium.

Regarding legacy, there are two strategies: to avoid working with it at all costs, or to bravely overcome the accompanying challenges. We are DevOpsConf taking the second path, changing processes and approaches. Join us in youtube, the newsletter ja telegram, and together we will implement a DevOps culture.

Allikas: habr.com