Voitot:
- Tapauksen kokonaisvaltainen hallinta tekoälyn tuella havaitsemis-, diagnoosi-, lieventämis-, pysyvä ratkaisu- ja oppimisvaiheessa
- Kyky ylläpitää varmennuskuria myös paniikkitilanteissa erottamalla tekoälyyn siirtyvät askeleet ja ihmisen päätöstä vaativat vaiheet joka vaiheessa.
- Kyky muuttaa kultainen sääntö, jonka mukaan tekoäly menee "mitä tapahtuu, miten kirjoitetaan" -kysymyksiin nähden, ja ihmisillä on etusija "pitäisikö minun tehdä se, kuka on takaaja" -kysymyksiin nähden, bisnesrefleksiksi
Päästä päähän -integraatio: Tapahtuman hallinta päästä päähän tekoälyllä
Opit edellisen kymmenen yksikön palaset: komentosarjat, lokianalyysit, seuranta, konfigurointi, IaC, dokumentointi, ennakoiva ylläpito, muutosten hallinta ja turvallisuus. Mutta todellisessa maailmassa nämä osat eivät tule yksitellen, vaan ne kietoutuvat yhteen tapahtuman sisällä. Tässä viimeisessä osiossa kokoamme palaset yhteen: näet kokonaisuudessaan kuinka hallita keskellä yötä alkanutta tapausta, päästä päähän, havaitsemisesta perimmäiseen syyyn, korjaamisesta dokumentointiin ja käyttämällä oikeaa tekoälyannosta jokaisessa vaiheessa. Tavoitteena ei ole opettaa uutta tekniikkaa; sitoa oppimasi yhteen insinöörin refleksinä, vahvistaa yhtä totuutta, joka toistetaan koko moduulin ajan: AI kiihdyttää, valaisee ja piirtää joka vaiheessa; mutta se on aina ihminen, joka vahvistaa diagnoosin, suorittaa komennon, vahvistaa muutoksen ja kantaa vastuun lopputuloksesta.
Tässä osiossa yhdistät tapauksen elinkaaren – havaitsemisen, diagnoosin, puuttumisen, ratkaisun, oppimisen – sekä tekoälyn roolin ja rajat kussakin vaiheessa esimerkin avulla.
Tapahtuman elinkaari
Jokainen vakava tapaus käy läpi samanlaisia vaiheita, ja tekoälyllä on erilainen rooli kussakin vaiheessa. Tunnistus: hälytys kuuluu, käyttäjä valittaa, mittari poikkeaa lähtötasosta (yksikkö 4). Validointi ja soveltamisala: onko se todella ongelma, kuinka laaja se on? Diagnoosi: perimmäisen syyn löytäminen lokeista ja mittareista (yksikkö 3). Reagointi ja lieventäminen: vahinkojen pysäyttäminen, kiertotapa. Pysyvä ratkaisu: korjaa muutoksenhallinnan (Unit 9), komentosarjan (Unit 2) tai tarvittaessa konfiguroinnin avulla (Unit 5). Oppiminen: post mortem ja runbook -päivitys (osa 7). Tekoäly merkitsee havaitsemisen poikkeavuutta, tuottaa hypoteeseja diagnoosissa, tarjoaa vaihtoehtoja interventioon, kirjoittaa luonnoksia ratkaisuksi, tuottaa asiakirjoja oppimisessa - mutta joka vaiheessa ihmiset ovat päätöksentekopisteessä.
Vinkki: Tapahtuman vaarallisin hetki on diagnoosin ja reagoinnin hetki, jolloin stressi on suurin – juuri silloin, kun halu sokeasti luottaa tekoälyyn on voimakkain. Mitä enemmän kiirehdit, sitä tiukemmin pidät kiinni "lue, tarkista, valmistaudu palautukseen" -refleksistä. Yksi paniikkihetkellä ohitettu vahvistus kaksinkertaistaa tapahtuman.
Esimerkki alusta loppuun
Tehdään siitä konkretia. Hälytys klo 02:10: maksupalvelun p99 vasteaika on 6 sekuntia, selvästi perusviivan yläpuolella (250–400 ms). Tunnistus oikein: seuranta toimi. Vahvistus: vahvistus useista paikoista, todellinen tapahtuma. Diagnostiikka: insinööri antaa tekoälylle peitetyn lokin ja mittarit viimeisen 20 minuutin ajalta; Tekoäly määrittää aikajanan ja merkitsee hidastumisen alkavan välittömästi käyttöönoton jälkeen klo 02.08 – vahva korrelaatio, mutta silti hypoteesi. Insinööri vahvistaa tämän käyttöönottolokin avulla: kyllä, julkaisu julkaistiin klo 02:08. Vastaus: nopein vähennys on jakelun peruuttaminen; Muutospyynnön palautusvaihe on valmis (yksikkö 9). Insinööri toteuttaa ensin palautuksen palvelimella kanaarilogiikalla, vasteaika paranee ja sitten levittää sen. Pysyvä ratkaisu: todellinen perimmäinen syy (indeksoimaton kysely uudessa versiossa) korjataan rauhallisesti seuraavana päivänä. Oppiminen: Tekoälystä vapaa post mortem laaditaan ja "käytön jälkeinen p99-seuranta" -vaihe lisätään runbookiin. Tekoäly kiihtyi joka vaiheessa; ihmisen validoitu jokaisessa päätöspisteessä.
Ihmisen ja tekoälyn työnjaon kultainen sääntö
Koko moduulin aikana havaitusta erosta tulee sääntö tässä: AI on edellä kysymyksissä "mitä tapahtuu, mitä voi tapahtua, kuinka kirjoittaa"; Ihmiset ovat edellä sellaisissa kysymyksissä kuin "pitäisikö minun tehdä tämä nyt, kuka voi taata tämän?" Tekoäly on väsymätön, nopea, skannaa valtavia tietoja ja luo piirustuksia – mutta se ei tunne koko kontekstia, voi aiheuttaa hallusinaatioita, ei pysty käsittelemään vastuullisuutta eikä näe organisaatiosi piilotettuja riippuvuuksia. Ihminen on hidas, mutta kantaa kontekstia, vastuuta ja arvostelukykyä. Paras tulos on oikea työnjako näiden kahden välillä: delegoida toistuva, tekstillinen, tuotettava työ tekoälylle; Pidä todentaminen, päätökset ja täytäntöönpano ihmisenä.
kolme minilaukkua
Tapaus 1 – 40 minuuttia päästä loppuun. Levyn täynnä -tapahtumassa SRE kiihdytti koko ketjua AI:lla: vahvisti hälytyksen perusviivalla (5 min), teki maskatun lokin yhteenvedon YZ:lle ja löysi ensimmäisen virheen (5 min), vahvisti AI:n "lokin kierto pysähtynyt" -hypoteesin todellisessa järjestelmässä (5 min), suoritti ja toteutti valmiin puhdistuskomentosarjan kuivaajon avulla, AIch totesi jälkeisen tarkastuksen (10 min) tosiasiat (15 min). Yhteensä 40 minuuttia; Noin kaksi kertaa enemmän ilman tekoälyä. Mutta jokaisessa vaiheessa oli varmistusvaihe.
Tapaus 2 – Vahvistus ohitettiin hetken paniikissa. Toinen joukkue ryntäsi leikkaukseen. Se hyväksyi tekoälyn ensimmäisen perussyyhypoteesin (riippuvuuspalvelu) vahvistamatta sitä ja käynnisti palvelun uudelleen. Ongelmaa ei korjattu, koska todellinen syy oli jokin muu; Lisäksi tarpeeton uudelleenkäynnistys aiheutti toisen katkoksen. Oppitunti: kiire ei oikeuta todentamisen ohittamista; Ennen kuin tekoälyhypoteesi vahvistetaan, toiminta eskaloi tapahtumaa.
Tapaus 3 – Tiedostaminen rajasta. Eräs insinööri oli toteuttamassa konfiguraatiomuutosta, jota tekoäly oli vaatinut monimutkaisessa verkkoongelmassa. Mutta muutos vaikutti peruuttamattomalta, eikä tekoäly tiennyt viraston erityisiä reitityssääntöjä. Insinööri pysähtyi, kysyi vanhemmalta verkkoasiantuntijalta ja sai tietää, että tekoälyn ehdotus loisi reitityssilmukan tässä nimenomaisessa topologiassa. Tekoälyn rajan tunteminen esti häiriön.
Neljä kopioitavaa mallia
1) Tapahtuman triage yhteenveto (triage):
Tehtäväsi: vanhempi SRE, apulaisonnettomuuskomentaja. Siellä on aktiivinen tapahtuma. Sinulle antamani peitetty hälytys/metriikka/loki antaa minulle nopean analyysin: (1) mikä on oire, (2) mikä on vaikutuksen laajuus, (3) 3 aluetta, jotka kannattaa tarkastella ensin, (4) vain luku -ohjauskomento jokaiselle. Päätös ja täytäntöönpano on minun; Lähetä tie. Data: [naamioitu]
2) Vaiheittainen tapahtumanhallintaopas:
Ota minut askel askeleelta läpi oireen [oire] elinkaari: havaitsemisen vahvistus, diagnoosi, lieventäminen, pysyvä ratkaisu, oppiminen. Kerro JOKAisessa vaiheessa minulle (a) mitä minun täytyy tehdä, (b) milloin voin turvallisesti delegoida sen tekoälylle, (c) mikä päätös minun TÄYTYY tehdä itse. Merkitse vahvistusvaiheet, joita minun ei pitäisi ohittaa, vaikka kiirehdinkin.
3) Päätöspisteen ohjaus:
Olen keskellä tapahtumaa ja aion tehdä seuraavan toimenpiteen: [toiminta]. Ennen käyttöönottoa kysy minulta: (1) onko tämä peruutettavissa, (2) minkä vahvistuksen tein/en tehnyt, (3) onko minulla palautussuunnitelma, (4) onko minulla todisteita siitä, että tämä toimenpide todella ratkaisi perimmäisen syyn? Jos näet jotain puuttuvan, pysäytä minut.
4) Tapahtuman jälkeinen integroitu oppiminen:
Juuri ratkaistua tapausta varten [yhteenveto] antaa minulle: (1) post mortem -luonnoksen ilman syyllistämistä, (2) 3 pysyvää parannusta (seuranta/automaatio/konfigurointi), jotka estävät tämän tapauksen, (3) päivitettävät runbook-vaiheet, (4) varhaisvaroitussignaaliehdotus samanlaiselle tapaukselle. Perussyyn kirjoittaminen ilman todisteita; tosiasioiden perusteella.
Heikko kehote / Vahva kehote
Heikko kehote:
Järjestelmä kaatui, mitä minun pitäisi tehdä?
Paniikkina, ilman kontekstia ja todentamista, tämä kehote saa yleisiä ja mahdollisesti vaarallisia neuvoja tekoälyltä. Kiire johtaa virheisiin tässä vaiheessa eniten.
Tehokas kehotus:
Tehtäväsi: apulaisvälityspäällikkö. Aktiivinen tapahtuma: maksupalveluip99 vasteaika 15 kertaa lähtötasoa (250-400 ms) klo 02:10 alkaen. Tiedän, että jako oli klo 02:08. Kerro minulle:(1) todennäköisin hypoteesi ja kuinka se varmistetaan VAIN LUKU: (2) nopein ja PERUUTTAVA lievennysvaihtoehto, (3) riskit, jotka minun täytyy hallita ennen tämän lieventämisen soveltamista. Minulla on toteutus ja hyväksyntä. Lisätiedot: [naamioitu metriikka/loki]
tapahtumavaihe
AI:n rooli
Kriittinen ihmisen päätös
havaitseminen
Merkitse poikkeama
Onko se todellinen tapahtuma, mikä on laajuus?
Diagnoosi
hypoteesin luominen
Mikä hypoteesi vahvistettiin?
vähentäminen
Älä tarjoa vaihtoehtoja
Mikä vähennys on palautuva?
pysyvä ratkaisu
Luonnos/käsikirjoitus
Hyväksy ja toteuta muutos
Oppiminen
Post mortem luonnos
Tosiasioiden ja oppituntien vahvistaminen
Yleisiä virheitä
- Vahvistuksen ohittaminen paniikissa. Kiirehtiminen ei oikeuta luopumaan "lue-tarkista-valmista paluu" -refleksistä; Kun stressi lisääntyy, kurinalaisuutta on lisättävä.
- Hypoteesin vääristäminen todisteeksi. Toimenpiteisiin ryhtyminen vahvistamatta tekoälyn ensimmäistä perussyyehdotusta lisää tapausta.
- Tekoälyn kontekstirajan unohtaminen. Tekoäly ei tunne organisaation piilotettuja riippuvuuksia; Kriittisessä muutoksessa inhimillinen harkinta voittaa.
- Oppimisvaiheen ohittaminen. Tapahtuma ilman post mortem- ja runbook-päivityksiä alkaa uudelleen samana iltana.
- Vastuun laittaminen tekoälylle. "Tekoäly sanoi niin" ei ole puolustus; Vastuu toteuttamisesta on aina ihmisellä.
Varoitus: tekoälyn käyttäminen tapausten hallinnassa ei korvaa tapausten hallintaa. Ajoneuvo saattaa törmätä, törmätä tai siihen ei päästä käsiksi. Perusasiat tunteva insinööri on nopeampi tekoälyn avulla; Insinööri, joka ei tunne perusasioita, tekee virheitä nopeammin tekoälyn avulla. Luo ensin kuri ja hanki sitten nopeus tekoälystä.
Yhteenvetona
Todellisessa maailmassa osat eivät tule yksitellen, vaan ne kietoutuvat yhteen tapahtuman sisällä. Kun tapahtumaa hallitaan havaitsemisesta oppimiseen, tekoäly kiihtyy joka vaiheessa: merkitsee poikkeaman, luo hypoteeseja, tarjoaa vaihtoehtoja, luonnoksia, valmistelee post mortem. Mutta jokaisessa päätöskohdassa pysähtyy – vahvistaa diagnoosin, päättää vähentää, hyväksyy muutoksen, omistaa tuloksen. Kultainen sääntö on selvä: tekoäly on edellä kysymyksissä "mitä tapahtuu, kuinka kirjoittaa", ja ihmiset ovat edellä kysymyksissä "pitäisikö minun tehdä se, kuka on takaaja?" Paniikkitilanteessa lisää kurinalaisuutta, erota hypoteesi todisteista, muista tekoälyn kontekstiraja ja ota oppitunti jokaisesta tapahtumasta. Tämän moduulin ydin on yksi lause: AI on tehokas avustaja; Suunnitteluvastuuta ei voi siirtää.
Sovellustehtävä
Harkitse tapahtumaa, jonka koit (tai kuvittelet) menneisyydessäsi alusta loppuun. Pyydä tekoälyä ohjaamaan tapaus havaitsemisen-diagnoosin-lieventämisen-resoluutio-oppimisen vaiheiden kautta yllä olevan "Vaiheisen tapahtumanhallintaoppaan" -mallin avulla. Kirjoita jokaisessa vaiheessa erikseen vaihe, jonka voit delegoida tekoälylle, ja vaihe, jonka sinun on päätettävä itse. Vahvista vähintään yksi tekoälyhypoteesi varmistuskomennolla diagnoosivaiheen aikana. Tuo lopuksi post mortem- ja runbook-päivitysluonnos "Tapahtuman jälkeisen integroidun oppimisen" -mallin avulla. Tee yhteenveto ihmisen ja tekoälyn työnjaosta koko prosessissa 7 kohdassa.
tarkistuslista
- [ ] Olenko jakanut tapahtuman havaitsemis-, diagnoosi-, lieventämis-, ratkaisu- ja oppimisvaiheisiin?
- [ ] Olenko erottanut tekoälylle delegoitavat vaiheet ja ne, jotka vaativat ihmisen päätöksentekoa kussakin vaiheessa?
- [ ] Erotinko diagnoosissa tekoälyhypoteesin todisteista ja vahvistanko sen varmistuskomennolla?
- [ ] Olenko arvioinut lieventämisen palautuvuuden ja palautussuunnitelman kannalta?
- [ ] Säilytinkö "lue-tarkista-valmista palautus" -refleksin jopa paniikkitilanteissa?
- [ ] Opinko tapauksesta post mortem ja runbook -oppitunnin?
Moduulin tentti
1. Mikä seuraavista on tarkin tekoälyn paikannus järjestelmä- ja verkkohallinnassa?
- A) Tekoäly on apu- ja päätöksenteon tukityökalu; Vastuu ja kriittisten johtopäätösten lopullinen hyväksyminen on ihmisillä ✔
- B) Tekoäly voi suorittaa komentoja ja toteuttaa muutoksia tuotannossa ilman ihmisen hyväksyntää
- C) Tekoäly toimii vain tekstin kirjoittamisessa, sillä ei ole mitään tekemistä järjestelmä- ja verkkotyön kanssa
- D) Tekoäly tekee aina tarkempia päätöksiä kuin ihminen, joten todentaminen on tarpeetonta
Kuvaus: Tekoäly on apu- ja päätöksentekotyökalu, joka tuottaa luonnoksia ja analyyseja, kuten komentosarjoja, lokianalyysiä ja asiakirjoja. Vastuu ja lopullinen hyväksyminen seisokkiin, tietojen katoamiseen ja turvallisuuteen vaikuttavista toimeenpanopäätöksistä, kuten komennon suorittamisesta tai muutoksen hyväksymisestä, kuuluu pätevälle insinöörille.
2. Mitkä ovat varmennusrefleksin neljä vaihetta, jotka on toteutettava ennen tekoälyn tuottaman komennon suorittamista tuotannossa?
- A) Kopioi, liitä, suorita, toivo
- B) Lue ja ymmärrä, dokumentoi, kokeile eristetyssä ympäristössä, valmistaudu palautteeseen ✔
- C) Tykkää, jaa, tallenna, arkistoi
- D) Poista, kirjoita uudelleen, pakkaa, lähetä
Kuvaus: Neljä vaihetta kriittiseen tulosteeseen: (1) lue ja ymmärrä komentorivi riviltä, (2) linkitä liput ja syntaksi viralliseen dokumentaatioon, (3) kokeile sitä eristetyssä/testiympäristössä, kuivaa, jos mahdollista, (4) valmistele varasuunnitelma (varmuuskopio, tilannekuva), jos se menee pieleen.
3. Mitä tarkoittaa, että automaatiokomentosarja on "idempotentti" ja miksi se on tärkeää?
- A) Skripti tuottaa erilaisia tuloksia jokaisessa ajossa
- B) Skripti voidaan suorittaa vain kerran ja sen jälkeen poistetaan
- C) Skripti ei aiheuta haittaa, kun se suoritetaan toisen kerran; ✔ Turvallinen, vaikka laukaisisi uudelleen
- D) Skripti ei sisällä virheenhallintaa
Selitys: Idempotenssi tarkoittaa, että kun sama komentosarja suoritetaan vähintään kaksi kertaa, se ei aiheuta vahinkoa tai aiheuta virheitä toisessa ajossa. Logiikka, kuten "ohita, jos käyttäjä on jo olemassa", "luo hakemisto, jos sitä ei ole, älä koske siihen, jos se on olemassa", on perustettu. Tämä varmistaa, että automaatio toimii turvallisesti, vaikka se laukaisisi vahingossa uudelleen.
4. Mikä on yksinkertaisin tapa suojata tuhoavia toimintoja (poisto, uudelleenkäynnistys) sisältävä komentosarja?
- A) Suorita skripti mahdollisimman nopeasti
- B) Piilottaa virheilmoitukset
- C) Käsikirjoituksen testaus suoraan tuotannossa
- D) Destruktiivisten toimintojen asettaminen oletuskuivakäynnin taakse ja varsinaisen toteutuksen sitominen nimenomaiseen rastilippuun ✔
Selitys: Kun tuhoavat prosessit pidetään oletusarvoisesti kuiva-ajon tilassa ja varsinainen sovellus suoritetaan vain nimenomaisella hyväksyntälipulla (esim. --apply), voit ensin nähdä, mitä tapahtuu, kun komentosarja suoritetaan. Myös nollamuuttujien tarkistus (VAR:?) estää polkuvirheet.
5. Mitä periaate 'korrelaatio ei ole syy-yhteyttä' tarkoittaa log-analyysissä?
- A) Kaksi yhdessä muuttuvaa tapahtumaa eivät välttämättä ole syy-seuraussuhteessa; Myös syy-yhteys on tarkistettava ✔
- B) Korrelaation etsiminen lokeista on ajanhukkaa
- C) Kahdesta yhdessä muuttuvasta tapahtumasta toinen on ehdottomasti toisen syy.
- D) Syy-seuraus voidaan määrittää vain tekoälyllä
Selitys: Se, että kaksi tapahtumaa tapahtuu samanaikaisesti (korrelaatio), ei tarkoita, että toinen aiheuttaa toista (syy-yhteys); Molemmat voivat olla seurausta kolmannesta tapahtumasta. Tekoälyn ehdotus, että 'X luultavasti aiheutti Y:n' on hypoteesi, eikä sitä pidetä löydöksenä ennen kuin se on varmistettu järjestelmässä.
6. Miksi prosenttipiste (p95/p99) on parempi kuin keskiarvo, kun mitataan vasteaikaa suorituskyvyn seurannassa?
- A) Prosenttipiste on helpompi laskea kuin keskiarvo
- B) Keskiarvo piilottaa vähemmistön huonot kokemukset; prosenttipiste paljastaa nämä piilotetut ongelmat ✔
- C) Keskiarvo on aina väärä, eikä sitä pidä käyttää
- D) Prosenttipiste koskee vain suorittimen mittareita
Selitys: Keskimääräinen piilottaa erittäin huonon kokemuksen, joka pienellä osalla käyttäjistä on. Vaikka keskiarvo näyttää olevan 200 ms, p99 voi olla 6 sekuntia; Tämä tarkoittaa, että yksi sadasta pyynnöstä on hirvittävän hidas. Persentiili tekee näkyväksi tämän vähemmistön keskiarvon kätkemän tuskan.
7. Mitä on 'drift' kokoonpanonhallinnassa ja miksi se on vaarallista?
- A) Verkkoliikenne laskee yöllä
- B) Palvelimen fyysinen siirto
- C) Palvelimet poikkeavat toisistaan ja standardista ajan myötä; ✔ Näkymätön, kunnes ongelma ilmenee
- D) Konfigurointitiedostojen automaattinen varmuuskopiointi
Kuvaus: Drift on palvelinten poikkeama toisistaan ja standardista dokumentoimattomien manuaalisten muutosten kautta ajan myötä. Sen vaara on sen hiljaisuus: se ei ole näkyvissä ennen kuin ongelma ilmenee, sitten yksi palvelin käyttäytyy eri tavalla kuin muut ja diagnoosi kestää tunteja. Tekoäly tekee ajautumisen näkyväksi vertailussa; Kultahitsausperiaate estää.
8. Miksi 'suunnitelma'-vaihe on IaC-työkalujen (kuten Terraformin) tärkein turvakaide?
- A) Suunnitelma suorittaa koodin nopeammin
- B) Poistaa suunnitelman tilatiedoston
- C) Suunnitelmassa korjataan vain koodin muotoilu
- D) Suunnitelma näyttää, mitä lisätään, muutetaan ja POISTETAAN ennen käyttöönottoa; Estää tietojen katoamisen ✔
Kuvaus: Suunnitelma (terraform plan / ansible --check) antaa 'mikä muuttuu' -esikatselun ennen koodin suorittamista: kuinka monta resurssia lisätään, muutetaan, poistetaan. Erityisesti "tuhoa"- ja "pakottaa korvaaminen" -rivit osoittavat tietojen menetyksen riskin ennen käyttöönottoa. Hakeminen lukematta suunnitelmaa on yksi kalleimmista virheistä.
9. Miksi Terraform-tilatiedosto tulee suojata huolellisesti, eikä sitä saa liittää tekoälyyn tai avoimiin tietovarastoihin?
- A) Valtiotiedostoon voidaan sisällyttää pelkkää tekstiä koskevia salaisuuksia; Jos henkilötieto vuotaa, henkilötiedot paljastetaan ✔
- B) Koska tilatiedosto on liian suuri
- C) Tilatiedosto on jo lukukelvottomasti salattu.
- D) Koodi toimii nopeammin, kun tilatiedosto jaetaan
Kuvaus: State-tiedosto säilyttää hallitun infrastruktuurin nykyisen tilan ja voi sisältää pelkkää tekstiä koskevia salaisuuksia (tietokannan salasanat, avaimet). Siksi se tulisi säilyttää salatussa, pääsyrajoitetussa, lukitussa etätaustaohjelmassa; Sitä ei saa koskaan sijoittaa julkiseen ajoneuvoon tai varastoon, muuten salaisuus vuotaa.
10. Mitä väite "väärä runbook on vaarallisempi kuin ei runbook" korostaa dokumentaatiossa?
- A) Runbookin kirjoittaminen on ajanhukkaa
- B) Testaamaton runbook otetaan sokeasti käyttöön kriisissä; Yksikin väärä askel voi johtaa katastrofiin ✔
- C) Runbookit on kirjoitettu vain järjestelmänvalvojille
- D) Dokumentaatiota ei saa koskaan päivittää
Selitys: Tiimi ilman runbookia on varovainen ja epäluuloinen kriisin aikana; mutta henkilö, jolla on "virallinen" runbook, soveltaa sitä stressin alla ilman kyseenalaistamista. Jos runbookia ei ole testattu ja siinä on yksi askel väärin, sokea toteutus johtaa katastrofiin. Siksi jokainen runbook on testattava perusteellisesti ja leimattava todellisessa ympäristössä.
11. Mikä on ennakoivassa kunnossapidossa oikea tapa ymmärtää, milloin levy on lähestymässä vikaa?
- A) Vaihda välittömästi yksittäinen viallinen SMART-levy
- B) SMART-tietojen huomioimatta jättäminen
- C) Tarkastellaan arvojen kehitystä ajan mittaan; ✔ Tasainen ja kiihtyvä signaalimäärän kasvu
- D) Toimenpiteisiin ryhtyminen vasta, kun levy on romahtanut kokonaan
Selitys: Yksittäinen huono SMART-lukema ei aiheuta paniikkia; On normaalia, että levyillä korjataan satunnaisia virheitä. Todellinen signaali on trendi: arvojen johdonmukainen ja kiihtyvä nousu, kuten uudelleenallokoitu sektori ajan myötä. Siksi tekoälylle annetaan aikasarja, ei yhtä lukemaa.
12. Mitkä ovat kaksi yleisimmin huomiotta jätettyä mutta kriittistä osaa tuotantoon siirtymisessä?
- A) Muutoksen väri ja nimi
- B) Muutoksen tekijän nimike ja osasto
- C) Ilmoitus muutoksesta sosiaalisessa mediassa
- D) Palautussuunnitelma ja onnistumisen varmistuskriteerit ✔
Selitys: Jos kysymyksiin "miten perutaan, jos se menee huonosti" (palautussuunnitelma) ja "miten todistan sen onnistuneen" (menestyksen varmistuskriteerit) ei ole kirjallista vastausta ennen muutoksen toteuttamista, muutos ei ole vielä valmis. Ilman näitä kahta rikkoutunutta muutosta voidaan pitää "täydellisenä".
13. Miksi "kanaari"-lähestymistapaa suositaan sen sijaan, että tietoturva-asennus (uusi versio/korjaus) otetaan käyttöön kaikille palvelimille samanaikaisesti?
- A) Muutosta sovelletaan ensin pieneen osaan; Virhe vaikuttaa pieneen osaan, ei koko laivastoon, ja se havaitaan aikaisin ✔
- B) Kanarian jakelu kuluttaa vähemmän sähköä
- C) Canary tekee käyttöönoton todentamisen täysin tarpeettomaksi
- D) Canaryn käyttöönotto koskee vain tietokantoja
Kuvaus: Canary-käyttöönotto ottaa muutoksen käyttöön ensin pieneen osaan (yksi palvelin, 5 % käyttäjistä) ja valvoo. Tällä tavalla bugi vaikuttaa pieneen osaan, ei koko laivastoon, ja se havaitaan aikaisin. Virhe, joka leviää kerralla, iskee kaikkiin käyttäjiin yhtä aikaa.
14. Mikä on muuttumaton eettinen ja laillinen sääntö käytettäessä tekoälyä turvallisuustyössä?
- A) Tekoälyä voidaan käyttää vapaasti haavoittuvuuksien etsimiseen mistä tahansa järjestelmästä
- B) Eettiset säännöt koskevat vain suuria instituutioita
- C) Sitä käytetään vain valtuutetuissa järjestelmissä ja puolustustarkoituksiin; Käyttö luvattomaan käyttöön tai hyökkäämiseen on rikos ✔
- D) On ilmaista soluttautua jonkun toisen järjestelmään oppiakseen.
Kuvaus: Järjestelmä- ja verkkotiedot ovat kaksikäyttöisiä. Tekoälyä voidaan käyttää vain järjestelmissä, joihin sinulla on kirjallinen lupa, ja puolustustarkoituksiin (lokiuhan havaitseminen, kovettuminen, välikohtaus). Sen käyttäminen järjestelmän skannaamiseen tai tunkeutumiseen, joka ei kuulu sinulle, on luvaton pääsy ja rikos; Oppimiseen on käytettävä eristettyä laboratoriota.