Znano je, da se usposobljenost tehničnega direktorja preveri šele, ko drugič opravlja to vlogo. Kajti eno je nekaj let delati v podjetju, se z njim razvijati in v istem kulturnem kontekstu postopoma prejeti več odgovornosti. In čisto nekaj drugega je priti naravnost na položaj tehničnega direktorja v podjetju s staro prtljago in kupom težav, lepo pometenih pod preprogo.

V tem smislu je izkušnja Leona Fire, ki jo je delil na DevOpsConf, ne ravno unikaten, a pomnožen z njegovimi izkušnjami in številom različnih vlog, ki jih je uspel preizkusiti v 20 letih, je zelo uporaben. Pod izrezom je kronologija dogodkov v 90 dneh in veliko zgodb, ki se jim je zabavno nasmejati, ko se zgodijo nekomu drugemu, a s katerimi se ni tako zabavno soočiti v živo.

Leon govori zelo barvito v ruščini, tako da, če imate 35-40 minut, priporočam ogled videa. Spodaj besedilna različica za prihranek časa.

Prva različica poročila je bila dobro strukturiran opis dela z ljudmi in procesi, ki vsebuje uporabna priporočila. Ni pa posredovala vseh presenečenj, ki so se zgodila na poti. Zato sem spremenil format in kronološko predstavil probleme, ki so se v novem podjetju pojavljali pred mano, in načine za njihovo reševanje.

En mesec prej

Kot mnoge dobre zgodbe se je tudi ta začela z alkoholom. S prijatelji smo sedeli v lokalu in kot se med IT strokovnjaki pričakuje, so vsi jokali o svojih težavah. Eden od njih je ravno zamenjal službo in je govoril o svojih težavah s tehnologijo, z ljudmi in z ekipo. Bolj ko sem poslušal, bolj sem ugotavljal, da bi me moral kar zaposliti, saj so to vrste problemov, ki jih rešujem zadnjih 15 let. To sem mu povedal in naslednji dan sva se srečala v delovnem okolju. Podjetje se je imenovalo Teaching Strategies.

Teaching Strategies je vodilni na trgu učnih načrtov za zelo majhne otroke od rojstva do treh let. Tradicionalno »papirnato« podjetje je staro že 40 let, digitalna SaaS različica platforme pa 10. Relativno nedavno se je začel proces prilagajanja digitalne tehnologije standardom podjetja. "Nova" različica je bila predstavljena leta 2017 in je bila skoraj podobna stari, le da je delovala slabše.

Najbolj zanimivo je, da je promet tega podjetja zelo predvidljiv - iz dneva v dan, iz leta v leto lahko zelo jasno napoveš, koliko ljudi bo prišlo in kdaj. Na primer, med 13. in 15. uro vsi otroci v vrtcih gredo spat in vzgojiteljice začnejo vnašati podatke. In to se dogaja vsak dan, razen vikendov, saj ob vikendih skoraj nihče ne dela.

Če pogledam malo naprej, bom omenil, da sem svoje delo začel v obdobju največjega letnega prometa, kar je zanimivo iz različnih razlogov.

Platforma, za katero se je zdelo, da je stara samo 2 leti, je imela nenavaden sklad: ColdFusion & SQL Server iz leta 2008. ColdFusion, če ne veste in najverjetneje ne veste, je PHP za podjetja, ki je izšel sredi 90-ih in od takrat sploh nisem slišal zanj. Tu so bili tudi: Ruby, MySQL, PostgreSQL, Java, Go, Python. Toda glavni monolit je deloval na ColdFusion in SQL Server.

Težave

Bolj ko sem se z zaposlenimi v podjetju pogovarjal o delu in težavah, ki so se pojavljale, bolj sem ugotavljal, da težave niso le tehnične narave. V redu, tehnologija je stara - in na njej niso delali, vendar so bile težave z ekipo in s procesi in podjetje je to začelo razumeti.

Tradicionalno so njihovi tehniki sedeli v kotu in opravljali nekakšno delo. Vendar je vse več poslov začelo potekati prek digitalne različice. Zato so se v zadnjem letu pred mojim nastopom v podjetju pojavili novi: upravni odbor, CTO, CPO in QA direktor. To pomeni, da je podjetje začelo vlagati v tehnološki sektor.

Sledi težke zapuščine niso bile le v sistemih. Podjetje je imelo podedovane procese, podedovane ljudi, podedovano kulturo. Vse to je bilo treba spremeniti. Mislil sem, da zagotovo ne bo dolgočasno, in sem se odločil, da poskusim.

Dva dni prej

Dva dni pred začetkom nove službe sem prišel v pisarno, izpolnil še zadnje papirje, spoznal ekipo in ugotovil, da se ekipa takrat spopada s težavo. Bilo je, da je povprečni čas nalaganja strani poskočil na 4 sekunde, torej 2-krat.

Po grafu sodeč se je očitno nekaj zgodilo, kaj pa ni jasno. Izkazalo se je, da je težava v zakasnitvi omrežja v podatkovnem centru: 5 ms zakasnitve v podatkovnem centru se je za uporabnike spremenilo v 2 s. Nisem vedel, zakaj se je to zgodilo, v vsakem primeru pa se je izkazalo, da je težava v podatkovnem centru.

Prvi dan

Minila sta dva dneva in prvi dan v službi sem ugotovil, da težava ni izginila.

V dveh dneh so se strani uporabnikov v povprečju naložile v 4 sekundah. Vprašam, če so ugotovili, v čem je problem.

- Da, vstopnico smo odprli.
- IN?
- No, še niso nam odgovorili.

Potem sem spoznal, da je vse, o čemer so mi prej govorili, le majhen vrh ledene gore, s katerim se moram boriti.

Obstaja dober citat, ki temu zelo ustreza:

"Včasih morate za spremembo tehnologije spremeniti organizacijo."

Ker pa sem začel delati v najbolj obremenjenem času v letu, sem moral preučiti obe možnosti rešitve problema: tako hitro kot dolgoročno. In začnite s tem, kar je trenutno kritično.

Tretji dan

Torej, nalaganje traja 4 sekunde in od 13 do 15 največjih vrhov.

Tretji dan v tem časovnem obdobju je hitrost prenosa izgledala takole:

Z mojega vidika sploh nič ni delovalo. Z vidika vseh drugih je teklo malo počasneje kot običajno. Ampak to se ne zgodi tako - to je resen problem.

Poskušal sem prepričati ekipo, na kar so mi odgovorili, da preprosto potrebujejo več strežnikov. To je seveda rešitev problema, ni pa vedno edina in najučinkovitejša. Vprašal sem, zakaj ni dovolj strežnikov, kakšen je bil promet. Ekstrapoliral sem podatke in ugotovil, da imamo približno 150 zahtevkov na sekundo, kar je načeloma v razumnih mejah.

Ne smemo pa pozabiti, da morate, preden dobite pravi odgovor, postaviti pravo vprašanje. Moje naslednje vprašanje je bilo: koliko sprednjih strežnikov imamo? Odgovor me je "malo zmedel" - imeli smo 17 čelnih strežnikov!

— Sram me je vprašati, ampak 150 deljeno s 17 daje približno 8? Hočete reči, da vsak strežnik omogoča 8 zahtev na sekundo in če bo jutri 160 zahtev na sekundo, bomo potrebovali še 2 strežnika?

Dodatnih strežnikov seveda nismo potrebovali. Rešitev je bila v sami kodi in na površini:

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

Tam je bila funkcija getCurrentClass(), ker vse na spletnem mestu deluje v kontekstu razreda – tako je. In za to funkcijo je bila na vsaki strani ena 200+ zahtev.

Rešitev na ta način je bila zelo preprosta, sploh vam ni bilo treba ničesar prepisati: samo ne zahtevajte več istih podatkov.

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

Bil sem zelo vesel, ker sem se odločil, da sem šele tretji dan našel glavni problem. Naivna, kot sem bila, je bila to le ena od mnogih težav.

Toda rešitev tega prvega problema je spustila graf precej nižje.

Hkrati smo delali še druge optimizacije. Na vidiku je bilo marsikaj, kar bi se dalo popraviti. Na primer, isti tretji dan sem odkril, da je v sistemu vendarle predpomnilnik (sprva sem mislil, da vse zahteve prihajajo neposredno iz baze). Ko pomislim na predpomnilnik, pomislim na standardni Redis ali Memcached. Vendar sem bil edini, ki je tako mislil, ker je ta sistem za predpomnjenje uporabljal MongoDB in SQL Server - istega, s katerega so bili podatki pravkar prebrani.

Dan deseti

Prvi teden sem se ukvarjal s problemi, ki jih je bilo treba rešiti takoj. Nekje v drugem tednu sem prvič prišel na stand-up, da sem komuniciral z ekipo, videl, kaj se dogaja in kako poteka celoten proces.

Spet se je odkrilo nekaj zanimivega. Ekipo sestavljajo: 18 razvijalcev; 8 testerjev; 3 menedžerji; 2 arhitekta. In vsi so sodelovali v skupnih ritualih, to je, da je vsako jutro na stand-up prišlo več kot 30 ljudi in povedalo, kaj počnejo. Jasno je, da srečanje ni trajalo 5 ali 15 minut. Nihče nikogar ni poslušal, ker vsi delajo na različnih sistemih. V tej obliki so bile že 2-3 karte na uro za nego dober rezultat.

Najprej smo ekipo razdelili na več proizvodnih linij. Za različne odseke in sisteme smo dodelili ločene ekipe, ki so vključevale razvijalce, preizkuševalce, produktne vodje in poslovne analitike.

Kot rezultat smo dobili:

Zmanjšanje vstajenj in zborovanj.
Predmetno poznavanje izdelka.
Občutek lastništva. Ko so se ljudje ves čas ukvarjali s sistemi, so vedeli, da bo moral nekdo drug najverjetneje delati z njihovimi hrošči, ne pa oni sami.
Sodelovanje med skupinami. Ni treba posebej poudarjati, da QA prej ni veliko komuniciral s programerji, izdelek je naredil svoje, itd. Zdaj imata skupno točko odgovornosti.

Predvsem smo se osredotočili na učinkovitost, produktivnost in kakovost – to so težave, ki smo jih poskušali rešiti s transformacijo ekipe.

Enajsti dan

V procesu spreminjanja strukture ekipe sem odkril, kako šteti ZgodbaTočke. 1 SP je bil enak enemu dnevu in vsaka vstopnica je vsebovala SP za razvoj in QA, torej vsaj 2 SP.

Kako sem to odkril?

Odkrili smo napako: v enem od poročil, kjer sta vpisana začetni in končni datum obdobja, za katerega je potrebno poročilo, ni upoštevan zadnji dan. To pomeni, da nekje v zahtevi ni bilo <=, ampak preprosto <. Povedali so mi, da gre za tri Story Points, tj 3 dni.

Po tem smo:

Sistem ocenjevanja Story Points je bil spremenjen. Zdaj popravki manjših napak, ki jih je mogoče hitro prenesti skozi sistem, hitreje dosežejo uporabnika.
Začeli smo združevati povezane vstopnice za razvoj in testiranje. Prej je bila vsaka vstopnica, vsak hrošč zaprt ekosistem, ki ni bil vezan na nič drugega. Spreminjanje treh gumbov na eni strani bi lahko pomenilo tri različne vstopnice s tremi različnimi postopki zagotavljanja kakovosti namesto enega samodejnega preizkusa na stran.
Z razvijalci smo začeli delati na pristopu k ocenjevanju stroškov dela. Tri dni za zamenjavo enega gumba ni smešno.

Dvajseti dan

Nekje sredi prvega meseca se je situacija malo stabilizirala, ugotovil sem, kaj se v bistvu dogaja, in že začel gledati v prihodnost in razmišljati o dolgoročnih rešitvah.

Dolgoročni cilji:

Upravljana platforma. Na stotine zahtevkov na vsaki strani ni resnih.
Predvidljivi trendi. Občasno so bile prometne konice, ki na prvi pogled niso bile v korelaciji z drugimi meritvami – morali smo razumeti, zakaj se je to zgodilo, in se naučiti napovedovati.
Širitev platforme. Posel nenehno raste, prihaja vse več uporabnikov, promet se povečuje.

V preteklosti je bilo pogosto rečeno: "Naredimo vse na novo v [jezik/ogrodje], vse bo delovalo bolje!"

V večini primerov to ne deluje, dobro je, če prepis sploh deluje. Zato smo morali izdelati načrt – specifično strategijo, ki korak za korakom prikazuje, kako bomo dosegli poslovne cilje (kaj bomo počeli in zakaj), ki:

odraža poslanstvo in cilje projekta;
daje prednost glavnim ciljem;
vsebuje urnik za njihovo doseganje.

Pred tem se nihče ni pogovarjal z ekipo o namenu kakršnih koli sprememb. To zahteva prave meritve uspeha. Prvič v zgodovini podjetja smo določili KPI za tehnično skupino in te kazalnike vezali na organizacijske.

To pomeni, da organizacijske KPI podpirajo ekipe, timske KPI pa podpirajo posamezni KPI. V nasprotnem primeru, če tehnološki KPI ne sovpadajo z organizacijskimi, potem vsak vleče odejo nase.

Na primer, eden od KPI-jev organizacije je povečanje tržnega deleža z novimi izdelki.

Kako lahko podprete cilj, da imate več novih izdelkov?

Prvič, več časa želimo porabiti za razvoj novih izdelkov, namesto za odpravljanje napak. To je logična rešitev, ki jo je enostavno izmeriti.
Drugič, želimo podpreti povečanje obsega transakcij, saj večji kot je tržni delež, več je uporabnikov in s tem več prometa.

Potem bodo posamezni KPI-ji, ki jih je mogoče izvajati znotraj skupine, na primer na mestu, od koder prihajajo glavne napake. Če se osredotočite posebej na ta razdelek, lahko zagotovite veliko manj napak, nato pa se bo čas za razvoj novih izdelkov in ponovno za podporo organizacijskih KPI povečal.

Tako mora vsaka odločitev, vključno s prepisovanjem kode, podpirati specifične cilje, ki si jih je podjetje zadalo (organizacijska rast, nove funkcije, zaposlovanje).

Med tem procesom je prišla na dan zanimiva stvar, ki je postala novica ne le za tehničarje, ampak na splošno v podjetju: vse vstopnice morajo biti osredotočene na vsaj en KPI. To pomeni, da če izdelek pravi, da želi narediti novo funkcijo, je treba postaviti prvo vprašanje: "Kateri KPI podpira ta funkcija?" Če ne, potem oprostite - zdi se, da je nepotrebna funkcija.

Trideseti dan

Konec meseca sem odkril še eno nianso: nihče v moji Ops ekipi ni nikoli videl pogodb, ki jih sklepamo s strankami. Morda boste vprašali, zakaj morate videti stike.

Prvič, ker so pogodbe o ravni storitev določene v pogodbah.
Drugič, pogodbe o ravni storitev so različne. Vsaka stranka je prišla s svojimi zahtevami, prodajalci pa so podpisali brez pogleda.

Še en zanimiv odtenek je, da pogodba z enim največjih strank določa, da morajo biti vse različice programske opreme, ki jih podpira platforma, n-1, torej ne najnovejša različica, ampak predzadnja.

Jasno je, kako daleč smo bili od n-1, če je platforma temeljila na ColdFusion in SQL Server 2008, ki julija sploh ni bil več podprt.

Petinštirideseti dan

Okoli sredine drugega meseca sem imel dovolj časa, da sem se usedel in naredil vrednosttokkartiranje popolnoma za celoten proces. To so nujni koraki, ki jih je treba narediti, od ustvarjanja izdelka do njegove dostave potrošniku, in jih je treba čim bolj podrobno opisati.

Proces razdelite na majhne koščke in vidite, kaj vzame preveč časa, kaj je mogoče optimizirati, izboljšati itd. Na primer, koliko časa traja, da gre zahteva za izdelek skozi obdelavo, kdaj doseže vstopnico, ki jo lahko sprejme razvijalec, QA itd. Tako si podrobno ogledate vsak posamezni korak in razmislite, kaj je mogoče optimizirati.

Ko sem to naredil, sta mi padli v oči dve stvari:

visok odstotek vstopnic, vrnjenih iz QA nazaj razvijalcem;
pregledi zahtevkov za vlečenje so trajali predolgo.

Težava je bila v tem, da so bili to sklepi, kot so: Zdi se, da traja veliko časa, vendar nismo prepričani, koliko časa.

"Ne morete izboljšati tistega, česar ne morete izmeriti."

Kako utemeljiti, kako resen je problem? Ali zapravlja dneve ali ure?

Da bi to izmerili, smo procesu Jira dodali nekaj korakov: »pripravljeno za razvijalce« in »pripravljeno za zagotavljanje kakovosti«, da izmerimo, kako dolgo vsaka vstopnica čaka in kolikokrat se vrne na določen korak.

Dodali smo tudi »v pregledu«, da vemo, koliko vstopnic je v povprečju za pregled, in od tega lahko začnete plesati. Imeli smo sistemske meritve, zdaj smo dodali nove meritve in začeli meriti:

Učinkovitost procesa: uspešnost in načrtovano/dostavljeno.
Kakovost postopka: število napak, napake iz QA.

Resnično pomaga razumeti, kaj gre dobro in kaj ne.

Dan petdeseti

Vse to je seveda dobro in zanimivo, a proti koncu drugega meseca se je zgodilo nekaj, kar je bilo načeloma predvidljivo, čeprav nisem pričakoval takšnega obsega. Ljudje so začeli odhajati, ker se je zamenjalo vodstvo. V vodstvo so prišli novi ljudje in začeli vse spreminjati, stari pa so odstopili. In ponavadi so v podjetju, ki je staro nekaj let, vsi prijatelji in vsi se poznajo.

To je bilo pričakovano, vendar je bil obseg odpuščanj nepričakovan. Na primer, v enem tednu sta dva vodja ekip hkrati podala odstop po lastni volji. Zato sem moral ne samo pozabiti na druge težave, ampak se osredotočiti na ustvarjanje ekipe. To je dolga in težka težava za reševanje, vendar se je bilo treba z njo spopasti, ker sem želel rešiti ljudi, ki so ostali (ali večino njih). Treba se je bilo nekako odzvati na dejstvo, da so ljudje odšli, da bi ohranili moralo v ekipi.

V teoriji je to dobro: pride nova oseba, ki ima popoln carte blanche, ki lahko oceni sposobnosti ekipe in nadomesti kadre. Pravzaprav ne moreš kar privabiti novih ljudi iz toliko razlogov. Ravnovesje je vedno potrebno.

Staro in novo. Ohraniti moramo stare ljudi, ki se lahko spremenijo in podpirajo poslanstvo. Toda hkrati moramo prinesti novo kri, o tem bomo govorili malo kasneje.
Izkušnje. Veliko sem se pogovarjal z dobrimi mladinci, ki so bili željni in so želeli delati z nami. Vendar jih nisem mogel sprejeti, ker ni bilo dovolj starejših, ki bi podpirali mladince in jim bili mentorji. Najprej je bilo treba novačiti vrh in šele nato mladino.
Korenček in palica.

Nimam dobrega odgovora na vprašanje, kaj je pravo ravnovesje, kako ga vzdrževati, koliko ljudi obdržati in koliko pritiskati. To je čisto individualen proces.

Enainpetdeseti dan

Začel sem natančno gledati ekipo, da bi razumel, koga imam, in še enkrat sem se spomnil:

"Večina težav je težav z ljudmi."

Ugotovil sem, da ima ekipa kot taka – tako Dev kot Ops – tri velike težave:

Zadovoljstvo s trenutnim stanjem.
Pomanjkanje odgovornosti - ker nihče nikoli ni prinesel rezultatov dela izvajalcev, da bi vplivali na poslovanje.
Strah pred spremembo.

Spremembe te vedno popeljejo iz cone udobja in mlajši kot so ljudje, bolj ne marajo sprememb, ker ne razumejo, zakaj in ne razumejo, kako. Najpogostejši odgovor, ki sem ga slišal, je: "Tega še nikoli nismo počeli." Še več, prišlo je do popolnega absurda - najmanjše spremembe niso mogle priti, ne da bi bil kdo ogorčen. In ne glede na to, kako zelo so spremembe vplivale na njihovo delo, so ljudje rekli: »Ne, zakaj? To ne bo delovalo."

Ampak ne moreš postati boljši, ne da bi karkoli spremenil.

Imel sem popolnoma absurden pogovor z zaposlenim, povedal sem mu svoje ideje za optimizacijo, na kar mi je rekel:
- Oh, niste videli, kaj smo imeli lani!
- Pa kaj?
"Zdaj je veliko bolje, kot je bilo."
- Torej ne more biti bolje?
- Kaj za?

Dobro vprašanje - zakaj? Kot da je zdaj bolje, kot je bilo, potem je vse dovolj dobro. To vodi v pomanjkanje odgovornosti, kar je načeloma povsem normalno. Kot sem rekel, je bila tehnična skupina malo na stranskem tiru. V podjetju menili, da bi morale obstajati, vendar nihče nikoli ni postavljal standardov. Tehnična podpora nikoli ni videla SLA, zato je bil za skupino precej "sprejemljiv" (in to me je najbolj prizadelo):

12 sekund nalaganja;
5-10 minut izpada vsake izdaje;
Odpravljanje kritičnih težav traja dneve in tedne;
pomanjkanje dežurnega osebja 24x7 / na klic.

Nihče se ni nikoli vprašal, zakaj tega ne naredimo bolje, in nihče ni ugotovil, da ni nujno, da je tako.

Kot bonus je bila še ena težava: pomanjkanje izkušenj. Starejši so odšli, preostala mlada ekipa pa je zrasla v prejšnjem režimu in bila z njim zastrupljena.

Poleg vsega tega so se ljudje tudi bali neuspeha in videti nesposobni. To se izraža v tem, da so, prvič, oni v nobenem primeru ni prosil za pomoč. Kolikokrat smo se pogovarjali kot skupina in posamično, pa sem rekel: "Postavite vprašanje, če ne veste, kako narediti nekaj." Prepričan sem vase in vem, da lahko rešim vsako težavo, vendar bo potreben čas. Zato, če lahko vprašam koga, ki zna rešiti v 10 minutah, bom vprašal. Manj ko imate izkušenj, bolj se bojite vprašati, ker mislite, da vas bodo imeli za nesposobnega.

Ta strah pred postavljanjem vprašanj se kaže na zanimive načine. Na primer, vprašate: "Kako vam gre s to nalogo?" - "Še nekaj ur, že končujem." Naslednji dan spet vprašaš, dobiš odgovor, da je vse v redu, vendar je bila ena težava, do konca dneva bo zagotovo pripravljeno. Še en dan mine in dokler nisi pribit ob steno in prisiljen govoriti z nekom, se to nadaljuje. Človek želi sam rešiti problem, verjame, da če ga sam ne reši, bo to velik neuspeh.

Zato razvijalci so napihnili ocene. Bila je tista ista anekdota, ko so se pogovarjali o neki nalogi, so mi dali tako številko, da sem bil zelo presenečen. Na kar so mi povedali, da razvijalec v ocene razvijalca vključi čas, ko bo vstopnica vrnjena iz QA, ker bodo tam našli napake, in čas, ki ga bo potreboval PR, in čas, ko bodo ljudje, ki bi morali pregledati zasedeno bo - torej vse, kar je mogoče.

Drugič, ljudje, ki se bojijo, da bodo videti nesposobni pretirano analizirati. Ko rečeš, kaj točno je treba narediti, se začne: "Ne, kaj pa če o tem razmišljamo tukaj?" V tem smislu naše podjetje ni edinstveno, to je standardna težava mladih.

Kot odgovor sem uvedel naslednje prakse:

Pravilo 30 minut. Če težave ne morete rešiti v pol ure, prosite nekoga za pomoč. To deluje z različnimi stopnjami uspeha, ker ljudje še vedno ne sprašujejo, a se je vsaj začel proces.
Odstranite vse razen bistva, pri oceni roka za dokončanje naloge, torej upoštevajte le, koliko časa bo trajalo pisanje kode.
Nenehno učenje za tiste, ki pretirano analizirajo. Gre le za nenehno delo z ljudmi.

Šestdeseti dan

Medtem ko sem vse to počel, je bil čas, da ugotovim proračun. Seveda sem našel veliko zanimivih stvari, kje smo porabili denar. Imeli smo na primer celotno omaro v ločenem podatkovnem centru z enim FTP strežnikom, ki ga je uporabljal en odjemalec. Izkazalo se je, da "... smo se preselili, on pa je ostal tak, nismo ga spremenili." Bilo je 2 leti nazaj.

Posebej zanimiv je bil račun za storitve v oblaku. Menim, da so glavni razlog za visok račun v oblaku razvijalci, ki imajo prvič v življenju neomejen dostop do strežnikov. Ni jim treba vprašati: "Prosim, dajte mi testni strežnik," lahko ga vzamejo sami. Poleg tega razvijalci vedno želijo zgraditi tako kul sistem, da bosta Facebook in Netflix ljubosumna.

Toda razvijalci nimajo izkušenj z nakupom strežnikov in veščine določanja zahtevane velikosti strežnikov, ker tega prej niso potrebovali. In običajno ne razumejo povsem razlike med razširljivostjo in zmogljivostjo.

Rezultati popisa:

Zapustili smo isti podatkovni center.
Prekinili smo pogodbo s 3 log servisi. Ker smo jih imeli 5 - vsak razvijalec, ki se je začel z nečim igrati, je vzel novega.
Zaustavljenih je bilo 7 sistemov AWS. Spet nihče ni ustavil mrtvih projektov, vsi so nadaljevali z delom.
Zmanjšanje stroškov programske opreme za 6-krat.

Petinsedemdeseti dan

Čas je tekel in čez dva meseca in pol sem se moral sestati z upravnim odborom. Naš upravni odbor ni nič boljši ali slabši od drugih, kot vsi upravni odbori želi vedeti vse. Ljudje vlagajo denar in želijo razumeti, koliko se to, kar počnemo, ujema z zastavljenimi KPI-ji.

Upravni odbor vsak mesec prejme veliko informacij: število uporabnikov, njihovo rast, katere storitve uporabljajo in kako, uspešnost in produktivnost ter končno povprečno hitrost nalaganja strani.

Problem je le v tem, da menim, da je povprečje čisto zlo. Je pa to zelo težko pojasniti upravnemu odboru. Navajeni so operirati z agregiranimi številkami in ne na primer z razporeditvijo časov nalaganja na sekundo.

V zvezi s tem je bilo nekaj zanimivih točk. Rekel sem na primer, da moramo promet razdeliti med ločene spletne strežnike glede na vrsto vsebine.

To pomeni, da gre ColdFusion skozi Jetty in nginx ter zažene strani. In slike, JS in CSS gredo skozi ločen nginx z lastnimi konfiguracijami. To je dokaj standardna praksa, o kateri govorim napisal sem pred nekaj leti. Posledično se slike nalagajo veliko hitreje in ... povprečna hitrost nalaganja se je povečala za 200 ms.

To se je zgodilo, ker je graf zgrajen na podlagi podatkov, ki jih dobite z Jetty. To pomeni, da hitra vsebina ni vključena v izračun - povprečna vrednost je poskočila. To nam je bilo jasno, smejali smo se, ampak kako naj upravnemu odboru razložimo, zakaj smo nekaj naredili in se je stanje poslabšalo za 12 %?

Petinosemdeseti dan

Konec tretjega meseca sem spoznal, da obstaja ena stvar, na katero sploh nisem računal: čas. Vse, o čemer sem govoril, zahteva čas.

To je moj pravi tedenski koledar – samo delovni teden, ki ni preveč zaseden. Za vse ni dovolj časa. Zato morate spet zaposliti ljudi, ki vam bodo pomagali pri soočanju s težavami.

Zaključek

To še ni vse. V tej zgodbi sploh nisem prišel do tega, kako smo delali s produktom in se poskušali uglasiti na splošni val, kako smo integrirali tehnično podporo ali kako smo reševali druge tehnične težave. Na primer, povsem po naključju sem izvedel, da na največjih tabelah v bazi ne uporabljamo SEQUENCE. Imamo samonapisano funkcijo nextID, in se ne uporablja v transakciji.

Bilo je še milijon podobnih stvari, o katerih bi lahko dolgo govorili. Toda najpomembnejše, kar je še treba povedati, je kultura.

Kultura oziroma pomanjkanje le-te vodi do vseh drugih težav. Poskušamo zgraditi kulturo, kjer ljudje:

se ne bojijo neuspehov;
učiti se iz napak;
sodelovati z drugimi ekipami;
prevzeti pobudo;
prevzeti odgovornost;
pozdravite rezultat kot cilj;
proslavljanje uspeha.

S tem pride vse ostalo.

Leon Požar na twitterju, facebook in srednje.

Obstajata dve strategiji glede dediščine: izogibajte se delu z njo za vsako ceno ali pogumno premagajte s tem povezane težave. Mi c DevOpsConf Ubiramo drugo pot, spreminjamo procese in pristope. Pridružite se nam youtube, poštni seznam и telegram, in skupaj bomo implementirali kulturo DevOps.

Vir: www.habr.com

Dedovanje podedovanih sistemov in procesov ali prvih 90 dni kot tehnični direktor