Felelősségek, kockázatok, antiminták és nyomon követhetőségi igények azonosítása
Ahogy az ügynökök egyre alkalmasabbak lesznek, csábító lehet elképzelni, hogy a felelősség átkerül a rendszerbe. Nem. Az ügynöki rendszerek végrehajthatják a munkát, de az emberek továbbra is elszámoltathatók az eredményekért és a végrehajtást szabályozó vezérlőkért.
Ebben az egységben meg fogsz tanulni,
Ki felelős az ügynökműveletekért és -eredményekért?
Milyen gyakori kockázatok és antiminták jelennek meg az ügynökrendszerekben?
Hogyan enyhítik a GitHub vezérlői ezeket a kockázatokat
Miért van szükség a megbízható rendszerek nyomon követhetőségére és megfigyelhetőségére?
A felelősség nem változik a végrehajtással
Amikor egy ügynök létrehoz egy lekéréses kérelmet, módosítja a kódot, vagy válaszol a visszajelzésekre, részt vesz a munkafolyamatban, de nem vállalja az eredmények tulajdonjogát. A felelős felek továbbra is azok a személyek és csapatok, akik:
A tevékenység definiálása
Engedélyek beállítása
Vezérlők kiválasztása és konfigurálása
Az eredményként kapott módosítás jóváhagyása
A lekéréses kérelmek felülvizsgálati modellje egyértelművé teszi ezt: a rendszer javasolhat, de az emberek eldöntik, hogy mit fogadnak el.
Gyakori kockázatok és antiminták
A korai fázisú ügynökrendszerek általában kiszámítható módon hiúsulnak meg:
Terv nélküli végrehajtás: Az ügynök világos, vizsgálható megközelítés nélkül kezdi meg a kód módosítását.
Túlengedélyezett ügynökök Az ügynök (vagy annak munkafolyamat-jogkivonata/eszközkezelési hitelesítő adatai) a szükségesnél szélesebb körű hozzáféréssel rendelkezik.
Rejtett érvelés: A munkafolyamat csak a kimeneteket (a diffet) teszi elérhetővé köztes összetevők (terv, feltételezések, döntési pontok, végrehajtási környezet) nélkül.
Az automatizálásban való vak megbízhatóság fontos a CI átadásában, de csak ellenőrzi, hogy mit terveznek észlelni. Az átmenő buildek nem jelentik automatikusan azt, hogy a módosítás befejeződött, megfelelő vagy alacsony kockázatú.
Implementáció-leképezés: kockázatcsökkentés → GitHub
| Kockázat / antipattern | Hogyan néz ki a GitHub | Mérséklés GitHub vezérlők használatával |
|---|---|---|
| Terv nélküli végrehajtás | PR-nek van egy diffje, de nincs hozzá terv vagy indoklás. | Tervszakasz megkövetelése PR-sablonon keresztül; ellenőrzés megkövetelése az egyesítés előtt |
| Túlengedélyezett ügynökök | A munkafolyamatok írhatnak adattárba, és széles körben elérhetik a titkos kulcsokat | Minimális jogosultsági GITHUB_TOKEN; a szükséges felülvizsgálókkal rendelkező környezetek; munkafolyamatok indításának korlátozása |
| Rejtett érvelés | Nincs feltételezés/hatókör/döntési nyomvonal | Munkafolyamat-futtatások tervezésének és csatolásának megkövetelése, valamint döntések rögzítése a pr-megjegyzésekben |
| Vak megbízhatóság az automatizálásban | "CI sikeres volt, engedjük ki" gondolkodásmód | Ellenőrzések kombinálása CODEOWNERS-ekkel, szükséges felülvizsgálatokkal és kockázatalapú jóváhagyásokkal |
Nyomon követhetőség és megfigyelhetőség
Egy ügynök hatékony felügyeletéhez többre van szükség, mint egy végső különbségelemzésre – nyomkövetésre van szüksége. A GitHub az alábbiakat tartalmazhat:
Lekéréses kérelmek és véglegesítési előzmények
Megjegyzések és jóváhagyások áttekintése
Munkafolyamat futtatása és feltöltött összetevők (tesztjelentések, naplók)
Kódvizsgálati feltöltések és riasztások
Titkos adatok vizsgálati riasztásai és push védelem eseményei
Szervezeti naplózási naplóesemények (a rendelkezésre állás és a hozzáférés a szervezeti/vállalati konfigurációtól függ)
A cél nem csak a megfelelőség. A működés megértése: ha valami meghiúsul, tudnia kell, hogy mi változott, ki hagyta jóvá, milyen bizonyítékok léteztek, és mi történt a következő lépésben.
Az ügynöki hozzájárulások minimális ellenőrzési nyomvonala
** Egy megadott cél (problémahivatkozás vagy pull request leírása)
Vizsgálható terv (PR-tervszakasz vagy -fájl)
Egy határolt változáskészlet (ág és kötelezés)
Automatizált bizonyítékok (munkafolyamat futtatása és artefaktumok)
Emberi ítélet (felülvizsgálat és jóváhagyás)
Egyértelmű eredmény (egyesítés, visszaállítás vagy eszkaláció)
Tegyük fel, hogy az ügynök biztonsági résének javítása megfelel a CI-nek, de később regressziót okoz. A fő kérdés nem csak az, hogy az ügynök hibát követett-e el, hanem az is, hogy a rendszer érthetővé és megelőzhetővé tette-e a hibát:
Volt látható terv és hatókör?
A megfelelő véleményezőket kérték (és jóváhagyták)?
Megegyeztek az ellenőrzések a változás kockázatával?
A napló elegendő a történtek rekonstruálásához?
Az ügynöki rendszerek megváltoztatják, hogy ki végez munkát, de azt nem, hogy kié az eredmény. Az emberi csapatok elszámoltathatóak maradnak, ezért kell a közös antiminták alapján tervezniük, és erős nyomon követhetőséget kell megkövetelniük GitHub natív összetevők és naplók segítségével.
Miután megismerte a felelősség működését, az utolsó lépés annak eldöntése, hogyan kell megítélni az ügynök munkáját. A következő leckében a közreműködői modellt fogja alkalmazni az ügynök által generált kimenetre.