Edytujesz DevOps zavádíš špatně: kde selhává většina týmů

Kde se to láme První slepá ulička je automatizace nepořádku. Pokud se build a testy dají spustit jen na jednom konkrétním počítači a výsledek závisí na tom, kdo je zrovna na službě, automatizace problém jen zrychlí. Než začneš cokoliv spojovat do pipeline, sjednoť prostředí. Použij kontejnery nebo virtuální stroje s verzovanou konfigurací. Cíl je prostý: stejný příkaz na vývojářově stroji i na serveru musí dát stejný výsledek.<br><br>Kde se nejčastěji chybuje a jak se tomu vyhno<br><br>DevOps není nástroj ani pracovní pozice. Je to způsob, jakým vývoj a provoz spolupracují na tom, aby se změny dostávaly do produkce rychle, bezpečně a opakovaně. Nejčastější chyba začátečníků je představa, že stačí koupit CI server, nasadit kontejnery a hotovo. Ve skutečnosti jde o změnu odpovědnosti: kdo napíše kód, ten ho také provozuje a nese následky. Pokud tuhle větu vedení neřekne nahlas a nepodepře ji, každá technická investice vyprchá do ztracena.<br><br>Praktický krok: zaveďte krátký týdenní stav, kde každý řekne, co dokončil, co ho blokuje a co potřebuje. Ne délku, ale konkrétní překážku. Pokud se stejná překážka objeví dvakrát, řešte ji jako systémový problém, ne jako osobní selhání. Dále je nutné ohlídat, aby se interní tým nerozpadl do příliš mnoha malých úkolů. Méně větších celků se dokončuje lépe než hromada drobností.<br><br>Základem je ověřit podpis přesně tím algoritmem, který očekáváte. Nikdy nenechávejte knihovnu, aby si algoritmus vybrala podle hlavičky alg z tokenu. Pokud aplikace podporuje HS256 i RS256, musíte dopředu rozhodnout, který použijete, a ostatní odmítnout. Zvlášť nebezpečná je kombinace, kdy se veřejný klíč z RS256 dá podstrčit jako HMAC secret. Vždy porovnávejte iss, aud a exp; token bez expirace je jen trvalý přístupový klíč v cizích rukou.<br><br>Asynchronní kód je další místo, kde vzniká zmatek. Nemíchejte async/await s .then() v jedné funkci. Zvolte jeden styl a držte se ho. U await vždy myslete na chyby – obalte volání do try/catch, nebo použijte pomocnou funkci, která vrací dvojici hodnot. Nikdy nenechávejte odmítnutý promise bez ošetření, jinak dostanete tichý pád, který se hledá těžko.<br><br>Python je pro automatizaci vhodný z několika konkrétních důvodů: čte se podobně jako angličtina, má obrovskou základní knihovnu a většina systémů ho už má nainstalovaný. Nepotřebuješ žádné vývojové prostředí za tisíce, stačí terminál a textový editor. Začni tím, že si ověříš, jakou verzi máš k dispozici příkazem python3 --version. Pokud se vypíše číslo 3.8 a vyšší, můžeš pokračovat. Když příkaz selže, nainstaluj Python z oficiálního instalátoru pro svůj operační systém a při instalaci na Windows zaškrtni volbu přidání do systémové proměnné PATH, jinak budeš muset příkazy spouštět přes celou cestu.<br><br>Projekty s vlastním týmem nepadají na nedostatku schopností, ale na nedostatku hranic, rozhodnutí a průběžné kontroly. Kdo si tyto tři věci nastaví předem, mívá projekt hotový v rozumném čase i bez externí pomoci.<br><br>Další častá chyba je absence rozhodčího. Když se tým nedohodne, projekt stojí. Někdo musí mít poslední slovo a musí být jasné, kdo to je. Není to o hierarchii, ale o tom, že bez rozhodnutí se práce hromadí. Zároveň je dobré předem určit, co se stane, když se něco nestihne. Bez plánu B se každé zpoždění mění v krizi.<br><br>Kdy je interní tým past a kdy výhoda Vlastní tým má smysl tam, kde je potřeba hluboká znalost prostředí, dlouhodobá návaznost a rychlá reakce na změny. Naopak u jednorázových, jasně ohraničených úkolů často přináší víc režie než užitku. Pastí je i to, že se interní lidé bojí říct si o pomoc, protože nechtějí vypadat neschopně. Manažer proto musí aktivně zjišťovat, kde se práce zasekává, ne jen kontrolovat termíny.<br><br>Druhá chyba je měření špatných věcí. Sledovat počet nasazení za týden bez ohledu na to, kolik z nich způsobilo výpadek, je statistika do výroční zprávy, ne do provozu. Zajímej se o dobu od commitu k běžící změně, četnost incidentů a hlavně o čas, za který se služba po chybě vrátí do normálu. Tyto údaje ti řeknou, zda se zlepšuješ, nebo jen přidáváš nástroje.<br><br>Nejrychlejší způsob, jak se posunout, je číst cizí skripty a rozebírat je řádek po řádku. Když narazíš na neznámou funkci, otevři dokumentaci a zjisti, co dělá a jaké má vstupy. Po několika týdnech takového čtení přestaneš kopírovat hotová řešení a začneš skládat vlastní. Automatizace v Pythonu není o tom naučit se celý jazyk, ale o tom vyřešit konkrétní problém a mít ho hotový dřív, než bys ho stihl udělat ručně.<br><br>Rozdělení práce mezi vlastní tým zní lákavě: žádné faktury, žádné čekání na cizí lidi, všechno pod kontrolou. Jenže právě tady vzniká většina zpoždění. Nejde o to, že by interní lidé byli horší než externisté. Jde o to, že projekt s vlastním týmem nemá žádné přirozené hranice. Práce se rozplyne do běžného provozu a najednou není jasné, kdo co dělá a do kdy.