Dokumentaatio ja tiedonhallinta: Runbook, Post mortem ja Corporate Memory

Voitot:

• Kyky tuottaa runbook-, post mortem- ja arkkitehtuuridokumenttien luurankoa hajallaan olevista muistiinpanoista tekoälyn avulla
• Kyky noudattaa kurinalaisuutta, joka koskee "valmistuskieltoa" ja jokaisen runbookin perusteellista testausta ja merkitsemistä todellisessa ympäristössä
• Kyky ymmärtää, että väärä runbook on vaarallisempi kuin ei mikään ja pitää dokumentaatio hengissä muutosprosessin ajan

Dokumentaatio ja tiedonhallinta: Runbook, arkkitehtuuri ja institutionaalinen muisti tekoälyllä

Järjestelmänhallinnan laiminlyönnein mutta pelastavin tehtävä on dokumentointi. Kun järjestelmä kaatuu ja sen rakentaja on lomalla eikä palautumisesta ole kirjoitettua sanaa, se on pitkä yö kaikille. Dokumentaatio on institutionaalinen muisti, joka antaa kirjoitetun ja saatavilla olevan järjestelmän kokoonpanon, toimintatavan ja ongelman ilmenemisen. Tämän muistin kriittisin tyyppi on runbook: käyttöopas, joka kertoo vaihe vaiheelta, mitä tehdä tietyssä tilanteessa (palvelu kaatui, levy täynnä, varmuuskopiointi epäonnistui). Täällä tekoäly ratkaisee "tyhjän sivun" ja "laiskuuden" ongelmat, jotka ovat dokumentaation kirjoittamisen suurimmat viholliset: se tuottaa hajautetuista muistiinpanoistasi järjestetyn runbookin, komentohistoriasta toimenpiteen, kuvauksen arkkitehtuurista. Mutta kriittinen periaate: tekoäly tuottaa piirustuksia ja luurankoja; Sinä testaat ja vahvistat jokaisen vaiheen nähdäksesi, ovatko ne oikein – väärä runbook on vaarallisempi kuin ei runbookia ollenkaan.

Tässä yksikössä runbook, post mortem (tapahtuman jälkeinen tutkimusraportti), arkkitehtoninen dokumentaatio ja tietopohjan kirjoittaminen; Luonnosten luominen tekoälyllä; ja mikä tärkeintä, opit vahvistamattomien asiakirjojen riskit.

Miksi väärä runbook on huonompi kuin ei runbookia?

Tämä on tämän yksikön tärkein konsepti. Tiimi ilman runbookia on varovainen ja epäluuloinen paniikkitilanteissa; miettii kahdesti jokaista käskyä. Mutta joku, jolla on "virallinen" runbook, luottaa siihen sokeasti – keskellä yötä, stressin alaisena ja suorittaa vaiheet kyselemättä. Jos tämä runbook julkaistaan ​​ilman tekoälyn tuottamista ja testaamista ja siinä on yksi vaihe väärin (väärä komento, puuttuva edellytys, ohitettu varavaihe), tulos on tuhoisa. Siksi jokainen tekoälyllä tuotettu runbook on ajettava alusta loppuun todellisessa ympäristössä ja jokainen vaihe on tarkistettava ennen julkaisua. Testaamaton runbook on kuin rauhoittava mutta tyhjä lupaus.

Varoitus: Merkitse runbookiin "testattu: [päivämäärä], [henkilö]". Merkitse testaamattomat luonnokset selkeästi merkinnällä LUONNOS – EI VAHVISTETTU. Joten kukaan ei turvallisesti soveltaisi vahvistamattomia toimenpiteitä todellisessa kriisissä.

Hyvän runbookin anatomia

Hyvä runbook koostuu tietyistä osista, ja tekoäly on hyvä rakentamaan tätä luurankoa: otsikko ja tarkoitus (mihin tilanteeseen), edellytykset (mitä käyttöoikeuksia, mitä työkalua tarvitaan), oireet (milloin käytän tätä runbookia), vaiheet (numeroidut, kopioitavat komennot), validointi (kuinkin vaiheen onnistumisen tunnistaminen), palautus (miten kumotaan, jos vaihe menee huonosti) ja eskalointi (kuka voin tehdä). Voit antaa tekoälylle hajallaan olevat muistiinpanosi ja pyytää sitä laittamaan ne tähän rakenteeseen; Varmistat vain sisällön oikeellisuuden.

Askel askeleelta: Dokumentoinnin tuotanto tekoälyllä

1. Kerää raaka-aine. Komentohistoriasi, muistiinpanosi, vanha sähköposti, chat-loki – aito materiaali, vaikka se olisikin sotkuinen, on parempi kuin tekoäly.
2. Kysy rakennetta. "Tee tästä runbook, jossa on seuraavat otsikot: tarkoitus, edellytys, oire, vaiheet, vahvistus, palautus, eskalaatio."
3. Kiellä valmistus. "Älä lisää komentoja, IP-osoitteita, versioita tai vaiheita, joita en ole sinulle antanut; merkitse puuttuviin osiin [TÄYTETTÄVÄ]." Tämä estää vaarallisimman virheen – uskottavilta vaikuttavilta sovituilta vaiheilta.
4. Naamio. Käytä paikkamerkkiä todellisen isännän, IP:n, käyttäjän sijaan; Jos asiakirja on jaettu, salaisuutta ei pidä vuotaa.
5. Testaa sitä. Suorita runbook alusta loppuun todellisessa (mieluiten testi) ympäristössä. Korjaa kaikki vaiheet, jotka eivät toimi, puuttuvat tai ovat epäselviä.
6. Leimaa ja julkaise. Lisää testipäivämäärä, testaaja ja viimeisin päivitys. Dokumentaatio on vilkasta; Se on päivitettävä, kun järjestelmä muuttuu.

kolme minilaukkua

Tapaus 1 – 2 tuntia työtä, 15 minuuttia. Järjestelmänvalvoja oli lykännyt varmuuskopion palautusmenettelyn dokumentointia kuukausia. Hän antoi terminaalin komentohistorian (naamioitu) ja muutaman hajallaan olevan muistiinpanon tekoälylle ja lisäsi sen runbook-kehykseen. Tekoäly tuotti siistit ääriviivat 15 minuutissa. Järjestelmänvalvoja käytti seuraavat 45 minuuttia luonnoksen suorittamiseen alusta loppuun testipalvelimella ja kahden puuttuvan vaiheen korjaamiseen. Tulos: testattu, luotettava runbook.

Tapaus 2 – kiinni väärin. Eräs tiimi antoi tekoälyn kirjoittaa palvelun uudelleenkäynnistysohjekirjan, mutta unohti kieltää "valmistuksen". YZ lisäsi "tyhjennä välimuisti ensin" -komennon, joka vaikuttaa loogiselta, mutta jota ei ole kyseisessä palvelussa. Onneksi insinööri suoritti runbookin testiympäristössä; Se komento antoi virheen. Testivaihe merkitsi keksittyä askelta, joka aiheuttaisi hämmennystä todellisessa kriisissä.

Tapaus 3 – Post mortem nopeutettu. Suuren käyttökatkon jälkeen tiimin piti kirjoittaa kuoleman jälkeinen selvitys, mutta kukaan ei voinut aloittaa. He luovuttivat tapahtuman aikajanan ja naamioidut lokit tekoälylle ja pyysivät moitteetonta kuolemanjälkeistä luurankoa – yhteenvetoa, vaikutusta, aikajanaa, perussyytä ja korjaavia toimia. Tekoälysuunnitelma lyhensi tunnin työn kymmeneen minuuttiin; Tiimi käytti energiaa tosiasioiden tarkistamiseen ja toimintakohtien selventämiseen.

Neljä kopioitavaa mallia

1) Runbook-rungon luominen:

Roolisi: vanhempi SRE. Luo runbook alla olevista peitetyistä muistiinpanoista/komentohistoriasta. Otsikot: Tarkoitus, Edellytykset, Oireet (milloin käyttää), Vaiheet (numeroitu, voidaan kopioida), Varmistus jokaisessa vaiheessa, Palautus, Eskalointi. SÄÄNTÖ: Älä keksi mitään komentoa/IP-osoitetta/versiota/vaihetta, jota en anna sinulle; kirjoita puuttuvat osat [TÄYTETTÄVÄ]. Materiaali: [naamioitu huomautus]

2) Post mortem ilman syyllistämistä:

Tehtäväsi: tapahtumatutkinnan ohjaaja. Kirjoita SUUTTAMATON post mortem -luonnos seuraavista peitetyistä aikajanasta ja lokeista: Yhteenveto, Vaikutus (kesto/laajuus), Aikajana, Perimmäinen syy (jos varmistettu), Myötävaikuttavat tekijät, Korjaavat toimet (omistaja + prioriteetti). Älä syytä henkilöä, vaan keskity järjestelmään. Älä kirjoita perimmäistä syytä ilman todisteita. Tiedot: [...]

3) Arkkitehtuuri/palvelun kuvaus:

Kirjoita palveludokumentti seuraavista peitetyistä konfiguraatio-/kaaviotiedoista: mitä palvelu tekee, mistä komponenteista se koostuu, mitkä ovat sen riippuvuudet, miten data kulkee, mitkä portit/protokollat. Pidä se teknisenä mutta luettavana. Merkitse suhde, josta et ole varma, "vaatii vahvistuksen". Info: [naamioitu]

4) Dokumentaation päivitystarkastus:

Tarkista seuraava olemassa oleva asiakirja ja tarkista valuutta: (1) mitkä osat puuttuvat/epäselviä, (2) mitkä vaiheet näyttävät testaamattomilta, (3) mitkä tiedot saattavat olla vanhentuneita? Kirjoita ylös, mitä minun pitäisi kysyä/varmentaa jokaisesta löydöstä. Asiakirja: [naamioitu dokumentti]

Heikko kehote / Vahva kehote

Heikko kehote:

Kirjoita minulle palvelimen ylläpidon ohjekirja.

Varsinaista materiaalia ei ole. Tekoäly tuottaa tekstin, täysin omasta yleistietostaan, joka ei sovi ympäristöösi tai sisältää jopa keksittyjä vaiheita. Tämä on vaarallinen väärän luottamuksen lähde.

Tehokas kehotus:

Roolisi: vanhempi SRE. Alla on peitetty komentohistoria ja huomautukseni, jotka toteutin "maksupalvelun levy täynnä" -tapahtumassa. Luo runbook näistä: Tarkoitus, Edellytys (käyttö/työkalu), Oire, Numeroidut vaiheet (omien komentojeni kanssa), Varmistus jokaisessa vaiheessa, Palautus, Eskalointi. Älä pakota minua noudattamaan käskyä, jota en ole antanut; Täytä tyhjä [TÄYTETTÄVÄ]. Laita loppuun varoitus "ei testattu". Materiaali: [naamioitu komentohistoria]

Asiakirjan tyyppi

Tekoälyn panos

Ihmisen pakollinen panos

runbook

Luuranko + asettelu

Testaus todellisessa ympäristössä, tarkkuus

Post mortem

Runko + rakenne

Tarkista tosiasiat ja perimmäinen syy

arkkitehtoninen asiakirja

Kuvaus + virtaus

Vahvista suhteet ja riippuvuudet

Tietopohjan artikkeli

nopea luonnos

Ajantasaisuus ja tarkkuustarkastus

Yleisiä virheitä

• Testaamattomien runbookien julkaiseminen. Todentamattomat toimet toteutetaan sokeasti kriisissä; Väärä ohjekirja on katastrofi.
• Ei määrätä valmistuskieltoa. Jos et sano tekoälylle "älä lisää, mitä en ole antanut", se tuottaa järkeviä mutta epärealistisia toimia.
• Maskauksen ohittaminen. Salaisuus vuotaa, kun todellisen isännän, IP:n ja käyttäjän sisältävä dokumentti jaetaan.
• Asiakirjaa ei päivitetä. Asiakirjat, joita ei päivitetä järjestelmän muuttuessa, tulevat harhaanjohtaviksi ajan myötä.
• Julkaisu ilman leimaa. Ei ole selvää, onko asiakirja ilman testipäivää ja -tilaa luotettava vai luonnos.

Vinkki: Paras tapa pitää dokumentaatio "livenä" on sitoa se muutosprosessiin: kun järjestelmä muuttuu, olkoon asiaankuuluvan runbookin päivittäminen yksi muutoksen toteuttamiskriteereistä. Tekoäly nopeuttaa päivitystä, mutta sinä olet käynnistäjäprosessi.

Yhteenvetona

Dokumentaatio on institutionaalista muistia; Runbook on toimintaopas, joka pelastaa ihmishenkiä kriisiaikoina. Tekoäly tuottaa järjestettyjä luonnoksia sotkuisista muistiinpanoistasi, mikä ratkaisee tyhjien sivujen ja laiskuuden ongelman. Mutta kriittisin totuus on tämä: väärä runbook on vaarallisempi kuin ei ollenkaan, koska sitä sovelletaan sokeasti kriisissä. Joten kiellä tekoälyä "valmistumasta", maskaa se ja testaa ja leimaa jokainen runbook perusteellisesti todellisessa ympäristössä. Pidä asiakirja elossa järjestelmän muuttuessa. AI rakentaa puitteet; Olet se, joka takaa tarkkuuden ja testauksen.

Sovellustehtävä

Valitse toimenpide, jota ei ole dokumentoitu tiimissäsi (esimerkiksi palvelun käynnistäminen uudelleen tai varmuuskopion palauttaminen). Peitä asiaankuuluva komentohistoriasi ja muistiinpanosi ja pyydä tekoälyä luomaan luonnos yllä olevan "Runbook skeleton generation" -mallin avulla; Muista asettaa tekosyyn kieltäminen. Suorita luonnos läpi testiympäristössä ja merkitse ja korjaa vialliset/puuttuvat vaiheet. Lisää testipäivämäärä ja testaajan tiedot runbookiin. Kirjoita ylös erot, jotka tekoäly tuottaa ja korjaat prosessissa 5 kohdassa.

tarkistuslista

• [ ] Tein runbookin oikeasta materiaalista (huomautus, komentohistoria), enkö keksinyt sitä tyhjästä?
• [ ] Olenko kieltänyt tekoälyä "lisäämästä komentoja/IP-osoitteita/vaiheita, joita en ole antanut"?
• [ ] Olenko peittänyt arkaluontoisia tietoja, kuten isännän, IP-osoitteen ja käyttäjän?
• [ ] Olenko suorittanut ja vahvistanut runbookin todellisessa/testiympäristössä?
• [ ] Olenko lisännyt testipäivän, testaajan ja viimeisimmän päivityksen tiedot?
• [ ] Olenko suunnitellut linkittävän asiakirjan järjestelmän muutosprosessiin ja pitävän sen ajan tasalla?