Poznato je da se kompetentnost CTO-a testira tek drugi put kada obavlja ovu funkciju. Jer jedno je raditi u kompaniji nekoliko godina, evoluirati s njom i, u istom kulturnom kontekstu, postepeno primati sve veću odgovornost. A sasvim je drugo doći pravo na poziciju tehničkog direktora u kompaniji sa naslijeđenim prtljagom i gomilom problema uredno gurnutih pod tepih.

U tom smislu, iskustvo Leona Fire, koje je podijelio na DevOpsConf, ne baš jedinstven, ali pomnožen njegovim iskustvom i brojem različitih uloga koje je uspio isprobati tokom 20 godina, vrlo je koristan. Ispod reza je hronologija događaja tokom 90 dana i mnoštvo priča kojima je zabavno smijati se kada se dogode nekom drugom, ali s kojima se nije tako zabavno suočiti lično.

Leon priča veoma šareno na ruskom, pa ako imate 35-40 minuta, preporučujem da pogledate video. Tekstualna verzija radi uštede vremena ispod.

Prva verzija izvještaja je bila dobro strukturiran opis rada s ljudima i procesa, sa korisnim preporukama. Ali nije prenijela sva iznenađenja koja su naišla na tom putu. Stoga sam promijenio format i predstavio probleme koji su se pojavili preda mnom kao džack-in-the-box u novoj kompaniji, te metode za njihovo rješavanje hronološkim redom.

Prije mjesec dana

Kao i mnoge dobre priče, i ova je počela alkoholom. Sjedili smo sa prijateljima u baru, a kao što se i očekivalo među IT stručnjacima, svi su plakali zbog svojih problema. Jedan od njih je upravo promijenio posao i pričao je o svojim problemima s tehnologijom, ljudima i timom. Što sam više slušao, više sam shvaćao da bi on trebao samo mene zaposliti, jer to su problemi koje rješavam posljednjih 15 godina. Rekao sam mu i sutradan smo se sreli u radnom okruženju. Kompanija se zvala Teaching Strategies.

Teaching Strategies je tržišni lider u nastavnom planu i programu za vrlo malu djecu od rođenja do tri godine. Tradicionalna “papirna” kompanija ima već 40 godina, a digitalna SaaS verzija platforme 10. Relativno nedavno je počeo proces prilagođavanja digitalne tehnologije standardima kompanije. “Nova” verzija je lansirana 2017. godine i bila je skoro kao stara, samo što je lošije radila.

Najzanimljivije je da je promet ove kompanije vrlo predvidljiv - iz dana u dan, iz godine u godinu, možete vrlo jasno predvidjeti koliko će ljudi doći i kada. Na primjer, između 13 i 15 sati sva djeca u vrtićima idu na spavanje, a učitelji počinju unositi podatke. I to se dešava svaki dan, osim vikendom, jer vikendom skoro niko ne radi.

Gledajući malo unapred, napomenuću da sam svoj posao započeo u periodu najvećeg godišnjeg prometa, što je interesantno iz raznih razloga.

Platforma, koja je izgledala kao stara samo 2 godine, imala je neobičan stek: ColdFusion & SQL Server iz 2008. ColdFusion, ako ne znate, a najvjerovatnije ne znate, je Enterprise PHP koji je izašao sredinom 90-ih, a od tada nisam ni čuo za njega. Tu su bili i: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ali glavni monolit je radio na ColdFusionu i SQL Serveru.

Problemi

Što sam više razgovarao sa zaposlenima kompanije o radu i problemima koji su naišli, sve sam više uviđao da problemi nisu samo tehničke prirode. U redu, tehnologija je stara - i nisu radili na njoj, ali bilo je problema s timom i procesima i kompanija je to počela shvaćati.

Tradicionalno, njihovi tehničari su sedeli u uglu i radili neku vrstu posla. Ali sve više i više poslova počelo je da ide kroz digitalnu verziju. Dakle, u posljednjoj godini prije nego što sam počeo raditi, pojavili su se novi u kompaniji: Upravni odbor, CTO, CPO i QA direktor. Odnosno, kompanija je počela da investira u tehnološki sektor.

Tragovi teškog nasleđa nisu bili samo u sistemima. Kompanija je imala naslijeđene procese, naslijeđene ljude, naslijeđenu kulturu. Sve ovo je trebalo promijeniti. Mislio sam da definitivno neće biti dosadno i odlučio sam da probam.

Dva dana ranije

Dva dana prije početka novog posla stigla sam u kancelariju, popunila zadnju papirologiju, upoznala tim i otkrila da se tim u tom trenutku bori sa problemom. Bilo je to da je prosječno vrijeme učitavanja stranice skočilo na 4 sekunde, odnosno 2 puta.

Sudeći po grafikonu, nešto se jasno dogodilo, a nije jasno šta. Ispostavilo se da je problem kašnjenje mreže u data centru: kašnjenje od 5 ms u data centru pretvorilo se u 2 s za korisnike. Nisam znao zašto se to dogodilo, ali se u svakom slučaju saznalo da je problem u data centru.

Prvi dan

Prošla su dva dana i prvog dana rada sam otkrila da problem nije nestao.

Za dva dana, stranice korisnika su se učitavale u prosjeku za 4 sekunde. Pitam da li su našli u čemu je problem.

- Da, otvorili smo kartu.
- I?
- Pa, još nam nisu odgovorili.

Tada sam shvatio da je sve o čemu su mi ranije govorili samo mali vrh ledenog brega sa kojim se moram boriti.

Postoji dobar citat koji se vrlo dobro uklapa u ovo:

“Ponekad da biste promijenili tehnologiju morate promijeniti organizaciju.”

Ali pošto sam počeo da radim u najprometnije doba godine, morao sam da pogledam obe opcije za rešavanje problema: i brzo i dugoročno. I počnite sa onim što je trenutno kritično.

Treći dan

Dakle, opterećenje traje 4 sekunde, a od 13 do 15 najveći vrhovi.

Trećeg dana tokom ovog perioda, brzina preuzimanja je izgledala ovako:

Sa moje tačke gledišta, ništa nije funkcionisalo. Sa gledišta svih ostalih, išao je malo sporije nego inače. Ali to se jednostavno ne dešava tako – to je ozbiljan problem.

Pokušao sam uvjeriti tim, na što su mi odgovorili da im jednostavno treba više servera. Ovo je, naravno, rješenje problema, ali nije uvijek jedino i najefikasnije. Pitao sam zašto nema dovoljno servera, koliki je obim saobraćaja. Ekstrapolirao sam podatke i ustanovio da imamo otprilike 150 zahtjeva u sekundi, što u principu spada u razumne granice.

Ali ne smijemo zaboraviti da prije nego što dobijete pravi odgovor, morate postaviti pravo pitanje. Moje sljedeće pitanje je bilo: koliko frontend servera imamo? Odgovor me je “malo zbunio” - imali smo 17 frontend servera!

— Neugodno mi je da pitam, ali 150 podeljeno sa 17 daje otprilike 8? Hoćete reći da svaki server dozvoljava 8 zahtjeva u sekundi, a ako sutra bude 160 zahtjeva u sekundi, trebat će nam još 2 servera?

Naravno, nisu nam bili potrebni dodatni serveri. Rješenje je bilo u samom kodu, i na površini:

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

Postojala je funkcija getCurrentClass(), jer sve na sajtu radi u kontekstu klase - tako je. I za ovu jednu funkciju na svakoj stranici bilo je 200+ zahtjeva.

Rješenje na ovaj način je bilo vrlo jednostavno, čak niste morali ništa da prepisujete: samo nemojte ponovo tražiti iste informacije.

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

Bio sam jako sretan jer sam odlučio da sam tek trećeg dana pronašao glavni problem. Koliko god da sam bio naivan, ovo je bio samo jedan od mnogih problema.

Ali rješavanje ovog prvog problema spustilo je graf mnogo niže.

Istovremeno smo radili i druge optimizacije. Bilo je mnogo stvari na vidiku koje su se mogle popraviti. Na primjer, istog trećeg dana otkrio sam da ipak postoji keš u sistemu (u početku sam mislio da svi zahtjevi dolaze direktno iz baze podataka). Kada pomislim na keš memoriju, mislim na standardni Redis ili Memcached. Ali ja sam jedini tako mislio, jer je taj sistem koristio MongoDB i SQL Server za keširanje - isti onaj iz kojeg su upravo čitani podaci.

Dan deseti

Prve sedmice sam se bavio problemima koje je trebalo odmah riješiti. Negde druge nedelje sam prvi put došao na stand-up da komuniciram sa timom, da vidim šta se dešava i kako se ceo proces odvija.

Ponovo je otkriveno nešto zanimljivo. Tim se sastojao od: 18 programera; 8 testera; 3 menadžera; 2 arhitekte. I svi su učestvovali u zajedničkim ritualima, odnosno svako jutro je dolazilo više od 30 ljudi na stand-up i pričalo šta su radili. Jasno je da sastanak nije trajao 5 ili 15 minuta. Niko nikoga nije slušao jer svi rade na različitim sistemima. U ovom obliku, 2-3 karte po satu za sesiju dotjerivanja je već bio dobar rezultat.

Prvo što smo uradili je da smo tim podelili na nekoliko linija proizvoda. Za različite sekcije i sisteme dodijelili smo zasebne timove, koji su uključivali programere, testere, menadžere proizvoda i poslovne analitičare.

Kao rezultat dobili smo:

• Smanjenje ustajanja i skupova.
• Predmetno poznavanje proizvoda.
• Osećaj vlasništva. Kada su ljudi stalno petljali sa sistemima, znali su da će neko drugi najverovatnije morati da radi sa njihovim greškama, ali ne i oni sami.
• Saradnja između grupa. Nepotrebno je reći da QA ranije nije mnogo komunicirao s programerima, proizvod je radio svoje, itd. Sada imaju zajedničku tačku odgovornosti.

Uglavnom smo se fokusirali na efikasnost, produktivnost i kvalitet - to su problemi koje smo pokušali riješiti transformacijom tima.

Dan jedanaesti

U procesu promjene strukture tima, otkrio sam kako se računa pričaPoints. 1 SP je bio jednak jednom danu, a svaki tiket je sadržavao SP i za razvoj i za QA, odnosno najmanje 2 SP.

Kako sam ovo otkrio?

Pronašli smo grešku: u jednom od izvještaja, gdje je upisan datum početka i završetka perioda za koji je izvještaj potreban, posljednji dan se ne uzima u obzir. Odnosno, negdje u zahtjevu nije bilo <=, već jednostavno <. Rečeno mi je da su to tri tačke priče, tj 3 dana.

Nakon ovoga mi:

• Sistem ocjenjivanja Story Points je revidiran. Sada ispravke za manje greške koje se mogu brzo prenijeti kroz sistem brže stižu do korisnika.
• Počeli smo spajati povezane tikete za razvoj i testiranje. Ranije je svaka karta, svaka greška bila zatvoreni ekosistem, nevezan ni za šta drugo. Promjena tri dugmeta na jednoj stranici mogla su biti tri različite karte sa tri različita QA procesa umjesto jednog automatiziranog testa po stranici.
• Počeli smo raditi sa programerima na pristupu procjeni troškova rada. Tri dana za promjenu jednog dugmeta nije smiješno.

Dvadeseti dan

Negde sredinom prvog meseca situacija se malo stabilizovala, shvatio sam šta se u suštini dešava i već počeo da gledam u budućnost i razmišljam o dugoročnim rešenjima.

Dugoročni ciljevi:

• Upravljana platforma. Stotine zahtjeva na svakoj stranici nisu ozbiljni.
• Predvidljivi trendovi. Postojali su periodični vršni prometni udari koji na prvi pogled nisu bili u korelaciji s drugim pokazateljima - morali smo razumjeti zašto se to dogodilo i naučiti predvidjeti.
• Proširenje platforme. Posao stalno raste, sve više korisnika dolazi, a promet se povećava.

U prošlosti se često govorilo: “Hajde da prepišemo sve na [jeziku/okviru], sve će raditi bolje!”

U većini slučajeva ovo ne radi, dobro je ako prepisivanje uopće funkcionira. Stoga smo morali napraviti mapu puta – konkretnu strategiju koja će korak po korak ilustrirati kako će se poslovni ciljevi postići (šta ćemo raditi i zašto), a koja:

• odražava misiju i ciljeve projekta;
• daje prioritet glavnim ciljevima;
• sadrži raspored za njihovo postizanje.

Prije toga, niko nije razgovarao sa timom o svrsi bilo kakvih promjena. Ovo zahtijeva prave metrike uspjeha. Po prvi put u istoriji kompanije postavili smo KPI za tehničku grupu, a ti pokazatelji su bili vezani za organizacione.

Odnosno, organizacione KPI podržavaju timovi, a timske KPI podržavaju pojedinačni KPI. Inače, ako se tehnološki KPI ne poklapaju s organizacijskim, onda svako vuče pokrivač na sebe.

Na primjer, jedan od organizacijskih KPI-a je povećanje tržišnog udjela kroz nove proizvode.

Kako možete podržati cilj da imate više novih proizvoda?

• Prvo, želimo provesti više vremena u razvoju novih proizvoda umjesto popravljanja nedostataka. Ovo je logično rješenje koje je lako izmjeriti.
• Drugo, želimo podržati povećanje obima transakcija, jer što je veći tržišni udio, to je više korisnika i, shodno tome, više prometa.

Tada će pojedinačni KPI koji se mogu izvršiti unutar grupe, na primjer, biti na mjestu odakle dolaze glavni nedostaci. Ako se posebno fokusirate na ovaj odjeljak, možete osigurati da ima mnogo manje nedostataka, a onda će se povećati vrijeme za razvoj novih proizvoda i opet za podršku organizacijskim KPI-ovima.

Dakle, svaka odluka, uključujući i prepisivanje koda, mora podržavati specifične ciljeve koje nam je kompanija postavila (organizacijski rast, nove funkcije, zapošljavanje).

Tokom ovog procesa, na vidjelo je izašla zanimljiva stvar, koja je postala vijest ne samo za tehničare, već i općenito u kompaniji: sve karte moraju biti fokusirane na barem jedan KPI. Odnosno, ako proizvod kaže da želi napraviti novu funkciju, prvo bi se trebalo postaviti pitanje: „Koji KPI podržava ova funkcija?“ Ako ne, onda izvinite - čini se da je to nepotrebno.

Trideseti dan

Krajem mjeseca otkrio sam još jednu nijansu: niko u mom operativnom timu nikada nije vidio ugovore koje sklapamo s klijentima. Možete pitati zašto trebate vidjeti kontakte.

• Prvo, zato što su SLA specificirani u ugovorima.
• Drugo, SLA su svi različiti. Svaki klijent je došao sa svojim zahtjevima, a odjel prodaje je potpisao bez gledanja.

Još jedna zanimljiva nijansa je da u ugovoru s jednim od najvećih klijenata stoji da sve verzije softvera koje platforma podržava moraju biti n-1, odnosno ne najnovija verzija, već pretposljednja.

Jasno je koliko smo bili daleko od n-1 ako je platforma bila bazirana na ColdFusionu i SQL Serveru 2008, koji u julu više uopće nije bio podržan.

Dan četrdeset peti

Sredinom drugog mjeseca imao sam dovoljno vremena da sjednem i radim vrijednostpotokkartografija potpuno za ceo proces. Ovo su neophodni koraci koje treba poduzeti, od kreiranja proizvoda do isporuke potrošaču, i treba ih opisati što je detaljnije moguće.

Razbijate proces na male komadiće i vidite šta oduzima previše vremena, šta se može optimizirati, poboljšati itd. Na primjer, koliko vremena je potrebno da zahtjev za proizvod prođe kroz uređivanje, kada stigne do tiketa koji programer može uzeti, QA, itd. Dakle, detaljno gledate svaki pojedinačni korak i razmišljate o tome šta se može optimizirati.

Kada sam ovo uradio dve stvari su mi zapele za oko:

• visok procenat tiketa vraćenih od QA nazad programerima;
• Pregledi zahtjeva za povlačenjem su predugo trajali.

Problem je bio što su to bili zaključci poput: Čini se da treba puno vremena, ali nismo sigurni koliko.

"Ne možete poboljšati ono što ne možete izmjeriti."

Kako opravdati koliko je problem ozbiljan? Da li gubi dane ili sate?

Da bismo ovo izmjerili, dodali smo nekoliko koraka u Jira proces: “spremni za dev” i “spremni za QA” kako bismo izmjerili koliko dugo svaka karta čeka i koliko puta se vraća na određeni korak.

Dodali smo i “u recenziji” da znamo koliko je karata u prosjeku za pregled, i od toga možete početi plesati. Imali smo sistemske metrike, sada smo dodali nove metrike i počeli mjeriti:

• Efikasnost procesa: performanse i planirane/isporučene.
• Kvalitet procesa: broj nedostataka, nedostataka iz QA.

Zaista pomaže razumjeti šta ide dobro, a šta ne.

Pedeseti dan

Sve je to, naravno, dobro i zanimljivo, ali pred kraj drugog mjeseca dogodilo se nešto što je, u principu, bilo predvidljivo, iako nisam očekivao takve razmjere. Ljudi su počeli da odlaze jer se promenio vrh. U upravu su došli novi ljudi i počeli sve mijenjati, a stari su odustali. I obično u društvu starom nekoliko godina, svi su prijatelji i svi se poznaju.

To je bilo očekivano, ali su razmjeri otpuštanja bili neočekivani. Na primjer, u jednoj sedmici dva čelnika tima su istovremeno podnijela ostavke svojom voljom. Stoga sam morao ne samo da zaboravim na druge probleme, već da se fokusiram na njih stvaranje tima. Ovo je dug i težak problem za rješavanje, ali se moralo riješiti jer sam želio spasiti ljude koji su ostali (ili većinu njih). Trebalo je nekako reagovati na to što su ljudi otišli kako bi se održao moral u timu.

U teoriji, ovo je dobro: dolazi nova osoba koja ima potpuni carte blanche, koja može procijeniti vještine tima i zamijeniti osoblje. U stvari, ne možete samo dovesti nove ljude iz toliko razloga. Balans je uvek potreban.

• Staro i novo. Moramo zadržati stare ljude koji mogu promijeniti i podržavati misiju. Ali u isto vrijeme, moramo donijeti novu krv, o tome ćemo malo kasnije.
• Iskustvo. Mnogo sam razgovarao sa dobrim juniorima koji su bili željni i hteli su da rade sa nama. Ali nisam mogao da ih prihvatim jer nije bilo dovoljno seniora da podrže juniore i da im budu mentori. Trebalo je prvo regrutirati vrh pa tek onda omladinu.
• Šargarepa i štap.

Nemam dobar odgovor na pitanje šta je pravi balans, kako ga održavati, koliko ljudi zadržati, a koliko gurati. Ovo je čisto individualan proces.

Dan pedeset prvi

Počeo sam pažljivo da gledam u tim da shvatim koga imam, i još jednom sam se setio:

“Većina problema su problemi ljudi.”

Otkrio sam da tim kao takav - i Dev i Ops - ima tri velika problema:

• Zadovoljstvo trenutnim stanjem stvari.
• Nedostatak odgovornosti - jer niko nikada nije doneo rezultate rada izvođača da bi uticao na poslovanje.
• Strah od promjene.

Promjena vas uvijek izvlači iz vaše zone udobnosti, a što su ljudi mlađi, to im se više ne sviđaju jer ne razumiju zašto i ne razumiju kako. Najčešći odgovor koji sam čuo je: "Nikada to nismo radili." Štaviše, došlo je do tačke potpunog apsurda - ni najmanja promena nije mogla da se desi a da neko ne bude ogorčen. I koliko god promene uticale na njihov rad, ljudi su govorili: „Ne, zašto? Ovo neće raditi."

Ali ne možete postati bolji a da ništa ne promijenite.

Imao sam apsolutno apsurdan razgovor sa zaposlenim, rekao sam mu svoje ideje za optimizaciju, na šta mi je on rekao:
- Oh, niste videli šta smo imali prošle godine!
- Pa šta?
“Sada je mnogo bolje nego što je bilo.”
- Dakle, ne može bolje?
- Zašto?

Dobro pitanje - zašto? Kao da je sada bolje nego što je bilo, onda je sve dovoljno dobro. To dovodi do nedostatka odgovornosti, što je u principu sasvim normalno. Kao što sam rekao, tehnička grupa je bila malo po strani. Kompanija je smatrala da treba da postoje, ali niko nikada nije postavljao standarde. Tehnička podrška nikada nije vidjela SLA, tako da je to bilo sasvim "prihvatljivo" za grupu (a ovo me najviše pogodilo):

• 12 sekundi učitavanja;
• 5-10 minuta zastoja za svako izdanje;
• Rješavanje kritičnih problema traje danima i sedmicama;
• nedostatak dežurnog osoblja 24x7 / dežurstva.

Niko se nikada nije pitao zašto to ne uradimo bolje, i niko nikada nije shvatio da ne mora biti tako.

Kao bonus, postojao je još jedan problem: nedostatak iskustva. Seniori su otišli, a preostala mlada ekipa stasala je pod prethodnim režimom i njime se otrovala.

Povrh svega, ljudi su se plašili neuspjeha i izgleda nesposobni. To se izražava u činjenici da, prvo, oni ni pod kojim okolnostima nije tražio pomoć. Koliko puta smo razgovarali kao grupa i pojedinačno, a ja sam rekao: „Postavi pitanje ako ne znaš kako da uradiš nešto“. Siguran sam u sebe i znam da mogu riješiti svaki problem, ali za to će trebati vrijeme. Zato, ako mogu da pitam nekoga ko zna da to reši za 10 minuta, pitaću. Što manje iskustva imate, to se više plašite da pitate jer mislite da ćete se smatrati nesposobnim.

Ovaj strah od postavljanja pitanja manifestuje se na zanimljive načine. Na primjer, pitate: "Kako ide s ovim zadatkom?" - “Još par sati, već završavam.” Sutradan ponovo pitate, dobijete odgovor da je sve u redu, ali je bio jedan problem, sigurno će biti gotovo do kraja dana. Prođe još jedan dan, a sve dok ne budete prikovani za zid i primorani da razgovarate s nekim, ovo se nastavlja. Čovek želi sam da reši problem, veruje da će, ako ga sam ne reši, to biti veliki neuspeh.

Zato programeri su naduvali procjene. To je bila ta ista anegdota, kada su razgovarali o nekom zadatku, dali su mi takvu cifru da sam se jako iznenadio. Na šta mi je rečeno da programer u procjenu programera uračunava vrijeme kada će tiket biti vraćen od QA, jer će tamo pronaći greške, i vrijeme koje će PR-u trebati, i vrijeme dok ljudi koji bi trebali pregledati biće zauzeto - to jest, sve, šta god je moguće.

Drugo, ljudi koji se boje da ne ispadnu nekompetentni preterano analizirati. Kada kažete šta tačno treba da se uradi, počinje: „Ne, šta ako razmislimo o tome ovde?“ U tom smislu, naša kompanija nije jedinstvena, ovo je standardan problem za mlade ljude.

Kao odgovor, uveo sam sljedeće prakse:

• Pravilo 30 minuta. Ako ne možete riješiti problem za pola sata, zamolite nekoga da vam pomogne. Ovo funkcioniše sa različitim stepenom uspeha, jer ljudi još uvek ne pitaju, ali je bar proces počeo.
• Uklonite sve osim suštine, pri procjeni roka za završetak zadatka, odnosno uzmite u obzir samo koliko će vremena biti potrebno za pisanje koda.
• Cjeloživotno učenje za one koji preterano analiziraju. To je samo stalni rad sa ljudima.

Dan šezdeseti

Dok sam sve ovo radio, došlo je vrijeme da smislim budžet. Naravno, našao sam mnogo zanimljivih stvari u tome gdje smo trošili novac. Na primjer, imali smo cijeli rack u zasebnom data centru sa jednim FTP serverom, koji je koristio jedan klijent. Ispostavilo se da “...mi smo se preselili, a on je ostao takav, nismo ga mijenjali.” Bilo je to prije 2 godine.

Posebno je zanimljiv bio račun za usluge u oblaku. Vjerujem da su glavni razlog za visoke račune u oblaku programeri koji po prvi put u životu imaju neograničen pristup serverima. Ne moraju da traže: „Molim vas, dajte mi test server“, mogu ga sami uzeti. Osim toga, programeri uvijek žele da naprave tako kul sistem da će Facebook i Netflix biti ljubomorni.

Ali programeri nemaju iskustva u kupovini servera i vještinu određivanja potrebne veličine servera, jer im to ranije nije trebalo. I obično ne razumiju razliku između skalabilnosti i performansi.

Rezultati inventara:

• Napustili smo isti data centar.
• Raskinuli smo ugovor sa 3 log servisa. Zato što smo ih imali 5 - svaki programer koji je počeo da se igra sa nečim uzimao je novog.
• Ugašeno je 7 AWS sistema. Opet, niko nije zaustavio mrtve projekte, svi su nastavili da rade.
• Smanjeni troškovi softvera za 6 puta.

Dan sedamdeset peti

Vrijeme je prolazilo, a za dva i po mjeseca morao sam se sastati sa upravnim odborom. Naš upravni odbor nije ni bolji ni lošiji od drugih, kao i svi upravni odbori, želi sve da zna. Ljudi ulažu novac i žele da shvate koliko se ono što radimo uklapa u postavljene KPI.

Upravni odbor svakog mjeseca prima mnogo informacija: broj korisnika, njihov rast, koje usluge koriste i kako, performanse i produktivnost i na kraju, prosječnu brzinu učitavanja stranice.

Jedini problem je što vjerujem da je prosjek čisto zlo. Ali vrlo je teško to objasniti upravnom odboru. Oni su navikli da rade sa agregiranim brojevima, a ne, na primer, sa razmakom vremena učitavanja u sekundi.

Bilo je nekih zanimljivih tačaka u tom pogledu. Na primjer, rekao sam da trebamo podijeliti promet između zasebnih web servera ovisno o vrsti sadržaja.

To jest, ColdFusion prolazi kroz Jetty i nginx i pokreće stranice. A slike, JS i CSS prolaze kroz poseban nginx sa svojim vlastitim konfiguracijama. Ovo je prilično standardna praksa o kojoj govorim napisao je prije par godina. Kao rezultat toga, slike se puno brže učitavaju i... prosječna brzina učitavanja je povećana za 200 ms.

To se dogodilo jer je graf napravljen na osnovu podataka koji dolaze s Jettyjem. Odnosno, brzi sadržaj nije uključen u izračun - prosječna vrijednost je skočila. To nam je bilo jasno, smijali smo se, ali kako da objasnimo upravnom odboru zašto smo nešto uradili i stvari su se pogoršale za 12%?

Dan osamdeset peti

Krajem trećeg mjeseca shvatila sam da postoji jedna stvar na koju uopće nisam računala: vrijeme. Sve o čemu sam pričao zahteva vreme.

Ovo je moj pravi sedmični kalendar - samo radna sedmica, bez puno posla. Nema dovoljno vremena za sve. Stoga, opet, morate regrutovati ljude koji će vam pomoći da se nosite s problemima.

zaključak

To nije sve. U ovoj priči nisam ni došao do toga kako smo radili sa proizvodom i pokušali da se prilagodimo opštem talasu, ili kako smo integrisali tehničku podršku, ili kako smo rešavali druge tehničke probleme. Na primjer, sasvim slučajno sam saznao da na najvećim tablicama u bazi podataka ne koristimo SEQUENCE. Imamo samopisnu funkciju nextID, i ne koristi se u transakciji.

Bilo je još milion sličnih stvari o kojima smo mogli dugo pričati. Ali najvažnija stvar koju još treba reći je kultura.

Kultura ili njen nedostatak dovodi do svih drugih problema. Pokušavamo da izgradimo kulturu u kojoj ljudi:

• ne plaše se neuspjeha;
• učiti iz grešaka;
• sarađivati ​​sa drugim timovima;
• preuzeti inicijativu;
• preuzeti odgovornost;
• pozdravite rezultat kao gol;
• slavljenje uspjeha.

Sa ovim će doći i sve ostalo.

Leon Fire na twitteru, facebook i dalje srednji.

Postoje dvije strategije u vezi sa naslijeđem: izbjegavajte rad s njim po svaku cijenu ili hrabro savladajte povezane poteškoće. Mi c DevOpsConf Idemo drugim putem, mijenjamo procese i pristupe. Pridružite nam se youtube, spisak adresa и telegram, i zajedno ćemo implementirati DevOps kulturu.

izvor: www.habr.com