Teadaolevalt pannakse CTO pädevus proovile alles teisel korral, kui ta seda rolli täidab. Sest üks asi on töötada ettevõttes mitu aastat, areneda koos sellega ja samas kultuurikontekstis olles saada järk-järgult vastutust juurde. Hoopis teine ​​asi on asuda otse ettevõtte tehnikadirektori ametikohale, kellel on pärandpagas ja hunnik probleeme korralikult vaiba alla pühitud.

Selles mõttes Leon Fire kogemus, mida ta edasi jagas DevOpsConf, mitte just ainulaadne, kuid korrutatuna tema kogemuste ja erinevate rollidega, mida tal õnnestus 20 aasta jooksul proovida, on see väga kasulik. Lõike all on kronoloogia sündmustest 90 päeva jooksul ja palju lugusid, mille üle on lõbus naerda, kui need kellegi teisega juhtuvad, kuid millega isiklikult silmitsi seista pole nii lõbus.

Leon räägib väga värvikalt vene keeles, nii et kellel on aega 35-40 minutit, soovitan videot vaadata. Tekstiversioon aja säästmiseks allpool.

Aruande esimene versioon oli hästi struktureeritud inimeste ja protsessidega töötamise kirjeldus, mis sisaldas kasulikke soovitusi. Kuid ta ei edastanud kõiki üllatusi, mis teel ette tulid. Seetõttu muutsin formaati ja esitasin uues ettevõttes nagu jack-in-the-box minu ette karganud probleemid ja nende lahendamise meetodid kronoloogilises järjekorras.

Üks kuu enne

Nagu paljud head lood, sai seegi alguse alkoholist. Istusime sõpradega baaris ja IT-spetsialistide seas ootuspäraselt nutsid kõik oma probleemide pärast. Üks neist oli just töökohta vahetanud ja rääkis oma probleemidest tehnoloogia, inimeste ja meeskonnaga. Mida rohkem ma kuulasin, seda rohkem mõistsin, et ta peaks mind lihtsalt palkama, sest just selliseid probleeme olen viimased 15 aastat lahendanud. Ütlesin talle seda ja järgmisel päeval kohtusime töökeskkonnas. Ettevõte kandis nime Teaching Strategies.

Teaching Strategies on turuliider väga väikeste laste sünnist kuni kolmeaastaseks saamiseni mõeldud õppekavade osas. Traditsiooniline “paber” ettevõte on juba 40 aastat vana ja platvormi digitaalne SaaS versioon 10. Suhteliselt hiljuti algas digitehnoloogia kohandamine ettevõtte standarditele. “Uus” versioon tuli turule 2017. aastal ja oli peaaegu nagu vana, ainult et töötas halvemini.

Kõige huvitavam on see, et selle ettevõtte liiklus on väga prognoositav - päevast päeva, aastast aastasse saate väga selgelt ennustada, kui palju inimesi ja millal tuleb. Näiteks kella 13–15 vahel lähevad kõik lasteaialapsed magama ja õpetajad hakkavad teavet sisestama. Ja seda juhtub iga päev, välja arvatud nädalavahetused, sest peaaegu keegi ei tööta nädalavahetustel.

Pisut tulevikku vaadates märgin, et alustasin oma tööd aasta suurima liiklusega perioodil, mis on erinevatel põhjustel huvitav.

Platvormil, mis tundus olevat vaid 2 aastat vana, oli omapärane pinu: ColdFusion & SQL Server aastast 2008. ColdFusion, kui te ei tea ja tõenäoliselt ei tea, on ettevõtte PHP, mis tuli välja 90ndate keskel ja sellest ajast peale pole ma sellest isegi kuulnud. Samuti olid seal: Ruby, MySQL, PostgreSQL, Java, Go, Python. Kuid peamine monoliit töötas ColdFusionis ja SQL Serveris.

Probleemid

Mida rohkem rääkisin ettevõtte töötajatega tööst ja probleemidest, mis ilmnesid, seda enam mõistsin, et probleemid ei ole ainult tehnilist laadi. Olgu, tehnoloogia on vana - ja nad ei töötanud selle kallal, kuid meeskonna ja protsessidega oli probleeme ning ettevõte hakkas sellest aru saama.

Traditsiooniliselt istusid nende tehnikamehed nurgas ja tegid mingit tööd. Kuid üha rohkem äri hakkas läbima digitaalset versiooni. Seetõttu tekkisid eelmisel aastal enne minu tööle asumist ettevõttesse uued: direktorite nõukogu, CTO, CPO ja QA direktor. See tähendab, et ettevõte hakkas investeerima tehnoloogiasektorisse.

Raske pärandi jäljed ei olnud ainult süsteemides. Ettevõttel olid pärandprotsessid, päritud inimesed, pärandkultuur. Seda kõike tuli muuta. Arvasin, et see kindlasti igav ei ole, ja otsustasin proovida.

Kaks päeva enne

Kaks päeva enne uuele tööle asumist saabusin kontorisse, täitsin viimased paberid, kohtusin meeskonnaga ja avastasin, et meeskond oli sel ajal hädas probleemiga. See oli see, et lehe keskmine laadimisaeg hüppas 4 sekundini, see tähendab 2 korda.

Graafiku järgi otsustades juhtus midagi selgelt ja pole selge, mis. Selgus, et probleemiks oli võrgu latentsus andmekeskuses: 5 ms latentsus andmekeskuses muutus kasutajate jaoks 2 sekundiks. Ma ei teadnud, miks see juhtus, kuid igal juhul sai teatavaks, et probleem oli andmekeskuses.

Esimene päev

Möödus kaks päeva ja esimesel tööpäeval avastasin, et probleem ei olnud kuhugi kadunud.

Kahe päeva jooksul laaditi kasutajate lehed keskmiselt 4 sekundiga. Küsin, kas nad leidsid, milles probleem.

- Jah, avasime pileti.
- JA?
- Noh, nad pole meile veel vastanud.

Siis mõistsin, et kõik, millest mulle varem räägiti, oli vaid väike jäämäe tipp, millega ma pidin võitlema.

Seal on hea tsitaat, mis sobib sellesse väga hästi:

"Mõnikord peate tehnoloogia muutmiseks muutma organisatsiooni."

Kuna aga asusin tööle aasta kõige kiiremal ajal, tuli probleemi lahendamiseks vaadata mõlemat varianti: nii kiiret kui pikaajalist. Ja alusta sellest, mis on praegu kriitiline.

Kolmas päev

Niisiis, laadimine kestab 4 sekundit ja 13-15 suurimat tippu.

Kolmandal päeval selle aja jooksul nägi allalaadimiskiirus välja selline:

Minu vaatevinklist ei töötanud mitte miski. Kõigi teiste vaatevinklist oli see tavapärasest veidi aeglasem. Kuid see lihtsalt ei juhtu nii – see on tõsine probleem.

Üritasin meeskonda veenda, millele nad vastasid, et neil on lihtsalt rohkem servereid vaja. See on loomulikult probleemi lahendus, kuid see pole alati ainus ja kõige tõhusam. Küsisin, miks pole piisavalt servereid, milline on liikluse maht. Ekstrapoleerisin andmed ja leidsin, et meil on umbes 150 päringut sekundis, mis põhimõtteliselt jääb mõistlikesse piiridesse.

Kuid me ei tohi unustada, et enne õige vastuse saamist peate esitama õige küsimuse. Minu järgmine küsimus oli: mitu esiserverit meil on? Vastus "äratas mind veidi" - meil oli 17 esiserverit!

— Mul on piinlik küsida, aga 150 jagatud 17-ga annab umbes 8? Kas sa tahad öelda, et iga server lubab 8 päringut sekundis ja kui homme on 160 päringut sekundis, siis vajame veel 2 serverit?

Täiendavaid servereid me muidugi ei vajanud. Lahendus oli koodis endas ja pinnal:

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

Seal oli funktsioon getCurrentClass(), sest kõik saidil olev töötab klassi kontekstis – see on õige. Ja selle jaoks oli igal lehel üks funktsioon 200+ taotlust.

Selline lahendus oli väga lihtne, isegi ei pidanud midagi ümber kirjutama: lihtsalt ära 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 õnnelik, sest otsustasin, et alles kolmandal päeval leidsin põhiprobleemi. Nii naiivne kui ma olin, oli see vaid üks paljudest probleemidest.

Kuid selle esimese probleemi lahendamine langetas graafiku palju madalamale.

Samal ajal tegime muid optimeerimisi. Silmas oli palju asju, mida saaks parandada. Näiteks samal kolmandal päeval avastasin, et ikkagi on süsteemis vahemälu (algul arvasin, et kõik päringud tulevad otse andmebaasist). Kui ma mõtlen vahemälule, pean ma silmas tavalist Redist või Memcachedi. Aga mina olin ainuke, kes nii arvas, sest see süsteem kasutas vahemällu salvestamiseks MongoDB-d ja SQL Serverit – sedasama, kust andmeid just loeti.

Päev kümnes

Esimesel nädalal tegelesin probleemidega, mis vajasid kohe lahendamist. Kuskil teisel nädalal tulin esimest korda stand-up’i, et meeskonnaga suhelda, vaadata, mis toimub ja kuidas kogu protsess kulgeb.

Jälle avastati midagi huvitavat. Meeskonda kuulusid: 18 arendajat; 8 testijat; 3 juhti; 2 arhitekti. Ja nad kõik osalesid ühistes rituaalides ehk üle 30 inimese tuli igal hommikul stand-upi ja rääkis, mida nad tegid. Selge see, et kohtumine ei võtnud 5 ega 15 minutit. Keegi ei kuulanud kedagi, sest kõik töötavad erinevatel süsteemidel. Sellisel kujul oli 2-3 piletit tunnis hooldusseansile juba hea tulemus.

Esimese asjana jagasime meeskonna mitmeks tootesarjaks. Erinevate sektsioonide ja süsteemide jaoks eraldasime eraldi meeskonnad, kuhu kuulusid arendajad, testijad, tootejuhid ja ärianalüütikud.

Selle tulemusena saime:

• Stand-up’ide ja rallide vähendamine.
• Aineteadmised tootest.
• Omanikutunne. Kui inimesed kogu aeg süsteemide kallal nokitsesid, teadsid nad, et tõenäoliselt peab keegi teine ​​nende vigadega töötama, aga mitte ise.
• Rühmadevaheline koostöö. Ütlematagi selge, et QA varem programmeerijatega eriti ei suhelnud, toode ajas oma asja jne. Nüüd on neil ühine vastutus.

Peamiselt keskendusime efektiivsusele, produktiivsusele ja kvaliteedile – just neid probleeme püüdsime meeskonna ümberkujundamisega lahendada.

Üheteistkümnes päev

Meeskonna struktuuri muutmise käigus avastasin, kuidas loendada LuguPoints. 1 SP oli võrdne ühe päevaga ja iga pilet sisaldas SP nii arenduse kui ka kvaliteedi tagamise eest, see tähendab vähemalt 2 SP.

Kuidas ma selle avastasin?

Leidsime vea: ühes aruandes, kuhu on kantud selle perioodi algus- ja lõppkuupäev, mille kohta aruannet vaja on, viimast päeva arvesse ei võeta. See tähendab, et kuskil taotluses ei olnud <=, vaid lihtsalt <. Mulle öeldi, et see on kolm loopunkti, see tähendab 3 päeva.

Pärast seda me:

• Story Pointsi hindamissüsteem on läbi vaadatud. Nüüd jõuavad väiksemate vigade parandused, mida saab kiiresti süsteemist läbi lasta, kasutajani kiiremini.
• Alustasime arendus- ja testimispiletite liitmist. Varem oli iga pilet, iga viga suletud ökosüsteem, mis ei olnud seotud millegi muuga. Kolme nupu muutmine ühel lehel oleks võinud olla kolm erinevat piletit kolme erineva kvaliteedikontrolli protsessiga ühe automaatse testi asemel lehe kohta.
• Alustasime arendajatega koostööd tööjõukulude hindamise lähenemisviisi kallal. Kolm päeva ühe nupu vahetamiseks pole naljakas.

Kahekümnes päev

Kuskil esimese kuu keskel olukord veidi stabiliseerus, sain aru, mis põhimõtteliselt toimub ning hakkasin juba tulevikku vaatama ja pikaajalistele lahendustele mõtlema.

Pikaajalised eesmärgid:

• Hallatav platvorm. Sajad taotlused igal lehel ei ole tõsised.
• Ennustavad trendid. Esineb perioodilisi liiklustippe, mis esmapilgul ei korreleerunud teiste mõõdikutega – pidime mõistma, miks see juhtus, ja õppima ennustama.
• Platvormi laiendamine. Äri kasvab pidevalt, kasutajaid tuleb juurde ja liiklus kasvab.

Varem öeldi sageli: "Kirjutame kõik [keeles/raamistikus] ümber, kõik läheb paremini!"

Enamasti see ei tööta, on hea, kui ümberkirjutamine üldse toimib. Seetõttu oli meil vaja koostada tegevuskava – konkreetne strateegia, mis näitab samm-sammult, kuidas ärieesmärgid saavutatakse (mida me teeme ja miks), mis:

• kajastab projekti missiooni ja eesmärke;
• seab prioriteediks peamised eesmärgid;
• sisaldab ajakava nende saavutamiseks.

Enne seda polnud keegi meeskonnaga rääkinud muudatuste eesmärgist. See nõuab õigeid edumõõdikuid. Esimest korda ettevõtte ajaloos määrasime tehnilisele rühmale KPI-d ja need näitajad seoti organisatsiooniliste näitajatega.

See tähendab, et organisatsiooni KPI-sid toetavad meeskonnad ja meeskonna KPI-sid üksikud KPI-d. Vastasel juhul, kui tehnoloogilised KPI-d ei kattu organisatsioonilistega, tõmbab igaüks endale teki.

Näiteks on üks organisatsiooni KPI-dest turuosa suurendamine uute toodete kaudu.

Kuidas saate toetada eesmärki saada rohkem uusi tooteid?

• Esiteks tahame vigade parandamise asemel kulutada rohkem aega uute toodete väljatöötamisele. See on loogiline lahendus, mida on lihtne mõõta.
• Teiseks tahame toetada tehingumahu kasvu, sest mida suurem on turuosa, seda rohkem kasutajaid ja vastavalt ka liiklust.

Siis on üksikud KPI-d, mida saab grupi sees teostada, näiteks kohas, kust peamised vead pärinevad. Kui keskendute konkreetselt sellele jaotisele, saate veenduda, et defekte on palju vähem ja siis pikeneb uute toodete väljatöötamise ja jällegi organisatsiooni KPI-de toetamise aeg.

Seega peab iga otsus, sealhulgas koodi ümberkirjutamine, toetama konkreetseid eesmärke, mis ettevõte on meile seadnud (organisatsiooni kasv, uued funktsioonid, värbamine).

Selle protsessi käigus tuli ilmsiks huvitav seik, mis sai uudiseks mitte ainult tehnikutele, vaid ettevõttes üldiselt: kõik piletid peavad olema fokusseeritud vähemalt ühele KPI-le. See tähendab, et kui toode ütleb, et ta soovib teha uut funktsiooni, tuleks esitada esimene küsimus: "Millist KPI-d see funktsioon toetab?" Kui ei, siis vabandust – see tundub ebavajaliku funktsioonina.

Päev kolmkümmend

Kuu lõpus avastasin veel ühe nüansi: keegi minu Opsi meeskonnast pole kunagi näinud lepinguid, mida me klientidega sõlmime. Võite küsida, miks peate kontakte nägema.

• Esiteks seetõttu, et SLA-d on lepingutes ette nähtud.
• Teiseks on SLA-d kõik erinevad. Iga klient tuli oma nõudmistega ja müügiosakond kirjutas alla vaatamata.

Huvitav nüanss on ka see, et ühe suurima kliendiga sõlmitud lepingus on kirjas, et kõik platvormi toetatud tarkvaraversioonid peavad olema n-1 ehk siis mitte uusim, vaid eelviimane.

On selge, kui kaugel me n-1-st olime, kui platvorm põhines ColdFusionil ja SQL Server 2008-l, mida juulis enam üldse ei toetatud.

Päev nelikümmend viis

Umbes teise kuu keskel oli mul piisavalt aega maha istuda ja teha väärtusojakaardistus täielikult kogu protsessi jaoks. Need on vajalikud sammud, mida tuleb teha, alates toote loomisest kuni tarbijani jõudmiseni, ja neid tuleb võimalikult üksikasjalikult kirjeldada.

Jagate protsessi väikesteks tükkideks ja näete, mis võtab liiga palju aega, mida saab optimeerida, täiustada jne. Näiteks kui kaua kulub tootepäringu läbimiseks hooldustööd, millal jõuab see piletini, mida arendaja võib võtta, QA jne. Nii et vaatate iga sammu üksikasjalikult ja mõtlete, mida saab optimeerida.

Kui ma seda tegin, jäid mulle silma kaks asja:

• suur osa piletitest tagastati QA-st arendajatele tagasi;
• tõmbamistaotluse ülevaatamine võttis liiga kaua aega.

Probleem oli selles, et need olid sellised järeldused: Tundub, et see võtab palju aega, kuid me pole kindlad, kui kaua.

"Sa ei saa parandada seda, mida te ei saa mõõta."

Kuidas põhjendada, kui tõsine probleem on? Kas see raiskab päevi või tunde?

Selle mõõtmiseks lisasime Jira protsessi paar sammu: "valmis arendamiseks" ja "valmis kvaliteedikontrolliks", et mõõta, kui kaua iga pilet ootab ja mitu korda teatud sammu juurde naaseb.

Lisasime ka “ülevaatamisel”, et teada saada, kui palju pileteid keskmiselt ülevaatamisele on ja sellest saab juba tantsima hakata. Meil olid süsteemimõõdikud, nüüd lisasime uued mõõdikud ja hakkasime mõõtma:

• Protsessi tõhusus: jõudlus ja kavandatud/tarnitud.
• Protsessi kvaliteet: defektide arv, defektid kvaliteedikontrollist.

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

Viiekümnes päev

See kõik on muidugi hea ja huvitav, kuid teise kuu lõpupoole juhtus midagi, mis oli põhimõtteliselt etteaimatav, kuigi ma ei oodanud sellist ulatust. Inimesed hakkasid lahkuma, sest tippjuhtkond oli vahetunud. Juhtkonda tulid uued inimesed ja hakkasid kõike muutma ning vanad lahkusid. Ja tavaliselt on mitmeaastases seltskonnas kõik sõbrad ja kõik tunnevad üksteist.

See oli ootuspärane, kuid koondamiste ulatus oli ootamatu. Näiteks ühe nädala jooksul esitasid kaks meeskonnajuhti korraga omal soovil lahkumisavalduse. Seetõttu pidin ma mitte ainult unustama muid probleeme, vaid keskenduma neile meeskonna loomine. See on pikk ja raske lahendatav probleem, kuid sellega tuli tegeleda, sest tahtsin päästa allesjäänud inimesi (või enamikku neist). Inimeste lahkumisele tuli kuidagi reageerida, et meeskonnas moraal säiliks.

Teoreetiliselt on see hea: tuleb uus inimene, kellel on täielik carte blanche, kes oskab hinnata meeskonna oskusi ja asendada personali. Tegelikult ei saa te lihtsalt nii paljudel põhjustel uusi inimesi juurde tuua. Tasakaalu on alati vaja.

• Vana ja uus. Peame hoidma vanu inimesi, kes suudavad muutuda ja missiooni toetada. Kuid samal ajal peame tooma uut verd, räägime sellest veidi hiljem.
• Kogemused. Rääkisin palju tublide juunioridega, kes olid innukad ja tahtsid meiega koostööd teha. Kuid ma ei saanud neid vastu võtta, sest polnud piisavalt vanemaid, kes juunioride toetamiseks ja nende juhendajatena tegutseksid. Kõigepealt oli vaja värvata tipp ja alles siis noored.
• Porgand ja pulk.

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

Päev viiskümmend üks

Hakkasin meeskonda tähelepanelikult uurima, et mõista, kes mul on, ja mulle meenus taas:

"Enamik probleeme on inimeste probleemid."

Olen avastanud, et meeskonnal kui sellisel – nii Devil kui ka Opsil – on kolm suurt probleemi:

• Rahulolu hetkeseisuga.
• Vastutuse puudumine - sest keegi pole kunagi toonud esinejate töö tulemusi äri mõjutamiseks.
• Hirm muutuste ees.

Muutused viivad teid alati mugavustsoonist välja ja mida nooremad on inimesed, seda rohkem neile muutus ei meeldi, sest nad ei saa aru, miks ja kuidas. Kõige tavalisem vastus, mida olen kuulnud, on: "Me pole kunagi seda teinud." Pealegi jõudis see täieliku absurdini – vähimadki muudatused ei saanud toimuda ilma, et keegi oleks nördinud. Ja hoolimata sellest, kui palju muutused nende tööd mõjutasid, ütlesid inimesed: “Ei, miks? See ei tööta."

Aga ilma midagi muutmata ei saa paremaks minna.

Mul oli töötajaga täiesti absurdne vestlus, rääkisin talle oma ideed optimeerimiseks, millele ta ütles mulle:
- Oh, te ei näinud, mis meil eelmisel aastal oli!
- Mis siis?
"Nüüd on palju parem kui varem."
- Niisiis, see ei saa paremaks minna?
- Milleks?

Hea küsimus – miks? Tundub, et praegu on parem kui oli, siis on kõik piisavalt hästi. See toob kaasa vastutustunde puudumise, mis on põhimõtteliselt täiesti normaalne. Nagu ma ütlesin, jäi tehniline grupp veidi kõrvale. Ettevõte uskus, et need peaksid olemas olema, kuid keegi ei sea kunagi standardeid. Tehniline tugi ei näinud kunagi SLA-d, nii et see oli rühma jaoks üsna vastuvõetav (ja see rabas mind kõige rohkem):

• 12 sekundit laadimist;
• 5-10 minutit seisakut iga vabastamise kohta;
• Kriitiliste probleemide tõrkeotsing võtab päevi ja nädalaid;
• valvepersonali puudumine 24x7 / valve.

Keegi pole kunagi proovinud küsida, miks me seda paremini ei tee, ja keegi pole kunagi aru saanud, et see ei pea nii olema.

Boonusena oli veel üks probleem: kogemuste puudumine. Vanemad lahkusid ja allesjäänud noor meeskond kasvas eelmise režiimi ajal üles ja sai sellest mürgituse.

Lisaks sellele kartsid inimesed läbikukkumist ja näisid ebakompetentsed. See väljendub selles, et esiteks nemad ei palunud mingil juhul abi. Kui palju kordi oleme rääkinud rühmana ja individuaalselt ning olen öelnud: "Esitage küsimus, kui te ei tea, kuidas midagi teha." Olen endas kindel ja tean, et suudan iga probleemi lahendada, kuid see võtab aega. Seega, kui ma saan küsida kelleltki, kes teab, kuidas seda 10 minutiga lahendada, siis ma küsin. Mida vähem kogemusi teil on, seda rohkem kardate küsida, sest arvate, et teid peetakse ebapädevaks.

See hirm küsimuste esitamise ees avaldub huvitaval viisil. Näiteks küsite: "Kuidas teil selle ülesandega läheb?" - "Paar tundi on jäänud, ma juba lõpetan." Järgmisel päeval küsid uuesti, saad vastuseks, et kõik on korras, aga üks probleem oli, päeva lõpuks saab kindlasti valmis. Möödub veel üks päev ja seni, kuni olete seina külge kinnitatud ja sunnitud kellegagi rääkima, see jätkub. Inimene tahab probleemi ise lahendada; ta usub, et kui ta seda ise ei lahenda, on see suur läbikukkumine.

Sellepärast arendajad paisutasid hinnanguid. See oli seesama anekdoot, kui nad mingi ülesande üle arutasid, andsid nad mulle sellise kuju, et ma olin väga üllatunud. Mille peale mulle öeldi, et arendaja hinnangul on arendaja sees aeg, millal pilet QA-st tagastatakse, sest nad leiavad sealt vead, ja aeg, mis kulub PR-le ja aeg, mille jooksul inimesed peaksid üle vaatama. see on hõivatud – see tähendab kõike, mis iganes võimalik.

Teiseks inimesed, kes kardavad ebakompetentsena näida üle analüüsida. Kui ütlete, mida täpselt tuleb teha, algab see: "Ei, mis siis, kui me selle siin mõtleme?" Selles mõttes pole meie ettevõte ainulaadne, see on noorte jaoks tavaline probleem.

Vastuseks tutvustasin järgmisi tavasid:

• Reegel 30 minutit. Kui te ei suuda probleemi poole tunniga lahendada, paluge kellelgi abi. See toimib vahelduva eduga, sest inimesed ikka ei küsi, aga vähemalt on protsess alanud.
• Likvideerige kõik peale olemuse, ülesande täitmise tähtaja hindamisel, st arvesta ainult sellega, kui kaua kulub koodi kirjutamiseks.
• Elukestev õpe neile, kes üle analüüsivad. See on lihtsalt pidev töö inimestega.

Kuuekümnes päev

Sel ajal, kui ma seda kõike tegin, oli aeg eelarve välja mõelda. Muidugi leidsin palju huvitavat, kuhu me oma raha kulutasime. Näiteks oli meil eraldi andmekeskuses terve riiul ühe FTP-serveriga, mida kasutas üks klient. Selgus, et "... me kolisime, aga ta jäi selliseks, me ei muutnud teda." See oli 2 aastat tagasi.

Eriti huvipakkuv oli pilveteenuste arve. Usun, et suure pilvearve peamiseks põhjuseks on arendajad, kellel on esimest korda elus piiramatu juurdepääs serveritele. Nad ei pea küsima: "Palun andke mulle testserver", nad saavad selle ise võtta. Lisaks tahavad arendajad alati ehitada nii lahedat süsteemi, et Facebook ja Netflix oleksid armukadedad.

Kuid arendajatel pole serverite ostmise kogemust ja serverite vajaliku suuruse määramise oskust, kuna neil polnud seda varem vaja. Ja tavaliselt ei saa nad hästi aru, mis vahe on skaleeritavuse ja jõudluse vahel.

Inventuuri tulemused:

• Lahkusime samast andmekeskusest.
• Lõpetasime lepingu 3 palgiteenusega. Sest meil oli neid 5 – iga arendaja, kes millegagi mängima hakkas, võttis uue.
• 7 AWS-süsteemi suleti. Jällegi ei peatanud keegi surnud projekte, nad kõik jätkasid tööd.
• Vähendatud tarkvarakulud 6 korda.

Seitsmekümne viies päev

Aeg läks ning kahe ja poole kuu pärast pidin kohtuma juhatusega. Meie juhatus pole teistest parem ega halvem; nagu kõik juhatused, tahab ka see kõike teada. Inimesed investeerivad raha ja tahavad aru saada, kui palju see, mida me teeme, seatud KPI-desse mahub.

Direktorite nõukogu saab iga kuu palju teavet: kasutajate arv, nende kasv, milliseid teenuseid ja kuidas nad kasutavad, jõudlus ja tootlikkus ning lõpuks lehe keskmine laadimiskiirus.

Ainus probleem on selles, et ma usun, et keskmine on puhas kurjus. Kuid seda on väga raske juhatusele selgitada. Nad on harjunud opereerima koondnumbritega, mitte näiteks laadimisaegade levikuga sekundis.

Sellega seoses oli mõned huvitavad punktid. Näiteks ütlesin, et peame jaotama liikluse eraldi veebiserverite vahel olenevalt sisu tüübist.

See tähendab, et ColdFusion läbib Jetty ja nginxi ning käivitab lehed. Ja pildid, JS ja CSS läbivad eraldi nginxi, millel on oma konfiguratsioonid. See on üsna tavaline praktika, millest ma räägin kirjutasin paar aastat tagasi. Tänu sellele laadivad pildid palju kiiremini ja... keskmine laadimiskiirus on kasvanud 200 ms võrra.

See juhtus seetõttu, et graafik on koostatud Jettyga kaasas olevate andmete põhjal. See tähendab, et kiire sisu pole arvutusse kaasatud - keskmine väärtus on hüppeliselt kasvanud. See oli meile selge, naersime, aga kuidas me saame selgitada juhatusele, miks me midagi tegime ja asjad läksid 12% hullemaks?

Kaheksakümne viies päev

Kolmanda kuu lõpus mõistsin, et on üks asi, millega ma polnud üldse arvestanud: aeg. Kõik, millest ma rääkisin, võtab aega.

See on minu tõeline nädalakalender – lihtsalt töönädal, mitte eriti tihe. Aega kõigeks ei jätku. Seetõttu tuleb jällegi värvata inimesi, kes aitavad probleemidega toime tulla.

Järeldus

See pole veel kõik. Selles loos pole ma isegi jõudnud selleni, kuidas me tootega töötasime ja üldisele lainele häälestuda püüdsime või kuidas integreerisime tehnilist tuge või kuidas lahendasime muid tehnilisi probleeme. Näiteks sain täiesti juhuslikult teada, et andmebaasi suurimatel tabelitel me ei kasuta SEQUENCE. Meil on ise kirjutatud funktsioon nextID, ja seda tehingus ei kasutata.

Sarnaseid asju oli veel miljon, millest võiks pikalt rääkida. Kuid kõige olulisem, mida veel öelda tuleb, on kultuur.

Kultuur või selle puudumine toob kaasa kõik muud probleemid. Püüame üles ehitada kultuuri, kus inimesed:

• ei karda ebaõnnestumisi;
• õppida vigadest;
• teha koostööd teiste meeskondadega;
• võtta initsiatiivi;
• vastutama;
• tervitada tulemust eesmärgina;
• edu tähistamine.

Sellega tuleb ka kõik muu.

Leon Fire twitteris, facebook ja keskmine.

Pärandiga seoses on kaks strateegiat: vältige sellega töötamist iga hinna eest või ületage julgelt sellega seotud raskused. Meie c DevOpsConf Me läheme teisele teele, muudame protsesse ja lähenemisi. Liituge meiega youtube, uudiskiri и telegrammja rakendame koos DevOpsi kultuuri.

Allikas: www.habr.com