74. Hodnocení a zavádění nových nástrojů (technology radar přístup)

Úvod a kontext

DevOps ekosystém se mění rychle — každý rok přibývají nové nástroje
pro CI/CD, monitoring, infrastrukturu jako kód i orchestraci. Senior
inženýr nebo tech lead je pravidelně v situaci, kdy někdo z týmu
přijde s nápadem "měli bychom přejít na nástroj X" nebo "zkusme
nahradit Y za Z". Bez systematického přístupu k hodnocení takových
návrhů tým buď skáče z nástroje na nástroj bez jasného přínosu
(tzv. "shiny new toy syndrome"), nebo naopak zůstává lpět na
zastaralých řešeních jen proto, že změna je nepohodlná. Tato lekce
ukazuje strukturovaný způsob, jak takové rozhodování dělat vědomě
a jak nový nástroj bezpečně zavést, pokud se pro něj tým rozhodne.

Teorie

Proč je potřeba proces, ne jen "cit"

Rozhodnutí zavést nový nástroj má reálné náklady, které se často
podceňují: čas na naučení celého týmu, migrace existující
konfigurace a dat, riziko provozních problémů v přechodném období,
a dlouhodobý náklad na údržbu ještě jednoho systému (viz princip
"každý nástroj navíc je dluh", podobně jako u technického dluhu
z kódu). Proti tomu stojí reálný přínos — úspora času, lepší
spolehlivost, nižší náklady, nebo řešení problému, který stávající
nástroje neumí řešit vůbec. Rozhodnutí "zavést, nebo nezavést" by
proto mělo vzniknout jako vědomé zvážení přínosu proti nákladu, ne
jako reakce na to, že o nástroji někdo mluvil na konferenci.

Technology radar

Jeden osvědčený rámec pro organizaci takového rozhodování je
technology radar (popularizovaný firmou ThoughtWorks). Nástroje
a techniky se zakreslují do čtyř soustředných prstenců podle míry
důvěry týmu v ně:

• Adopt (zavést) — nástroj, který tým already důvěrně zná a
  aktivně doporučuje pro nové projekty; výchozí volba.
• Trial (vyzkoušet) — nástroj, který vypadá slibně a tým ho
  chce ověřit na reálném, ale nízkorizikovém projektu, než ho
  doporučí plošně.
• Assess (sledovat) — nástroj, o kterém tým ví a sleduje jeho
  vývoj, ale zatím nemá dost zkušeností ani kapacitu ho zkoušet
  aktivně.
• Hold (nezavádět/opouštět) — nástroj, který se pro nové
  použití nedoporučuje — buď je zastaralý, nahrazený lepší
  alternativou, nebo se ukázal jako problematický v praxi.

Radar se typicky rozděluje ještě do kvadrantů podle typu (jazyky
a frameworky, nástroje, platformy, techniky/procesy) a aktualizuje
se v pravidelném intervalu (např. jednou za čtvrt roku) na
společném setkání týmu, kde se navrhují přesuny mezi prstenci.
Hodnota radaru není jen ve výsledné mapě, ale v samotné diskuzi —
nutí tým si nahlas říct, proč nástroj X věří a nástroj Y ne, a
zaznamenat to na jedno viditelné místo, ke kterému se dá odkazovat
při budoucích rozhodnutích (podobně jako ADR z minulé lekce
zaznamenávají důvod jednotlivého rozhodnutí, radar zaznamenává
celkový přehled).

Kritéria hodnocení nového nástroje

Než se nástroj posune z "assess" do "trial", je užitečné projít
konkrétní kontrolní seznam:

1. Jaký konkrétní problém řeší? Pokud odpověď je vágní
   ("je to modernější"), jde o špatný kandidát — musí existovat
   měřitelný problém, který stávající řešení neřeší dobře.
2. Zralost a komunita. Jak dlouho nástroj existuje, jak aktivní
   je vývoj, jak velká komunita, existuje komerční podpora?
   Nástroj bez aktivní komunity je riziko, i když funkčně vyhovuje.
3. Provozní náročnost. Kolik práce si vyžádá provoz nástroje
   samotného (další systém k monitorování, zálohování, upgradům)?
4. Integrace se stávajícím stackem. Zapadá do existující
   infrastruktury (viz volby z modulů 7–11), nebo vyžaduje zásadní
   přestavbu okolí?
5. Náklady na exit. Jak těžké by bylo se od nástroje odklonit,
   kdyby se ukázal jako špatná volba (vendor lock-in, proprietární
   formáty dat)?
6. Bezpečnostní a compliance dopad (viz modul 13) — nevyžaduje
   nástroj přístup k citlivým datům způsobem, který poruší
   compliance požadavky?

Bezpečné zavádění: pilot, ne velký třesk

I po kladném vyhodnocení kritérií výše se nový nástroj nezavádí
najednou do celé produkce. Standardní bezpečný postup:

1. Pilot na omezeném rozsahu — jeden nekritický projekt, tým
   nebo prostředí (např. staging, ne produkce).
2. Definice úspěchu předem — jaké metriky pilot musí splnit,
   aby se rozhodlo o rozšíření (např. "nasazení musí být stabilně
   rychlejší o alespoň 30 % po dobu čtyř týdnů").
3. Časové ohraničení — pilot má konec, po kterém se vyhodnotí,
   ne že "zkoušíme donekonečna".
4. Zpětná vazba od uživatelů (vývojářů, kteří s nástrojem
   pracují) — technická metrika nestačí, pokud nástroj lidem
   komplikuje práci.
5. Rozhodnutí a záznam — výsledek pilotu se zaznamená (ideálně
   jako ADR, viz předchozí lekce) a promítne do radaru.

Praktický příklad

Ukázka jednoduchého technology radaru zapsaného jako Markdown tabulka
verzovaná v repozitáři (docs as code z předchozí lekce), s příkladem
reálného rozhodnutí:

# Technology radar — tým Platforma (aktualizace Q2 2024)

## Nástroje

| Nástroj          | Prsten | Poznámka |
|------------------|--------|----------|
| Terraform        | Adopt  | Standard pro veškerou infrastrukturu od 2022 |
| Ansible          | Adopt  | Konfigurace serverů mimo Kubernetes |
| ArgoCD           | Trial  | Pilot na staging clusteru do konce Q3, cíl: nahradit ruční `kubectl apply` v CI |
| Pulumi           | Assess | Sledujeme jako alternativu k Terraformu, zatím bez kapacity na pilot |
| Jenkins          | Hold   | Nahrazeno GitHub Actions (viz ADR-021), nezakládat nové pipeline |

## Rozhodnutí k ArgoCD (pilot Q2–Q3 2024)

**Problém:** ruční `kubectl apply` v CI pipeline (modul 9) nedává
viditelnost do skutečného stavu clusteru a neumí automatický rollback
při driftu konfigurace.

**Kritéria úspěchu pilotu:**
- Nasazení viditelné v UI bez nutnosti SSH na CI runner.
- Detekce configuration driftu do 5 minut od změny mimo Git.
- Žádný nárůst průměrné doby nasazení oproti současnému stavu.

**Rozsah pilotu:** jeden nekritický staging cluster, tým Platforma,
8 týdnů. Rozhodnutí o rozšíření na produkci padne na review 15.9.2024.

Shrnutí

Zavádění nových nástrojů má reálné náklady (učení, migrace, provoz,
riziko), a proto zaslouží stejně vědomé rozhodování jako architektonické
volby. Technology radar (prstenty Adopt/Trial/Assess/Hold) dává týmu
sdílený, pravidelně aktualizovaný přehled o tom, čemu důvěřuje a proč.
Kontrolní kritéria (problém, zralost, provozní náročnost, integrace,
náklady na exit, bezpečnost) pomáhají vyhodnotit kandidáta dřív, než
se do něj investuje čas. Zavádění samotné probíhá přes časově ohraničený
pilot s předem definovanými kritérii úspěchu, ne jako plošná změna
najednou.

Kontrolní otázky

1. Co znamenají jednotlivé prstence technology radaru (Adopt, Trial,
   Assess, Hold) a kdy se nástroj posouvá mezi nimi?
2. Proč je "je to modernější" nedostatečný důvod pro zavedení nového
   nástroje a jaká otázka by měla nahradit toto zdůvodnění?
3. Jaká jsou rizika zavedení nového nástroje "velkým třeskem" rovnou
   do celé produkce místo pilotního nasazení?
4. Mini cvičení: navrhněte technology radar se třemi nástroji z
   libovolného modulu této sekce (např. z Modulu 7 nebo 8), zařaďte
   je do prstenců a zdůvodněte zařazení jednou větou u každého.