Divadlo lidského zásahu
Nesprávná debata, kterou týmy stále vedou: plná automatizace versus plná manuální kontrola.
Vysoce výkonné týmy nedělají ani jedno. Automatizují deterministické provádění a lidská rozhodnutí si vyhrazují pro rizikové hranice, kde úsudek podstatně mění výsledek.
Otázka nezní „měli by se zapojit lidé?“. Zní „kde člověk skutečně zlepší rozhodnutí?“.
Lidská kontrola přidává skutečnou hodnotu, když:
- Existuje nejednoznačný kompromis rizika
- Je řešena výjimka z politiky
- Je třeba vyřešit konflikt priorit napříč týmy
- V kontextu je incident ovlivňující zákazníka
Nepřidává hodnotu pro opakované deterministické kontroly, které již mají explicitní kritéria pro úspěch/neúspěch. Žádost o schválení tam nezvyšuje bezpečnost – zvyšuje dobu čekání ve frontě.
Definujte hranice schvalování jako architektonická rozhodnutí, nikoli zvyky. Povýšení do produkce, přepsání bezpečnostních kontrol, dočasné výjimky z politik, nouzové obcházení rollbacků – to jsou skutečné hranice. Vše ostatní by mělo být řízeno pracovním postupem.
V letech 2025 a 2026 patří na tento seznam další hranice: změny důvěryhodnosti upstreamu.
Pokud pracovní postup zavádí novou akci třetí strany, mění akci z připnutí SHA commitu zpět na měnitelnou značku, rozšiřuje rozsah tokenu runneru nebo otevírá novou cestu provádění nesoucí tajemství, nejedná se o rutinní úpravu. Jedná se o událost řízení. Zacházejte s ní jako s takovou.
Tři stavy řízení:
- Prošlo: všechny požadované automatizované brány uspěly
- Blokováno: požadovaná brána selhala nebo došlo k závažnému porušení politiky
- Eskalovat: nedostatečné automatizované důkazy; vyžadováno lidské rozhodnutí
Když je potřeba eskalace, předání musí být kompaktní: co selhalo, které brány jsou ovlivněny, odkazy na důkazy, operační riziko, doporučené možnosti. Žádné výpisy logů. Recenzenti potřebují podporu rozhodování, ne archeologii.
Varovný signál, že něco není v pořádku: stínové řízení. Inženýři říkají „dostali jsme ústní schválení“ bez artefaktu. Manuální rozhodnutí o opakovaném spuštění se neprojevují v záznamech pracovních postupů. Kritéria rozhodování se liší napříč týmy. Pokud se to děje, váš model řízení není dostatečně silně zakódován.
Nepřeskakujte z manuálních operací k plné autonomii. Budujte důvěru prostřednictvím důkazů:
- Režim pozorování – pracovní postup doporučuje, lidé rozhodují.
- Asistovaný režim – pracovní postup automaticky provádí nízkorizikové brány, lidé schvalují na hranicích.
- Řízená autonomie – pracovní postup zpracovává většinu cest, eskaluje definované výjimky.
Nedávné incidenty v dodavatelském řetězci činí tento postup ještě důležitějším. Týmy, které skočí rovnou na „automatizace ví, co dělat“, obvykle příliš pozdě zjistí, že automatizace také s radostí provádí otrávené závislosti, útočníkem kontrolované značky nebo kompromitované verze správců, pokud nikdo nezakódoval hranici důvěry do zdroje.
Co jsme vybudovali v Kolsetu: řízení je kompilováno, nikoli vynucováno konvencí. allow_default_branch=false tvrdě selže spuštění, pokud někdo spustí orchestraci z main nebo master – žádné výjimky, žádné ústní přepsání. Každá brána se vyřeší do jednoho ze tří explicitních stavů: passed, skipped-by-input nebo failed. strict_full_plan=true tvrdě selže spuštění, pokud se jakákoli definovaná brána nevyřeší do explicitního stavu – žádné tiché průchody. Eskalace vždy zahrnuje strukturovaný balíček: co selhalo, které brány jsou ovlivněny, odkazy na důkazy, doporučené možnosti. Balíček je nesmlouvavý, protože bez něj se eskalace stává požárním poplachem bez adresy.
Pozorovatelnost vytvořená pro jednu úlohu
Agentní pracovní postupy jsou často zaváděny jako „chytřejší automatizace“.
Provozní, chovají se jako distribuované systémy – více fází, asynchronní závislosti, částečná selhání, opakování, časové limity, lidské předávání.
Pokud váš model pozorovatelnosti předpokládá jednu lineární úlohu, řešení incidentů bude pomalé. A pokud jste postavili brány 8–11 z části 2 (pokrytí jazyka, systémové metriky, integrita záznamů, hygiena logů), již jste vytvořili přesně tento druh závislosti na distribuovaném stavu. Hodnocení pokrytí jazyka, například, zahrnuje více volání, více jazyků, kontext na úrovni relace. Neexistuje jediný řádek logu, který by vám řekl, že prošlo.
Pozorujte čtyři vrstvy:
- Orchestrační vrstva – události odeslání, přechody bran, časování
- Vrstva provádění workerů – jednotlivá spuštění bran, použité vstupy, vyprodukované výstupy
- Výstupní/mutační vrstva – co se skutečně změnilo a kdy
- Vrstva rozhodování o řízení – rozhodnutí o průchodu/blokování/eskalaci a jejich důkazy
Pro každé spuštění zachyťte: identitu spuštění a korelační ID, přechody bran s časovými razítky, události odeslání a dokončení, reference a hashe artefaktů, provedené výstupní operace, konečný stav rozhodnutí a důvod.
A pro jakýkoli pracovní postup, který se může dotknout tajemství, sestavení, balíčků nebo cest nasazení, zachyťte také důkazy o důvěře: které SHA akce se skutečně spustily, které verze balíčků se vyřešily, které odchozí hostitelé byli kontaktováni, které rozsahy tokenů byly použity a zda spuštění překročilo hranici schválení.
Bez toho jsou opakování slepá a audity drahé.
Stavte pro přehrávání, nejen pro opakování.
Opakování je užitečné, když je pravděpodobné přechodné selhání. Přehrávání je nezbytné, když potřebujete důvěru v kauzální analýzu – opětovné spuštění segmentu se stejnými vstupy, omezeními a kontextem politiky, abyste pochopili proč něco selhalo, nejen že selhalo.
„Teď to funguje, neznámo proč“ není přijatelný stav obnovy.
Klasifikujte selhání konzistentně: selhání vstupu, selhání politiky, selhání závislosti, selhání logiky, selhání výstupu. Tato klasifikace patří do vašich souhrnů a upozornění.
Tento kbelík selhání závislostí už není teoretický. Nyní pokrývá přesně ty scénáře, kterými se týmy stále pálí: kompromitovaná značka akce, otrávený artefakt vydání, podezřelý přístup k paměti runneru nebo neočekávaný odchozí provoz během kroku sestavení, který „obvykle jen instaluje nástroje“.
Upozornění by měla být akceschopná do jedné minuty: název brány, třída selhání, korelační ID, přímý odkaz na spuštění, navrhovaná první akce a jakýkoli abnormální signál důvěry (nová síťová destinace, nepřipnutá závislost, změna rozsahu tokenu nebo neočekávaná cesta provádění). Pokud upozornění nepomůže inženýrovi udělat první krok do 60 sekund, je neúplné.
Po každém významném incidentu se zeptejte: bylo to možné předejít pravidly zdroje? Bylo selhání odhaleno ve správné fázi? Jaké jediné instrumentační pole by zkrátilo diagnostiku? Zakódujte odpověď do zdroje a testů. Ne do paměti.
Co jsme vybudovali v Kolsetu: každá brána v souhrnu před sloučením zahrnuje název pracovního postupu, ID spuštění, URL spuštění a stav. Vstupní záložní hodnoty brány jsou logovány, aby recenzenti viděli, co orchestrace skutečně použila, nikoli jen to, co bylo předáno. Když je potřeba přehrávání, přesné vstupy, omezení a pořadí provádění bran jsou pevně stanoveny v době kompilace ve zdrojovém .md – nikoli rekonstruovány z paměti. Režim selhání je explicitní: "Okamžitě zastavit při prvním tvrdém selhání a vytvořit stručnou zprávu o selhání s URL spuštění a další akcí."
Provozní lekce z poslední vlny kompromitací dodavatelského řetězce je jednoduchá: pokud nemůžete rychle odpovědět na otázku „jaký přesný upstream kód se spustil, s jakými oprávněními a s čím se pokusil komunikovat?“, pak vaše pozorovatelnost není připravena na produkční automatizaci.
Měření aktivity namísto výsledků
Většina týmů měří špatné věci:
- Počet vytvořených pracovních postupů
- Počet spuštění agentů
- Snížení počtu manuálních komentářů
Toto jsou metriky aktivity. Skutečnou otázkou je, zda se zlepšila rychlost dodání, zatímco kvalita a kontrola zůstaly zachovány.
Třívrstvý metrický model:
Vrstva 1 – Výkon dodávky:
- Doba od sloučení do nasazení (Merge lead time)
- Doba od připravenosti PR do konečného rozhodnutí
- Doba čekání ve frontě na hranicích řízení
Vrstva 2 – Kvalita a spolehlivost:
- Uniklé vady spojené se selháním procesu sloučení
- Míra opětovného otevření/vrácení pro sloučené změny
- Frekvence opakovaného spouštění selhaných bran
Vrstva 3 – Riziko a řízení:
- Míra porušení politiky
- Míra blokování detekce hrozeb
- Míra lidských zásahů podle kategorie
- Počet schválení výjimek
Používejte jak předstihové, tak zpožděné indikátory. Předstihové (stabilita průchodu brány, vady nejednoznačnosti výzev, latence od upozornění k akci) pro rychlé řízení. Zpožděné (míra incidentů, průměrná doba obnovy, důvěra zúčastněných stran v připravenost automatického sloučení) pro ověření směru.
Nastavte základní linii před nasazením: předchozí 30denní časování rozhodnutí o sloučení, stávající počet manuálních kontaktních bodů, aktuální profil incidentů vydání. Měřte po 30/60/90 dnech po přijetí. To poskytuje spravedlivé srovnání a zabraňuje reportování založenému na vyprávění.
Když se výkon zlepší, zeptejte se, co to způsobilo. Návrh pracovního postupu? Změna chování týmu? Snížený objem? Stabilizace prostředí? Nepřipisujte vše agentnímu pracovnímu postupu.
Po 90 dnech „dobře“ vypadá takto:
- Nižší latence rozhodnutí o sloučení
- Méně manuálních kroků předání
- Stabilní nebo zlepšený profil vad/vrácení
- Jasné hranice pro lidskou eskalaci
- Lepší auditovatelnost rozhodnutí o vydání
Jediný problém? Pokud se rychlost zlepší, ale rizikové signály se zhorší, problém jste nevyřešili. Jen jste ho zrychlili.
A přesně to odhalily tyto nedávné incidenty. Spousta týmů měla rychlé pipeline. Neměly důvěryhodné pipeline.
Co jsme vybudovali v Kolsetu: brána před sloučením končí zprávou o pokrytí – 11 bran, každá s explicitním stavem (prošlo / přeskočeno / selhalo). Po 90 dnech přesně víme, které brány selhávají nejčastěji, které jsou nejpomalejší a kde se shlukují opakování. Signál není „kolik pracovních postupů se spustilo“ – je to „kolik větví prošlo všemi 11 branami čistě bez opakování“. To je to, co koreluje s produkční stabilitou.
Úplný kontrolní seznam série – všech 8 základů:
- Explicitní graf bran
- Logika pracovního postupu spravovaná zdrojem/kompilací
- Bezpečnostní kontroly nativní, nikoli dodatečně přidané – včetně neměnných referencí, přísných oprávnění a explicitních hranic důvěry
- Oddělené odpovědnosti orchestrace a workerů
- Výzvy napsané jako protokoly
- Lidská schválení založená na hranicích, nikoli na zvyku
- Přehrávatelná pozorovatelnost
- Měření výsledků, nikoli aktivity
Boom. Pokud můžete na všech osm odpovědět ano, váš program agentních pracovních postupů funguje jako inženýrský systém, nikoli jako demo.
Další čtení:
