Je známe, že spôsobilosť ČTÚ sa testuje až pri druhom výkone tejto úlohy. Pretože jedna vec je pracovať vo firme niekoľko rokov, vyvíjať sa s ňou a byť v rovnakom kultúrnom kontexte postupne preberať väčšiu zodpovednosť. A úplne iné je dostať sa priamo do pozície technického riaditeľa v spoločnosti so starou batožinou a množstvom problémov úhľadne zametených pod koberec.

V tomto zmysle skúsenosť Leona Fire, o ktorú sa podelil ďalej DevOpsConf, nie práve jedinečný, no znásobený jeho skúsenosťami a množstvom rôznych rolí, ktoré si stihol v priebehu 20 rokov vyskúšať, je veľmi užitočný. Pod strihom je chronológia udalostí za 90 dní a množstvo príbehov, na ktorých je zábavné sa zasmiať, keď sa stanú niekomu inému, ale nie je také zábavné čeliť im osobne.

Leon hovorí po rusky veľmi farebne, takže ak máte 35-40 minút, odporúčam pozrieť si video. Textová verzia pre úsporu času nižšie.

Prvou verziou správy bol dobre štruktúrovaný popis práce s ľuďmi a procesmi, ktorý obsahoval užitočné odporúčania. Neprezradila však všetky prekvapenia, ktoré sa na ceste stretli. Preto som zmenil formát a prezentoval problémy, ktoré sa predo mnou vynorili ako jack-in-the-box v novej spoločnosti, a spôsoby ich riešenia v chronologickom poradí.

Pred mesiacom

Ako mnoho dobrých príbehov, aj tento začal alkoholom. Sedeli sme s kamarátmi v bare a podľa očakávania medzi IT špecialistami každý plakal nad svojimi problémami. Jeden z nich práve zmenil prácu a hovoril o svojich problémoch s technológiou, s ľuďmi a s tímom. Čím viac som počúval, tým viac som si uvedomoval, že by ma mal jednoducho zamestnať, pretože toto sú typy problémov, ktoré riešim posledných 15 rokov. Povedal som mu to a na druhý deň sme sa stretli v pracovnom prostredí. Spoločnosť sa volala Teaching Strategies.

Teaching Strategies je lídrom na trhu v oblasti učebných osnov pre veľmi malé deti od narodenia do troch rokov. Tradičná „papierová“ spoločnosť má už 40 rokov a digitálna SaaS verzia platformy 10. Relatívne nedávno sa začal proces prispôsobovania digitálnej technológie firemným štandardom. „Nová“ verzia bola uvedená na trh v roku 2017 a bola takmer ako stará, len fungovala horšie.

Najzaujímavejšie je, že návštevnosť tejto spoločnosti je veľmi predvídateľná – zo dňa na deň, z roka na rok môžete veľmi jasne predpovedať, koľko ľudí príde a kedy. Napríklad medzi 13. a 15. hodinou idú všetky deti v materských školách spať a učitelia začínajú zadávať informácie. A to sa deje každý deň, okrem víkendov, pretože cez víkendy takmer nikto nepracuje.

Keď sa pozriem trochu dopredu, všimnem si, že som začal pracovať v období najvyššej ročnej návštevnosti, čo je zaujímavé z rôznych dôvodov.

Platforma, ktorá sa zdala byť stará len 2 roky, mala zvláštny zásobník: ColdFusion & SQL Server z roku 2008. ColdFusion, ak neviete a s najväčšou pravdepodobnosťou neviete, je podnikový PHP, ktorý vyšiel v polovici 90-tych rokov a odvtedy som o ňom ani nepočul. Tiež tam boli: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ale hlavný monolit bežal na ColdFusion a SQL Server.

Problémy

Čím viac som sa s pracovníkmi spoločnosti rozprával o práci a o problémoch, ktoré sa vyskytli, tým viac som si uvedomoval, že problémy nie sú len technického charakteru. Dobre, technológia je stará - a nepracovali na nej, ale vyskytli sa problémy s tímom a procesmi a spoločnosť to začala chápať.

Tradične ich technici sedeli v rohu a robili nejakú prácu. Ale čoraz viac biznisu začalo prechádzať cez digitálnu verziu. Posledný rok pred mojím nástupom sa preto v spoločnosti objavili noví: predstavenstvo, CTO, CPO a QA director. To znamená, že spoločnosť začala investovať do technologického sektora.

Stopy ťažkého dedičstva neboli len v systémoch. Spoločnosť mala staré procesy, starých ľudí, starú kultúru. Toto všetko bolo potrebné zmeniť. Myslel som si, že to rozhodne nebude nuda a rozhodol som sa to skúsiť.

Dva dni predtým

Dva dni pred nástupom do novej práce som prišiel do kancelárie, vyplnil posledné papiere, stretol sa s tímom a zistil som, že tím v tom čase zápasil s problémom. Išlo o to, že priemerný čas načítania stránky vyskočil na 4 sekundy, teda 2-krát.

Súdiac podľa grafu, niečo sa jasne stalo a nie je jasné, čo. Ukázalo sa, že problémom bola latencia siete v dátovom centre: latencia 5 ms v dátovom centre sa pre používateľov zmenila na 2 s. Nevedel som, prečo sa to stalo, ale v každom prípade sa ukázalo, že problém bol v dátovom centre.

Deň prvý

Prešli dva dni a v prvý deň v práci som zistil, že problém nezmizol.

Počas dvoch dní sa stránky používateľov načítali v priemere za 4 sekundy. Pýtam sa, či zistili, v čom je problém.

- Áno, otvorili sme lístok.
- A?
- No, ešte nám neodpovedali.

Potom som si uvedomil, že všetko, o čom mi predtým hovorili, bola len malá špička ľadovca, s ktorou som musel bojovať.

Existuje dobrý citát, ktorý sa k tomu veľmi hodí:

"Niekedy, ak chcete zmeniť technológiu, musíte zmeniť organizáciu."

No keďže som do práce nastúpil v najrušnejšom období roka, musel som sa pozrieť na obe možnosti riešenia problému: rýchle aj dlhodobé. A začnite tým, čo je kritické práve teraz.

Deň tretí

Načítanie teda trvá 4 sekundy a od 13 do 15 najväčších vrcholov.

Na tretí deň v tomto časovom období vyzerala rýchlosť sťahovania takto:

Z môjho pohľadu nefungovalo vôbec nič. Z pohľadu všetkých ostatných to bežalo trochu pomalšie ako zvyčajne. Ale to sa tak jednoducho nestáva – je to vážny problém.

Snažil som sa presvedčiť tím, na čo odpovedali, že jednoducho potrebujú viac serverov. To je, samozrejme, riešenie problému, no nie vždy jediné a najefektívnejšie. Pýtal som sa, prečo nie je dostatok serverov, aký bol objem prevádzky. Extrapoloval som údaje a zistil som, že máme približne 150 požiadaviek za sekundu, čo je v zásade v rozumných medziach.

Nesmieme však zabúdať, že kým dostanete správnu odpoveď, musíte si položiť správnu otázku. Moja ďalšia otázka bola: koľko máme frontend serverov? Odpoveď „trochu ma zmiatla“ – mali sme 17 frontend serverov!

— Hanbím sa opýtať, ale 150 delené 17 dáva asi 8? Chcete povedať, že každý server umožňuje 8 požiadaviek za sekundu, a ak zajtra bude 160 požiadaviek za sekundu, budeme potrebovať ďalšie 2 servery?

Samozrejme, nepotrebovali sme ďalšie servery. Riešenie bolo v samotnom kóde a na povrchu:

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

Bola tam funkcia getCurrentClass(), pretože všetko na stránke funguje v kontexte triedy – je to tak. A pre túto jednu funkciu na každej stránke boli 200+ žiadostí.

Riešenie týmto spôsobom bolo veľmi jednoduché, ani ste nemuseli nič prepisovať: jednoducho už nežiadajte o tie isté informácie.

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

Bol som veľmi šťastný, pretože som sa rozhodol, že až na tretí deň som našiel hlavný problém. Aj keď som bol naivný, toto bol len jeden z mnohých problémov.

Ale vyriešením tohto prvého problému sa graf znížil oveľa nižšie.

Zároveň sme robili ďalšie optimalizácie. V dohľade bolo veľa vecí, ktoré sa dali opraviť. Napríklad v ten istý tretí deň som zistil, že v systéme predsa len je cache (najskôr som si myslel, že všetky požiadavky prichádzajú priamo z databázy). Keď myslím na kešku, myslím na štandardný Redis alebo Memcached. Ale bol som jediný, kto si to myslel, pretože tento systém používal na ukladanie do vyrovnávacej pamäte MongoDB a SQL Server - ten istý, z ktorého sa práve čítali údaje.

Desiaty deň

Prvý týždeň som riešil problémy, ktoré bolo potrebné vyriešiť práve teraz. Niekde v druhom týždni som prvýkrát prišiel na stand-up komunikovať s tímom, pozrieť sa, čo sa deje a ako celý proces prebieha.

Opäť sa objavilo niečo zaujímavé. Tím tvorilo: 18 vývojárov; 8 testerov; 3 manažéri; 2 architekti. A všetci sa zúčastnili spoločných rituálov, to znamená, že každé ráno prišlo na stand-up viac ako 30 ľudí a povedali, čo robili. Je jasné, že stretnutie netrvalo 5 ani 15 minút. Nikto nikoho nepočúval, pretože každý pracuje na iných systémoch. V tejto forme už 2-3 lístky na hodinu na úpravu boli dobrým výsledkom.

Prvá vec, ktorú sme urobili, bolo rozdelenie tímu do niekoľkých produktových radov. Pre rôzne sekcie a systémy sme pridelili samostatné tímy, ktoré zahŕňali vývojárov, testerov, produktových manažérov a obchodných analytikov.

V dôsledku toho sme dostali:

• Obmedzenie stand-upov a mítingov.
• Znalosť predmetu o produkte.
• Pocit vlastníctva. Keď sa ľudia neustále hrabali v systémoch, vedeli, že s ich chybami bude s najväčšou pravdepodobnosťou musieť pracovať niekto iný, ale nie oni sami.
• Spolupráca medzi skupinami. Netreba dodávať, že QA predtým veľa nekomunikovalo s programátormi, produkt si robil svoje veci atď. Teraz majú spoločný bod zodpovednosti.

Zamerali sme sa najmä na efektivitu, produktivitu a kvalitu – to sú problémy, ktoré sme sa snažili riešiť transformáciou tímu.

Deň jedenásty

V procese zmeny štruktúry tímu som zistil, ako počítať PríbehBody. 1 SP sa rovnal jednému dňu a každý tiket obsahoval SP na vývoj aj QA, teda aspoň 2 SP.

Ako som to zistil?

Našli sme chybu: v jednom z prehľadov, kde je zadaný dátum začiatku a konca obdobia, na ktoré je prehľad potrebný, sa neberie do úvahy posledný deň. To znamená, že niekde v požiadavke nebolo <=, ale jednoducho <. Bolo mi povedané, že toto sú tri Story Points 3 dni.

Po tomto sme:

• Systém hodnotenia Story Points bol revidovaný. Opravy menších chýb, ktoré je možné rýchlo preniesť cez systém, sa teraz dostanú k používateľovi rýchlejšie.
• Začali sme spájať súvisiace lístky na vývoj a testovanie. Predtým bol každý lístok, každá chyba uzavretým ekosystémom, ktorý nebol viazaný na nič iné. Výmenou troch tlačidiel na jednej stránke mohli byť tri rôzne lístky s tromi rôznymi procesmi kontroly kvality namiesto jedného automatického testu na stránku.
• Začali sme spolupracovať s vývojármi na prístupe k odhadu nákladov práce. Tri dni na výmenu jedného tlačidla nie je sranda.

Deň dvadsiaty

Niekde v polovici prvého mesiaca sa situácia trochu stabilizovala, prišiel som na to, čo sa v podstate deje, a už som sa začal pozerať do budúcnosti a rozmýšľať nad dlhodobými riešeniami.

Dlhodobé ciele:

• Spravovaná platforma. Stovky žiadostí na každej stránke nie sú vážne.
• Predvídateľné trendy. Dochádzalo k periodickým špičkám návštevnosti, ktoré na prvý pohľad nekorelovali s inými metrikami – potrebovali sme pochopiť, prečo k tomu došlo, a naučiť sa predpovedať.
• Rozšírenie platformy. Biznis neustále rastie, prichádza stále viac používateľov a zvyšuje sa návštevnosť.

V minulosti sa často hovorilo: „Prepíšme všetko do [jazyka/rámca], všetko bude fungovať lepšie!“

Vo väčšine prípadov to nefunguje, je dobré, ak prepis vôbec funguje. Preto sme potrebovali vytvoriť cestovnú mapu – špecifickú stratégiu, ktorá bude krok za krokom ilustrovať, ako sa budú dosahovať obchodné ciele (čo budeme robiť a prečo), ktorá:

• odráža poslanie a ciele projektu;
• uprednostňuje hlavné ciele;
• obsahuje harmonogram ich dosiahnutia.

Predtým nikto s tímom nehovoril o účele vykonaných zmien. Vyžaduje si to správne metriky úspechu. Prvýkrát v histórii spoločnosti sme nastavili KPI pre technickú skupinu a tieto ukazovatele boli prepojené s organizačnými.

To znamená, že organizačné KPI podporujú tímy a tímové KPI podporujú jednotlivé KPI. Inak, ak sa technologické KPI nezhodujú s organizačnými, tak každý ťahá deku na seba.

Napríklad jedným z organizačných KPI je zvyšovanie podielu na trhu prostredníctvom nových produktov.

Ako môžete podporiť cieľ mať viac nových produktov?

• Po prvé, chceme tráviť viac času vývojom nových produktov namiesto odstraňovania chýb. Ide o logické riešenie, ktoré sa ľahko meria.
• Po druhé, chceme podporiť zvýšenie objemu transakcií, pretože čím väčší podiel na trhu, tým viac používateľov, a teda aj väčšia návštevnosť.

Potom budú jednotlivé KPI, ktoré možno vykonať v rámci skupiny, napríklad na mieste, odkiaľ pochádzajú hlavné chyby. Ak sa zameriate špeciálne na túto časť, môžete sa uistiť, že je tam oveľa menej defektov a potom sa zvýši čas na vývoj nových produktov a opäť na podporu organizačných KPI.

Každé rozhodnutie, vrátane prepisovania kódu, teda musí podporovať konkrétne ciele, ktoré nám spoločnosť stanovila (organizačný rast, nové funkcie, nábor).

Počas tohto procesu vyšla najavo zaujímavá vec, ktorá sa stala novinkou nielen pre technikov, ale celkovo v spoločnosti: všetky vstupenky musia byť zamerané aspoň na jeden KPI. To znamená, že ak produkt hovorí, že chce vytvoriť novú funkciu, mala by sa položiť prvá otázka: „Aký KPI ​​táto funkcia podporuje? Ak nie, tak prepáčte – zdá sa to ako zbytočná funkcia.

Deň tridsiaty

Na konci mesiaca som objavil ďalšiu nuansu: nikto z môjho tímu Ops nikdy nevidel zmluvy, ktoré uzatvárame s klientmi. Môžete sa opýtať, prečo potrebujete vidieť kontakty.

• Po prvé, pretože SLA sú špecifikované v zmluvách.
• Po druhé, všetky zmluvy SLA sú odlišné. Každý klient prišiel s vlastnými požiadavkami a obchodné oddelenie podpísalo bez toho, aby sa pozrelo.

Ďalšou zaujímavou nuansou je, že zmluva s jedným z najväčších klientov uvádza, že všetky verzie softvéru podporované platformou musia byť n-1, teda nie najnovšia, ale predposledná.

Je jasné, ako ďaleko sme boli od n-1, ak bola platforma založená na ColdFusion a SQL Server 2008, ktorý už v júli nebol vôbec podporovaný.

Deň štyridsaťpäť

Okolo polovice druhého mesiaca som mal dosť času sadnúť si a robiť hodnotuprúdmapovanie úplne pre celý proces. Toto sú nevyhnutné kroky, ktoré je potrebné podniknúť od vytvorenia produktu až po jeho dodanie spotrebiteľovi a je potrebné ich čo najpodrobnejšie popísať.

Rozdelíte proces na malé kúsky a uvidíte, čo zaberá príliš veľa času, čo sa dá optimalizovať, vylepšiť atď. Napríklad, ako dlho trvá, kým žiadosť o produkt prejde groomingom, kedy dosiahne lístok, ktorý môže vývojár prijať, QA atď. Podrobne sa teda pozriete na každý jednotlivý krok a premýšľate, čo sa dá optimalizovať.

Keď som to urobil, upútali ma dve veci:

• vysoké percento lístkov vrátených z kontroly kvality späť vývojárom;
• kontroly žiadosti o stiahnutie trvali príliš dlho.

Problém bol v tom, že to boli závery ako: Zdá sa, že to trvá veľa času, ale nie sme si istí, ako dlho.

"Nemôžete zlepšiť to, čo nemôžete zmerať."

Ako zdôvodniť, aký vážny je problém? Stráca dni alebo hodiny?

Aby sme to zmerali, pridali sme do procesu Jira niekoľko krokov: „pripravený na vývoj“ a „pripravený na kontrolu kvality“, aby sme zmerali, ako dlho každý lístok čaká a koľkokrát sa vráti do určitého kroku.

Pridali sme aj „in review“, aby sme vedeli, koľko lístkov je v priemere na kontrolu, a z toho môžete začať tancovať. Mali sme systémové metriky, teraz sme pridali nové metriky a začali merať:

• Efektivita procesu: plnenie a plánované/dodané.
• Kvalita procesu: počet závad, závad z QA.

Naozaj pomáha pochopiť, čo sa darí a čo nie.

Deň päťdesiaty

To je všetko, samozrejme, dobré a zaujímavé, ale ku koncu druhého mesiaca sa stalo niečo, čo sa v zásade dalo predvídať, hoci som nečakal taký rozsah. Ľudia začali odchádzať, pretože sa zmenilo vrcholové vedenie. Do vedenia prišli noví ľudia a začali všetko meniť a tí starí odišli. A väčšinou vo firme, ktorá má niekoľko rokov, sú všetci kamaráti a všetci sa poznajú.

Očakávalo sa to, ale rozsah prepúšťania bol neočakávaný. Napríklad počas jedného týždňa dvaja vedúci tímu súčasne podali rezignáciu z vlastnej slobodnej vôle. Preto som musel nielen zabudnúť na iné problémy, ale sústrediť sa na vytvorenie tímu. Toto je dlhý a ťažko riešiteľný problém, ale bolo potrebné ho riešiť, pretože som chcel zachrániť ľudí, ktorí zostali (alebo väčšinu z nich). Na to, že ľudia odišli, bolo treba nejako reagovať, aby sa udržala morálka v tíme.

Teoreticky je to dobré: príde nový človek, ktorý má úplnú voľnosť, ktorý dokáže zhodnotiť schopnosti tímu a nahradiť personál. V skutočnosti nemôžete len priviesť nových ľudí z toľkých dôvodov. Rovnováha je vždy potrebná.

• Staré aj nové. Potrebujeme si udržať starých ľudí, ktorí sa môžu zmeniť a podporovať poslanie. Zároveň však musíme priniesť novú krv, o tom si povieme o niečo neskôr.
• Skúsenosti. Veľa som sa rozprával s dobrými juniormi, ktorí boli horliví a chceli s nami pracovať. Ale nemohol som ich prijať, pretože nebolo dosť seniorov, ktorí by juniorov podporovali a pôsobili ako ich mentori. Bolo treba najskôr naverbovať vrchol a až potom mládež.
• Mrkva a palica.

Na otázku, aká je správna rovnováha, ako ju udržiavať, koľko ľudí držať a koľko tlačiť, nemám dobrú odpoveď. Ide o čisto individuálny proces.

Deň päťdesiat jeden

Začal som sa pozorne pozerať na tím, aby som pochopil, koho mám, a opäť som si spomenul:

"Väčšina problémov sú problémy ľudí."

Zistil som, že tím ako taký – vývojár aj operačný – má tri veľké problémy:

• Spokojnosť so súčasným stavom.
• Nedostatok zodpovednosti - pretože nikto nikdy nepriniesol výsledky práce výkonných umelcov, aby ovplyvnili obchod.
• Strach zo zmeny.

Zmena vás vždy vyvedie z vašej komfortnej zóny a čím sú ľudia mladší, tým viac sa im zmeny nepáčia, pretože nerozumejú prečo a nechápu ako. Najčastejšia odpoveď, ktorú som počul, je: "Nikdy sme to nerobili." Navyše to dosiahlo bod úplnej absurdity – tie najmenšie zmeny sa nemohli udiať bez toho, aby to niekto nebol rozhorčený. A bez ohľadu na to, ako veľmi zmeny ovplyvnili ich prácu, ľudia povedali: „Nie, prečo? Toto nebude fungovať."

Ale nemôžete sa zlepšiť bez toho, aby ste niečo zmenili.

Mal som absolútne absurdný rozhovor so zamestnancom, povedal som mu svoje nápady na optimalizáciu, na čo mi povedal:
- Ach, nevideli ste, čo sme mali minulý rok!
- No a čo?
"Teraz je to oveľa lepšie ako to bolo."
- Takže to nemôže byť lepšie?
- Za čo?

Dobrá otázka - prečo? Je to, ako keby to bolo teraz lepšie ako to bolo, potom je všetko dosť dobré. To vedie k nedostatku zodpovednosti, čo je v zásade úplne normálne. Ako som povedal, technická skupina bola trochu na vedľajšej koľaji. Spoločnosť verila, že by mali existovať, ale nikto nikdy nestanovil normy. Technická podpora nikdy nevidela SLA, takže to bolo pre skupinu celkom „prijateľné“ (a toto ma zasiahlo najviac):

• načítanie 12 sekúnd;
• 5-10 minút odstávky pri každom uvoľnení;
• Riešenie kritických problémov trvá dni a týždne;
• nedostatok personálu 24x7 / na zavolanie.

Nikto sa nikdy nepokúsil opýtať, prečo to neurobíme lepšie, a nikto si nikdy neuvedomil, že to tak nemusí byť.

Ako bonus bol ešte jeden problém: nedostatok skúseností. Seniori odišli a zvyšné mladé mužstvo vyrástlo za minulého režimu a bolo z toho otrávené.

Okrem toho sa ľudia báli zlyhania a prejavu nekompetentnosti. To je vyjadrené v tom, že po prvé, oni za žiadnych okolností nepožiadal o pomoc. Koľkokrát sme sa rozprávali ako skupina a jednotlivo a ja som povedal: „Spýtajte sa, ak neviete, ako niečo urobiť. Som si istý a viem, že dokážem vyriešiť akýkoľvek problém, ale bude to chvíľu trvať. Preto ak sa môžem opýtať niekoho, kto to vie vyriešiť za 10 minút, tak sa opýtam. Čím menej skúseností máte, tým viac sa bojíte opýtať, pretože si myslíte, že vás budú považovať za neschopného.

Tento strach z kladenia otázok sa prejavuje zaujímavými spôsobmi. Napríklad sa pýtate: „Ako sa vám darí s touto úlohou? - "Ešte pár hodín, už končím." Na druhý deň sa opýtate znova, dostanete odpoveď, že všetko je v poriadku, no bol tu jeden problém, do konca dňa to bude určite hotové. Uplynie ďalší deň a kým nie ste pritlačení k stene a donútení sa s niekým porozprávať, pokračuje to. Človek chce problém vyriešiť sám, verí, že ak ho nevyrieši sám, bude to veľké zlyhanie.

Preto разработчики завышали оценки. Bola to tá istá anekdota, keď diskutovali o určitej úlohe, dali mi taký údaj, že som bol veľmi prekvapený. Na čo mi bolo povedané, že do odhadov developera developer započítava čas, kedy sa tiket vráti z QA, pretože tam nájdu chyby, a čas, ktorý zaberie PR a čas, kým ľudia, ktorí by mali skontrolovať bude rušno - teda všetko, čo je možné.

Po druhé, ľudia, ktorí sa boja, že budú pôsobiť neschopne nadmerne analyzovať. Keď poviete, čo presne treba urobiť, začne to: „Nie, čo keby sme o tom premýšľali tu?“ V tomto zmysle nie je naša spoločnosť jedinečná, to je štandardný problém mladých ľudí.

V reakcii na to som zaviedol nasledujúce postupy:

• Pravidlo 30 minút. Ak nemôžete vyriešiť problém do pol hodiny, požiadajte niekoho, aby vám pomohol. Funguje to s rôznym stupňom úspechu, pretože ľudia sa stále nepýtajú, ale proces sa aspoň začal.
• Odstráňte všetko okrem podstaty, pri odhadovaní termínu dokončenia úlohy, teda zvážte len to, ako dlho bude trvať napísanie kódu.
• Neustále učenie pre tých, ktorí príliš analyzujú. Je to len neustála práca s ľuďmi.

Deň šesťdesiaty

Kým som to všetko robil, nastal čas vybaviť rozpočet. V tom, kde sme míňali peniaze, som samozrejme našiel veľa zaujímavých vecí. Napríklad sme mali celý rack v samostatnom dátovom centre s jedným FTP serverom, ktorý využíval jeden klient. Ukázalo sa, že "...presťahovali sme sa, ale on zostal taký, nezmenili sme ho." Bolo to pred 2 rokmi.

Zaujímavý bol najmä účet za cloudové služby. Domnievam sa, že hlavným dôvodom vysokého účtu za cloud sú vývojári, ktorí majú prvýkrát v živote neobmedzený prístup k serverom. Nemusia sa pýtať: „Prosím, dajte mi testovací server,“ môžu si ho vziať sami. Navyše, vývojári chcú vždy vybudovať taký skvelý systém, že Facebook a Netflix budú žiarliť.

Vývojári však nemajú skúsenosti s nákupom serverov a schopnosť určiť požadovanú veľkosť serverov, pretože to predtým nepotrebovali. A zvyčajne celkom nerozumejú rozdielu medzi škálovateľnosťou a výkonom.

Výsledky inventára:

• Opustili sme rovnaké dátové centrum.
• Zmluvu sme ukončili s 3 log službami. Pretože sme ich mali 5 – každý vývojár, ktorý sa začal s niečím hrať, si vzal nový.
• 7 systémov AWS bolo vypnutých. Opäť nikto nezastavil mŕtve projekty, všetci pokračovali v práci.
• Šesťnásobné zníženie nákladov na softvér.

Deň sedemdesiaty piaty

Čas plynul a o dva a pol mesiaca som sa musel stretnúť s predstavenstvom. Naša správna rada nie je o nič lepšia alebo horšia ako ostatné, ako každá správna rada chce vedieť všetko. Ľudia investujú peniaze a chcú pochopiť, do akej miery to, čo robíme, zapadá do stanovených KPI.

Predstavenstvo dostáva každý mesiac množstvo informácií: počet používateľov, ich rast, aké služby a ako využívajú, výkon a produktivitu a napokon aj priemernú rýchlosť načítania stránok.

Jediný problém je, že verím, že priemer je čisté zlo. Ale to je veľmi ťažké vysvetliť predstavenstvu. Sú zvyknutí pracovať s agregovanými číslami, a nie napríklad s rozložením časov načítania za sekundu.

V tejto súvislosti bolo niekoľko zaujímavých bodov. Napríklad som povedal, že musíme rozdeliť prevádzku medzi samostatné webové servery v závislosti od typu obsahu.

To znamená, že ColdFusion prechádza cez Jetty a nginx a spúšťa stránky. A obrázky, JS a CSS prechádzajú samostatným nginx s vlastnými konfiguráciami. Toto je celkom štandardná prax, o ktorej hovorím napísal som pred pár rokmi. V dôsledku toho sa obrázky načítavajú oveľa rýchlejšie a... priemerná rýchlosť načítania sa zvýšila o 200 ms.

Stalo sa to preto, že graf je zostavený na základe údajov, ktoré sa dodávajú s Jetty. To znamená, že rýchly obsah nie je zahrnutý do výpočtu - priemerná hodnota vyskočila. To nám bolo jasné, zasmiali sme sa, ale ako vysvetliť predstavenstvu, prečo sme niečo urobili a veci sa zhoršili o 12 %?

Deň osemdesiaty piaty

Na konci tretieho mesiaca som si uvedomil, že je tu jedna vec, s ktorou som vôbec nerátal: čas. Všetko, o čom som hovoril, si vyžaduje čas.

Toto je môj skutočný týždenný kalendár - len pracovný týždeň, nie veľmi zaneprázdnený. Na všetko nie je dostatok času. Preto opäť musíte získať ľudí, ktorí vám pomôžu vyrovnať sa s problémami.

Záver

To nie je všetko. V tomto príbehu som sa ani nedostal k tomu, ako sme s produktom pracovali a snažili sa naladiť na všeobecnú vlnu, ani ako sme integrovali technickú podporu, či ako sme riešili iné technické problémy. Napríklad som sa celkom náhodou dozvedel, že na najväčších tabuľkách v databáze, ktoré nepoužívame SEQUENCE. Máme samopísanú funkciu nextIDa nepoužíva sa pri transakcii.

Podobných vecí, o ktorých by sme sa mohli dlho baviť, bolo ešte milión. Ale to najdôležitejšie, čo treba ešte povedať, je kultúra.

Je to kultúra alebo jej nedostatok, ktorý vedie k všetkým ostatným problémom. Snažíme sa vybudovať kultúru, kde ľudia:

• nebojí sa zlyhania;
• poučiť sa z chýb;
• spolupracovať s inými tímami;
• prevziať iniciatívu;
• prevziať zodpovednosť;
• privítať výsledok ako cieľ;
• oslavuje úspech.

S týmto príde všetko ostatné.

Leon Fire na twitteri, facebook a strednou.

Existujú dve stratégie týkajúce sa dedičstva: vyhnúť sa práci s ním za každú cenu alebo statočne prekonať súvisiace ťažkosti. My c DevOpsConf Ideme druhou cestou, meníme procesy a prístupy. Pridajte sa k nám youtube, newsletter и telegrama spoločne zavedieme kultúru DevOps.

Zdroj: hab.com