Poznato je da se stručnost CTO-a provjerava tek kad drugi put obavlja tu ulogu. Jer jedna je stvar raditi u tvrtki nekoliko godina, razvijati se s njom i, nalazeći se u istom kulturnom kontekstu, postupno dobivati ​​sve više odgovornosti. A sasvim je nešto drugo doći ravno na mjesto tehničkog direktora u tvrtki s naslijeđenom prtljagom i hrpom problema uredno pometenih pod tepih.

U tom smislu iskustvo Leona Vatra koje je prenio na DevOpsConf, ne baš jedinstven, ali pomnožen njegovim iskustvom i brojem različitih uloga koje je uspio isprobati tijekom 20 godina, vrlo je koristan. Ispod presjeka je kronologija događaja tijekom 90 dana i mnoštvo priča kojima se zabavno nasmijati kad se dogode nekome drugome, ali s kojima nije zabavno suočiti se osobno.

Leon vrlo slikovito priča na ruskom, pa ako imate 35-40 minuta, preporučujem da pogledate video. Tekstualna verzija za uštedu vremena u nastavku.

Prva verzija izvješća bila je dobro strukturiran opis rada s ljudima i procesima, s korisnim preporukama. No nije prenijela sva iznenađenja koja su se našla na putu. Stoga sam promijenio format i kronološkim redoslijedom prikazao probleme koji su kao iz kutije iskakali ispred mene u novom poduzeću, te metode za njihovo rješavanje.

Prije mjesec dana

Kao i mnoge dobre priče, i ova je počela s alkoholom. Sjedili smo s prijateljima u baru i očekivano među informatičarima, svatko je plakao zbog svojih problema. Jedan od njih je upravo promijenio posao i pričao je o svojim problemima s tehnologijom, i s ljudima, i s timom. Što sam više slušao, sve sam više shvaćao da bi me jednostavno trebao zaposliti, jer to su problemi koje sam rješavao zadnjih 15 godina. Rekao sam mu to i sutradan smo se sreli u radnom okruženju. Tvrtka se zvala Teaching Strategies.

Teaching Strategies je vodeći na tržištu u kurikulumu za vrlo malu djecu od rođenja do tri godine. Tradicionalna “papirnata” tvrtka stara je već 40 godina, a digitalna SaaS verzija platforme 10. Relativno nedavno je započeo proces prilagođavanja digitalne tehnologije standardima tvrtke. “Nova” verzija lansirana je 2017. i bila je gotovo kao stara, samo što je radila lošije.

Najzanimljivije je to što je promet ove tvrtke vrlo predvidljiv - iz dana u dan, iz godine u godinu, možete vrlo jasno predvidjeti koliko će ljudi doći i kada. Primjerice, između 13 i 15 sati sva djeca u vrtićima idu spavati, a učitelji počinju unositi podatke. I to se događa svaki dan, osim vikendom, jer vikendom gotovo nitko ne radi.

Gledajući malo unaprijed, primijetit ću da sam s radom započeo u razdoblju najvećeg godišnjeg prometa, što je zanimljivo iz raznih razloga.

Platforma, koja se činila starom samo 2 godine, imala je neobičan skup: ColdFusion & SQL Server iz 2008. ColdFusion je, ako ne znate, a najvjerojatnije ne znate, poslovni PHP koji se pojavio sredinom 90-ih i od tada nisam ni čuo za njega. Tu su još bili: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ali glavni monolit radio je na ColdFusionu i SQL Serveru.

Problemi

Što sam više razgovarao sa zaposlenicima tvrtke o radu i problemima s kojima se susreću, to 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 s procesima, a tvrtka je to počela shvaćati.

Tradicionalno, njihovi tehničari sjedili su u kutu i obavljali nekakav posao. Ali sve više i više poslova počelo je ići kroz digitalnu verziju. Stoga su se zadnjih godinu dana prije mog rada u tvrtki pojavili novi: Upravni odbor, CTO, CPO i QA direktor. Odnosno, tvrtka je počela ulagati u tehnološki sektor.

Tragovi teške ostavštine nisu bili samo u sustavima. Tvrtka je imala naslijeđene procese, naslijeđene ljude, naslijeđenu kulturu. Sve je to trebalo promijeniti. Mislio sam da sigurno neće biti dosadno i odlučio sam pokušati.

Dva dana prije

Dva dana prije početka novog posla, stigao sam u ured, ispunio zadnju papirologiju, upoznao tim i otkrio da se tim u tom trenutku bori s problemom. Bilo je to da je prosječno vrijeme učitavanja stranice skočilo na 4 sekunde, odnosno 2 puta.

Sudeći po grafu, nešto se očito dogodilo, a nije jasno što. Ispostavilo se da je problem bila latencija mreže u podatkovnom centru: 5 ms latencija u podatkovnom centru pretvorilo se u 2 s za korisnike. Nisam znao zašto se to dogodilo, ali u svakom slučaju saznalo se da je problem u podatkovnom centru.

Dan jednom

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

Tijekom dva dana stranice korisnika učitavale su se u prosjeku za 4 sekunde. Pitam jesu li otkrili u čemu je problem.

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

Tada sam shvatio da je sve ono o čemu su mi prije govorili samo mali vrh ledenog brijega s kojim se moram boriti.

Postoji dobar citat koji ovome dobro pristaje:

"Ponekad da biste promijenili tehnologiju morate promijeniti organizaciju."

Ali kako sam počeo raditi u najvećem dijelu godine, morao sam sagledati obje mogućnosti rješavanja problema: i brzu i dugoročnu. I počnite s onim što je trenutno kritično.

Treći dan

Dakle, učitavanje traje 4 sekunde, a od 13 do 15 najveći vrhovi.

Trećeg dana u tom vremenskom razdoblju brzina preuzimanja izgledala je ovako:

S moje točke gledišta, ništa nije uspjelo. Sa stajališta svih ostalih, radio je malo sporije nego inače. Ali to se jednostavno ne događa tako - to je ozbiljan problem.

Pokušao sam uvjeriti tim, na što su mi odgovorili da jednostavno trebaju više servera. To je, naravno, rješenje problema, ali nije uvijek jedino i najučinkovitije. Pitao sam zašto nema dovoljno servera, koliki je promet. Ekstrapolirao sam podatke i ustanovio da imamo otprilike 150 zahtjeva u sekundi, što je, načelno, u razumnim granicama.

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

— Neugodno mi je pitati, ali 150 podijeljeno sa 17 daje otprilike 8? Hoćete reći da svaki poslužitelj dopušta 8 zahtjeva u sekundi, a ako sutra bude 160 zahtjeva u sekundi, trebat će nam još 2 poslužitelja?

Naravno, nismo trebali dodatne servere. Rješenje je bilo u samom kodu i na površini:

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

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

Rješenje je na ovaj način bilo vrlo jednostavno, niste čak morali ništa prepisivati: samo nemojte ponovno tražiti iste podatke.

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

Bio sam jako sretan jer sam zaključio da sam tek treći dan otkrio glavni problem. Naivan kakav sam bio, to je bio samo jedan od mnogih problema.

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

Istovremeno smo radili i druge optimizacije. Naziralo se puno toga što se dalo popraviti. Na primjer, istog trećeg dana otkrio sam da ipak postoji cache u sustavu (isprva sam mislio da svi zahtjevi dolaze direktno iz baze). Kad pomislim na predmemoriju, pomislim na standardni Redis ili Memcached. Ali ja sam bio jedini koji je tako mislio, jer je taj sustav za predmemoriju koristio MongoDB i SQL Server - isti onaj s kojeg su upravo iščitavani podaci.

Dan deseti

Prvi tjedan bavio sam se problemima koje je trebalo riješiti odmah. Negdje u drugom tjednu došao sam prvi put na stand-up da komuniciram s ekipom, da vidim što se događa i kako ide cijeli proces.

Opet se otkrilo nešto zanimljivo. Tim se sastojao od: 18 programera; 8 testera; 3 upravitelja; 2 arhitekta. I svi su sudjelovali u zajedničkim ritualima, odnosno više od 30 ljudi je svako jutro dolazilo na stand-up i pričalo što rade. Jasno je da sastanak nije trajao 5 ili 15 minuta. Nitko nikoga nije slušao jer svi rade na različitim sustavima. U ovom obliku, 2-3 karte po satu za grooming session već je bio dobar rezultat.

Prvo što smo napravili je podijeliti tim u nekoliko proizvodnih linija. Za različite dijelove i sustave dodijelili smo zasebne timove koji su uključivali programere, testere, voditelje proizvoda i poslovne analitičare.

Kao rezultat dobili smo:

• Smanjenje ustajanja i skupova.
• Predmetno poznavanje proizvoda.
• Osjećaj vlasništva. Kad su se ljudi stalno petljali sa sustavima, znali su da će netko drugi najvjerojatnije morati raditi s njihovim greškama, ali ne oni sami.
• Suradnja između grupa. Nepotrebno je reći da QA prije nije puno komunicirao s programerima, proizvod je radio svoje, itd. Sada imaju zajedničku točku odgovornosti.

Uglavnom smo se fokusirali na učinkovitost, produktivnost i kvalitetu – to su problemi koje smo pokušali riješiti transformacijom tima.

Dan jedanaesti

U procesu mijenjanja strukture tima otkrio sam kako se računa PričaBodovi. 1 SP bio je jednak jednom danu, a svaka je karta sadržavala SP i za razvoj i za QA, odnosno najmanje 2 SP.

Kako sam to otkrio?

Pronašli smo grešku: u jednom od izvještaja, gdje je upisan datum početka i završetka razdoblja za koje je potrebno izvješće, zadnji dan nije uzet u obzir. Odnosno, negdje u zahtjevu nije bilo <=, već jednostavno <. Rečeno mi je da se radi o tri Story Pointa, tj 3 dana.

Nakon ovoga mi:

• Sustav ocjenjivanja Story Points je revidiran. Sada popravci za manje pogreške koji se mogu brzo provući kroz sustav brže dolaze do korisnika.
• Počeli smo spajati povezane karte za razvoj i testiranje. Prije je svaka ulaznica, svaki bug bio zatvoreni ekosustav, nevezan ni za što drugo. Promjena tri gumba na jednoj stranici mogla bi biti tri različite karte s tri različita QA procesa umjesto jednog automatiziranog testa po stranici.
• Počeli smo raditi s programerima na pristupu procjene troškova rada. Tri dana za promjenu jednog gumba nije smiješno.

Dan dvadeseti

Negdje sredinom prvog mjeseca situacija se malo stabilizirala, shvatio sam što se zapravo događa i već sam počeo gledati u budućnost i razmišljati o dugoročnim rješenjima.

Dugoročni ciljevi:

• Upravljana platforma. Stotine zahtjeva na svakoj stranici nisu ozbiljni.
• Predvidljivi trendovi. Bilo je povremenih vršnih prometa koji na prvi pogled nisu bili u korelaciji s drugim mjernim podacima - morali smo razumjeti zašto se to dogodilo i naučiti predviđati.
• Proširenje platforme. Posao je u stalnom porastu, korisnika je sve više, a promet sve veći.

U prošlosti se često govorilo: "Prepišimo sve na [jezik/okvir], sve će bolje funkcionirati!"

U većini slučajeva to ne funkcionira, dobro je ako prepisivanje uopće uspije. Stoga smo morali izraditi mapu puta - konkretnu strategiju koja korak po korak prikazuje kako će se ostvariti poslovni ciljevi (što ć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, nitko nije razgovarao s timom o svrsi bilo kakvih promjena. To zahtijeva pravu metriku uspjeha. Po prvi put u povijesti tvrtke postavili smo KPI-jeve za tehničku grupu, a ti pokazatelji vezani su uz organizacijske.

To jest, organizacijske KPI-je podržavaju timovi, a timske KPI-je podržavaju pojedinačni KPI-jevi. Inače, ako se tehnološki KPI ne poklapaju s organizacijskim, onda svatko povlači deku na sebe.

Na primjer, jedan od organizacijskih ključnih pokazatelja uspješnosti je povećanje tržišnog udjela putem novih proizvoda.

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

• Prvo, želimo potrošiti više vremena na razvoj novih proizvoda umjesto na popravljanje nedostataka. Ovo je logično rješenje koje je lako izmjeriti.
• Drugo, želimo podržati povećanje volumena transakcija, jer što je veći tržišni udio, to je više korisnika, a time i više prometa.

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

Stoga svaka odluka, uključujući ponovno pisanje koda, mora podržati specifične ciljeve koje nam je tvrtka postavila (organizacijski rast, nove značajke, zapošljavanje).

Tijekom ovog procesa na vidjelo je izašla zanimljiva stvar koja je postala vijest ne samo za tehničare, već općenito u tvrtki: svi tiketi moraju biti usmjereni na barem jedan KPI. Odnosno, ako proizvod kaže da želi napraviti novu značajku, prvo treba postaviti pitanje: "Koji KPI podržava ova značajka?" Ako nije, ispričavamo se - čini se kao nepotrebna značajka.

Dan trideseti

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

• Prvo, zato što su SLA navedeni u ugovorima.
• Drugo, svi SLA-ovi su različiti. Svaki klijent dolazio je sa svojim zahtjevima, a prodajni odjel je potpisivao bez gledanja.

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

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

Dan četrdeset peti

Otprilike sredinom drugog mjeseca imao sam dovoljno vremena sjesti i raditi vrijednostpotokkartografija potpuno za cijeli proces. To su nužni koraci koje je potrebno poduzeti, od izrade proizvoda do isporuke potrošaču, te ih je potrebno opisati što detaljnije.

Razbijate proces na male dijelove i vidite što oduzima previše vremena, što se može optimizirati, poboljšati itd. Na primjer, koliko je vremena potrebno da zahtjev za proizvod prođe kroz dotjerivanje, kada stigne do karte koju razvojni programer može uzeti, QA, itd. Dakle, svaki pojedinačni korak detaljno promatrate i razmišljate što se može optimizirati.

Kad sam ovo radio, dvije su mi stvari upale u oči:

• visok postotak ulaznica vraćenih iz QA-a nazad programerima;
• recenzije zahtjeva za povlačenjem trajale su predugo.

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

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

Kako opravdati koliko je problem ozbiljan? Gube li se dani ili sati?

Da bismo to izmjerili, dodali smo nekoliko koraka u proces Jira: "spreman za razvoj" i "spreman za QA" kako bismo izmjerili koliko dugo svaka karta čeka i koliko se puta vraća na određeni korak.

Dodali smo i "u pregledu" kako bismo znali koliko je karata u prosjeku za pregled, a od toga možete početi plesati. Imali smo metriku sustava, sada smo dodali nove metrike i počeli mjeriti:

• Učinkovitost procesa: izvedba i planirano/isporučeno.
• Kvaliteta procesa: broj nedostataka, nedostataka iz QA.

Stvarno pomaže razumjeti što ide dobro, a što ne ide dobro.

Dan pedeseti

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 odlaziti jer se promijenila uprava. U menadžment su došli novi ljudi i počeli sve mijenjati, a stari su otišli. A obično su u tvrtki staroj nekoliko godina svi prijatelji i svi se poznaju.

To je bilo očekivano, ali je opseg otpuštanja bio neočekivan. Na primjer, u jednom tjednu dva voditelja timova istovremeno su podnijela ostavke svojom voljom. Stoga sam morao ne samo zaboraviti na druge probleme, već se usredotočiti na njih stvaranje tima. Ovo je dug i težak problem za rješavanje, ali se s njim moralo pozabaviti jer sam želio spasiti ljude koji su ostali (ili većinu njih). Trebalo je nekako reagirati na to što su ljudi otišli da bi se održao moral u momčadi.

U teoriji je to dobro: dolazi nova osoba koja ima potpuni carte blanche, koja može procijeniti vještine tima i zamijeniti kadar. Zapravo, ne možete jednostavno dovesti nove ljude iz toliko mnogo razloga. Ravnoteža je uvijek potrebna.

• Staro i novo. Moramo zadržati stare ljude koji se mogu promijeniti i podržati misiju. Ali u isto vrijeme, moramo unijeti novu krv, o tome ćemo malo kasnije.
• Iskustvo. Puno sam razgovarao s dobrim juniorima koji su bili željni i željeli raditi s nama. Ali nisam ih mogao uzeti jer nije bilo dovoljno seniora koji bi podržali juniore i bili im mentori. Trebalo je prvo regrutirati vrh pa tek onda omladinu.
• Mrkva i batina.

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

Dan pedeset prvi

Počeo sam pažljivo promatrati tim kako bih shvatio koga imam i još jednom sam se sjetio:

“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 nitko nikada nije donio rezultate rada izvođača da utječu na poslovanje.
• Strah od promjene.

Promjene vas uvijek izbace iz zone udobnosti, a što su ljudi mlađi, to više ne vole promjene jer ne razumiju zašto i ne razumiju kako. Najčešći odgovor koji sam čuo je: "Nikad to nismo radili." Štoviše, došlo je do potpunog apsurda - ni najmanje promjene nisu mogle proći, a da se netko na to ne ogorči. I koliko god su promjene utjecale na njihov rad, ljudi su rekli: “Ne, zašto? Ovo neće uspjeti."

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

Imao sam apsolutno apsurdan razgovor sa zaposlenikom, rekao sam mu svoje ideje za optimizaciju, na što mi je on rekao:
- Joj, nisi vidio što smo imali prošle godine!
- Pa što?
“Sada je puno bolje nego što je bilo.”
- Znači, 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. Tvrtka je vjerovala da trebaju postojati, ali nitko nikad nije postavio standarde. Tehnička podrška nikada nije vidjela SLA, tako da je za grupu bio prilično "prihvatljiv" (i ovo me najviše pogodilo):

• 12 sekundi učitavanja;
• 5-10 minuta prekida rada pri svakom izdanju;
• Rješavanje kritičnih problema traje danima i tjednima;
• nedostatak dežurnog osoblja 24x7 / na poziv.

Nitko se nikada nije zapitao zašto to ne učinimo bolje i nitko nikada nije shvatio da to ne mora biti tako.

Kao bonus, pojavio se još jedan problem: Manjak iskustva. Seniori su otišli, a preostala mlada momčad stasala je u prošlom režimu i njime se zatrovala.

Povrh svega toga, ljudi su se također bojali neuspjeha i ispadanja nesposobnih. To se izražava u činjenici da su, prvo, oni ni pod kojim okolnostima nije tražio pomoć. Koliko puta smo razgovarali grupno i pojedinačno, a ja sam rekao: "Postavi pitanje ako ne znaš kako se nešto radi." Siguran sam u sebe i znam da mogu riješiti svaki problem, ali treba vremena. Stoga, ako mogu pitati nekoga tko to zna riješiti u 10 minuta, pitat ću. Što manje iskustva imate, to se više bojite pitati jer mislite da će vas smatrati nesposobnim.

Taj strah od postavljanja pitanja očituje se na zanimljive načine. Na primjer, pitate: "Kako napredujete s ovim zadatkom?" - “Još par sati, već završavam.” Sutradan opet pitaš, dobiješ odgovor da je sve u redu, ali bio je jedan problem, sigurno će biti gotovo do kraja dana. Prođe još jedan dan, i sve dok ne budete pribijeni uza zid i prisiljeni s nekim razgovarati, ovo se nastavlja. Čovjek želi sam riješiti problem, vjeruje da će to biti veliki neuspjeh ako ga sam ne riješi.

Zato je programeri su prenapuhali procjene. Bila je ta ista anegdota, kad su razgovarali o nekom zadatku, dali su mi takvu cifru da sam se jako iznenadio. Na što mi je rečeno da u procjenu programera programer uključuje vrijeme koje će karta biti vraćena iz QA-a, jer će tamo pronaći greške, vrijeme koje će trajati PR i vrijeme dok ljudi koji bi trebali pregledati bit će zauzeto - to jest, sve, što god je moguće.

Drugo, ljudi koji se boje ispasti nesposobni pretjerano analizirati. Kad kažete što točno treba učiniti, počinje: “Ne, što ako o tome razmišljamo ovdje?” U tom smislu naša tvrtka nije jedinstvena, to je standardni problem mladih ljudi.

Kao odgovor, uveo sam sljedeće prakse:

• Pravilo 30 minuta. Ako ne možete riješiti problem u pola sata, zamolite nekoga da vam pomogne. Ovo funkcionira s različitim stupnjevima uspjeha, jer ljudi još uvijek ne pitaju, ali barem je proces započeo.
• Eliminirajte sve osim suštine, u procjeni roka dovršetka zadatka, odnosno uzmite u obzir samo koliko će vremena trajati pisanje koda.
• Cjeloživotno učenje za one koji pretjerano analiziraju. To je samo stalni rad s ljudima.

Dan šezdeseti

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

Posebno je zanimljiv bio račun za usluge u oblaku. Vjerujem da su glavni razlog visokog računa za oblak programeri koji po prvi put u životu imaju neograničen pristup poslužiteljima. Ne trebaju pitati: "Molim te, daj mi testni poslužitelj", mogu ga preuzeti sami. Osim toga, programeri uvijek žele izgraditi tako cool sustav da će Facebook i Netflix biti ljubomorni.

Ali programeri nemaju iskustva u kupnji poslužitelja i vještine određivanja potrebne veličine poslužitelja, jer im to prije nije bilo potrebno. I obično ne razumiju baš razliku između skalabilnosti i performansi.

Rezultati popisa:

• Napustili smo isti podatkovni centar.
• Raskinuli smo ugovor sa 3 log servisa. Budući da smo ih imali 5 - svaki programer koji se počeo igrati s nečim uzeo je novi.
• Isključeno je 7 AMS sustava. Opet, nitko nije zaustavio mrtve projekte, svi su nastavili raditi.
• Smanjeni troškovi softvera za 6 puta.

Dan sedamdeset peti

Vrijeme je prolazilo, a za dva i pol mjeseca trebao sam se sastati s upravnim odborom. Naš upravni odbor nije ni bolji ni lošiji od drugih; kao i svi upravni odbori, želi sve znati. Ljudi ulažu novac i žele razumjeti koliko se ono što radimo uklapa u postavljene KPI-ove.

Upravni odbor svakog mjeseca dobiva mnoštvo informacija: broj korisnika, njihov rast, koje usluge koriste i kako, performanse i produktivnost te na kraju prosječnu brzinu učitavanja stranica.

Jedini problem je što vjerujem da je prosjek čisto zlo. Ali to je vrlo teško objasniti upravnom odboru. Oni su navikli raditi s agregiranim brojevima, a ne, na primjer, rasporedom vremena učitavanja po sekundi.

Bilo je nekoliko zanimljivih točaka u vezi s tim. Na primjer, rekao sam da moramo podijeliti promet između zasebnih web poslužitelja ovisno o vrsti sadržaja.

Odnosno, ColdFusion prolazi kroz Jetty i nginx i pokreće stranice. A slike, JS i CSS prolaze kroz zaseban nginx s vlastitim konfiguracijama. Ovo je prilično standardna praksa o kojoj govorim napisao sam prije nekoliko godina. Kao rezultat toga, slike se učitavaju puno brže, a... prosječna brzina učitavanja porasla je za 200 ms.

To se dogodilo jer je grafikon izgrađen na temelju 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 objasniti upravnom odboru zašto smo nešto napravili, a stvari su se pogoršale za 12 posto?

Dan osamdeset peti

Na kraju trećeg mjeseca shvatila sam da postoji jedna stvar na koju uopće nisam računala: vrijeme. Za sve o čemu sam govorio potrebno je vrijeme.

Ovo je moj pravi tjedni kalendar - samo radni tjedan, bez puno posla. Nema dovoljno vremena za sve. Stoga, opet, trebate zaposliti ljude koji će vam pomoći da se nosite s problemima.

Zaključak

To nije sve. U ovoj priči nisam došao niti do toga kako smo radili s proizvodom i pokušavali se uklopiti u opći val, niti kako smo integrirali tehničku podršku, niti kako smo rješavali druge tehničke probleme. Na primjer, sasvim sam slučajno saznao da na najvećim tablicama u bazi ne koristimo SEQUENCE. Imamo samonapisanu funkciju nextID, i ne koristi se u transakciji.

Bilo je još milijun sličnih stvari o kojima bismo mogli dugo pričati. Ali ono najvažnije što još treba reći je kultura.

Kultura ili nedostatak kulture je ono što dovodi do svih ostalih problema. Pokušavamo izgraditi kulturu u kojoj ljudi:

• ne boje se neuspjeha;
• učiti iz grešaka;
• surađivati ​​s drugim timovima;
• preuzeti inicijativu;
• Preuzmi odgovornost;
• pozdraviti rezultat kao cilj;
• slaveći uspjeh.

S ovim će doći i sve ostalo.

Leon Vatra na twitteru, facebook i srednji.

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

Izvor: www.habr.com