CI/CD pipeline může převzít část role CAB

Na pravidelném CAB čeká dvacet osm změn. Na každou vycházejí přibližně tři minuty. Přítomní se ptají, zda proběhly testy, bezpečnostní kontrola, existuje návratový plán a je schválené nasazovací okno. Odpovědi bývají kladné a jejich hlavním důkazem je správně vyplněný ticket.

Ve stejném prostředí může CI/CD pipeline doložit, kdo změnu vytvořil, kdo ji nezávisle schválil, který commit prošel testy, jaký artefakt z něj vznikl, zda splnil bezpečnostní politiku a co se stalo při prvních fázích nasazení. Pokud některá podmínka neprojde, změna se vůbec nemusí dostat do produkce.

To není argument pro zrušení governance. Je to argument pro přesun opakovatelných kontrol z porady do systému, který je dokáže vynutit. CAB nebo jiná change authority má rozhodovat o pravidlech, třídách změn a výjimkách. Pipeline musí mít autoritu říct ne.

CAB není schůzka. Je to change authority

V článku používám CAB jako srozumitelnou zkratku pro schvalovací autoritu. Moderní change enablement nemusí mít podobu pravidelné porady. PeopleCert popisuje jeho účel jako přesné posouzení rizika, autorizaci změn a řízení jejich harmonogramu. DORA současně doporučuje realizovat schvalování především peer review během vývoje a doplnit je automatizací, která špatnou změnu zachytí co nejdříve.

Z toho plyne důležitý posun. U opakované nízkorizikové změny nemusí autorita pokaždé znovu rozhodovat, zda věří týmu. Může jednou schválit třídu změny, povinné důkazy a technické hranice. Každý další release je autorizován pouze tehdy, když tyto podmínky skutečně splní.

Co může pipeline skutečně převzít

Tradiční CAB se často snaží ověřit, že změnu posoudili správní lidé, proběhly požadované testy, byly splněny bezpečnostní požadavky a nasazení proběhne ve vhodném okně. AWS tyto otázky uvádí jako typickou náplň manuálního change validation. Vyspělá pipeline je však může nejen zobrazit, ale také technicky vynutit.

GitHub například umožňuje vynutit status checks, určit důvěryhodný zdroj výsledku, chránit prostředí, zakázat self-review a podmínit přístup k environment secrets schválením. SLSA a nástroje typu Binary Authorization přidávají ověřitelnou provenance a možnost nasadit jen artefakt, který vznikl schváleným procesem.

Moderní CAB má čtyři vrstvy

Samotná sada testů ještě nevytváří change authority. Aby pipeline převzala část tradičního schvalování, musí spojit čtyři vrstvy: důkaz, politiku, výjimku a správu samotných pravidel.

Schvalujte třídy změn, ne každý ticket

Každá služba by měla mít vlastní change contract: kritičnost, povolené typy změn, povinné důkazy, maximální blast radius, strategii nasazení, stop podmínky, recovery třídu a autoritu pro výjimku. Potom lze změny vést různými cestami podle skutečného rizika.

Tento model neodstraňuje člověka z continuous delivery. AWS výslovně rozlišuje continuous delivery, kde může před produkcí zůstat manuální approval, a continuous deployment bez explicitního schválení. Podstatné je, aby lidský krok rozhodoval o riziku, nikoli znovu ručně opisoval technické výsledky.

Kde pipeline CAB nenahradí

Pipeline umí velmi dobře vyhodnocovat to, co je předem popsáno a technicky pozorovatelné. Hůře rozhoduje o kontextu, který do politiky dosud nikdo nepřevedl. Lidská change authority je důležitá zejména tehdy, když změna:

• má nevratný datový, účetní nebo zákaznický dopad;

• otevírá nový datový tok, právní závazek nebo regulatorní otázku;

• mění několik služeb, týmů či dodavatelů a pipeline nevidí celý řetězec závislostí;

• vyžaduje vědomé přijetí obchodního rizika nebo neobvyklé načasování;

• je první svého druhu a organizace ještě nezná spolehlivé stop podmínky;

• překračuje připravenou provozní kapacitu podpory, incident response nebo obnovy.

Největší past: zelená pipeline s možností bypassu

Zelená pipeline může vytvořit falešný pocit bezpečí. Kontrola je silná pouze tak, jak silný je její nejsnazší způsob obejití. GitHub například umožňuje zablokovat administrátorské bypassy a určit konkrétní aplikaci jako důvěryhodný zdroj status checku. Google u Binary Authorization zdůrazňuje omezení jednostranného zásahu člověka do produkce.

Modelový příklad: z dvaceti ticketů tři skutečná rozhodnutí

Představme si tým, který nasazuje aplikaci dvakrát týdně. CAB pokaždé prochází přibližně dvacet změn. Většina je podobná: peer review, stejné testy, stejná služba a stejný canary postup. Komise se proto soustředí hlavně na úplnost ticketu.

Po změně modelu získají běžné aplikační releasy předem schválenou cestu. Pipeline vyžaduje dva reviews u citlivých částí, všechny testy, bezpečnostní prahy, důvěryhodný artefakt a úspěšnou první fázi rollout. Databázová migrace s mazáním dat, nový odchozí datový tok a emergency bypass zůstávají předmětem lidského rozhodnutí.

CAB pak neřeší dvacet technicky podobných položek. Řeší tři výjimky, u kterých je skutečně potřeba úsudek. Cílem není méně schůzek samo o sobě. Cílem je vyšší rozlišení rozhodnutí a lepší důkaz u každé standardní změny.

Osm otázek pro vedení IT

• Dokážeme každý produkční artefakt jednoznačně spojit s commitem, review, buildem a výsledky kontrol?

• Může někdo změnu sám vytvořit, schválit, obejít policy a nasadit?

• Přijímáme status checks pouze od jmenovaných a chráněných nástrojů?

• Lze produkci nebo její konfiguraci měnit mimo evidovanou pipeline?

• Zastaví rollout měřitelný health signal dříve, než změna zasáhne celý provoz?

• Které třídy změn jsou skutečně předem autorizované a kde začíná lidské rozhodnutí?

• Mají všechny výjimky vlastníka, důvod, rozsah a datum expirace?

• Kdo schvaluje změny samotné pipeline, testovacích prahů a policy-as-code?

Třicetidenní přechod od porady k autoritě

Vedení by potom nemělo měřit pouze počet automaticky schválených změn. Důležitější je change failure rate, doba čekání na rozhodnutí, podíl bypassů, počet trvalých výjimek, úplnost auditní stopy a incidenty způsobené změnami, které všemi gates prošly.