End-to-end-integratie: een incident van begin tot eind beheren — Kunstmatige intelligentie in systeem- en netwerkbeheer

Winst:

End-to-end beheer van een incident met ondersteuning van kunstmatige intelligentie in de detectie-, diagnose-, mitigatie-, permanente oplossing- en leerfasen
Mogelijkheid om de verificatiediscipline te handhaven, zelfs in tijden van paniek, door stappen te scheiden die kunnen worden overgedragen naar kunstmatige intelligentie en stappen die in elke fase menselijke beslissingen vereisen.
Het vermogen om de gouden regel dat kunstmatige intelligentie voorrang heeft op vragen over ‘wat gebeurt er, hoe moet ik schrijven’, en dat mensen voorrang hebben op vragen over ‘moet ik het doen, wie staat garant’, om te zetten in een zakelijke reflex

End-to-end-integratie: een incident van begin tot eind beheren met AI

Je hebt de stukken in de voorgaande tien modules geleerd: scripting, loganalyse, monitoring, configuratie, IaC, documentatie, voorspellend onderhoud, verandermanagement en beveiliging. Maar in de echte wereld komen deze onderdelen niet één voor één, maar zijn ze met elkaar verweven binnen een gebeurtenis. In dit laatste deel brengen we de stukken samen: je zult in zijn geheel zien hoe je een incident kunt beheren dat midden in de nacht is begonnen, van begin tot eind, van detectie tot hoofdoorzaak, van herstel tot documentatie, en het gebruik van de juiste dosis AI in elke fase. Het doel is niet om een nieuwe techniek aan te leren; het samenbrengen van wat je hebt geleerd als de reflex van een ingenieur, waardoor de enige waarheid wordt versterkt die in de hele module wordt herhaald: AI versnelt, verlicht en blauwdrukken in elke fase; maar het is altijd de mens die de diagnose bevestigt, het bevel voert, de verandering bevestigt en de verantwoordelijkheid draagt voor de uitkomst.

In deze unit integreer je de levenscyclus van een incident (detectie, diagnose, interventie, oplossing, leren) en de rol en grenzen van AI in elke fase aan de hand van een voorbeeld.

Levenscyclus van een gebeurtenis

Elk ernstig incident doorloopt vergelijkbare fasen, en in elke fase speelt AI een andere rol. Detectie: er klinkt een alarm, een gebruiker klaagt, een metriek wijkt af van de basislijn (Unit 4). Validatie en reikwijdte: is het echt een probleem, hoe breed is het? Diagnose: op basis van logboeken en statistieken de hoofdoorzaak achterhalen (Unit 3). Reactie en beperking: schade stoppen, oplossing. Permanente oplossing: fix met wijzigingsbeheer (Unit 9), script (Unit 2) of configuratie indien nodig (Unit 5). Leren: post-mortem en runbook-update (Unit 7). AI markeert de anomalie bij de detectie, produceert hypothesen bij de diagnose, biedt opties bij interventies, schrijft concepten bij de oplossing, produceert documenten bij het leren - maar in elke fase staan mensen op het beslissingspunt.

Tip: Het gevaarlijkste moment van een incident is het moment van diagnose en reactie wanneer de stress het hoogst is – juist wanneer de drang om blindelings op de AI te vertrouwen het sterkst is. Hoe meer je haast, hoe steviger je vasthoudt aan de reflex van ‘lezen, verifiëren, voorbereiden op terugkeer’. Eén enkele verificatie die in een moment van paniek wordt overgeslagen, verdubbelt de gebeurtenis.

Een voorbeeld van begin tot eind

Laten we het concreet maken. Alarm om 02:10 uur: de reactietijd van betaaldienst p99 is 6 seconden, ruim boven de basislijn (250–400 ms). Detectie correct: tracking werkte. Bevestiging: bevestiging vanaf meerdere locaties, een echt evenement. Diagnostiek: ingenieur geeft gemaskeerd logboek en statistieken van de afgelopen 20 minuten aan AI; De AI stelt een tijdlijn vast en markeert de vertraging als beginnend onmiddellijk na een inzet om 02:08 uur – een sterke correlatie, maar nog steeds een hypothese. De engineer bevestigt dit met het implementatielogboek: ja, er is om 02:08 uur een release vrijgegeven. Reactie: de snelste reductie is het terugdraaien van de distributie; De rollback-stap in het wijzigingsverzoek is gereed (Unit 9). De engineer implementeert de rollback eerst op een server met kanarielogica, de responstijd verbetert en propageert deze vervolgens. Permanente oplossing: de echte oorzaak (niet-geïndexeerde zoekopdracht in de nieuwe versie) wordt de volgende dag rustig opgelost. Leren: er wordt een AI-vrij post-mortem opgesteld en de stap ‘post-implementatie p99 monitoring’ wordt toegevoegd aan het runbook. In elke fase versnelde AI; mens gevalideerd op elk beslissingspunt.

De gouden regel van de arbeidsverdeling tussen mens en AI

Het onderscheid dat u door de module heen ziet, wordt hier een regel: AI loopt voorop in vragen over “wat er gebeurt, wat kan gebeuren, hoe te schrijven”; Mensen lopen voorop als het gaat om vragen als ‘moet ik dit nu doen, wie kan hiervoor instaan?’ AI is onvermoeibaar, snel, scant enorme hoeveelheden informatie en genereert blauwdrukken – maar kent niet de volledige context, kan hallucinaties veroorzaken, kan geen verantwoordelijkheid aan en ziet de verborgen afhankelijkheden van uw organisatie niet. De mens is traag, maar draagt context, verantwoordelijkheid en oordeel met zich mee. Het beste resultaat ligt in de juiste taakverdeling tussen de twee: delegeer repetitief, tekstueel, produceerbaar werk aan de AI; Houd verificatie, besluitvorming en uitvoering menselijk.

drie minikoffers

Geval 1 – 40 minuten van begin tot eind. Bij een gebeurtenis dat de schijf vol was, versnelde een SRE de hele keten met AI: bevestigde het alarm met de basislijn (5 min), liet het gemaskeerde log samenvatten in YZ en vond de eerste fout (5 min), verifieerde de 'logrotatie gestopt'-hypothese van de AI op het echte systeem (5 min), voerde een kant-en-klaar opschoningsscript uit met dry-run (10 min), liet de post-mortem-schets naar AI schrijven en verifieerde de feiten (15 min). Totaal 40 minuten; Ongeveer twee keer zoveel zonder AI. Maar in elke fase was er een verificatiestap.

Geval 2 — Verificatie overgeslagen in een moment van paniek. Een ander team haastte zich naar een snee. Het accepteerde de eerste hoofdoorzaakhypothese van de AI (een afhankelijkheidsservice) zonder deze te verifiëren en startte die service opnieuw. Het probleem werd niet opgelost omdat de werkelijke oorzaak iets anders was; Bovendien zorgde het onnodig opnieuw opstarten voor een tweede storing. Les: haast is geen rechtvaardiging voor het overslaan van de verificatie; Voordat de AI-hypothese wordt bevestigd, escaleert actie de gebeurtenis.

Geval 3 — Zich bewust zijn van de limiet. Een ingenieur stond op het punt een configuratiewijziging door te voeren waar de AI op had aangedrongen vanwege een complex netwerkprobleem. Maar de verandering leek onomkeerbaar en de AI kende de specifieke routeringsregels van het bureau niet. De ingenieur stopte, raadpleegde een senior netwerkexpert en ontdekte dat het voorstel van de AI een routeringslus in deze specifieke topologie zou creëren. Het kennen van de limiet van de AI voorkwam een verstoring.

Vier kopieerbare sjablonen

1) Samenvatting van gebeurtenistriggers (triage):

Jouw rol: senior SRE, assistent incidentcommandant. Er is een actief evenement. De gemaskeerde waarschuwing/statistiek/log die ik je geef, geeft me een snelle beoordeling: (1) wat is het symptoom, (2) wat is de omvang van de impact, (3) 3 gebieden waar we eerst naar moeten kijken, (4) een alleen-lezen controlecommando voor elk. De beslissing en uitvoering is aan mij; Stuur de weg. Gegevens: [gemaskeerd]

2) Gids voor gefaseerd incidentbeheer:

Leid mij stap voor stap door de levenscyclus van het incident voor symptoom [symptoom]: detectiebevestiging, diagnose, mitigatie, permanente oplossing, leren. Vertel mij in ELKE fase (a) wat ik moet doen, (b) wanneer ik dit veilig aan de AI kan delegeren, (c) welke beslissing ik zelf MOET nemen. Markeer de verificatiestappen die ik niet mag overslaan, ook al haast ik me.

3) Beslissingspuntcontrole:

Ik zit midden in een gebeurtenis en sta op het punt de volgende actie te ondernemen: [actie]. Vraag me vóór de implementatie het volgende: (1) is dit omkeerbaar, (2) welke verificatie heb ik wel/niet gedaan, (3) heb ik een terugdraaiplan, (4) heb ik bewijs dat deze actie daadwerkelijk de hoofdoorzaak heeft opgelost? Als je ziet dat er iets ontbreekt, stop me dan.

4) Geïntegreerd leren na het evenement:

Voor het zojuist opgeloste incident geeft [samenvatting] mij: (1) een post-mortem-concept zonder schuld, (2) 3 permanente verbeteringen (monitoring/automatisering/configuratie) die dit incident zullen voorkomen, (3) runbookstappen die moeten worden bijgewerkt, (4) suggestie voor vroegtijdige waarschuwingssignalen voor een soortgelijk incident. Het schrijven van de hoofdoorzaak zonder bewijs; gebaseerd op feiten.

Zwakke prompt/sterke prompt

Zwakke prompt:

Het systeem is gecrasht, wat moet ik doen?

In paniek, zonder context en zonder verificatie, ontvangt deze prompt generiek en mogelijk gevaarlijk advies van de AI. Haasten leidt op dit punt het meest tot fouten.

Krachtige prompt:

Jouw rol: assistent incidentcommandant. Actieve gebeurtenis: responstijd van betalingsserviceip99 15 keer de basislijn (250-400 ms) sinds 02:10 uur. Ik weet dat er een distributie was om 02:08. Geef mij: (1) de meest waarschijnlijke hypothese en hoe ik deze kan verifiëren ALLEEN LEZEN, (2) de snelste en OMKEERBARE mitigatieoptie, (3) de risico's die ik moet beheersen voordat ik deze mitigatie toepas. Ik heb de uitvoering en goedkeuring. Aanvullende gegevens: [gemaskeerde statistiek/log]

gebeurtenis fase

Rol van AI

Kritische menselijke beslissing

detectie

Markeer de anomalie

Is het de feitelijke gebeurtenis, wat is de reikwijdte?

Diagnose

hypothese generatie

Welke hypothese werd bevestigd?

reductie

Bied geen opties aan

Welke reductie is omkeerbaar?

permanente oplossing

Concept/script

Keur de wijziging goed en voer deze uit

Leren

Post-mortem schets

Valideren van feiten en lessen

Veel voorkomende fouten

Verificatie overslaan in paniek. Haasten is geen rechtvaardiging voor het opgeven van de ‘lees-verifieer-voorbereid-terugkeer’-reflex; Naarmate de stress toeneemt, moet de discipline toenemen.
Een hypothese voor bewijs verwarren. Als u actie onderneemt zonder de eerste suggestie van de AI te bevestigen, zal het incident escaleren.
De contextgrens van AI vergeten. AI kent de verborgen afhankelijkheden van de organisatie niet; Bij kritische verandering prevaleert het menselijk oordeel.
De leerfase overslaan. Het evenement begint, zonder post-mortem- en runbook-updates, dezelfde avond opnieuw.
De verantwoordelijkheid bij AI leggen. “De AI zei het” is geen verdediging; De verantwoordelijkheid voor de uitvoering ligt altijd bij de mens.

Let op: het gebruik van AI bij incidentbeheer vervangt het leren van incidentbeheer niet. Het voertuig kan crashen, crashen of ontoegankelijk zijn. De ingenieur die de basis kent, is sneller met AI; Een engineer die de basis niet kent, zal sneller fouten maken met AI. Zorg eerst voor discipline en haal dan de snelheid van AI.

Samengevat

In de echte wereld komen de onderdelen niet één voor één, maar zijn ze met elkaar verweven binnen een gebeurtenis. Bij het beheren van een gebeurtenis, van detectie tot leren, versnelt AI in elke fase: signaleert de anomalie, genereert hypothesen, biedt opties, stelt concepten op, bereidt post-mortem voor. Maar op elk beslissingspunt stopt men: bevestigt de diagnose, kiest voor vermindering, keurt de verandering goed, is eigenaar van de uitkomst. De gouden regel is duidelijk: AI loopt voorop in vragen als “wat gebeurt er, hoe te schrijven”, en mensen lopen voorop in vragen als “moet ik het doen, wie staat garant?” Verhoog in tijden van paniek de discipline, scheid hypothese van bewijs, onthoud de contextlimiet van AI en trek uit elke gebeurtenis een runbookles. De essentie van deze module is één zin: AI is een krachtige assistent; De technische verantwoordelijkheid kan niet worden gedelegeerd.

Applicatie taak

Denk eens aan een gebeurtenis die je in je verleden hebt meegemaakt (of je hebt voorgesteld), van begin tot eind. Met het bovenstaande sjabloon ‘Gefaseerde incidentbeheergids’ kunt u de AI vragen om het incident door de fasen van detectie-diagnose-mitigatie-resolutie-leren te leiden; Schrijf in elke fase apart welke stap je aan de AI kunt delegeren en welke stap je zelf moet beslissen. Bevestig ten minste één AI-hypothese met een verificatiecommando tijdens de diagnosefase. Maak ten slotte een post-mortem- en runbook-updateconcept met de sjabloon 'Post-event Integrated Learning'. Vat de taakverdeling tussen mens en AI in het hele proces samen in 7 items.

controlelijst

[ ] Heb ik het incident onderverdeeld in detectie-, diagnose-, mitigatie-, oplossings- en leerfasen?
[ ] Heb ik onderscheid gemaakt tussen stappen die aan AI kunnen worden gedelegeerd en stappen die in elke fase menselijke besluitvorming vereisen?
[ ] Heb ik bij de diagnose de AI-hypothese gescheiden van het bewijsmateriaal en bevestigd met een verificatiecommando?
[ ] Heb ik de mitigatie geëvalueerd in termen van omkeerbaarheid en een terugdraaiplan?
[ ] Heb ik de reflex van "lezen, verifiëren, voorbereiden" behouden, zelfs in tijden van paniek?
[ ] Heb ik een post-mortem- en runbook-les geleerd van het incident?

Module-examen

1. Welke van de volgende is de meest nauwkeurige positionering voor kunstmatige intelligentie in systeem- en netwerkbeheer?

A) Kunstmatige intelligentie is een hulp- en beslissingsondersteunend instrument; De verantwoordelijkheid en de uiteindelijke goedkeuring van cruciale beslissingen van de uitvoerende macht liggen bij mensen ✔
B) Kunstmatige intelligentie kan commando's uitvoeren en veranderingen in de productie doorvoeren zonder menselijke goedkeuring
C) Kunstmatige intelligentie werkt alleen bij het schrijven van tekst, het heeft niets te maken met systeem- en netwerkwerk
D) Kunstmatige intelligentie neemt altijd nauwkeurigere beslissingen dan mensen, dus verificatie is niet nodig

Beschrijving: Kunstmatige intelligentie is een assistent en beslissingsondersteunend hulpmiddel dat concepten en analyses produceert, zoals scripts, loganalyses en documenten. De verantwoordelijkheid en de uiteindelijke goedkeuring van uitvoerende beslissingen die van invloed zijn op downtime, gegevensverlies en veiligheid, zoals het uitvoeren van een opdracht of het goedkeuren van een wijziging, behoren toe aan de bevoegde ingenieur.

2. Wat zijn de vier stappen van de verificatiereflex die moeten worden geïmplementeerd voordat een door kunstmatige intelligentie gegenereerde opdracht in productie wordt uitgevoerd?

A) Kopiëren, plakken, uitvoeren, hopen
B) Lezen en begrijpen, documenteren, uitproberen in een geïsoleerde omgeving, voorbereiden op feedback ✔
C) Vind ik leuk, deel, bewaar, archiveer
D) Verwijderen, herschrijven, comprimeren, verzenden

Beschrijving: Vier stappen die moeten worden toegepast op een kritische uitvoer: (1) lees en begrijp de opdracht regel voor regel, (2) koppel de vlaggen en syntaxis aan de officiële documentatie, (3) probeer het in een geïsoleerde/testomgeving, probeer het indien mogelijk uit, (4) bereid een noodplan voor (back-up, momentopname) als het fout gaat.

3. Wat betekent het dat een automatiseringsscript 'idempotent' is en waarom is dit belangrijk?

A) Het script levert bij elke run verschillende resultaten op
B) Het script kan slechts één keer worden uitgevoerd en vervolgens worden verwijderd
C) Het script veroorzaakt geen schade als het een tweede keer wordt uitgevoerd; ✔ Veilig, zelfs als het opnieuw wordt geactiveerd
D) Het script bevat geen foutbeheer

Uitleg: Idempotency betekent dat wanneer hetzelfde script twee of meer keren wordt uitgevoerd, het bij de tweede run geen schade veroorzaakt of fouten veroorzaakt. Logica zoals 'overslaan als de gebruiker al bestaat', 'maak de map aan als deze niet bestaat, raak deze niet aan als deze bestaat' is tot stand gebracht. Dit zorgt ervoor dat de automatisering veilig werkt, zelfs als deze per ongeluk opnieuw wordt geactiveerd.

4. Wat is de meest eenvoudige manier om een script te beveiligen dat destructieve bewerkingen bevat (verwijderen, opnieuw opstarten)?

A) Voer het script zo snel mogelijk uit
B) Foutmeldingen verbergen
C) Het script rechtstreeks in productie testen
D) Het plaatsen van destructieve operaties achter de standaard dry-run en het binden van de daadwerkelijke implementatie aan een expliciete vinkje ✔

Uitleg: Door standaard destructieve processen in de droogloopmodus te houden en de daadwerkelijke applicatie alleen uit te voeren met een expliciete goedkeuringsvlag (bijvoorbeeld --apply), kunt u eerst zien wat er zal gebeuren als het script wordt uitgevoerd. Ook nulvariabelencontrole (VAR:?) voorkomt padfouten.

5. Wat betekent het principe 'correlatie is geen causaliteit' bij loganalyse?

A) Twee gebeurtenissen die samen veranderen, hebben niet noodzakelijkerwijs een oorzaak-gevolgrelatie; Causaliteit moet ook worden geverifieerd ✔
B) Het zoeken naar correlaties in logboeken is tijdverspilling
C) Van twee gebeurtenissen die samen veranderen, is de ene zeker de oorzaak van de andere.
D) Causaliteit kan alleen worden bepaald door kunstmatige intelligentie

Uitleg: Het feit dat twee gebeurtenissen tegelijkertijd plaatsvinden (correlatie) betekent niet dat de een de ander veroorzaakt (causaliteit); Beide kunnen het gevolg zijn van een derde gebeurtenis. De suggestie van de AI dat 'X waarschijnlijk Y heeft veroorzaakt' is een hypothese en wordt pas als een bevinding beschouwd nadat deze in het systeem is geverifieerd.

6. Waarom heeft het percentiel (p95/p99) de voorkeur boven het gemiddelde bij het meten van de responstijd bij prestatiemonitoring?

A) Percentiel is gemakkelijker te berekenen dan gemiddeld
B) Het gemiddelde verbergt de slechte ervaringen van de minderheid; percentiel onthult deze verborgen problemen ✔
C) Het gemiddelde is altijd verkeerd en mag niet worden gebruikt
D) Percentiel is alleen van toepassing op CPU-statistieken

Uitleg: Gemiddeld verbergt de zeer slechte ervaring die een klein deel van de gebruikers heeft. Hoewel het gemiddelde 200 ms lijkt te zijn, kan p99 6 seconden zijn; Dit betekent dat één op de honderd verzoeken verschrikkelijk traag is. Percentiel maakt de pijn van deze minderheid zichtbaar die door het gemiddelde verborgen blijft.

7. Wat is 'drift' in configuratiemanagement en waarom is het gevaarlijk?

A) Het netwerkverkeer neemt 's nachts af
B) Fysieke verhuizing van een server
C) Servers wijken in de loop van de tijd af van elkaar en de standaard; ✔ Onzichtbaar totdat er een probleem optreedt
D) Automatische back-up van configuratiebestanden

Beschrijving: Drift is de afwijking van servers van elkaar en van de standaard door ongedocumenteerde handmatige wijzigingen in de loop van de tijd. Het gevaar is de stilte: deze is pas zichtbaar als het probleem zich voordoet, de ene server gedraagt zich dan anders dan de andere en de diagnose duurt uren. AI maakt drift in vergelijking zichtbaar; Het gouden lasprincipe voorkomt dit.

8. Waarom is de 'plan'-stap de belangrijkste veiligheidsbarrière in IaC-tools (zoals Terraform)?

A) Het plan voert de code sneller uit
B) Verwijdert het planstatusbestand
C) Het plan repareert alleen de codeopmaak
D) Het plan laat zien wat er vóór implementatie zal worden toegevoegd, gewijzigd en VERWIJDERD; Voorkomt gegevensverlies ✔

Beschrijving: Plan (terraform plan / ansible --check) geeft een voorbeeld van 'wat zal er veranderen' voordat de code wordt uitgevoerd: hoeveel bronnen zullen worden toegevoegd, gewijzigd, verwijderd. Met name de regels 'destroy' en 'forces replacement' geven het risico van gegevensverlies vóór de implementatie aan. Solliciteren zonder het plan te lezen is een van de duurste fouten.

9. Waarom moet het Terraform-statusbestand zorgvuldig worden beschermd en niet in AI of open repository's worden geplakt?

A) Geheimen in platte tekst kunnen in het staatsdossier worden opgenomen; Indien gelekt wordt identiteitsinformatie openbaar gemaakt ✔
B) Omdat het statusbestand te groot is
C) Het statusbestand is al onleesbaar gecodeerd.
D) De code werkt sneller wanneer het statusbestand wordt gedeeld

Beschrijving: Het statusbestand houdt de huidige status van de beheerde infrastructuur bij en kan platte tekstgeheimen bevatten (databasewachtwoorden, sleutels). Daarom moet het worden bewaard in een gecodeerde, toegangsbeperkte, vergrendelde externe backend; Het mag nooit in een openbaar voertuig of opslagplaats worden geplaatst, anders zal het geheim lekken.

10. Wat wordt in de documentatie benadrukt door de uitspraak 'een verkeerd runbook is gevaarlijker dan geen runbook'?

A) Het schrijven van een runbook is tijdverspilling
B) Een ongetest runbook wordt blindelings geïmplementeerd in een crisis; Eén verkeerde stap kan tot een ramp leiden ✔
C) Runbooks zijn uitsluitend voor beheerders geschreven
D) Documentatie mag nooit worden bijgewerkt

Toelichting: Een team zonder runbook is tijdens een crisis voorzichtig en achterdochtig; maar de persoon met een 'officieel' runbook past het onder stress toe zonder vragen te stellen. Als het runbook niet is getest en één stap verkeerd is, zal blinde implementatie tot een ramp leiden. Daarom moet elk runbook grondig worden getest en gestempeld in een echte omgeving.

11. Wat is bij voorspellend onderhoud de juiste aanpak om te begrijpen wanneer een schijf bijna defect raakt?

A) Vervang onmiddellijk een enkele slechte SMART-schijf
B) Het volledig negeren van SMART-gegevens
C) Kijken naar de trend van waarden in de loop van de tijd; ✔ Consistente en versnellende toename van het aantal signalen
D) Pas actie ondernemen nadat de schijf volledig is ingestort

Uitleg: Eén enkele slechte SMART-meting is geen reden tot paniek; Het is normaal dat schijven af en toe fouten corrigeren. Het echte signaal is de trend: de consistente en versnellende stijging van waarden, zoals de herverdeelde sector in de loop van de tijd. Daarom krijgt de AI een tijdreeks, en geen enkele meting.

12. Wat zijn de twee meest over het hoofd geziene maar cruciale onderdelen van een productieomschakeling?

A) Kleur en naam van de wijziging
B) Titel en afdeling van de persoon die de wijziging doorvoert
C) Aankondiging van de wijziging op sociale media
D) Terugdraaiplan en succesverificatiecriteria ✔

Toelichting: Als er geen schriftelijk antwoord is op de vragen ‘hoe draai ik precies terug als het slecht gaat’ (rollback plan) en ‘hoe bewijs ik dat het succesvol is’ (succesverificatiecriteria) voordat een wijziging wordt doorgevoerd, dan is die wijziging nog niet klaar. Zonder deze twee kan een kapotte verandering als ‘voltooid’ worden beschouwd.

13. Waarom verdient de 'kanarie'-benadering de voorkeur boven het tegelijkertijd uitrollen van een beveiligingsimplementatie (nieuwe versie/patch) naar alle servers?

A) De wijziging wordt eerst op een klein deel toegepast; Een bug treft een klein deel, niet de hele vloot, en wordt vroegtijdig ontdekt ✔
B) Kanariedistributie verbruikt minder elektriciteit
C) Canary maakt implementatieverificatie volledig overbodig
D) Canary-implementatie is alleen van toepassing op databases

Beschrijving: Bij de Canary-implementatie wordt de wijziging eerst toegepast op een klein deel (één server, 5% van de gebruikers) en gevolgd door monitoring. Op deze manier treft een bug een klein deel, en niet de hele vloot, en wordt hij vroegtijdig opgemerkt. Een bug die zich in één keer verspreidt, treft alle gebruikers tegelijkertijd.

14. Wat is de onveranderlijke ethische en juridische regel bij het gebruik van kunstmatige intelligentie bij veiligheidswerk?

A) Kunstmatige intelligentie kan vrijelijk worden gebruikt om in elk systeem naar kwetsbaarheden te scannen
B) De ethische code is alleen van toepassing op grote instellingen
C) Het wordt alleen gebruikt in geautoriseerde systemen en voor defensiedoeleinden; Gebruik voor ongeoorloofde toegang of aanval is een misdrijf ✔
D) Het is gratis om in het systeem van iemand anders te infiltreren om te leren.

Beschrijving: Systeem- en netwerkinformatie is voor tweeërlei gebruik. Kunstmatige intelligentie kan alleen worden gebruikt in systemen waarvoor u schriftelijke toestemming heeft en voor defensieve doeleinden (logboekdreigingsdetectie, verharding, incidentrespons). Het gebruik ervan om een systeem te scannen of te infiltreren dat niet van u is, is ongeoorloofde toegang en een misdaad; Om te leren moet een geïsoleerd laboratorium worden gebruikt.