Je známo, že způsobilost ČTÚ je prověřována až při druhém výkonu této role. Protože jedna věc je pracovat ve firmě několik let, vyvíjet se s ní a být ve stejném kulturním kontextu postupně přijímat větší zodpovědnost. A něco úplně jiného je nastoupit rovnou do pozice technického ředitele ve společnosti se staršími zavazadly a spoustou problémů úhledně zametených pod koberec.

V tomto smyslu zkušenost Leona Fire, o kterou se podělil DevOpsConf, ne zrovna ojedinělý, ale znásobený jeho zkušenostmi a množstvím různých rolí, které si během 20 let stihl vyzkoušet, je velmi užitečný. Pod sestřihem je chronologie událostí za 90 dní a spousta příběhů, kterým je zábavné se zasmát, když se přihodí někomu jinému, ale které není tak zábavné čelit osobně.

Leon mluví rusky velmi barvitě, takže pokud máte 35-40 minut, doporučuji zhlédnout video. Textová verze pro úsporu času níže.

První verzí zprávy byl dobře strukturovaný popis práce s lidmi a procesy, obsahující užitečná doporučení. Neprozradila však všechna překvapení, která se cestou setkala. Změnil jsem proto formát a představil problémy, které se přede mnou objevily jako jack-in-the-box v nové společnosti, a způsoby jejich řešení v chronologickém pořadí.

Před měsícem

Jako mnoho dobrých příběhů, i tento začal alkoholem. Seděli jsme s přáteli v baru a podle očekávání mezi IT specialisty všichni plakali nad svými problémy. Jeden z nich právě změnil práci a mluvil o svých problémech s technologií, s lidmi a s týmem. Čím víc jsem poslouchal, tím víc jsem si uvědomoval, že by mě měl prostě zaměstnat, protože tohle jsou typy problémů, které řeším posledních 15 let. Řekl jsem mu to a druhý den jsme se potkali v pracovním prostředí. Společnost se jmenovala Teaching Strategies.

Teaching Strategies je lídrem na trhu v oblasti kurikula pro velmi malé děti od narození do tří let. Tradiční „papírová“ společnost má již 40 let, digitální SaaS verze platformy 10. Relativně nedávno začal proces přizpůsobování digitální technologie firemním standardům. „Nová“ verze byla spuštěna v roce 2017 a byla téměř jako ta stará, jen fungovala hůř.

Nejzajímavější je, že provoz této společnosti je velmi předvídatelný – ze dne na den, z roku na rok můžete velmi jasně předvídat, kolik lidí přijde a kdy. Například mezi 13. a 15. hodinou jdou všechny děti ve školkách spát a učitelé začínají zadávat informace. A to se děje každý den, kromě víkendů, protože o víkendech skoro nikdo nepracuje.

Když se podívám trochu dopředu, poznamenám, že jsem začal pracovat v období nejvyšší roční návštěvnosti, což je zajímavé z různých důvodů.

Platforma, která se zdála být pouze 2 roky stará, měla zvláštní zásobník: ColdFusion & SQL Server z roku 2008. ColdFusion, pokud neznáte a s největší pravděpodobností nevíte, je podnikové PHP, které vyšlo v polovině 90. let a od té doby jsem o něm ani neslyšel. Také tam byly: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ale hlavní monolit běžel na ColdFusion a SQL Server.

Problémy

Čím více jsem mluvil se zaměstnanci společnosti o práci ao tom, jaké problémy se vyskytly, tím více jsem si uvědomoval, že problémy nejsou pouze technické povahy. Dobře, technologie je stará - a nepracovali na ní, ale vyskytly se problémy s týmem a procesy a společnost to začala chápat.

Tradičně jejich technici seděli v rohu a dělali nějakou práci. Stále více obchodů však začalo procházet digitální verzí. V posledním roce, než jsem začal pracovat, se proto ve firmě objevili noví: představenstvo, CTO, CPO a QA ředitel. To znamená, že společnost začala investovat do technologického sektoru.

Stopy těžkého dědictví nebyly jen v systémech. Společnost měla staré procesy, staré lidi, starší kulturu. To vše se muselo změnit. Řekl jsem si, že to rozhodně nebude nuda, a rozhodl jsem se to zkusit.

Dva dny předtím

Dva dny před nástupem do nové práce jsem dorazil do kanceláře, vyplnil poslední papíry, seznámil se s týmem a zjistil, že tým se v tu chvíli potýká s problémem. Šlo o to, že průměrná doba načítání stránky vyskočila na 4 sekundy, tedy 2x.

Soudě podle grafu se něco jasně stalo a není jasné co. Ukázalo se, že problémem byla latence sítě v datovém centru: latence 5 ms v datovém centru se pro uživatele změnila na 2 s. Nevěděl jsem, proč se to stalo, ale v každém případě se ukázalo, že problém byl v datovém centru.

Den první

Uběhly dva dny a první den v práci jsem zjistil, že problém nezmizel.

Po dva dny se stránky uživatelů načítaly v průměru za 4 sekundy. Ptám se, jestli zjistili, v čem je problém.

- Ano, otevřeli jsme lístek.
- A?
- No, ještě nám neodpověděli.

Pak jsem si uvědomil, že všechno, o čem mi předtím řekli, byla jen malá špička ledovce, se kterou jsem musel bojovat.

Existuje dobrý citát, který se k tomu velmi hodí:

"Někdy ke změně technologie musíte změnit organizaci."

Jelikož jsem ale do práce nastupoval v nejrušnějším období roku, musel jsem se podívat na obě možnosti řešení problému: jak rychlé, tak dlouhodobé. A začněte tím, co je kritické právě teď.

Den třetí

Načítání tedy trvá 4 sekundy a od 13 do 15 největších vrcholů.

Třetí den v tomto časovém období vypadala rychlost stahování takto:

Z mého pohledu nefungovalo vůbec nic. Z pohledu všech ostatních to běželo trochu pomaleji než obvykle. Ale to se tak prostě nestává – je to vážný problém.

Snažil jsem se přesvědčit tým, na což mi odpověděli, že prostě potřebují více serverů. To je samozřejmě řešení problému, ale ne vždy to jediné a nejúčinnější. Ptal jsem se, proč není dostatek serverů, jaký byl objem provozu. Extrapoloval jsem data a zjistil jsem, že máme přibližně 150 požadavků za sekundu, což v zásadě spadá do rozumných mezí.

Nesmíme ale zapomínat, že než dostanete správnou odpověď, musíte se správně zeptat. Moje další otázka byla: kolik máme frontend serverů? Odpověď „trochu mě zmátla“ – měli jsme 17 frontend serverů!

— Stydím se zeptat, ale 150 děleno 17 dává asi 8? Říkáte, že každý server umožňuje 8 požadavků za sekundu, a pokud zítra bude 160 požadavků za sekundu, budeme potřebovat další 2 servery?

Samozřejmě jsme nepotřebovali další servery. Řešení bylo v samotném kódu a na povrchu:

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

Byla tam funkce getCurrentClass(), protože vše na webu funguje v kontextu třídy – je to tak. A pro tuto jednu funkci na každé stránce byly 200+ žádostí.

Řešení tímto způsobem bylo velmi jednoduché, nemuseli jste ani nic přepisovat: prostě nepožadujte znovu stejné informace.

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

Byl jsem velmi šťastný, protože jsem se rozhodl, že teprve třetí den jsem našel hlavní problém. I když jsem byl naivní, byl to jen jeden z mnoha problémů.

Ale vyřešením tohoto prvního problému klesl graf mnohem níže.

Zároveň jsme prováděli další optimalizace. V dohledu byla spousta věcí, které se daly opravit. Například ten samý třetí den jsem zjistil, že v systému přece jenom cache je (zprvu jsem si myslel, že všechny požadavky přicházejí přímo z databáze). Když myslím na cache, myslím na standardní Redis nebo Memcached. Ale byl jsem jediný, kdo si to myslel, protože tento systém používal pro ukládání do mezipaměti MongoDB a SQL Server - ten samý, ze kterého byla data právě načtena.

Den desátý

První týden jsem řešil problémy, které bylo potřeba vyřešit právě teď. Někde ve druhém týdnu jsem poprvé přišel na stand-up komunikovat s týmem, podívat se, co se děje a jak celý proces probíhá.

Opět se objevilo něco zajímavého. Tým se skládal z: 18 vývojářů; 8 testerů; 3 vedoucí; 2 architekti. A všichni se účastnili společných rituálů, to znamená, že každé ráno přišlo na stand-up více než 30 lidí a řekli, co dělali. Je jasné, že jednání netrvalo 5 ani 15 minut. Nikdo nikoho neposlouchal, protože každý pracuje na jiném systému. V této podobě už byly 2-3 lístky za hodinu na grooming session dobrý výsledek.

První věc, kterou jsme udělali, bylo rozdělení týmu do několika produktových řad. Pro různé sekce a systémy jsme přidělili samostatné týmy, které zahrnovaly vývojáře, testery, produktové manažery a obchodní analytiky.

V důsledku toho jsme dostali:

Omezení stand-upů a rally.
Předmětová znalost produktu.
Pocit vlastnictví. Když se lidé neustále vrtali se systémy, věděli, že s jejich chybami bude nejspíš muset pracovat někdo jiný, ale ne oni sami.
Spolupráce mezi skupinami. Netřeba dodávat, že QA předtím s programátory moc nekomunikovala, produkt dělal svou vlastní věc atd. Nyní mají společný bod odpovědnosti.

Zaměřili jsme se především na efektivitu, produktivitu a kvalitu – to jsou problémy, které jsme se snažili řešit transformací týmu.

Den jedenáctý

V procesu změny struktury týmu jsem zjistil, jak počítat PříběhBody. 1 SP se rovnal jednomu dni a každý tiket obsahoval SP pro vývoj i QA, tedy alespoň 2 SP.

Jak jsem to zjistil?

Zjistili jsme chybu: v jednom z přehledů, kde je zadáno datum začátku a konce období, pro které je přehled potřeba, není zohledněn poslední den. To znamená, že někde v požadavku nebylo <=, ale prostě <. Bylo mi řečeno, že to jsou tři příběhové body 3 dny.

Po tomto jsme:

Systém hodnocení Story Points byl revidován. Opravy drobných chyb, které lze rychle projít systémem, se nyní dostanou k uživateli rychleji.
Začali jsme slučovat související vstupenky pro vývoj a testování. Dříve byla každá vstupenka, každá chyba uzavřeným ekosystémem, který nebyl svázán s ničím jiným. Změna tří tlačítek na jedné stránce mohla být třemi různými lístky se třemi různými procesy kontroly kvality namísto jednoho automatického testu na stránku.
Začali jsme spolupracovat s vývojáři na přístupu k odhadu mzdových nákladů. Tři dny na výměnu jednoho tlačítka není sranda.

Den dvacátý

Někde v polovině prvního měsíce se situace trochu stabilizovala, přišel jsem na to, co se v podstatě děje, a už jsem se začal dívat do budoucnosti a přemýšlet o dlouhodobých řešeních.

Dlouhodobé cíle:

Spravovaná platforma. Stovky požadavků na každé stránce nejsou vážné.
Předvídatelné trendy. Docházelo k periodickým špičkám návštěvnosti, které na první pohled nekorelovaly s jinými metrikami – potřebovali jsme pochopit, proč k tomu došlo, a naučit se předvídat.
Rozšíření platformy. Obchod neustále roste, přichází stále více uživatelů a zvyšuje se návštěvnost.

V minulosti se často říkalo: "Přepišme vše do [jazyka/rámce], všechno bude fungovat lépe!"

Ve většině případů to nefunguje, je dobré, když přepis vůbec funguje. Potřebovali jsme proto vytvořit cestovní mapu – specifickou strategii ilustrující krok za krokem, jak bude dosahováno obchodních cílů (co budeme dělat a proč), která:

odráží poslání a cíle projektu;
upřednostňuje hlavní cíle;
obsahuje harmonogram jejich dosažení.

Předtím s týmem nikdo nemluvil o účelu jakýchkoli provedených změn. To vyžaduje správné metriky úspěchu. Poprvé v historii společnosti jsme nastavili KPI pro technickou skupinu a tyto ukazatele byly svázány s organizačními.

To znamená, že organizační KPI jsou podporovány týmy a týmové KPI jsou podporovány jednotlivými KPI. Jinak pokud se technologická KPI neshodují s organizačními, tak si deku tahá každý sám na sebe.

Jedním z organizačních KPI je například zvyšování podílu na trhu prostřednictvím nových produktů.

Jak můžete podpořit cíl mít více nových produktů?

Za prvé, chceme strávit více času vývojem nových produktů namísto opravování defektů. Jde o logické řešení, které lze snadno měřit.
Zadruhé chceme podpořit nárůst objemu transakcí, protože čím větší podíl na trhu, tím více uživatelů a tím i větší návštěvnost.

Jednotlivé KPI, které lze v rámci skupiny realizovat, pak budou například v místě, odkud pocházejí hlavní závady. Pokud se zaměříte konkrétně na tuto sekci, můžete se ujistit, že je zde mnohem méně defektů, a pak se prodlouží čas na vývoj nových produktů a opět na podporu organizačních KPI.

Každé rozhodnutí, včetně přepisování kódu, tedy musí podporovat konkrétní cíle, které nám společnost stanovila (organizační růst, nové funkce, nábor).

Během tohoto procesu vyšla najevo zajímavá věc, která se stala novinkou nejen pro techniky, ale obecně ve firmě: všechny vstupenky musí být zaměřeny alespoň na jeden KPI. To znamená, že pokud produkt říká, že chce vytvořit novou funkci, měla by být položena první otázka: „Jaký KPI tato funkce podporuje? Pokud ne, tak se omlouvám – zdá se to jako zbytečná funkce.

Den třicátý

Na konci měsíce jsem objevil další nuanci: nikdo z mého týmu Ops nikdy neviděl smlouvy, které uzavíráme s klienty. Můžete se zeptat, proč potřebujete vidět kontakty.

Jednak proto, že SLA jsou specifikovány ve smlouvách.
Za druhé, SLA jsou všechny odlišné. Každý klient přišel s vlastními požadavky a obchodní oddělení podepsalo, aniž by se dívalo.

Další zajímavou nuancí je, že ve smlouvě s jedním z největších klientů je uvedeno, že všech verzí softwaru podporovaných platformou musí být n-1, tedy nikoli nejnovější, ale předposlední.

Je jasné, jak daleko jsme byli od n-1, pokud byla platforma založena na ColdFusion a SQL Server 2008, který v červenci již nebyl vůbec podporován.

Den čtyřicátý pátý

Kolem poloviny druhého měsíce jsem měl dost času si sednout a dělat hodnotaproudmapování úplně za celý proces. Toto jsou nezbytné kroky, které je třeba podniknout, od vytvoření produktu až po jeho dodání spotřebiteli, a je třeba je popsat co nejpodrobněji.

Rozdělíte proces na malé kousky a uvidíte, co zabírá příliš mnoho času, co lze optimalizovat, vylepšit atd. Například, jak dlouho trvá, než požadavek na produkt projde úpravou, kdy dosáhne tiket, který může vývojář vzít, QA atd. Podrobně se tedy podíváte na každý jednotlivý krok a přemýšlíte, co lze optimalizovat.

Když jsem to udělal, zaujaly mě dvě věci:

vysoké procento lístků vrácených z QA zpět vývojářům;
kontroly žádostí o stažení trvaly příliš dlouho.

Problém byl v tom, že to byly závěry typu: Zdá se, že to trvá hodně času, ale nejsme si jisti, jak dlouho.

"Nemůžete zlepšit to, co nemůžete změřit."

Jak zdůvodnit, jak závažný je problém? Ztrácí dny nebo hodiny?

Abychom to změřili, přidali jsme do procesu Jira několik kroků: „připraveno pro vývoj“ a „připraveno pro kontrolu kvality“, abychom změřili, jak dlouho každý lístek čeká a kolikrát se vrátí k určitému kroku.

Také jsme přidali „in review“, abychom věděli, kolik vstupenek je v průměru na kontrolu, a z toho můžete začít tančit. Měli jsme systémové metriky, nyní jsme přidali nové metriky a začali měřit:

Efektivita procesu: plnění a plánované/dodané.
Kvalita procesu: počet závad, závady z QA.

Opravdu pomáhá pochopit, co se daří a co ne.

Den padesátý

To je všechno samozřejmě dobré a zajímavé, ale ke konci druhého měsíce se stalo něco, co se v zásadě dalo předvídat, i když jsem takový rozsah nečekal. Lidé začali odcházet, protože se změnil top management. Do vedení přišli noví lidé a začali vše měnit a ti staří odešli. A většinou ve společnosti, která je stará několik let, jsou všichni přátelé a všichni se znají.

To se očekávalo, ale rozsah propouštění byl neočekávaný. Například během jednoho týdne dva vedoucí týmu současně podali rezignaci z vlastní svobodné vůle. Musel jsem proto nejen zapomenout na další problémy, ale soustředit se na vytvoření týmu. Toto je dlouhý a obtížně řešitelný problém, ale bylo třeba se s ním vypořádat, protože jsem chtěl zachránit lidi, kteří zůstali (nebo většinu z nich). Na to, že lidé odešli, bylo potřeba nějak reagovat, aby se udržela morálka v týmu.

Teoreticky je to dobré: přichází nový člověk, který má úplnou volnou ruku, který může zhodnotit dovednosti týmu a nahradit zaměstnance. Ve skutečnosti nemůžete jen tak přivést nové lidi z tolika důvodů. Rovnováha je vždy potřeba.

Staré i nové. Musíme si udržet staré lidi, kteří se mohou změnit a podpořit misi. Ale zároveň musíme přinést novou krev, o tom si povíme trochu později.
Zkušenosti. Hodně jsem mluvil s dobrými juniory, kteří byli dychtiví a chtěli s námi pracovat. Ale nemohl jsem je vzít na sebe, protože nebylo dost seniorů, kteří by juniory podporovali a působili pro ně jako mentoři. Bylo potřeba nejprve naverbovat vrchol a teprve potom mládež.
Cukr a bič.

Na otázku, jaká je správná rovnováha, jak ji udržovat, kolik lidí držet a jak moc tlačit, nemám dobrou odpověď. Jedná se o čistě individuální proces.

Den padesátý jedna

Začal jsem pozorně sledovat tým, abych pochopil, koho mám, a znovu jsem si vzpomněl:

"Většina problémů jsou problémy lidí."

Zjistil jsem, že tým jako takový – jak Dev, tak Ops – má tři velké problémy:

Spokojenost se současným stavem věcí.
Nedostatek zodpovědnosti - protože nikdo nikdy nepřinesl výsledky práce výkonných umělců k ovlivnění obchodu.
Strach ze změny.

Změna vás vždy vyvede z vaší komfortní zóny, a čím jsou lidé mladší, tím více se jim změny nelíbí, protože nechápou proč a nechápou jak. Nejčastější odpověď, kterou jsem slyšel, je: "To jsme nikdy nedělali." Navíc to dospělo k naprosté absurditě – sebemenší změny nemohly proběhnout, aniž by se někdo rozhořčil. A bez ohledu na to, jak moc změny ovlivnily jejich práci, lidé říkali: „Ne, proč? Tohle nebude fungovat."

Ale nemůžete se zlepšit, aniž byste něco změnili.

Měl jsem naprosto absurdní rozhovor se zaměstnancem, řekl jsem mu své nápady na optimalizaci, na což mi řekl:
- Oh, neviděli jste, co jsme měli minulý rok!
- Tak co?
"Teď je to mnohem lepší, než to bylo."
-Takže už to nemůže být lepší?
- Na co?

Dobrá otázka - proč? Jako kdyby to bylo teď lepší než to bylo, pak je všechno dost dobré. To vede k nedostatku odpovědnosti, což je v zásadě naprosto normální. Jak jsem řekl, technická skupina byla trochu stranou. Společnost věřila, že by měly existovat, ale nikdo nikdy neurčoval standardy. Technická podpora nikdy neviděla SLA, takže to bylo pro skupinu docela „přijatelné“ (a to mě zasáhlo nejvíce):

12 sekund načítání;
5-10 minut prostoje každé uvolnění;
Řešení kritických problémů trvá dny a týdny;
nedostatek personálu 24x7 / na zavolání.

Nikdo se nikdy nezkusil zeptat, proč to neuděláme lépe, a nikdo si nikdy neuvědomil, že to tak být nemusí.

Jako bonus byl ještě jeden problém: nedostatek zkušeností. Senioři odešli a zbylý mladý tým vyrostl za minulého režimu a byl tím otráven.

Kromě toho se lidé také báli, že selžou a budou vypadat neschopně. To je vyjádřeno ve skutečnosti, že za prvé, oni za žádných okolností nežádal o pomoc. Kolikrát jsme mluvili jako skupina i jednotlivě a já jsem řekl: "Zeptejte se, když nevíte, jak něco udělat." Jsem si jistý sám sebou a vím, že dokážu vyřešit jakýkoli problém, ale bude to chtít čas. Proto pokud se mohu zeptat někoho, kdo ví, jak to vyřešit za 10 minut, zeptám se. Čím méně zkušeností máte, tím více se bojíte zeptat, protože si myslíte, že budete považováni za neschopného.

Tento strach klást otázky se projevuje zajímavými způsoby. Například se zeptáte: "Jak se vám daří s tímto úkolem?" "Zbývá pár hodin, už končím." Druhý den se zeptáte znovu, dostanete odpověď, že je vše v pořádku, ale vyskytl se jeden problém, do konce dne to bude určitě hotové. Uplyne další den, a dokud nejste přišpendleni ke zdi a donuceni si s někým promluvit, pokračuje to. Člověk chce problém vyřešit sám, věří, že když ho nevyřeší sám, bude to velký neúspěch.

To je důvod, proč vývojáři odhady nafoukli. Byla to ta samá anekdota, když diskutovali o určitém úkolu, dali mi takový údaj, že jsem byl velmi překvapen. Na což mi bylo řečeno, že do odhadů vývojáře započítává vývojář čas, po který se tiket vrátí z QA, protože tam najdou chyby, a čas, který zabere PR a čas, kdy lidé, kteří by měli zkontrolovat bude rušno - tedy všechno, co je možné.

Za druhé, lidé, kteří se bojí, že budou vypadat neschopně přeanalyzovat. Když řeknete, co přesně je třeba udělat, začne to: „Ne, co kdybychom o tom přemýšleli tady?“ V tomto smyslu není naše společnost unikátní, to je standardní problém mladých lidí.

V reakci na to jsem zavedl následující praktiky:

Pravidlo 30 minut. Pokud nemůžete problém vyřešit do půl hodiny, požádejte někoho o pomoc. Funguje to s různou mírou úspěchu, protože lidé se stále neptají, ale proces alespoň začal.
Odstraňte vše kromě podstaty, při odhadování termínu dokončení úkolu, tedy uvažujte pouze o tom, jak dlouho bude trvat napsání kódu.
Průběžné učení pro ty, kteří příliš analyzují. Je to jen neustálá práce s lidmi.

Den šedesátý

Zatímco jsem to všechno dělal, byl čas zjistit rozpočet. V tom, kde jsme utráceli peníze, jsem samozřejmě našel spoustu zajímavých věcí. Měli jsme například celý rack v samostatném datovém centru s jedním FTP serverem, který využíval jeden klient. Ukázalo se, že "...přestěhovali jsme se, ale on zůstal takový, nezměnili jsme ho." Bylo to před 2 lety.

Zajímavý byl zejména účet za cloudové služby. Domnívám se, že hlavním důvodem vysokého účtu za cloud jsou vývojáři, kteří mají poprvé v životě neomezený přístup k serverům. Nemusí se ptát: „Dejte mi prosím testovací server,“ mohou si ho vzít sami. Navíc vývojáři vždy chtějí vybudovat tak skvělý systém, že jim Facebook a Netflix budou závidět.

Vývojáři ale nemají zkušenosti s nákupem serverů a dovedností určit požadovanou velikost serverů, protože to dříve nepotřebovali. A obvykle tak úplně nechápou rozdíl mezi škálovatelností a výkonem.

Výsledky inventury:

Opustili jsme stejné datové centrum.
Ukončili jsme smlouvu se 3 log službami. Protože jsme jich měli 5 – každý vývojář, který si s něčím začal hrát, si vzal nový.
7 systémů AWS bylo vypnuto. Opět nikdo nezastavil mrtvé projekty, všichni pokračovali v práci.
Snížení nákladů na software 6krát.

Den sedmdesátý pátý

Čas plynul a za dva a půl měsíce jsem se musel sejít s představenstvem. Naše představenstvo není o nic lepší ani horší než ostatní, stejně jako všechny správní rady chce vědět všechno. Lidé investují peníze a chtějí pochopit, jak moc to, co děláme, zapadá do nastavených KPI.

Představenstvo dostává každý měsíc spoustu informací: počet uživatelů, jejich růst, jaké služby a jak využívají, výkon a produktivitu a konečně průměrnou rychlost načítání stránek.

Jediný problém je, že věřím, že průměr je čisté zlo. Ale je velmi těžké to vysvětlit představenstvu. Jsou zvyklí operovat s agregovanými čísly, a ne například s rozložením dob načítání za sekundu.

V tomto ohledu bylo několik zajímavých bodů. Například jsem řekl, že musíme rozdělit provoz mezi samostatné webové servery v závislosti na typu obsahu.

To znamená, že ColdFusion prochází Jetty a nginx a spouští stránky. A obrázky, JS a CSS procházejí samostatným nginx s vlastními konfiguracemi. To je celkem standardní praxe, o které mluvím napsal jsem před pár lety. V důsledku toho se obrázky načítají mnohem rychleji a... průměrná rychlost načítání se zvýšila o 200 ms.

Stalo se to proto, že graf je sestaven na základě dat dodaných s Jetty. To znamená, že rychlý obsah není zahrnut do výpočtu - průměrná hodnota vyskočila. To nám bylo jasné, smáli jsme se, ale jak vysvětlit představenstvu, proč jsme něco udělali a věci se zhoršily o 12 %?

Den osmdesát pět

Na konci třetího měsíce jsem si uvědomil, že je tu jedna věc, se kterou jsem vůbec nepočítal: čas. Všechno, o čem jsem mluvil, vyžaduje čas.

Toto je můj skutečný týdenní kalendář - jen pracovní týden, není moc nabitý. Na všechno není dost času. Proto opět musíte nabrat lidi, kteří vám pomohou se s problémy vyrovnat.

Závěr

To není vše. V tomto příběhu jsem se ani nedostal k tomu, jak jsme s produktem pracovali a snažili se naladit na obecnou vlnu, ani jak jsme integrovali technickou podporu nebo jak jsme řešili jiné technické problémy. Například jsem se zcela náhodou dozvěděl, že na největších tabulkách v databázi nepoužíváme SEQUENCE. Máme samostatně psanou funkci nextIDa nepoužívá se v transakci.

Podobných věcí, o kterých bychom mohli mluvit ještě dlouho, bylo ještě milion. Ale to nejdůležitější, co je třeba ještě říci, je kultura.

Kultura nebo její nedostatek vede ke všem dalším problémům. Snažíme se budovat kulturu, kde lidé:

nebojí se selhání;
učit se z chyb;
spolupracovat s ostatními týmy;
převzít iniciativu;
přijmout odpovědnost;
vítat výsledek jako cíl;
slaví úspěch.

S tím přijde vše ostatní.

Leon Fire na Twitteru, Facebook a střední.

Existují dvě strategie týkající se dědictví: vyhnout se práci s ním za každou cenu nebo statečně překonat související potíže. My c DevOpsConf Jdeme druhou cestou, měníme procesy a přístupy. Přidejte se k nám Youtube, zpravodaj и telegrama společně zavedeme kulturu DevOps.

Zdroj: www.habr.com

Dědičnost starších systémů a procesů nebo Prvních 90 dní jako CTO