Odovzdanie softvérového projektu sa vo väčšine firiem odohrá takto: príde posledná faktúra, k nej e-mail s odkazom na repozitár a veta, že všetko podstatné je v README. Tri týždne to funguje. Potom príde prvý výpadok mimo pracovného času alebo požiadavka na drobnú zmenu — a ukáže sa, že do produkčnej databázy vidí jediný človek, ktorý už u dodávateľa nepracuje, doména je registrovaná na jeho súkromný účet a zálohy síce bežia, len ich nikto nikdy neskúsil obnoviť.
Odovzdanie pritom nie je administratívny krok na konci. Je to samostatná fáza s vlastným rozsahom, harmonogramom, rozpočtom a akceptačnými kritériami. A hlavne — dá sa naplánovať od začiatku projektu, alebo sa dá improvizovať v poslednom týždni. Rozdiel medzi tými dvoma prístupmi zaplatí preberajúca strana, spravidla v najhoršom možnom čase.
Odovzdanie sa plánuje od prvého šprintu
Pripravenosť na odovzdanie nie je dokument, ktorý sa napíše na konci. Je to vlastnosť projektu, ktorá buď priebežne existuje, alebo neexistuje. Tím, ktorý od začiatku počíta s tým, že systém raz prevezme niekto iný, pracuje inak: infraštruktúru drží ako kód, nie ako sériu ručných klikov, tajomstvá ukladá do správcu tajomstiev a nie do konfiguračných súborov na disku, účty tretích strán zakladá na firemné e-maily klienta a nie na osobné, a dôvody architektonických rozhodnutí zapisuje vtedy, keď rozhodnutie padne.
Ten posledný bod je rozhodujúci. Rekonštruovať osemnásť mesiacov rozhodnutí v poslednom týždni projektu nie je dokumentácia, ale archeológia — a výsledkom je text, ktorý znie hodnoverne a je z tretiny nepresný. Ak si počas projektu prechádzate jednotlivé fázy vývoja softvéru na mieru, odovzdanie patrí do plánu rovnako ako testovanie alebo nasadenie.
Druhá vec, ktorá sa rieši na začiatku, je zmluva. Exitová doložka by mala pomenovať, čo presne dodávateľ pri ukončení spolupráce odovzdáva, v akej lehote, kto je vlastníkom účtov a licencií a koľko hodín podpory je súčasťou ceny. Ak sa toto rieši až vo chvíli, keď je vzťah napätý, vyjednávacia pozícia klienta je slabá. Patrí to medzi otázky, ktoré má zmysel položiť už pri výbere softvérového dodávateľa.
Čo musí reálne zmeniť majiteľa
Praktický checklist odovzdania má tri okruhy. Nič z toho nie je exotické, a predsa sa v reálnych odovzdaniach pravidelne stráca minimálne polovica.
Kód, prostredia a nasadenie
Repozitár vrátane histórie, nie iba posledný snapshot. K nemu popis vetvenia a release stratégie — ktorá vetva je produkčná, ako vzniká vydanie, čím je označená verzia, ktorá práve beží v produkcii. Ďalej zoznam prostredí (vývoj, staging, produkcia), čím sa navzájom líšia a kde tie rozdiely spôsobujú prekvapenia. A napokon postup nasadenia aj postup návratu späť. Rollback je tá časť, ktorá sa dokumentuje najmenej často a potrebuje sa najsúrnejšie.
Prístupy, účty a licencie
Kľúčové slovo je rotácia, nie zdieľanie. Odovzdať prístup neznamená poslať existujúce heslo — znamená to vytvoriť nové prihlasovacie údaje pre preberajúcu stranu a staré zneplatniť. To isté platí pre API kľúče, servisné účty, SSH kľúče a tokeny do CI. Ďalej sem patria účty poskytovateľa infraštruktúry vrátane fakturačného vlastníctva, registrátor domény a správa DNS, účty tretích strán (platobná brána, e-mailová a SMS brána, mapové a analytické služby, monitoring) a licencie s dátumami obnovy. Pri mobilných aplikáciách navyše účty v obchodoch s aplikáciami a podpisové certifikáty — bez nich sa aplikácia nedá aktualizovať, iba znovu vydať pod novou identitou.
Dáta, prevádzka a znalosti o systéme
Schéma databázy a spôsob, akým sa mení (migrácie), retenčná politika, a predovšetkým procedúra zálohovania a obnovy. Zálohovanie sa dá skontrolovať za päť minút; obnova sa musí odskúšať. Zálohu, ktorú nikto nikdy neobnovil, treba považovať za neexistujúcu, kým sa nepreukáže opak. Do tohto okruhu ďalej patrí monitoring a smerovanie alertov — po odovzdaní musí existovať menovitý človek, ktorému alert reálne pípne na telefóne. A napokon záznamy architektonických rozhodnutí, zoznam známych chýb aj s obchádzkami a runbook pre tri až päť najčastejších incidentov.
| Oblasť | Čo sa odovzdáva | Ako sa overí prevzatie |
|---|---|---|
| Repozitár a vydania | História, vetviaca a release stratégia, označenie produkčnej verzie | Preberajúci tím zostaví build zo zdrojov na vlastnom stroji |
| Prostredia a nasadenie | Postup nasadenia, rollback, rozdiely medzi prostrediami | Preberajúci tím nasadí a vráti zmenu na stagingu |
| Tajomstvá a prístupy | Rotované kľúče, servisné účty, tokeny do CI | Staré údaje sú preukázateľne zneplatnené |
| Infraštruktúra a DNS | Vlastníctvo účtov, fakturácia, registrátor domény | Zmena v DNS vykonaná bez asistencie dodávateľa |
| Databáza a zálohy | Schéma, migrácie, retencia, procedúra obnovy | Obnova do testovacieho prostredia úspešne odskúšaná |
| Monitoring a alerty | Prehľady, prahy, eskalačné cesty | Testovací alert dorazí menovitému príjemcovi |
| Tretie strany a licencie | Účty, zmluvy, dátumy obnovy, kontakty na podporu | Preberajúca strana sa prihlási do každého účtu |
| Rozhodnutia a incidenty | Záznamy rozhodnutí, známe chyby, runbook | Simulovaný incident vyriešený podľa runbooku |
Dokumentácia napísaná raz verzus dokumentácia, ktorá zostáva pravdivá
Väčšina odovzdávacej dokumentácie sa píše v jednom nárazovom týždni, odovzdá sa v PDF a od toho dňa už len zastaráva. Po pol roku je nebezpečnejšia než jej absencia: tvári sa ako zdroj pravdy, pričom polovica postupov už neplatí, a človek, ktorý podľa nej rieši incident, stráca čas v slepej uličke.
Rozdiel medzi mŕtvou a živou dokumentáciou nie je v kvalite písania, ale v tom, či sa dokument niekým používa a či sa mýlka prejaví. Fungujú tri typy obsahu. Prvý je ten, ktorý sa nedá odvodiť z kódu: prečo bolo rozhodnutie prijaté, aké alternatívy boli zvažované, aké obchodné pravidlo stojí za zvláštnou výnimkou v objednávkovom procese. Druhý je obsah, ktorý sa spúšťa — skript na lokálne nastavenie prostredia, ktorý beží aj v CI, seed dát, infraštruktúra ako kód. Ak prestane platiť, pipeline spadne. Tretí je runbook, ktorý sa reálne otvára pri incidentoch a po každom incidente sa upravuje.
Naopak, dokumentácia, ktorá slovami prerozprávava kód, je nepravdivá do niekoľkých týždňov. Dobrý test pripravenosti je jednoduchý: nový vývojár dostane iba dokumentáciu, žiadnu ústnu pomoc, a má rozbehnúť projekt lokálne a nasadiť triviálnu zmenu na staging. Čo ho zastaví, to je diera v dokumentácii. Rovnaká logika platí aj pri dlhodobej údržbe a rozvoji softvéru po spustení — dokumentácia je prevádzkový nástroj, nie príloha k faktúre.
Prenos znalostí: preberajúci tím musí robiť, nie pozerať
Typický „knowledge transfer" vyzerá ako séria hovorov, kde dodávateľ zdieľa obrazovku a hovorí. Preberajúci tím prikyvuje, robí si poznámky a odchádza s pocitom, že rozumie. O mesiac neskôr, pri prvom skutočnom nasadení, sa ukáže, že nerozumie.
Funkčná alternatíva je obrátiť role. Sedenia sú pracovné: klávesnicu drží preberajúci tím, dodávateľ sedí vedľa a odpovedá na otázky. Nasadenie na staging robí nový tím. Obnovu zálohy robí nový tím. Simulovaný incident podľa runbooku rieši nový tím. Tri až päť sedení po deväťdesiat minút, každé s konkrétnym výstupom, prinesie viac než dvadsať hodín prezentácií. Nahrávky sedení sú užitočný doplnok, nie náhrada.
Znalosť, ktorú preberajúci tím nikdy nepoužil vlastnými rukami, nie je prenesená — je len nahratá na videu.
Osobitná kategória sú znalosti o dátach. Pri systéme, ktorý vznikol migráciou zo staršej platformy, býva najcennejšou informáciou to, ktoré historické záznamy sú nekonzistentné, prečo a ako sa s nimi zaobchádza. Táto znalosť je takmer vždy iba v hlavách a takmer nikdy v repozitári.
Skúšobná prevádzka a akceptačné kritériá odovzdania
Medzi „dodávateľ prevádzkuje" a „dodávateľ je preč" patrí prechodné obdobie, typicky štyri až osem týždňov podľa zložitosti systému. Nový tím prevádzkuje, pôvodný je v pohotovosti s dohodnutou reakčnou dobou a vopred vyčleneným počtom hodín. Kľúčové je zadefinovať, kedy sa eskaluje: ak nový tím volá pri každej maličkosti, znalosti sa neprenesú, ak nevolá nikdy, riskuje sa výpadok.
Odovzdanie samo o sebe potrebuje akceptačné kritériá — inak nikdy nemá jasný koniec. Rozumný súbor vyzerá takto: preberajúci tím samostatne nasadil zmenu do produkcie; samostatne vykonal obnovu zálohy do testovacieho prostredia; prihlásil sa do všetkých účtov tretích strán a je ich vlastníkom; alerty chodia jeho ľuďom; vyriešil aspoň jeden reálny alebo simulovaný incident bez zásahu dodávateľa; a všetky tajomstvá boli rotované. Kým tieto body neplatia, odovzdanie prebieha, nech už bola posledná faktúra vystavená kedykoľvek.
Kedy odovzdanie zlyhá aj pri kvalitnom dodávateľovi
Najčastejšia príčina neúspechu nie je na strane odovzdávajúceho. Je na strane preberajúcej: nikto nemá na odovzdanie vyčlenený čas. Ľudia sú stopercentne alokovaní na inú prácu, na sedenia chodia „ak stihnú", dokumentáciu si prečítajú neskôr a neskôr nikdy nepríde. Výsledok je rovnaký, ako keby odovzdanie neprebehlo — s tým rozdielom, že obe strany si myslia, že prebehlo.
Prakticky to znamená tri veci. Menovitý vlastník odovzdania na preberajúcej strane, nie „IT oddelenie". Reálna kapacita, orientačne dvadsať až tridsať percent času dvoch až troch ľudí počas prechodného obdobia. A jasne určený človek, ktorému budú chodiť alerty od prvého dňa po ukončení pohotovosti. Ak firma tieto tri veci nevie zabezpečiť, je poctivejšie predĺžiť spoluprácu s pôvodným dodávateľom, než odovzdať systém do prázdna.
Existuje aj situácia, keď odovzdanie nedáva zmysel: systém je natoľko prepletený s know-how jedného tímu a natoľko málo dokumentovaný, že jeho prevzatie stojí viac než prepísanie kritickej časti. Vtedy je odovzdanie skôr riadeným útlmom než prevzatím prevádzky. V INTERFASE takéto situácie riešime v rámci vývoja softvéru na mieru tak, že najprv stabilizujeme prevádzku a až potom rozhodujeme o ďalšom osude systému.
Zhrnutie
Odovzdanie softvérového projektu je proces, nie e-mail. Plánuje sa od začiatku, má vlastný rozsah a akceptačné kritériá a končí sa vtedy, keď preberajúci tím systém samostatne nasadil, obnovil zo zálohy a prežil incident. Dokumentácia má cenu len vtedy, ak sa používa; prístupy sa rotujú, nie zdieľajú; znalosti sa prenášajú prácou, nie prezentáciou. A ani dokonale pripravené odovzdanie nefunguje, ak preberajúca strana nevyčlení menovitého vlastníka a reálny čas.
Ak práve preberáte systém po inom dodávateľovi alebo pripravujete odovzdanie svojho projektu a chcete si prejsť checklist na konkrétnom prípade, ozvite sa nám — pomôžeme zadefinovať rozsah odovzdania aj jeho akceptačné kritériá.