Project Phoenix fikcia popisujúca realitu fungovania IT a prechod k DevOps

Intro

Kniha začína pomerne nečakaným uvedením hlavného hrdinu do role VP pre IT operations v Drme, ktorá vyrába autodiely. Horší vstup si neviete ani predstaviť. Firma dlhodobo neplní stanovené ciele, prerába, jej akcie padajú dolu rýchlejšie ako popularita Jana Fischera. Konkurencia im dáva poriadne na frak a podľa analytikov bude najskôr Drmu potrebné rozdeliť a predať. Aby tej smoly nebolo málo, v Drme krúži banda audítorov so súpisom porušenia bezpečnostných a právnych pravidiel, ktorý by mal výrazne pomôcť dosiahnuť ciel spoločnosti. Projekt sa niekoľkokrát omeškal a jeho rozpočet sa poriadne predražil, jeho aktuálny stav je neurčitý a dátum nasadenia je nebezpečne blízko. Na hlavného hrdinu padajú kostlivci zo skrine úplne neočakávane, presne vo chvíli kedy si myslíte, že to nemôže byť horšie.

Na scéne sa postupne objavuje postava mentora Erika, ktorý necháva hlavného hrdinu nahliadnuť do výrobného procesu továrne a dospieť k zisteniu, že správna cesta k riadeniu práce je Kanban a modus operandi fungovanie vývojárov a ľudí z operations je potrebné vymeniť za DevOps. K ďalším výrazným postavám patrí Brent, DeusEx machina zasahujúci prakticky kedykoľvek sa objaví incident na produkcii, prípadne je potrebné urobiť nejakú zložitejšiu prácu. Polená pod nohy IT hádže šéfka retail oddelenia Sarah a dlhú dobu aj John zodpovedný za bezpečnosť.

Zdroje činností v IT a ich vplyv

Jeden z prvých problémov, ktorý musí Bill Palmer vyriešiť, je výpadok výplatného systému. Po dlhom pátraní prídu na to, že niekto nasadil šifrovanie čísel sociálneho poistenia (obdoba nášho rodného čísla a zákonu o jeho utajení), ktoré spôsobilo nevalidné dáta v databáze. Postupne sa ukazuje, že zmena nebola testovaná (nebolo testované prostredie) a niekto tu zmenu prepašoval bokom mimo akýchkoľvek change management.

The only thing more dangerous than a developer is a developer conspiring with security. Information security is always ashing their badges at people and making urgend demands, regardless of the consequences to the rest of the organization.

Hlavnému hrdinovi ide hlava okolo z množstva práce, ktorá na IT oddelenie padá. Z pohľadu zákazníkov IT oddelení (business, marketing atď.) to vypadá, že všetky ich projekty sú omeškané a aj tie najjednoduchšie požiadavky trvá vybaviť neúmerne dlho. Ako sa čoskoro ukáže, tieto požiadavky sú len jednou štvrtinou toho, čo IT bežne rieši alebo je po ňom požadované. S tým by sa malo počítať a zohľadniť pri odhade výkonu/priepustnosti tímu.

• business projekty - úlohy vychádzajúce z potrieb core businessu napr. urobte feature XYZ
• interné IT projekty - úlohy, ktoré si stanovuje IT, aby mohli efektívne fungovať napr. vývoj monitorovacej infraštruktúry, nástroje pre vývoj, zber a analýzu logov
• zmeny - nasadenie záplat, zmena konfigurácie, deploy nových mašín a iné záležitosti súvisiace s operačnými požiadavkami na doručované aplikácie/služby
• neplánovaná práca - urgentné požiadavky mimo plán napr. riešenie incidentov, hotDoxy

Tieto štyri zdroje činností IT sa bijú o zdielané zdroje. Prvá vec, ktorú náš hlavný hrdina urobí, a vy by ste mali tiež, je rozdelenie plánovania zdrojov na tieto štyri oblasti a identifikáciu obmedzení, ktorá spôsobuje, že sa tieto štyri činnosti vzájomne blokujú. V prípade knihy a jej deja je obmedzením DeusEx machina vývojár Brent, na ktorom sa zbiehajú všetky dôležité požiadavky.

Vybudujte stenu

Processes are supposed to protect people. We need figure out how to protect Brent.

Pred Brenta do slova a do písmena postaví stenu v podobe manažéra, cez ktorého prichádzajú všetky požiadavky. Bolo totiž zvykom Brentovi priamo volať alebo posielať emaily s tým, že niečo je potrebné urobiť hneď teraz a urgentne. Brent potom nerobil nič iné okrem neplánovanej práce pretože bola potreba na projekte Phoenix. S Brentom pracujú traja vývojári, aby sa predalo jeho know how ďalej.  Postupne sa podarí požiadavky kategorizovať, zdokumentovať ich spracovávanie a nakoniec ich vybavenie kompletne preberú ďalší vývojári. Brentove ruky sú potom kompletne k dispozícií projektu Phoenix.

Unlike other categories of work, unplanned work is recovery work, which almost always takes you away from your goals. That’s why it’s so important to know where your unplanned work is coming from.

Z tohto minipríbehu plynie ponaučenie, že úlohy by sa mali ľuďom predávať riadenou formou a mal by pre ne existovať jeden zdroj. V knihe používajú Kanban a čo nie je na Kanbanu, na tom sa nerobí. Je veľmi prínosné, aby sa spolu ľudia bavili o tom, čo je potreba urobiť. Žiadna vec, a to ani v IT, sa však nestala len pretože ste o nej s niekým hovorili alebo poslali skupinový email. Samozrejme pokiaľ u vás nefunguje bájná skupina japonských inžienierov Onoseto a Samoseto. Bez jedného autoritativného zdroja práce vám hrozí, že budete pracovať len na neplánovanej práci. Naviac ani nebudete schopný identifikovať ich zdroje a spôsob ako ich eliminovať.

Unplanned work kills your ability to do planned work, so you must always do whatever it takes to eradicate it.

Work In Process

V metodológií Kanban vývoj funguje podobne ako výrobná linka v továrni. Na začiatku je úloha/zadanie, ktoré pláva cez jednotlivé fázy linky. Pre nové furnitures môže mať linka fázu-návrh, kódovanie, testy a deploy. Pre provisioning nových strojoch to môže byť - alokácia hardwaru, konfigurácia, inštalácia software a odovzdanie. Keď je úloha vo vnútri výrobnej linky má označenie Work In Process (skrátene WIP). Úloha je splnená až vo chvíli kedy opustí výrobnú linku. Čím viac úloh máte paralelne vo výrobnej linke, tím viac WIP úloh tj. práca ktorá stále nebola dokončená.

Remember, outcomes what matter — not to the process, not controls, or, for that matter, what work you complete.

V našom príbehu sa ukáže, že dôvodom prečo má IT oddelenie čokoľvek doručiť včas je práve vysoký počet WIP úloh. Vďaka analýze sa príde na to, že zdrojom WIP je Brent, na ktorom sa všetko zbieha a úlohy musia čakať, kým ich postupne vyrieši. Ďalšími faktormi ovplivňujúcimi WIP je technologický dlh Drmy. Nakoniec hlavní hrdina siahne k pomerne drastickému opatreniu a po určitú dobu zakáže príjmanie ďalších úloh dokiaľ si nedokončí aktuálne WIP úlohy. Znovu otvorenie je možné len pre úlohy rep. výrobné linky, ktoré nezávisia na ich kľúčovom obmedzení.

- Brentovi.

Prečo je dôležité nerobiť všetko

Hlavný hrdina si veľmi rýchlo uvedomí, že tempom ktorým na IT oddelení padajú nové úlohy príde skôr alebo neskôr k opätovnému zahlteniu a rastu WIP. Výsledkom bude, že IT oddelenie nebude schopné plniť svoje záväzky a všetko sa bude oneskorovať proti plánu. Na scénu vstupuje mentor Erik, ktorý vysvetľuje, že nie všetky úlohy, ktoré na IT padajú z vonku sú skutočne potrebné. Kľúčom je pochopiť, ktoré z tých úloh súvisia s cieľom spoločnosti.

Spoločne s hlavným hrdinom postupne navštevujete jednotlivé oddelenia (marketing, predaj atď.) s cieľom pochopiť, ako sa ciele spoločnosti odrážajú v ich práci. To mu umožňuje identifikovať ich kľúčové potreby vzhľadom k IT a zároveň pochopiť, čím by ich mohlo IT ohroziť. Jedným zo zdrojov veľkého množstva úloh sú výsledky auditu. Nakoniec sa ukáže, že vďaka toku spracovania finančných transakcií je možné veľkú časť IT systému vyňať z auditu a znížiť počet úloh.

Remember, it goes beyond reducing WIP. Being able to take nedless work out of the system is more important than being able to put more work into the system. To do that, you need to know waht matters to the achievement of the business objectives, whether it’s projects, operations, strategy, compliance with laws and regulations, security, or whatever.

Poznámka pod čiarou: a z toho plynie ponaučenie, že výsledky auditu možno vykladať rovanko pružne ako našu ústavu.

Veľké projekty nefungujú a veľké DevOps -nále

Hlavný hrdina prichádza k záveru, že projekt Phoenix, ktorý sa im v pote tváre nakoniec podarí nasadiť, vlastne není úplne potrebný vzhľadom k cieľom spoločnosti. Inými slovami, že práca mnoho ľudí a milióny investovaných dolárov padnú k ničomu a tým pádom aj nádej Drmy na prežitie. Jedným z posledných záchvevov nádeje je zostavenie tímu, ktorý by v krátkom čase implementoval projekt umožňujúci lepšie zacielenie predajnej kampane. V tíme sú obsadený nielen ľudia z developmentu, ale aj z operations a businessu. Čo vám mám povedať, je to happyend. Projekt je doručený presne na čas pred Čiernym piatkom (deň kedy američania najviac nakupujú) a umožňuje Drme dosiahnúť najlepšie výsledky za niekoľko rokov. Firma je zachránená a nehrozí jej predaj na časti s outsorcovaním IT do Bengalore.

Veľké projekty väčšinou nefungujú, pretože stoja moc peňazí a nikdy sa ich nepodarí doručiť včas. Rozhodujúcim faktorom je takzvaný Time to market, teda ako rýchlo sa vám podarí dostať konkrétny produkt na trh. Nie je potreba, aby bol dokonalý, je potreba aby tam bol. Je to o skúšaní čo by sa mohlo uchytiť, pretože pokiaľ to neskúsite, nemôžete vedieť, ako to zákazníci príjmu alebo ako zareaguje vaša konkurencia. Všetky tieto atribúty hrajú do kariet proti veľkým projektom.

Cieľom knihy je previesť čitateľov zmenou organizácie a fungovanie IT, ktorá sa nazýva Three Ways.

The First way is all about controlling the how of work from Development to IT operations.

The Second way is about creating constant feedback loops from IT operations back intro Development, designing quality into the product at the earlies stages

The Third way is about creating a culture that reinforces the value of taking risks and learning from failure and the need for repetition and practice to create mastery.

Záver

Žiadny článok popisujúci knihu nemôže byť rovnako vyčerpavajúci ako vlastná kniha, mnoho zaujímavých informácií a z nich plynúcich konsekvencií som musel vynechať - nezostalo miesto na skrátenie dodacieho cyklu z deviatich mesiacov na dni tj. reminiscence continuous delivery, nemohol som sa ani venovať tomu, prečo je dôležité nechať ľudom nejaký voľný pracovný čas - možno to napravím v niektorom z ďalších článkov. Som v pokušení napísať, že pokiaľ to s DevOps myslíte vážne, predstavuje pre vás táto kniha povinné čítanie. Nebola by to avšak celá pravda, pretože táto kniha ponúka podľa mojích skpsenosti úplne reálny popis toho ako funguje IT oddelenie valnej vačšiny Drem.

When IT fails, the business fails. It stands to reason that if IT is organized so that it can win, the business wins, too.