Jasně, ten titulek je trošku návnada na kliknutí. Software ale opravdu údržbu nepotřebuje, není to totiž dům ani auto. Není v něm potřeba měnit olej, nemusí se natírat, nereziví, ani se neochodí. Pokud funguje hardware, bude i za sto let pracovat naprosto stejně, jako v den, kdy jste ho naprogramovali. Není to úžasné? Tak proč k našim systémům přistupujeme tak, jako by se tomu baráku nebo autu podobaly a pak se divíme, že to funguje blbě?
Špatná přirovnání
Mluvit o vývoji softwaru s lidmi, kteří se vývojem softwaru nezabývají je těžké. Proto si pomáháme celou řadou přirovnání a analogií. Bohužel často jsou to analogie zavádějící a někdy vyloženě škodlivé. Ani já nejsem výjimkou a v minulosti jsem se toho mnohokrát dopustil.
Začíná to už tím, že si říkáme softwaroví inženýři, což v lidech navozuje dojem, že jsme něco jako stavitelé mostů nebo jaderných elektráren. Pokračuje to tím, že se snažíme vývoj řídit pomocí projektových metod, které vznikly většinou pro účely stavebnictví. A končí to tím, že životní cyklus systému dělíme na projekci (analýza, tvorba zadání), stavbu (vývoj) a následnou údržbu. A právě tomuto poslednímu tématu se chci v tomto článku věnovat.
Před a po
Když se rozhodnete implementovat nový softwarový systém, a je jedno jestli to je nový e-shop, ERP systém nebo skladové hospodářství, všechno směřuje ke dni D, kdy celou tu parádu spustíte do provozu. Termín spuštění je spolu s cenou za implementaci přirozeně to hlavní, co vás zajímá. Den spuštění tvoří pomyslnou hranici mezí “vývojem” a “údržbou”. Všichni samozřejmě počítají, že po spuštění budou problémy, takže se také počítá s tím, že v prvních měsících bude ta podpora ze strany dodavatele intenzivní, ale pak se předpokládá, že už “bude volněji” a přejde to do toho standardního údržbového režimu, který bude stát zlomek toho, co stál prvotní vývoj.
Jenže takhle to nefunguje. Jak jsme si řekli, software žádnou údržbu nepotřebuje. Co ale potřebuje, jsou změny. Každý software obsahuje chyby a ty je potřeba opravovat. Mění se firemní potřeby, mění se zákazníci, mění se konkurence, mění se legislativa. To všechno vyžaduje provádět změny softwaru. Potřeba těchto změn je obvykle mnohem větší, než jsme si představovali během prvotního vývoje.
Není vůbec výjimkou, aby roční objem práce na živém systému dosahoval podobných hodnot jako jeho vývoj. Vyvíjeli jste nový e-shop rok a stál vás deset milionů? Počítejte na příští tři roky s pěti až deseti miliony ročně na změny, které budou potřeba. A pokud to tak není, obvykle to znamená, že systém rychle zastarává a jeho vliv na firemní výsledky bude spíše negativní. Pokud si toto uvědomíte až po, bývá už pozdě a přichází rozčarování.
Co z toho vyplývá? Že doba po je mnohem důležitější, než doba před. Podle způsobu, jak vybíráme dodavatele a jak implementační projekty řídíme, to ale není moc poznat. Když se podívám do zadání výběrových řízení na dodávky nejrůznějších systémů i do nabídek od dodavatelů v rámci těchto řízení—a že už jsem jich pár viděl—95% stránek textu řeší zadání na vývoj, záruky dodržení termínu spuštění, jaké jsou orgány řízení projektu, kdo podepíše akcepťák, kolik mendejů to bude a jaká bude sleva nebo pokuta za to či ono pochybení.
Období po se obvykle omezuje na to, jestli dodavatel bude na e-maily odpovídat od devíti do pěti ve všední dny nebo i o víkendu a jak dlouho bude trvat, než někdo začne řešit, že došlo místo na disku. Čest výjimkám, ale moc jich není.
Spuštění nového netriviálního systému je pro každou firmu náročné. Často to s sebou nese změnu firemních procesů a náplně práce vašich lidí. Je to období plné stresu. Poslední, co chcete v tuto chvíli dělat, je zásadně měnit způsob, jakým tento systém vyvíjíte a nasazujete. Ale právě to se většinou děje.
Optimalizujeme na po
Prvním krokem k nápravě je přijetí skutečnosti, že problém existuje. V tu chvíli můžeme začít uvažovat, co s tím můžeme dělat. Při všem, co v období před budeme dělat je třeba mít na paměti, jestli a jak to ovlivní období po. A při volbě řešení brát v potaz, že po je důležitější než před. Co tím myslím uvedu na několika příkladech.
Příklad první: Realizační tým
Pokud vám bude systém vyvíjet externí dodavatel, ptejte se hned od začátku, jak bude vypadat období po. Je skoro pravidlem, že dodavatel pro vás bude mít realizační tým, ve kterém vám nabídne své nejlepší lidi, kteří za sebou určitě mají spoustu úspěšných projektů. Jenže tenhle tým po skončení implementace pravděpodobně půjde dělat nějaký jiný projekt a vás přehodí do týmu “údržby”. To s sebou nese celou řadu problémů.
Nikdy nedojde k dokonalému přenosu znalostí mezi realizačním a udržovacím týmem. Když mezi nimi bude dobrá komunikace, ztratí se třetina know-how. Když špatná, ztratí se ho polovina. Tým údržby obvykle bude mít takových zákazníků na starost víc, takže se budete o jejich zdroje přetahovat.
I když se dodavatel bude tvářit, že to tak není, dochází mezi těmito týmy ke konfliktu v motivaci. Primárním kritériem realizačního týmu je obvykle co nejméněkrát posunout termín spuštění, moc nepřekročit plánovaný rozpočet a donutit zákazníka, aby podepsal akcepťák. To se logicky odrazí v některých architektonických rozhodnutích na úkor dlouhodobého rozvoje. Pokud by realizační tým věděl, že bude systém další tři roky mít na krku, vypadalo by to jinak.
Proto preferujte dodavatele, který vám dopředu garantuje, že následný rozvoj systému bude mít na starost stejný tým, který ho bude prvotně vyvíjet a že na to bude mít kapacitu. A to i za cenu, že v týmu nebudou ty vývojářské superstar, které jsou zvyklé udělat projekt a jít o dům dál.
Pokud plánujete, že si rozvoj systému převezmete sami interně, nebo chcete, aby to dělal jiný dodavatel, je potřeba s tím počítat od začátku a tento nový tým zatáhnout do procesu vývoje co nejdříve a co nejintenzivněji. A to i přesto, že vám dodavatel bude tvrdit, že ho to zdrží a nebude tak efektivní.
Pokud je vaší prioritou po, raději akceptujte posun termínu spuštění nebo zmenšete rozsah první verze, než abyste přijali to, že po bude dělat úplně jiný tým než před.
Příklad druhý: Spuštění vs. nasazení
Pojmy spuštění a nasazení nového systému, nebo i jednotlivé změny v systému již existujícím, jsou často brány jako synonyma. Ale ve skutečnosti jsou to dvě různé činnosti. To, že obvykle probíhají najednou, je spíš ke škodě věci. Nasazením myslíme proces, kdy se software dostane na produkční prostředí a je připraven ke spuštění. Spouštěním myslíme moment, kdy se software, nebo funkcionalita, začne používat uživateli.
U většiny projektů, u kterých jsem měl možnost vidět pod pokličku, dochází k nasazení na produkční prostředí až velmi pozdě v celém vývojovém cyklu. Často pouze týdny nebo dokonce jen dny či hodiny před plánovaným spuštěním.
Důvody bývají hlavně dva:
- Pro produkční prostředí chybí infrastruktura. Servery samozřejmě něco stojí a může se zdát jako plýtvání pořizovat virtuální, nebo nedej bože fyzické, servery dřív, než bude systém spuštěn. Toto je jeden z mnoha důvodů, proč byste měli využít cloud. Nikdo neříká, že musíte mít infrastrukturu naškálovanou jako by na ní běžel plný provoz, ale měla by obsahovat všechny komponenty shodné s vývojovým a testovacím prostředím. Že se vám ty komponenty v průběhu vývoje mění a architektura ještě není finální? Dobře. To nebude ani po. Tak si aspoň natrénujete, jak bude vypadat proces přidání například nové databáze a donutí vás to infrastrukturu automatizovat a spravovat jako kód.
- Vývojáři budou efektivnější, když budou vyvíjet na zjednodušeném nebo lokálním prostředí, bez nutnosti všechny změny “protáhnout” skrz složitý landscape až na produkci. Pokud se vyvíjí na prostředí, které se chová a vypadá jinak než produkce, zaděláváte si na problémy, které se projeví v tu nejnevhodnější dobu. Jestliže je proces nasazení změny na produkci kostrbatý a pro vývojáře nepohodlný, bude takový i po. A co čert nechtěl, obvykle těsně po budete potřebovat nasazovat do produkce často a hlavně rychle. Není lepší doba pro automatizaci a odladění tohoto procesu, než ve chvíli kdy problém s nasazením na produkci ještě nemá valné následky.
Příklad třetí: Ladění výkonu
Software musí nejen dělat to co má, ale musí to dělat dostatečně rychle a být schopen s rezervou odbavit produkční provoz. Něco lze řešit posílením infrastruktury, ale řádového zlepšení se obvykle dosahuje úpravou softwaru—změnou SQL dotazu, změnou pořadí zamykání řádků, změnou algoritmu výpočtu. Aby to nebylo formou pokus-omyl, jsou potřeba ladící nástroje. Nejednou jsem byl svědkem, že kvalitní ladící nástroje byly k dispozici hlavně na vývojovém prostředí. Někdy kvůli ceně těchto nástrojů (to se dívám třeba na tebe, Oracle, s tvým Tuning packem), někdy kvůli obavám o bezpečnost a strachu z toho, že by to mohlo ovlivnit produkci a někdy kvůli tomu, že zatímco vývoj probíhal na lokální databázi, produkce měla běžet v managed cloud instanci.
Vždy se to ale přešlo s tím, že přeci se to odladí před spuštěním do produkce, pořádně otestuje a pak už to nebude potřeba. Už asi tušíte, kam tohle spěje. Vždy se nakonec ukázalo, že potřeba ladit výkon po je řádově větší než před. Na spoustu problémů se před spuštěním při sebevětší snaze přijít nedá. A najednou jsme slepí. Na testovacím prostředí se problém nedaří nasimulovat a v produkci nemáme instrumentaci. Navíc budeme v systému dělat spoustu změn a u každé si potřebujeme být jistí, že negativně výkon neovlivní.
Lepší způsob je tedy používat pro ladění pouze ty nástroje, které budou fungovat stejně při vývoji jako během provozu v produkci. A pokud takové nástroje nemáme, opatřit si je co nejdříve během prvotního vývoje, aby se s nimi vývojáři naučili pracovat.
V ideálním případě programátoři rovnou během vývoje píšou vedle unit testů i automatizované výkonnostní testy pokrývající jimi vyvíjenou oblast a tyto testy se budou spouštět v rámci continuous integration pipeline při každém commitu. Poslouží to nejen při prvotním vývoji k včasnému odhalení problémů, ale hlavně po, když budeme chtít systém bezpečně měnit.
Je to na vás
Tři příklady uvažování, které jsem tu nastínil nejsou zdaleka kompletním výčtem toho, co je potřeba v životním cyklu systému řešit. Podobných rozhodnutí musíte udělat desítky. Doufám ale, že se mi podařilo snad trochu změnit optiku, kterou se na svůj příští nový systém budete dívat. Pokud byste s tím chtěli poradit, ozvěte se mi.
Možná bych tedy nakonec doplnil titulek tohoto článku:
Software nepotřebuje údržbu, potřebuje se měnit.
Comments