Dokumentáció és információkezelés: Runbook, Post mortem és Corporate Memory

Nyereség:

• Lehetőség runbook, post mortem és építészeti dokumentumvázak előállítására szétszórt jegyzetekből mesterséges intelligenciával
• Képes érvényesíteni a „gyártási tilalom” szabályait, valamint minden egyes runbook alapos tesztelését és megjelölését valós környezetben
• Képes megérteni, hogy egy rossz runbook veszélyesebb, mint a semmi, és életben tartani a dokumentációt a változtatási folyamat során

Dokumentáció és információkezelés: Runbook, architektúra és intézményi memória AI-val

A rendszermenedzsment leginkább elhanyagolt, de életmentő feladata a dokumentáció. Amikor egy rendszer összeomlik, és az azt építő személy szabadságon van, és nincs írott szó a helyreállításról, ez egy hosszú éjszaka mindenkinek. A dokumentáció az az intézményi memória, amely írottá és elérhetővé teszi a rendszer felállítását, működését, és mit kell tenni probléma esetén. Ennek a memóriának a legkritikusabb típusa a runbook: egy működési útmutató, amely lépésről lépésre elmondja, mit kell tenni egy adott helyzetben (a szolgáltatás összeomlott, a lemez megtelt, a biztonsági mentés sikertelen). Itt az AI megoldja az "üres oldal" és a "lustaság" problémáját, amelyek a dokumentációírás legnagyobb ellenségei: a szétszórt jegyzetekből rendezett runbookot, parancstörténetből eljárást, architektúrából leírást készít. De a kritikus elv: az AI tervrajzokat és csontvázakat készít; Te vagy az, aki minden egyes lépést tesztel és érvényesít, hogy kiderüljön, valóban helyes-e – egy rossz runbook veszélyesebb, mint a runbook hiánya.

Ebben az egységben runbook, post mortem (esemény utáni vizsgálati jelentés), építészeti dokumentáció és tudásbázis írás; Piszkozatok generálása mesterséges intelligencia segítségével; és ami a legfontosabb, megtanulja az ellenőrizetlen dokumentáció kockázatait.

Miért rosszabb a rossz runbook, mint a nem runbook?

Ez az egység legfontosabb koncepciója. A runbook nélküli csapat pánik idején óvatos és gyanakvó; kétszer gondol minden parancsot. De valaki, akinek van „hivatalos” runbookja, vakon megbízik benne – az éjszaka közepén, stresszhelyzetben, kérdés nélkül végrehajtja a lépéseket. Ha ezt a runbookot anélkül adják ki, hogy mesterséges intelligencia állította volna elő és tesztelte volna, és egy lépésben hibás (rossz parancs, hiányzó előfeltétel, kihagyott tartaléklépés), az eredmény katasztrofális. Ezért minden mesterséges intelligenciával előállított runbookot az elejétől a végéig valós környezetben kell futtatni, és minden lépést ellenőrizni kell a közzététel előtt. A teszteletlen runbook olyan, mint egy megnyugtató, de üres ígéret.

Vigyázat: bélyegezzen egy runbookot a következővel: "tesztelt: [dátum], [személy]". A nem tesztelt piszkozatokat egyértelműen jelölje meg a „VÁZLAT – NEM ELLENŐRZETT” címkével. Tehát senki sem alkalmazna biztonságosan ellenőrizetlen lépéseket valódi válsághelyzetben.

Egy jó runbook anatómiája

Egy jó runbook meghatározott részekből áll, és az AI jó ennek a váznak a felépítésében: cím és cél (milyen helyzetre), előfeltételek (milyen hozzáférés, milyen eszköz szükséges), tünetek (mikor használom ezt a runbookot), lépések (számozott, másolható parancsokkal), érvényesítés (hogyan ismerjük fel a sikert minden lépés után), visszaállítás (hogyan lehet visszavonni, ha egy lépés rosszul sül el), és kitalálom, ha megtehetem. Megadhatja az AI-nak a szétszórt jegyzeteit, és megkérheti, hogy helyezze el ebbe a szerkezetbe; Csak a tartalom pontosságát garantálod.

Lépésről lépésre: Dokumentáció készítés AI-val

1. Gyűjtsd össze az alapanyagot. A parancselőzmények, a jegyzetek, egy régi e-mail, egy csevegési napló – a valódi anyag, még ha rendetlen is, jobb, mint a mesterséges intelligencia.
2. Kérjen szerkezetet. "Tegye ezt a runbookot a következő címsorokkal: cél, előfeltétel, tünet, lépések, ellenőrzés, visszaállítás, eszkaláció."
3. Tiltsuk be a koholmányt. "Ne adjon hozzá semmilyen parancsot, IP-címet, verziót vagy lépést, amelyet nem adtam meg; a hiányzó részeket jelölje meg [KITÖLTHETŐ]-ként." Ez megakadályozza a legveszélyesebb hibát – a hihetőnek tűnő kitalált lépéseket.
4. Maszk. Helyőrző használata a tényleges gazdagép, IP, felhasználó helyett; Ha a dokumentumot megosztják, a titkot nem szabad kiszivárogtatni.
5. Teszteld. Futtassa a runbookot az elejétől a végéig valós (lehetőleg teszt) környezetben. Javítsa ki a nem működő, hiányzó vagy nem egyértelmű lépéseket.
6. Bélyegző és közzététel. Adja hozzá a teszt dátumát, a tesztelőt és az utolsó frissítést. A dokumentáció élénk; A rendszer változása esetén frissíteni kell.

három mini tok

1. eset – 2 óra munka, 15 perc. Egy rendszergazda hónapokig halogatta a biztonsági mentés visszaállítási eljárásának dokumentálását. Megadta a terminálparancsok előzményeit (maszkolt) és néhány elszórt megjegyzést az AI-nak, és beillesztette a runbook keretrendszerbe. Az AI 15 perc alatt szép körvonalat készített. Az adminisztrátor a következő 45 percet azzal töltötte, hogy a vázlatot az elejétől a végéig futtatta egy tesztszerveren, és kijavította a két hiányzó lépést. Az eredmény: tesztelt, megbízható runbook.

2. eset – Hamisan elkapták. Egy csapat az AI-vel írt egy szolgáltatás-újraindítási runbookot, de elfelejtette betiltani a "gyártást". Az YZ hozzáadott egy "először ürítse ki a gyorsítótárat" parancsot, amely logikusnak tűnik, de nem létezik abban a szolgáltatásban. Szerencsére a mérnök futtatta a runbookot a tesztkörnyezetben; Ez a parancs hibát adott. A tesztlépés egy kitalált lépést ragadott meg, amely valódi válsághelyzetben zavart kelt.

3. eset – Post mortem gyorsított. Egy nagyobb kiesés után a csapatnak utólagos vizsgálatot kellett írnia, de senki sem tudott hozzákezdeni. Átadták az esemény idővonalát és a maszkolt naplókat az MI-nek, és kértek egy feddhetetlen post mortem csontvázat – összefoglalót, hatást, idővonalat, kiváltó okot, korrekciós intézkedéseket. Az AI-terv tíz percre csökkentette az egyórás munkát; A csapat a tények ellenőrzésére és a cselekvési tételek tisztázására fordította energiáját.

Négy másolható sablon

1) Runbook váz létrehozása:

Az Ön szerepe: vezető SRE. Hozzon létre egy runbookot az alábbi maszkolt jegyzetekből/parancselőzményekből. Címsorok: Cél, Előfeltételek, Tünetek (mikor kell használni), Lépések (számozott, másolható), Ellenőrzés minden lépésnél, Visszagörgetés, Eszkaláció. SZABÁLY: Ne találj ki olyan parancsot/IP-t/verziót/lépést, amelyet nem adok neked; írja be a hiányzó részeket [KITÖLTENI]. Anyaga: [maszkos megjegyzés]

2) Post mortem hibáztatás nélkül:

Az Ön szerepe: az incidens kivizsgálásának segítője. Írjon egy FEJEZETMENTES poszt mortem vázlatot a következő maszkolt idővonalból és naplókból: Összegzés, Hatás (időtartam/hatókör), Idővonal, Kiváltó ok (ha igazolt), Közreműködő tényezők, Javító intézkedések (tulajdonos + prioritás). Ne az embert hibáztasd, hanem a rendszerre koncentrálj. Ne írjon kiváltó okot bizonyíték nélkül. Adatok: [...]

3) Építészet/szolgáltatás leírása:

Írjon szervizdokumentumot a következő maszkolt konfigurációs/diagram információkból: mit csinál a szolgáltatás, milyen összetevőkből áll, milyen függőségei vannak, hogyan folyik az adatáramlás, milyen portok/protokollok. Legyen technikai, de olvasható. Jelölje meg azt a kapcsolatot, amelyben nem biztos, hogy „ellenőrzést igényel”. Info: [maszkos]

4) Dokumentáció-frissítő audit:

Tekintse át a következő meglévő dokumentumot, és ellenőrizze a pénznemet: (1) mely szakaszok hiányoznak/homályosak, (2) mely lépések tűnnek teszteletlennek, (3) milyen információk lehetnek elavultak? Minden egyes leletnél írd le, hogy mit kérjek/ellenőrizzek. Dokumentum: [maszkolt dokumentum]

Gyenge felszólítás / Erős felszólítás

Gyenge felszólítás:

Írj nekem egy szerver karbantartási füzetet.

Nincs igazi anyag. Az AI teljes egészében saját általános ismeretei alapján olyan szöveget állít elő, amely nem illik a környezetéhez, vagy akár kitalált lépéseket is tartalmaz. Ez a hamis bizalom veszélyes forrása.

Erőteljes felszólítás:

Az Ön szerepe: vezető SRE. Az alábbiakban látható a maszkolt parancselőzmények és a megjegyzéseim, amelyeket a "fizetési szolgáltatás lemeze megtelt" eseményben implementáltam. Készítsen runbookot ezekből: Cél, Előfeltétel (hozzáférés/eszköz), Tünet, Számozott lépések (az én parancsaimmal), Ellenőrzés minden lépésnél, Visszagörgetés, Eszkaláció. Ne kényszerítsen arra, hogy olyan parancsot kövessem, amelyet nem adtam; Töltse ki az üres mezőt [KITÖLTENI]. A végére tegyen egy „nem tesztelt” figyelmeztetést. Anyag: [maszkolt parancstörténet]

Dokumentum típusa

Az AI hozzájárulása

Az ember kötelező hozzájárulása

runbook

Csontváz + elrendezés

Tesztelés valós környezetben, pontosság

Post mortem

Vázlat + szerkezet

Ellenőrizze a tényeket és a kiváltó okot

építészeti dokumentum

Leírás + áramlás

Erősítse meg a kapcsolatokat és a függőségeket

Tudásbázis cikk

gyors tervezet

Aktuálisság és pontosság ellenőrzése

Gyakori hibák

• Nem tesztelt runbookok közzététele. Az ellenőrizetlen lépéseket a válságban vakon hajtják végre; A rossz runbook katasztrófa.
• Nem tiltani a gyártást. Ha nem mondod az AI-nak, hogy "ne add hozzá, amit nem adtam", az ésszerű, de irreális lépéseket fog produkálni.
• A maszkolás kihagyása. A titok akkor szivárog ki, amikor megosztják a valódi gazdagépet, IP-címet és felhasználót tartalmazó dokumentumot.
• Nem frissíti a dokumentumot. A rendszerváltáskor nem frissített dokumentumok idővel félrevezetővé válnak.
• Kiadás bélyeg nélkül. Nem világos, hogy a teszt dátuma és állapota nélküli dokumentum megbízható vagy tervezet.

Tipp: A dokumentáció „élőben” tartásának legjobb módja, ha a változási folyamathoz köti: amikor a rendszer megváltozik, a megfelelő runbook frissítése legyen a változtatás egyik befejezési feltétele. Az AI felgyorsítja a frissítést, de te vagy a kiváltó folyamat.

Összefoglalva

A dokumentálás intézményi emlékezet; A runbook olyan működési útmutató, amely életeket menthet válság idején. A mesterséges intelligencia rendezett piszkozatokat állít elő a rendetlen jegyzeteiből, megoldva az üres oldalak és a lustaság problémáját. De a legkritikusabb igazság a következő: egy rossz runbook veszélyesebb, mint a semmi, mert vakon alkalmazzák válsághelyzetben. Ezért tiltsa le a mesterséges intelligencia „gyártását”, maszkolja le, és alaposan tesztelje le és bélyegezze meg az egyes runbookokat valós környezetben. Tartsa életben a dokumentumot a rendszer változásaival. Az AI építi a keretet; Te vagy az, aki garantálja a pontosságot és a tesztelést.

Pályázati feladat

Válasszon olyan eljárást, amelyet a csapata nem dokumentált (például egy szolgáltatás újraindítása vagy egy biztonsági mentés visszaállítása). Maszkolja a vonatkozó parancselőzményeket és megjegyzéseket, és kérje meg az AI-t, hogy hozzon létre egy piszkozatot a fenti „Runbook csontváz generálása” sablon segítségével; Feltétlenül szabjon tilalmat a koholmányokra. Futtassa végig a piszkozatot tesztkörnyezetben, és jelölje meg és javítsa ki a hibás/hiányzó lépéseket. Adja hozzá a teszt dátumát és a tesztelő adatait a runbookhoz. Írd le a mesterséges intelligencia által generált különbségeket, és 5 tételben javítsd ki.

ellenőrző lista

• [ ] A runbookot valós anyagból (jegyzet, parancselőzmények) készítettem, nem a semmiből készítettem?
• [ ] Megtiltottam az AI-t, hogy "nem adtam hozzá parancsokat/IP-ket/lépéseket"?
• [ ] Elfedtem az érzékeny információkat, például a gazdagépet, az IP-címet és a felhasználót?
• [ ] Futtattam és érvényesítettem a runbookot valós/tesztkörnyezetben?
• [ ] Hozzáadtam a teszt dátumát, a tesztelőt és az utolsó frissítési információkat?
• [ ] Terveztem-e, hogy a dokumentumot összekapcsoljam a rendszerváltási folyamattal, és naprakészen tartom?