Vienetas 11 / 11

Integracija nuo galo iki galo: incidento valdymas nuo pradžios iki pabaigos

Pelnas:

  • Visapusiškas incidento valdymas naudojant dirbtinio intelekto palaikymą aptikimo, diagnozavimo, švelninimo, nuolatinio sprendimo ir mokymosi etapuose
  • Galimybė išlaikyti tikrinimo drausmę net ir panikos metu, atskiriant veiksmus, kurie gali būti perkelti į dirbtinį intelektą, ir tuos, kuriems kiekviename etape reikia žmogaus sprendimo.
  • Gebėjimas auksinę taisyklę, kad dirbtinis intelektas turi viršenybę prieš klausimus „kas vyksta, kaip rašyti“, o žmonės turi pirmenybę prieš klausimus „ar turėčiau tai padaryti, kas yra garantas“ paversti verslo refleksu.

Integracija nuo galo iki galo: incidento valdymas nuo galo iki galo naudojant AI

Išmokėte ankstesnių dešimties dalių: scenarijų kūrimą, žurnalų analizę, stebėjimą, konfigūraciją, IaC, dokumentaciją, nuspėjamąją priežiūrą, pakeitimų valdymą ir saugumą. Tačiau realiame pasaulyje šios dalys atsiranda ne po vieną, o susipynusios per įvykį. Šiame paskutiniame skyriuje sujungiame dalis: pamatysite visą, kaip valdyti incidentą, prasidėjusį vidury nakties, nuo galo iki galo, nuo aptikimo iki pagrindinės priežasties, nuo ištaisymo iki dokumentacijos ir kiekviename etape naudojant tinkamą AI dozę. Tikslas nėra išmokyti naujos technikos; sujungdami tai, ko išmokote, kaip inžinieriaus refleksą, sustiprindami vieną tiesą, kartojamą visame modulyje: AI pagreitina, apšviečia ir brėžia kiekviename etape; bet visada žmogus patvirtina diagnozę, vykdo komandą, patvirtina pasikeitimą ir prisiima atsakomybę už rezultatą.

Šiame skyriuje pateikdami pavyzdį integruosite incidento gyvavimo ciklą – aptikimą, diagnozę, intervenciją, sprendimą, mokymąsi – ir AI vaidmenį bei ribas kiekviename etape.

Renginio gyvavimo ciklas

Kiekvienas rimtas incidentas pereina panašius etapus, o AI kiekviename etape atlieka skirtingą vaidmenį. Aptikimas: skamba pavojaus signalas, vartotojas skundžiasi, metrika nukrypsta nuo pradinio lygio (4 skyrius). Patvirtinimas ir taikymo sritis: ar tai tikrai problema, kokia ji yra? Diagnozė: pagrindinės priežasties paieška pagal žurnalus ir metrikas (3 skyrius). Reagavimas ir mažinimas: žalos sustabdymas, sprendimas. Nuolatinis sprendimas: pataisykite naudodami pakeitimų valdymą (9 skyrius), scenarijų (2 skyrius) arba, jei reikia, konfigūraciją (5 skyrius). Mokymasis: pomirtinis ir runbook atnaujinimas (7 skyrius). Dirbtinis intelektas pažymi aptikimo anomaliją, sukuria hipotezes diagnozuojant, siūlo intervencijos variantus, rašo sprendimo juodraščius, rengia mokymosi dokumentus, tačiau kiekviename etape žmonės yra apsisprendimo taške.

Patarimas: pavojingiausias incidento momentas yra diagnozės nustatymo ir atsako momentas, kai stresas yra didžiausias – būtent tada, kai stipriausias noras aklai pasitikėti AI. Kuo labiau skubate, tuo tvirčiau laikotės reflekso „skaityti, patikrinti, ruoštis sugrįžimui“. Vienintelis patikrinimas, praleistas per paniką, padvigubina įvykį.

Pavyzdys nuo pradžios iki galo

Sukonkretinkime. Pavojaus signalas 02:10: mokėjimo paslaugos p99 atsako laikas yra 6 sekundės, gerokai viršija bazinę liniją (250–400 ms). Aptikimas teisingas: sekimas veikė. Patvirtinimas: patvirtinimas iš kelių vietų, tikras įvykis. Diagnostika: inžinierius AI pateikia užmaskuotą žurnalą ir paskutinių 20 minučių metriką; AI nustato laiko juostą ir pažymi, kad sulėtėjimas prasideda iškart po įdiegimo 02:08 - tai tvirta koreliacija, bet vis tiek hipotezė. Inžinierius tai patvirtina su diegimo žurnalu: taip, leidimas buvo išleistas 02:08. Atsakymas: greičiausias sumažinimas yra paskirstymo atšaukimas; Pakeitimo užklausos atšaukimo veiksmas paruoštas (9 skyrius). Inžinierius pirmiausia įgyvendina atšaukimą serveryje su kanarine logika, pagerėja atsako laikas, o tada jį platina. Nuolatinis sprendimas: tikroji pagrindinė priežastis (neindeksuota užklausa naujoje versijoje) bus ramiai ištaisyta kitą dieną. Mokymasis: parengiamas pomirtinis tyrimas, kuriame nėra dirbtinio intelekto, o „p99 stebėjimas po įdiegimo“ veiksmas įtraukiamas į rinkmenų knygą. Kiekviename etape AI paspartėjo; žmogus patvirtinamas kiekviename sprendimo taške.

Auksinė žmogaus ir AI darbo pasidalijimo taisyklė

Skirtumas, kurį matote visame modulyje, čia tampa taisykle: AI pirmauja klausimais, „kas vyksta, kas gali atsitikti, kaip rašyti“; Žmonės yra priekyje, kai kalbama apie tokius klausimus kaip "ar turėčiau tai padaryti dabar, kas gali tai garantuoti?" AI yra nenuilstantis, greitas, nuskaito didžiulę informaciją ir generuoja brėžinius, bet nežino viso konteksto, gali sukelti haliucinacijas, negali susidoroti su atskaitomybe ir nemato paslėptų jūsų organizacijos priklausomybių. Žmogus yra lėtas, bet neša kontekstą, atsakomybę ir sprendimą. Geriausias rezultatas yra teisingas darbo pasidalijimas tarp šių dviejų: pasikartojantį, tekstinį, produktyvų darbą perduoti AI; Tikrinimas, sprendimas ir vykdymas yra žmogiški.

trys mini dėklai

1 atvejis – 40 minučių iki galo. Disko pilno įvykio atveju SRE paspartino visą grandinę su AI: patvirtino aliarmą su bazine linija (5 min.), užmaskuotą žurnalą apibendrino į YZ ir rado pirmąją klaidą (5 min.), patikrino AI hipotezę „žurnalo sukimasis sustabdytas“ realioje sistemoje (5 min.), paleido ir įdiegė paruoštą valymo scenarijų su sausuoju paleidimu, AIch patikrino ir patikrino post morte (10 min. faktai (15 min.). Iš viso 40 minučių; Maždaug dvigubai daugiau be AI. Tačiau kiekviename etape buvo atliktas patikrinimas.

2 atvejis – patikrinimas praleistas ištikus panikai. Kita komanda suskubo sumažinti. Ji patvirtino pirmąją AI pagrindinės priežasties hipotezę (priklausomybės paslaugą) jos nepatikrinusi ir iš naujo paleido tą paslaugą. Problema nebuvo išspręsta, nes tikroji priežastis buvo kažkas kita; Be to, nereikalingas perkrovimas sukėlė antrą gedimą. Pamoka: skubėjimas nėra pateisinimas praleisti patikrinimą; Prieš patvirtinant AI hipotezę, veiksmas padidina įvykį.

3 atvejis – žinojimas apie ribą. Inžinierius ketino įgyvendinti konfigūracijos pakeitimą, kurio AI ragino dėl sudėtingos tinklo problemos. Tačiau pakeitimas atrodė negrįžtamas, o AI nežinojo konkrečių agentūros maršruto taisyklių. Inžinierius sustojo, pasikonsultavo su vyresniuoju tinklo ekspertu ir sužinojo, kad AI pasiūlymas sukurs maršruto kilpą šioje konkrečioje topologijoje. Žinodami AI ribą, buvo išvengta trikdžių.

Keturi kopijuojami šablonai

1) Įvykio aktyviklio suvestinė (triažas):

Jūsų vaidmuo: vyresnysis SRE, incidento vado padėjėjas. Vyksta aktyvus renginys. Užmaskuotas įspėjimas / metrika / žurnalas, kurį jums pateikiau, greitai nustato: (1) kas yra simptomas, (2) poveikio apimtis, (3) 3 sritys, į kurias pirmiausia reikia atkreipti dėmesį, (4) tik skaitoma valdymo komanda kiekvienai. Sprendimas ir vykdymas yra mano; Siųsk kelią. Duomenys: [užmaskuotas]

2) Laipsniško incidentų valdymo vadovas:

Žingsnis po žingsnio peržiūrėkite simptomo [simptomo] incidento gyvavimo ciklą: aptikimo patvirtinimą, diagnozę, švelninimą, nuolatinį sprendimą, mokymąsi. KIEKVIENA etapo metu pasakykite man (a) ką turiu daryti, (b) kada galiu saugiai tai perduoti dirbtiniam intelektui, (c) kokį sprendimą PRIVALAU priimti pats. Pažymėkite patvirtinimo veiksmus, kurių neturėčiau praleisti, net jei skubu.

3) Sprendimo taško kontrolė:

Esu įvykio viduryje ir ketinu imtis šių veiksmų: [veiksmas]. Prieš diegdami paklauskite manęs: 1) ar tai grįžtama, 2) kokį patikrinimą aš padariau / neatlikau, 3) ar turiu atšaukimo planą, 4) ar turiu įrodymų, kad šis veiksmas iš tikrųjų pašalino pagrindinę priežastį? Jei matote, kad ko nors trūksta, sustabdykite mane.

4) Integruotas mokymasis po renginio:

Dėl ką tik išspręsto incidento [santrauka] pateikia: (1) pomirtinį juodraštį be priekaištų, (2) 3 nuolatinius patobulinimus (stebėjimą / automatizavimą / konfigūraciją), kurie padės išvengti šio incidento, (3) vykdymo knygos veiksmus, kuriuos reikia atnaujinti, (4) išankstinio įspėjimo signalo pasiūlymą dėl panašaus incidento. Pagrindinės priežasties rašymas be įrodymų; remiantis faktais.

Silpnas raginimas / Stiprus raginimas

Silpnas raginimas:

Sistema sugedo, ką turėčiau daryti?

Panikuodamas, be konteksto ir patikrinimo, šis raginimas gauna bendrų ir galbūt pavojingų AI patarimų. Skubėjimas priveda prie klaidų šiuo metu labiausiai.

Galingas raginimas:

Jūsų vaidmuo: incidento vado padėjėjas. Aktyvus įvykis: mokėjimo serviceip99 atsako laikas 15 kartų didesnis nei pradinis (250–400 ms) nuo 02:10. Žinau, kad 02:08 buvo platinimas. Pateikite man: (1) labiausiai tikėtiną hipotezę ir kaip ją patikrinti TIK SKAITYMO, (2) greičiausią ir GRĮŽIAMĄ švelninimo variantą, (3) riziką, kurią turiu kontroliuoti prieš taikydamas šį mažinimą. Aš turiu vykdymą ir patvirtinimą. Papildomi duomenys: [užmaskuota metrika / žurnalas]

įvykio fazė

AI vaidmuo

Kritinis žmogaus sprendimas

aptikimas

Pažymėkite anomaliją

Ar tai tikras įvykis, kokia apimtis?

Diagnozė

hipotezių generavimas

Kuri hipotezė pasitvirtino?

sumažinimas

Nesiūlykite variantų

Kuris sumažinimas yra grįžtamas?

nuolatinis sprendimas

Juodraštis/scenarijus

Patvirtinti ir vykdyti pakeitimą

Mokymasis

Pomirtinis eskizas

Faktų ir pamokų patvirtinimas

Dažnos klaidos

  • Panikuojant praleidžiamas patvirtinimas. Skubėjimas nėra pateisinimas atsisakyti reflekso „skaityk-patikrink-paruošk sugrįžimą“; Didėjant stresui, turi didėti disciplina.
  • Hipotezės klaidingas įrodymas. Jei imsitės veiksmų nepatvirtinus pirmosios AI pagrindinės priežasties pasiūlymo, incidentas padidės.
  • Pamiršus AI konteksto ribą. AI nežino paslėptų organizacijos priklausomybių; Esant kritiniams pokyčiams, vyrauja žmogaus sprendimas.
  • Mokymosi etapo praleidimas. Renginys be post mortem ir runbook atnaujinimų vėl prasideda tą pačią naktį.
  • Atsakomybės sukėlimas AI. „AI taip pasakė“ nėra gynyba; Atsakomybė už vykdymą visada tenka žmogui.
Įspėjimas: AI naudojimas incidentų valdymui nepakeičia mokymosi incidentų valdymo. Transporto priemonė gali sudužti, trenktis arba būti nepasiekiama. Inžinierius, žinantis pagrindus, yra greitesnis naudojant AI; Inžinierius, kuris neišmano pagrindinių dalykų, su AI padarys klaidas greičiau. Pirmiausia nustatykite discipliną, tada gaukite greitį iš AI.

Apibendrinant

Realiame pasaulyje dalys ateina ne po vieną, o yra susipynusios per įvykį. Valdydamas įvykį nuo aptikimo iki mokymosi, dirbtinis intelektas įsibėgėja kiekviename etape: pažymi anomaliją, generuoja hipotezes, siūlo parinktis, juodraščius, ruošia postmortem. Bet kiekviename sprendimo taške sustojama – patvirtinama diagnozė, pasirenkama sumažinti, patvirtinama pakeitimas, priklauso rezultatas. Auksinė taisyklė aiški: AI lenkia klausimais „kas atsitinka, kaip rašyti“, o žmonės – „ar turėčiau tai padaryti, kas yra garantas?“ Panikos metu padidinkite drausmę, atskirkite hipotezes nuo įrodymų, prisiminkite AI konteksto ribą ir pasimokykite iš kiekvieno įvykio. Šio modulio esmė yra vienas sakinys: AI yra galingas asistentas; Inžinerinės atsakomybės perleisti negalima.

Taikymo užduotis

Apsvarstykite įvykį, kurį patyrėte (ar įsivaizdavote) praeityje, nuo pradžios iki pabaigos. Naudodami anksčiau pateiktą šabloną „Laipsinis incidentų valdymo vadovas“, paprašykite AI nukreipti incidentą aptikimo, diagnozavimo, mažinimo, sprendimo ir mokymosi etapais; Kiekviename etape atskirai parašykite žingsnį, kurį galite deleguoti AI, ir žingsnį, kurį turite nuspręsti patys. Diagnostikos etape patvirtinkite bent vieną AI hipotezę naudodami patikros komandą. Galiausiai sukurkite post mortem ir runbook naujinimo juodraštį naudodami šabloną „Integruotas mokymasis po įvykio“. Apibendrinkite žmogaus ir AI darbo pasidalijimą visame procese į 7 punktus.

kontrolinis sąrašas

  • [ ] Ar aš suskirstiau incidentą į aptikimo, diagnozavimo, sušvelninimo, sprendimo ir mokymosi etapus?
  • [ ] Ar atskyriau veiksmus, kuriuos galima deleguoti dirbtiniam intelektui, ir tuos, kuriems kiekviename etape reikia priimti sprendimus?
  • [ ] Ar diagnozėje atskyriau AI hipotezę nuo įrodymų ir patvirtinau ją patvirtinimo komanda?
  • [ ] Ar įvertinau švelninimą, atsižvelgdamas į grįžtamumą ir atšaukimo planą?
  • [ ] Ar net ir panikos metu išlaikiau refleksą „skaityti-patikrinti-paruošti sugrįžimą“?
  • [ ] Ar iš šio įvykio išmokau pomirtinį ir runbook pamoką?

Modulio egzaminas

1. Kuris iš šių yra tiksliausias dirbtinio intelekto padėties nustatymas sistemų ir tinklų valdyme?

  • A) Dirbtinis intelektas yra asistentas ir sprendimų palaikymo įrankis; Atsakomybė ir galutinis kritinių vykdomųjų sprendimų patvirtinimas tenka žmonėms ✔
  • B) Dirbtinis intelektas gali vykdyti komandas ir atlikti gamybos pakeitimus be žmogaus sutikimo
  • C) Dirbtinis intelektas veikia tik rašant tekstą, jis neturi nieko bendra su sistemos ir tinklo darbu
  • D) Dirbtinis intelektas visada priima tikslesnius sprendimus nei žmonės, todėl tikrinti nereikia

Aprašymas: Dirbtinis intelektas yra asistentas ir sprendimų palaikymo įrankis, kuris kuria juodraščius ir analizę, pvz., scenarijus, žurnalų analizę ir dokumentus. Atsakomybė ir galutinis sprendimų, turinčių įtakos prastovoms, duomenų praradimui ir saugumui, patvirtinimas, pavyzdžiui, komandos vykdymas ar pakeitimo patvirtinimas, priklauso kompetentingam inžinieriui.

2. Kokie keturi patikros reflekso žingsniai turi būti įgyvendinti prieš paleisdami dirbtinio intelekto sugeneruotą komandą gamyboje?

  • A) Nukopijuokite, įklijuokite, paleiskite, tikėkitės
  • B) Skaitykite ir supraskite, dokumentuokite, bandykite izoliuotoje aplinkoje, pasiruoškite atsiliepimui ✔
  • C) Pamėgti, dalintis, išsaugoti, archyvuoti
  • D) Ištrinti, perrašyti, suspausti, siųsti

Aprašymas: Keturi veiksmai, taikomi kritinei išvestiei: (1) perskaitykite ir supraskite komandų eilutę po eilutės, (2) susiekite vėliavėles ir sintaksę su oficialia dokumentacija, (3) išbandykite tai izoliuotoje / bandomojoje aplinkoje, jei įmanoma, atlikite sausą paleidimą, (4) paruoškite atsarginį planą (atsarginę kopiją, momentinę kopiją), jei nepavyktų.

3. Ką reiškia, kad automatizavimo scenarijus yra „idempotentas“ ir kodėl tai svarbu?

  • A) Scenarijus kiekviename paleidime pateikia skirtingus rezultatus
  • B) Scenarijus gali būti paleistas tik vieną kartą ir tada gali būti ištrintas
  • C) scenarijus nedaro jokios žalos, kai paleistas antrą kartą; ✔ Saugus net ir vėl suaktyvinus
  • D) Scenarijuje nėra klaidų valdymo

Paaiškinimas: Idempotencija reiškia, kad kai tas pats scenarijus paleidžiamas du ar daugiau kartų, jis nepadaro žalos ir nesukelia klaidų antrą kartą. Nustatyta logika, pvz., „praleisti, jei vartotojas jau yra“, „sukurti katalogą, jei jo nėra, nelieskite jo, jei jis yra“. Tai užtikrina, kad automatika veiktų saugiai, net jei netyčia vėl įsijungtų.

4. Koks yra elementariausias būdas apsaugoti scenarijų, kuriame yra destruktyvių operacijų (ištrynimas, paleidimas iš naujo)?

  • A) Paleiskite scenarijų kuo greičiau
  • B) Klaidų pranešimų slėpimas
  • C) Scenarijaus testavimas tiesiogiai gamyboje
  • D) Destruktyvių operacijų įtraukimas į numatytąjį sausąjį paleidimą ir faktinio diegimo susiejimas su aiškia varnele ✔

Paaiškinimas: destruktyvių procesų išlaikymas sausojo paleidimo režimu pagal numatytuosius nustatymus ir tik faktinės programos vykdymas su aiškia patvirtinimo žyma (pvz., --apply) leidžia pirmiausia pamatyti, kas atsitiks, kai bus paleistas scenarijus. Taip pat nulinio kintamojo tikrinimas (VAR:?) apsaugo nuo kelio klaidų.

5. Ką loginės analizės metu reiškia principas „koreliacija nėra priežastinis ryšys“?

  • A) Du kartu besikeičiantys įvykiai nebūtinai yra priežasties ir pasekmės ryšyje; Taip pat turi būti patikrintas priežastinis ryšys ✔
  • B) Ieškoti koreliacijos žurnaluose yra laiko švaistymas
  • C) Iš dviejų kartu besikeičiančių įvykių vienas neabejotinai yra kito priežastis.
  • D) Priežastinį ryšį gali nustatyti tik dirbtinis intelektas

Paaiškinimas: vien todėl, kad du įvykiai vyksta vienu metu (koreliacija), nereiškia, kad vienas sukelia kitą (priežastinis ryšys); Abu gali būti trečiojo įvykio pasekmė. AI pasiūlymas, kad „X tikriausiai sukėlė Y“ yra hipotezė ir nelaikoma radiniu, kol nepatvirtinama sistemoje.

6. Kodėl vertinant atsako laiką atliekant veiklos stebėjimą pirmenybė teikiama procentiliui (p95/p99), o ne vidutiniam?

  • A) Procentilį lengviau apskaičiuoti nei vidurkį
  • B) Vidurkis slepia blogą mažumos patirtį; procentilė atskleidžia šias paslėptas problemas ✔
  • C) Vidurkis visada neteisingas ir neturėtų būti naudojamas
  • D) Percentilis taikomas tik procesoriaus metrikai

Paaiškinimas: Vidutinis slepia labai blogą patirtį, kurią turi nedidelė dalis vartotojų. Nors atrodo, kad vidurkis yra 200 ms, p99 gali būti 6 sekundės; Tai reiškia, kad vienas iš šimto užklausų yra siaubingai lėtas. Percentilis daro matomą šios mažumos skausmą, kurį slepia vidurkis.

7. Kas yra konfigūracijos valdymo „dreifas“ ir kodėl jis pavojingas?

  • A) Tinklo srautas sumažėja naktį
  • B) Fizinis serverio perkėlimas
  • C) serveriai laikui bėgant nukrypsta vienas nuo kito ir standarto; ✔ Nematomas, kol iškyla problema
  • D) Automatinė konfigūracijos failų atsarginė kopija

Aprašymas: „Dreifas“ yra serverių nukrypimas vienas nuo kito ir nuo standarto dėl nedokumentuotų rankinių pakeitimų laikui bėgant. Jo pavojus yra tyla: jis nematomas, kol neįvyksta problema, tada vienas serveris elgiasi kitaip nei kiti, o diagnostika trunka valandas. AI leidžia lyginti dreifą; Aukso suvirinimo principas neleidžia.

8. Kodėl „plano“ žingsnis yra pats svarbiausias IaC įrankių (pvz., „Terraform“) apsauginis turėklas?

  • A) Planas paleidžia kodą greičiau
  • B) Ištrina plano būsenos failą
  • C) Planas nustato tik kodo formatavimą
  • D) Plane parodyta, kas bus pridėta, pakeista ir IŠTRINTA prieš įgyvendinimą; Apsaugo nuo duomenų praradimo ✔

Aprašymas: Planas (terraform plan / ansible --check) pateikia „kas pasikeis“ peržiūrą prieš vykdant kodą: kiek išteklių bus pridėta, pakeista, ištrinta. Visų pirma, eilutės „sunaikinti“ ir „pakeisti pajėgas“ rodo duomenų praradimo riziką prieš įdiegiant. Prašymas neperskaičius plano yra viena brangiausių klaidų.

9. Kodėl Terraform būsenos failas turi būti kruopščiai apsaugotas ir neįklijuojamas į AI ar atviras saugyklas?

  • A) į valstybės bylą gali būti įtrauktos paprasto teksto paslaptys; Jei nutekės, tapatybės informacija bus atskleista ✔
  • B) Kadangi būsenos failas yra per didelis
  • C) Būsenos failas jau neįskaitomai užšifruotas.
  • D) Kodas veikia greičiau, kai bendrinamas būsenos failas

Aprašymas: Būsenos failas išsaugo dabartinę valdomos infrastruktūros būseną ir gali apimti paprasto teksto paslaptis (duomenų bazės slaptažodžius, raktus). Todėl jis turėtų būti laikomas užšifruotoje, apribotoje prieiga, užrakintoje nuotolinėje programoje; Jo niekada negalima dėti į viešąją transporto priemonę ar saugyklą, kitaip paslaptis nutekės.

10. Ką dokumentacijoje pabrėžia teiginys „neteisingas runbook yra pavojingesnis už jokio nebuvimą“?

  • A) „Runbook“ rašymas yra laiko švaistymas
  • B) Neišbandyta runbook yra aklai įgyvendinama krizės metu; Vienas neteisingas žingsnis gali sukelti nelaimę ✔
  • C) „Runbooks“ yra parašyti tik administratoriams
  • D) Dokumentai niekada neturėtų būti atnaujinami

Paaiškinimas: komanda, neturinti „runbook“, krizės metu yra atsargi ir įtari; bet asmuo, turintis „oficialią“ taisyklių knygą, jį taiko patyręs stresą, neklausinėdamas. Jei „runbook“ nėra išbandytas ir jame yra vienas žingsnis klaidingas, aklas diegimas sukels nelaimę. Štai kodėl kiekvienas „runbook“ turi būti kruopščiai išbandytas ir patvirtintas realioje aplinkoje.

11. Koks yra teisingas būdas suprasti, kada diskas artėja prie gedimo atliekant nuspėjamąją priežiūrą?

  • A) Nedelsdami pakeiskite vieną blogą SMART diską
  • B) Visiškas SMART duomenų ignoravimas
  • C) pažvelgti į verčių tendenciją laikui bėgant; ✔ Nuolatinis ir greitėjantis signalų skaičiaus padidėjimas
  • D) Imkitės veiksmų tik tada, kai diskas visiškai subyrės

Paaiškinimas: vienas blogas SMART rodmuo nesukelia panikos; Normalu, kad retkarčiais ištaisomos diskų klaidos. Tikrasis signalas yra tendencija: nuoseklus ir spartėjantis vertybių, tokių kaip perskirstytas sektorius, didėjimas laikui bėgant. Štai kodėl AI suteikiama laiko eilutė, o ne vienas skaitymas.

12. Kokios yra dvi dažniausiai nepastebimos, bet svarbiausios gamybos pakeitimo dalys?

  • A) Pakeitimo spalva ir pavadinimas
  • B) Keičiančio asmens pareigos ir skyrius
  • C) Pranešimas apie pasikeitimą socialiniuose tinkluose
  • D) Atšaukimo planas ir sėkmės patvirtinimo kriterijai ✔

Paaiškinimas: jei prieš įgyvendinant pakeitimą nėra raštiško atsakymo į klausimus „kaip tiksliai atšaukti, jei sugenda“ (atšaukimo planas) ir „kaip įrodyti, kad jis sėkmingas“ (sėkmės patvirtinimo kriterijai) prieš įgyvendinant pakeitimą, tas pakeitimas dar neparengtas. Be šių dviejų nutrūkęs pakeitimas gali būti laikomas „užbaigtu“.

13. Kodėl pirmenybė teikiama „kanarų“ metodui, o ne visiems serveriams vienu metu įdiegti saugos diegimą (naują versiją / pataisą)?

  • A) pakeitimas pirmiausia taikomas mažai daliai; Klaida paveikia nedidelę dalį, o ne visą laivyną, ir pagaunama anksti ✔
  • B) Kanarų paskirstymas sunaudoja mažiau elektros energijos
  • C) „Canary“ padaro diegimo patikrinimą visiškai nereikalingą
  • D) Kanarų diegimas taikomas tik duomenų bazėms

Aprašymas: Kanarų diegimas pirmiausia taiko pakeitimą nedidelei daliai (vienam serveriui, 5 % vartotojų) ir stebi. Tokiu būdu klaida paveikia mažą dalį, o ne visą laivyną, ir pagaunama anksti. Vienu metu išplitusi klaida paveikia visus vartotojus vienu metu.

14. Kokia yra nekintama etinė ir teisinė taisyklė naudojant dirbtinį intelektą apsaugos darbe?

  • A) Dirbtinis intelektas gali būti laisvai naudojamas bet kurios sistemos pažeidžiamumui nuskaityti
  • B) Etikos kodeksas galioja tik didelėms įstaigoms
  • C) Jis naudojamas tik patvirtintose sistemose ir gynybos tikslais; Naudojimas neteisėtai prieigai ar užpuolimui yra nusikaltimas ✔
  • D) Norint mokytis, galima laisvai įsiskverbti į kažkieno sistemą.

Aprašymas: Sistemos ir tinklo informacija yra dvejopo naudojimo. Dirbtinis intelektas gali būti naudojamas tik sistemose, kurioms turite raštišką leidimą, ir gynybos tikslais (logo grėsmių aptikimas, grūdinimas, reagavimas į incidentus). Jos naudojimas norint nuskaityti arba įsiskverbti į sistemą, kuri jums nepriklauso, yra neteisėta prieiga ir nusikaltimas; Mokymuisi turi būti naudojama izoliuota laboratorija.