Guadagni:
- Gestione end-to-end di un incidente con il supporto dell'intelligenza artificiale nelle fasi di rilevamento, diagnosi, mitigazione, soluzione permanente e apprendimento
- Capacità di mantenere la disciplina della verifica anche in tempi di panico, separando i passaggi che possono essere trasferiti all’intelligenza artificiale da quelli che richiedono una decisione umana in ogni fase.
- Capacità di trasformare la regola d'oro secondo cui l'intelligenza artificiale ha la precedenza sulle domande "cosa sta succedendo, come scrivere" e gli esseri umani hanno la priorità sulle domande "devo farlo, chi è il garante", in un riflesso aziendale
Integrazione end-to-end: gestire un incidente dall'inizio alla fine con l'intelligenza artificiale
Hai appreso gli elementi nelle dieci unità precedenti: scripting, analisi dei log, monitoraggio, configurazione, IaC, documentazione, manutenzione predittiva, gestione delle modifiche e sicurezza. Ma nel mondo reale, queste parti non si presentano una per una, ma sono intrecciate all’interno di un evento. In questa unità finale metteremo insieme i pezzi: vedrai nella sua interezza come gestire un incidente iniziato nel cuore della notte, end-to-end, dal rilevamento alla causa principale, dalla riparazione alla documentazione, e utilizzando la giusta dose di IA in ogni fase. Lo scopo non è insegnare una nuova tecnica; mettendo insieme ciò che hai imparato come riflesso di un ingegnere, rafforzando l'unica verità ripetuta in tutto il modulo: l'intelligenza artificiale accelera, illumina e progetta in ogni fase; ma è sempre l’essere umano che conferma la diagnosi, esegue il comando, conferma il cambiamento e si assume la responsabilità del risultato.
In questa unità integrerai il ciclo di vita di un incidente (rilevamento, diagnosi, intervento, risoluzione, apprendimento) e il ruolo e i limiti dell'intelligenza artificiale in ogni fase attraverso un esempio.
Ciclo di vita di un evento
Ogni incidente grave attraversa fasi simili e l’intelligenza artificiale ha un ruolo diverso in ciascuna fase. Rilevamento: suona un allarme, un utente si lamenta, una metrica si discosta dalla linea di base (Unità 4). Convalida e ambito: è davvero un problema, quanto è ampio? Diagnosi: arrivare alla causa principale da log e parametri (Unità 3). Risposta e mitigazione: arresto del danno, soluzione alternativa. Soluzione permanente: risolvere il problema con la gestione delle modifiche (Unità 9), script (Unità 2) o configurazione se necessario (Unità 5). Apprendimento: aggiornamento post-mortem e runbook (Unità 7). L’intelligenza artificiale segnala l’anomalia nel rilevamento, produce ipotesi nella diagnosi, offre opzioni di intervento, scrive bozze di soluzione, produce documenti nell’apprendimento – ma in ogni fase gli esseri umani si trovano al punto decisionale.
Suggerimento: il momento più pericoloso di un incidente è il momento della diagnosi e della risposta, quando lo stress è massimo, proprio quando è più forte la voglia di fidarsi ciecamente dell’intelligenza artificiale. Più corri, più ti aggrappi al riflesso "leggi, verifica, preparati per il ritorno". Una sola verifica saltata in un momento di panico raddoppia l'evento.
Un esempio dall'inizio alla fine
Rendiamolo concreto. Un allarme alle 02:10: il tempo di risposta del servizio di pagamento p99 è di 6 secondi, ben al di sopra della linea di base (250–400 ms). Rilevamento corretto: il tracciamento ha funzionato. Cresima: conferma da più sedi, un vero e proprio evento. Diagnostica: l'ingegnere fornisce all'IA il registro mascherato e le metriche degli ultimi 20 minuti; L’intelligenza artificiale stabilisce una sequenza temporale e segnala che il rallentamento è iniziato immediatamente dopo lo schieramento alle 02:08: una forte correlazione, ma pur sempre un’ipotesi. L'ingegnere lo conferma con il registro di distribuzione: sì, alle 02:08 è stato rilasciato un comunicato. Risposta: la riduzione più rapida consiste nel ripristinare la distribuzione; La fase di rollback nella richiesta di modifica è pronta (Unità 9). L'ingegnere prima implementa il rollback su un server con logica canary, il tempo di risposta migliora e poi lo propaga. Soluzione permanente: la vera causa principale (query non indicizzata nella nuova versione) verrà risolta con calma il giorno successivo. Apprendimento: viene redatto un post mortem senza intelligenza artificiale e la fase di "monitoraggio p99 post-distribuzione" viene aggiunta al runbook. In ogni fase, l’intelligenza artificiale ha subito un’accelerazione; convalidato dall'uomo in ogni punto decisionale.
La regola d’oro della divisione del lavoro tra uomo e intelligenza artificiale
La distinzione che vedi in tutto il modulo diventa qui una regola: l'intelligenza artificiale è in vantaggio su "cosa sta succedendo, cosa può succedere, come scrivere"; Le persone sono in vantaggio quando si tratta di domande come "dovrei farlo adesso, chi può garantirlo?" L'intelligenza artificiale è instancabile, veloce, analizza vaste informazioni e genera progetti, ma non conosce il contesto completo, può produrre allucinazioni, non è in grado di gestire le responsabilità e non vede le dipendenze nascoste della tua organizzazione. L’uomo è lento, ma porta con sé contesto, responsabilità e giudizio. Il risultato migliore sta nella corretta divisione del lavoro tra i due: delegare il lavoro ripetitivo, testuale e producibile all’IA; Mantieni la verifica, la decisione e l'esecuzione umane.
tre mini custodie
Caso 1: 40 minuti dall'inizio alla fine. In un evento di disco pieno, un SRE ha accelerato l'intera catena con l'IA: ha confermato l'allarme con la linea di base (5 minuti), ha riepilogato il registro mascherato in YZ e ha trovato il primo errore (5 minuti), ha verificato l'ipotesi di "rotazione del registro interrotta" dell'AI sul sistema reale (5 minuti), ha eseguito e implementato uno script di pulizia già pronto con il dry-run (10 minuti), ha fatto scrivere lo schizzo post-mortem all'IA e ha verificato i fatti (15 minuti). Totale 40 minuti; Circa il doppio senza l’intelligenza artificiale. Ma c'era una fase di verifica in ogni fase.
Caso 2 – Verifica saltata in un momento di panico. Un'altra squadra si è affrettata a tagliare. Ha accettato la prima ipotesi della causa principale dell'IA (un servizio di dipendenza) senza verificarla e ha riavviato quel servizio. Il problema non è stato risolto perché la vera causa era qualcos'altro; Inoltre, il riavvio non necessario ha creato una seconda interruzione. Lezione: la fretta non è una giustificazione per saltare la verifica; Prima che l’ipotesi dell’IA venga confermata, l’azione intensifica l’evento.
Caso 3 — Essere consapevoli del limite. Un ingegnere stava per implementare una modifica alla configurazione richiesta dall'intelligenza artificiale per un problema di rete complesso. Ma il cambiamento sembrava irreversibile e l’intelligenza artificiale non conosceva le regole di routing specifiche dell’agenzia. L'ingegnere si fermò, consultò un esperto di rete senior e apprese che la proposta dell'intelligenza artificiale avrebbe creato un circuito di routing in questa particolare topologia. Conoscere il limite dell'IA ha impedito un'interruzione.
Quattro modelli copiabili
1) Riepilogo dell'attivazione dell'evento (triage):
Il tuo ruolo: SRE senior, assistente comandante dell'incidente. C'è un evento attivo. L'avviso/metrica/registro mascherato che ti fornisco mi fornisce una rapida valutazione: (1) qual è il sintomo, (2) qual è l'ambito dell'impatto, (3) 3 aree da esaminare per prime, (4) un comando di controllo di sola lettura per ciascuna. La decisione e l'esecuzione sono mie; Manda la via. Dati: [mascherato]
2) Guida alla gestione degli incidenti in più fasi:
Accompagnami passo passo attraverso il ciclo di vita dell'incidente per sintomo [sintomo]: conferma del rilevamento, diagnosi, mitigazione, risoluzione permanente, apprendimento. In OGNI fase, dimmi (a) cosa devo fare, (b) quando posso delegarlo in sicurezza all'IA, (c) quale decisione DEVO prendere da solo. Segna i passaggi di verifica che non dovrei saltare anche se ho fretta.
3) Controllo del punto decisionale:
Sono nel mezzo di un evento e sto per eseguire la seguente azione: [azione]. Prima dell'implementazione, chiedimi: (1) è reversibile, (2) quale verifica ho fatto/non ho fatto, (3) ho un piano di ripristino, (4) ho prove che questa azione abbia effettivamente risolto la causa principale? Se vedi che manca qualcosa, fermami.
4) Apprendimento integrato post-evento:
Per l'incidente appena risolto, [riepilogo] mi fornisce: (1) una bozza post mortem senza colpa, (2) 3 miglioramenti permanenti (monitoraggio/automazione/configurazione) che impediranno questo incidente, (3) passaggi del runbook che devono essere aggiornati, (4) suggerimento di segnali di allarme tempestivi per incidenti simili. Scrivere la causa principale senza prove; basato sui fatti.
Prompt debole / Prompt forte
Suggerimento debole:
Il sistema si è bloccato, cosa devo fare?
In preda al panico, senza contesto e senza verifica, questo messaggio riceve consigli generici e forse pericolosi dall'IA. La fretta porta a commettere errori soprattutto a questo punto.
Suggerimento potente:
Il tuo ruolo: assistente comandante dell'incidente. Evento attivo: tempo di risposta del servizio di pagamento ip99 15 volte la linea di base (250-400 ms) dalle 02:10. So che c'era una distribuzione alle 02:08. Dammi: (1) l'ipotesi più probabile e come verificarla SOLA LETTURA, (2) l'opzione di mitigazione più rapida e REVERSIBILE, (3) i rischi che devo controllare prima di applicare questa mitigazione. Ho l'esecuzione e l'approvazione. Dati aggiuntivi: [metrica/log mascherato]
fase dell'evento
Ruolo dell'intelligenza artificiale
Decisione umana critica
rilevamento
Segna l'anomalia
È l'evento reale, qual è la portata?
Diagnosi
generazione di ipotesi
Quale ipotesi è stata confermata?
riduzione
Non offrire opzioni
Quale riduzione è reversibile?
soluzione permanente
Bozza/sceneggiatura
Approvare ed eseguire la modifica
Apprendimento
Schizzo post-mortem
Convalidare fatti e lezioni
Errori comuni
- Saltare la verifica in preda al panico. La fretta non è una giustificazione per abbandonare il riflesso “leggi-verifica-prepara il reso”; All’aumentare dello stress, la disciplina deve aumentare.
- Confondere un'ipotesi con una prova. Agire senza confermare il primo suggerimento della causa principale dell'IA aggraverà l'incidente.
- Dimenticare il confine di contesto dell’intelligenza artificiale. L'intelligenza artificiale non conosce le dipendenze nascoste dell'organizzazione; Nel cambiamento critico, prevale il giudizio umano.
- Saltare la fase di apprendimento. L'evento, senza aggiornamenti post mortem e runbook, riprende la stessa notte.
- Attribuire la responsabilità all’IA. “L’ha detto l’IA” non è una difesa; La responsabilità dell’esecuzione spetta sempre all’essere umano.
Attenzione: l'utilizzo dell'intelligenza artificiale nella gestione degli incidenti non sostituisce l'apprendimento della gestione degli incidenti. Il veicolo potrebbe schiantarsi, schiantarsi o essere inaccessibile. L'ingegnere che conosce le basi è più veloce con l'intelligenza artificiale; Un ingegnere che non conosce le basi commetterà errori più velocemente con l'intelligenza artificiale. Prima stabilisci la disciplina, poi ottieni la velocità dall'intelligenza artificiale.
In sintesi
Nel mondo reale, le parti non vengono una per una ma si intrecciano all'interno di un evento. Nella gestione di un evento, dal rilevamento all'apprendimento, l'intelligenza artificiale accelera in ogni fase: segnala l'anomalia, genera ipotesi, offre opzioni, abbozza, prepara l'autopsia. Ma ad ogni punto decisionale ci si ferma: si conferma la diagnosi, si sceglie di ridurre, si approva il cambiamento, si possiede il risultato. La regola d'oro è chiara: l'intelligenza artificiale è avanti nelle questioni "cosa succede, come scrivere", e gli esseri umani sono avanti nelle questioni "devo farlo, chi è il garante?" In tempi di panico, aumenta la disciplina, separa le ipotesi dalle prove, ricorda il limite del contesto dell'intelligenza artificiale e trai una lezione da manuale da ogni evento. L'essenza di questo modulo è una frase: l'intelligenza artificiale è un potente assistente; La responsabilità ingegneristica non può essere delegata.
Compito dell'applicazione
Considera un evento che hai vissuto (o immaginato) nel tuo passato, dall'inizio alla fine. Con il modello “Guida alla gestione degli incidenti per fasi” sopra, chiedi all’IA di guidare l’incidente attraverso le fasi di rilevamento-diagnosi-mitigazione-risoluzione-apprendimento; In ogni fase, scrivi separatamente il passaggio che puoi delegare all'IA e il passaggio di cui hai bisogno per decidere tu stesso. Confermare almeno un'ipotesi AI con un comando di verifica durante la fase di diagnosi. Infine, produrre una bozza di aggiornamento post mortem e runbook con il modello "Apprendimento integrato post-evento". Riassumere la divisione del lavoro uomo-intelligenza artificiale nell'intero processo in 7 elementi.
lista di controllo
- [ ] Ho suddiviso l'incidente in fasi di rilevamento, diagnosi, mitigazione, soluzione e apprendimento?
- [ ] Ho distinto tra i passaggi che possono essere delegati all’intelligenza artificiale e quelli che richiedono un processo decisionale umano in ogni fase?
- [ ] Nella diagnosi ho separato l’ipotesi dell’AI dall’evidenza e l’ho confermata con un comando di verifica?
- [ ] Ho valutato la mitigazione in termini di reversibilità e piano di rollback?
- [ ] Ho mantenuto il riflesso "leggere-verificare-preparare" anche nei momenti di panico?
- [] Ho imparato una lezione sull'autopsia e sul runbook dall'incidente?
Esame del modulo
1. Quale dei seguenti è il posizionamento più accurato per l'intelligenza artificiale nella gestione dei sistemi e delle reti?
- A) L’intelligenza artificiale è uno strumento di assistente e di supporto alle decisioni; La responsabilità e l'approvazione finale delle decisioni esecutive critiche spettano agli esseri umani ✔
- B) L’intelligenza artificiale può eseguire comandi e implementare cambiamenti nella produzione senza l’approvazione umana
- C) L'intelligenza artificiale funziona solo scrivendo testi, non ha nulla a che fare con il lavoro di sistema e di rete
- D) L’intelligenza artificiale prende sempre decisioni più accurate rispetto agli esseri umani, quindi la verifica non è necessaria
Descrizione: L'intelligenza artificiale è uno strumento di assistente e supporto alle decisioni che produce bozze e analisi come script, analisi di log e documenti. La responsabilità e l'approvazione finale delle decisioni esecutive che influiscono sui tempi di inattività, sulla perdita di dati e sulla sicurezza, come l'esecuzione di un comando o l'approvazione di una modifica, appartengono all'ingegnere competente.
2. Quali sono i quattro passaggi del riflesso di verifica che devono essere implementati prima di eseguire un comando generato dall'intelligenza artificiale in produzione?
- A) Copia, incolla, corri, spera
- B) Leggere e comprendere, documentare, provare in un ambiente isolato, prepararsi al feedback ✔
- C) Metti mi piace, condividi, salva, archivia
- D) Cancella, riscrivi, comprimi, invia
Descrizione: quattro passaggi da applicare a un output critico: (1) leggere e comprendere la riga di comando riga per riga, (2) collegare i flag e la sintassi alla documentazione ufficiale, (3) provarlo in un ambiente isolato/test, prova a secco se possibile, (4) preparare un piano di fallback (backup, snapshot) se va storto.
3. Cosa significa che uno script di automazione è "idempotente" e perché è importante?
- R) Lo script produce risultati diversi in ogni esecuzione
- B) Lo script può essere eseguito solo una volta e poi essere eliminato
- C) Lo script non causa alcun danno se eseguito una seconda volta; ✔ Sicuro anche se attivato nuovamente
- D) Lo script non contiene la gestione degli errori
Spiegazione: Idempotenza significa che quando lo stesso script viene eseguito due o più volte, non causa danni o produce errori alla seconda esecuzione. Si stabilisce una logica del tipo 'salta se l'utente esiste già', 'crea la directory se non esiste, non toccarla se esiste'. Ciò garantisce che l'automazione funzioni in sicurezza anche in caso di nuovo azionamento accidentale.
4. Qual è il modo più semplice per proteggere uno script che contiene operazioni distruttive (eliminazione, riavvio)?
- A) Esegui lo script il più velocemente possibile
- B) Nascondere i messaggi di errore
- C) Testare lo script direttamente in produzione
- D) Mettere operazioni distruttive dietro l'esecuzione di prova predefinita e vincolare l'implementazione effettiva a un flag di spunta esplicito ✔
Spiegazione: mantenere i processi distruttivi in modalità di esecuzione a prova per impostazione predefinita ed eseguire solo l'applicazione effettiva con un flag di approvazione esplicito (ad esempio --apply) consente di vedere prima cosa accadrà quando lo script viene eseguito. Inoltre il controllo delle variabili nulle (VAR:?) previene errori di percorso.
5. Cosa significa il principio "correlazione non causalità" nell'analisi dei log?
- A) Due eventi che cambiano insieme non sono necessariamente in una relazione di causa-effetto; Va verificata anche la causalità ✔
- B) Cercare la correlazione nei log è una perdita di tempo
- C) Di due eventi che cambiano insieme, uno è sicuramente la causa dell'altro.
- D) La causalità può essere determinata solo dall’intelligenza artificiale
Spiegazione: solo perché due eventi si verificano contemporaneamente (correlazione) non significa che uno causi l'altro (causazione); Entrambi possono essere il risultato di un terzo evento. Il suggerimento dell'IA secondo cui "X probabilmente ha causato Y" è un'ipotesi e non è considerata una scoperta finché non viene verificata nel sistema.
6. Perché il percentile (p95/p99) è preferito rispetto alla media quando si misura il tempo di risposta nel monitoraggio delle prestazioni?
- A) Il percentile è più facile da calcolare rispetto alla media
- B) La media nasconde la brutta esperienza della minoranza; il percentile rivela questi problemi nascosti ✔
- C) La media è sempre sbagliata e non va utilizzata
- D) Il percentile si applica solo ai parametri della CPU
Spiegazione: La media nasconde l'esperienza pessima vissuta da una piccola parte di utenti. Anche se la media sembra essere di 200 ms, p99 potrebbe essere di 6 secondi; Ciò significa che una richiesta su cento è terribilmente lenta. Il percentile rende visibile il dolore di questa minoranza che è nascosto dalla media.
7. Cos'è la "deriva" nella gestione della configurazione e perché è pericolosa?
- R) Il traffico di rete diminuisce di notte
- B) Trasferimento fisico di un server
- C) I server si discostano gli uni dagli altri e dallo standard nel tempo; ✔ Invisibile finché non si verifica un problema
- D) Backup automatico dei file di configurazione
Descrizione: la deriva è la deviazione dei server gli uni dagli altri e dallo standard attraverso modifiche manuali non documentate nel tempo. Il suo pericolo è il silenzio: non è visibile finché non si verifica il problema, poi un server si comporta diversamente dagli altri e la diagnosi richiede ore. L’intelligenza artificiale rende visibile la deriva al confronto; Il principio della saldatura dell'oro impedisce.
8. Perché la fase di "pianificazione" è la barriera di sicurezza più importante negli strumenti IaC (come Terraform)?
- R) Il piano esegue il codice più velocemente
- B) Elimina il file di stato del piano
- C) Il piano corregge solo la formattazione del codice
- D) Il piano mostra cosa verrà aggiunto, modificato ed ELIMINATO prima dell'implementazione; Previene la perdita di dati ✔
Descrizione: Plan (terraform plan / ansible --check) fornisce un'anteprima di "cosa cambierà" prima di eseguire il codice: quante risorse verranno aggiunte, modificate, eliminate. In particolare, le righe "distruzione" e "sostituzione forzata" indicano il rischio di perdita di dati prima dell'implementazione. Fare domanda senza leggere il piano è uno degli errori più costosi.
9. Perché il file di stato Terraform dovrebbe essere protetto con cura e non incollato nell'intelligenza artificiale o nei repository aperti?
- A) I segreti in testo semplice possono essere inclusi nel fascicolo di Stato; In caso di fuga, le informazioni sull'identità verranno divulgate ✔
- B) Perché il file di stato è troppo grande
- C) Il file di stato è già crittografato in modo illeggibile.
- D) Il codice viene eseguito più velocemente quando il file di stato è condiviso
Descrizione: il file di stato conserva lo stato corrente dell'infrastruttura gestita e può includere segreti in testo semplice (password del database, chiavi). Pertanto, dovrebbe essere conservato in un backend remoto bloccato, crittografato e con accesso limitato; Non dovrebbe mai essere collocato in un veicolo o in un deposito pubblico, altrimenti il segreto verrà divulgato.
10. Cosa sottolinea nella documentazione l'affermazione "un runbook sbagliato è più pericoloso di nessun runbook"?
- A) Scrivere un runbook è una perdita di tempo
- B) Un runbook non testato viene implementato ciecamente durante una crisi; Un passo sbagliato può portare al disastro ✔
- C) I runbook sono scritti solo per gli amministratori
- D) La documentazione non dovrebbe mai essere aggiornata
Spiegazione: una squadra senza runbook è cauta e sospettosa durante una crisi; ma la persona con un runbook "ufficiale" lo applica sotto stress senza fare domande. Se il runbook non è testato e presenta un passaggio sbagliato, l'implementazione cieca porterà al disastro. Ecco perché ogni runbook deve essere accuratamente testato e timbrato in un ambiente reale.
11. Nella manutenzione predittiva, qual è l'approccio corretto per capire quando un disco è prossimo al guasto?
- A) Sostituire immediatamente un singolo disco SMART danneggiato
- B) Ignorare completamente i dati SMART
- C) Osservare l'andamento dei valori nel tempo; ✔ Conteggio del segnale di aumento costante e accelerato
- D) Agire solo dopo che il disco è completamente collassato
Spiegazione: una singola lettura SMART errata non è motivo di panico; È normale che sui dischi vengano corretti errori occasionali. Il vero segnale è la tendenza: l’aumento costante e accelerato di valori come il settore riallocato nel tempo. Ecco perché all'intelligenza artificiale viene fornita una serie temporale, non una singola lettura.
12. Quali sono le due parti più frequentemente trascurate ma critiche di un cambio di produzione?
- A) Colore e nome della modifica
- B) Titolo e dipartimento di chi effettua la modifica
- C) Annuncio del cambiamento sui social media
- D) Piano di rollback e criteri di verifica del successo ✔
Spiegazione: Se non c'è una risposta scritta alle domande "come posso eseguire esattamente il rollback se va male" (piano di rollback) e "come posso dimostrare che ha avuto successo" (criteri di verifica del successo) prima che una modifica venga implementata, quella modifica non è ancora pronta. Senza questi due, un cambiamento interrotto può essere considerato "completo".
13. Perché è preferibile l'approccio "canary" piuttosto che implementare una distribuzione di sicurezza (nuova versione/patch) su tutti i server contemporaneamente?
- A) La modifica viene prima applicata ad una piccola parte; Un bug colpisce una piccola parte, non l'intera flotta, e viene individuato in anticipo ✔
- B) La distribuzione delle Canarie consuma meno elettricità
- C) Canary rende completamente superflua la verifica della distribuzione
- D) La distribuzione Canary si applica solo ai database
Descrizione: la distribuzione Canary applica prima la modifica a una piccola parte (un server, il 5% degli utenti) e poi esegue il monitoraggio. In questo modo, un bug colpisce una piccola parte, non l'intera flotta, e viene individuato tempestivamente. Un bug che si diffonde contemporaneamente colpisce tutti gli utenti contemporaneamente.
14. Qual è la regola etica e giuridica immutabile quando si utilizza l’intelligenza artificiale nel lavoro di sicurezza?
- R) L'intelligenza artificiale può essere utilizzata liberamente per cercare vulnerabilità in qualsiasi sistema
- B) Il codice etico si applica solo alle grandi istituzioni
- C) Viene utilizzato solo in sistemi autorizzati e per scopi di difesa; L'utilizzo per l'accesso o l'attacco non autorizzato è un reato ✔
- D) È libero di infiltrarsi nel sistema di qualcun altro per imparare.
Descrizione: le informazioni di sistema e di rete hanno un duplice utilizzo. L'intelligenza artificiale può essere utilizzata solo in sistemi per i quali si dispone di autorizzazione scritta e per scopi difensivi (rilevamento delle minacce di registro, rafforzamento, risposta agli incidenti). Usarlo per scansionare o infiltrarsi in un sistema che non ti appartiene è un accesso non autorizzato e un crimine; Per apprendere è necessario utilizzare un laboratorio isolato.