Valutazione del danno dell'attrezzatura a seguito di un fulmine - Avrei dovuto pianificare di più?

Uno dei siti dei miei clienti ha ricevuto un fulmine diretto la scorsa settimana (per coincidenza venerdì 13! ).

Ero remoto al sito, ma lavorando con qualcuno in loco, ho scoperto uno strano modello di danno. Entrambi i collegamenti a Internet erano inattivi, la maggior parte dei server era inaccessibile. Gran parte del danno si è verificato nell'MDF , ma un IDF collegato in fibra ha perso anche il 90% delle porte su un membro dello stack. Erano disponibili abbastanza porte switch di ricambio per ridistribuire i cavi altrove e riprogrammare, ma ci sono stati tempi di inattività mentre abbiamo inseguito i dispositivi interessati.

Si trattava di un nuovo edificio / magazzino e molta pianificazione è stata dedicata alla progettazione della sala server. La sala server principale è esaurita da un UPS online APC SmartUPS RT 8000VA a doppia conversione, supportato da un generatore. C'era una corretta distribuzione dell'alimentazione a tutte le apparecchiature collegate. La replica dei dati fuori sede e i backup dei sistemi erano in atto.

In tutto, il danno (di cui sono a conoscenza) è stato:

• Scheda di linea a 48 porte non riuscita su uno switch di chassis Cisco 4507R-E .
• Switch Cisco 2960 non riuscito in uno stack di 4 membri. (oops ... cavo impilabile allentato)
• Diverse porte traballanti su uno switch Cisco 2960.
• Scheda madre e alimentatore HP ProLiant DL360 G7.
• Elfiq WAN link balancer.
• Un modem fax Multitech.
• Antenna Internet WiMax / Wireless fissa e iniettore di potenza.
• Numerosi dispositivi PoE connessi (telefoni VoIP, punti di accesso Cisco Aironet, telecamere di sicurezza IP)

La maggior parte dei problemi era legata alla perdita di un intero switch blade nel Cisco 4507R-E. Ciò conteneva parte della rete VMware NFS e l'uplink al firewall del sito. Un host VMWare non è riuscito, ma HA si è preso cura della VM una volta ripristinata la connettività di rete di archiviazione. Sono stato costretto a riavviare / spegnere e riaccendere un certo numero di dispositivi per cancellare stati di alimentazione funky. Quindi il tempo per il recupero è stato breve, ma sono curioso di sapere quali lezioni dovrebbero essere apprese ...

• Quali protezioni aggiuntive dovrebbero essere implementate per proteggere le apparecchiature in futuro?
• Come devo rivolgersi alla garanzia e alla sostituzione? Cisco e HP stanno sostituendo gli articoli sotto contratto. Il costoso bilanciatore di collegamenti WAN Elfiq ha un bizzarro sul loro sito Web che in pratica diceva " peccato , usa una protezione da sovratensione di rete ". (sembra che si aspettino questo tipo di errore)
• Sono stato in IT abbastanza a lungo per aver riscontrato danni da tempesta elettrica in passato, ma con un impatto molto limitato; ad es. un'interfaccia di rete per PC economica o la distruzione di mini switch.
• C'è qualcos'altro che posso fare per rilevare apparecchiature potenzialmente traballanti o devo semplicemente aspettare che emergano comportamenti strani?
• È stata solo una sfortuna o qualcosa di cui bisogna tener conto nel ripristino di emergenza?

Con abbastanza $$$, è possibile creare tutti i tipi di ridondanze in un ambiente, ma qual è un ragionevole equilibrio tra progettazione preventiva / ponderata e uso efficace delle risorse qui?

Un paio di lavori fa, uno dei datacenter per il posto in cui lavoravo era un piano sotto un'antenna molto grande. Questo grosso, sottile oggetto di metallo era la cosa più alta della zona e veniva colpito da un fulmine ogni 18 mesi circa. Il datacenter stesso è stato costruito intorno al 1980, quindi non lo definirei la cosa più moderna in circolazione, ma avevano una lunga esperienza nella gestione dei danni da fulmine (le schede delle comunicazioni seriali dovevano essere sostituite ogni volta , il che è un processo se le comunicazioni le schede sono in un sistema che non ha prodotto nuove parti da 10 anni).

Una cosa che è stata sollevata dalle vecchie mani è che tutta quella corrente spuria può trovare un modo per aggirare qualsiasi cosa, e può diffondersi in un terreno comune una volta che si fa ponte. E può colmare da lacune d'aria. Il fulmine è un caso eccezionale, in cui i normali standard di sicurezza non sono abbastanza buoni da prevenire gli archi e si spingeranno fino a che ha energia. E ha molto. Se c'è abbastanza energia che può arco da una griglia del controsoffitto (forse uno dei cavi di sospensione è appeso a un anello con connessione a una trave di edificio nel cemento) alla cima di un rack a 2 montanti e da lì nel chicche di rete.

Come gli hacker, c'è solo così tanto che puoi fare. Tutti i tuoi alimentatori hanno interruttori che bloccano le tensioni spurie, ma i tuoi dispositivi di rete a bassa tensione non lo fanno quasi mai e rappresentano un percorso comune per il percorso di una corrente estremamente energetica.

Rilevare kit potenzialmente traballanti è qualcosa che so fare in teoria, ma non nella realtà. Probabilmente la tua scommessa migliore è mettere l'attrezzatura sospetta in un'area e portare deliberatamente la temperatura nella stanza nella parte alta della gamma operativa e vedere cosa succede. Esegui alcuni test, carica il diavolo. Lascialo lì per un paio di giorni. Lo stress termico aggiunto su eventuali danni elettrici preesistenti può eliminare alcune bombe a tempo.

Ha sicuramente abbreviato la durata di vita di alcuni dei tuoi dispositivi, ma scoprire quali sono difficili. I circuiti di condizionamento dell'alimentazione all'interno degli alimentatori potrebbero avere componenti compromessi e fornire energia sporca al server, cosa che è possibile rilevare solo attraverso l'uso di dispositivi specializzati progettati per testare gli alimentatori.

I fulmini non sono qualcosa che ho preso in considerazione per il DR al di fuori di avere un DC in una struttura con un parafulmine gigante sul tetto . Generalmente, uno sciopero è una di quelle cose che accadono così raramente che viene mischiato sotto "l'atto di Dio" e si è spostato.

Ma ... ne hai avuto uno adesso. Mostra che la tua struttura ha avuto le giuste condizioni almeno una volta. È tempo di ottenere una valutazione di quanto siano predisposte le condizioni giuste per la struttura e pianificare di conseguenza. Se stai pensando solo agli impatti dei fulmini sulla DR adesso, penso che sia appropriato.

Ho pensato a questa domanda da quando è stata recentemente modificata in cima alla prima pagina.

Dichiaro liberamente che, per persone come sysadmin1138, che devono affrontare installazioni che sono molto interessanti per i grandi fulmini sul tetto DC, ha senso una specifica pianificazione di emergenza per un grande sciopero. Ma per la maggior parte di noi, questa è una circostanza unica, e ho pensato che una risposta più in generale adatta al resto di noi potesse avere un certo valore.

È possibile immaginare ogni tipo di minaccia per la trama del film ; scenari che potrebbero sicuramente accadere, indubbiamente eliminerebbero le operazioni aziendali se lo facessero, ma che non vi è motivo di pensare che abbia un'elevata probabilità di accadere. Conosci il genere di cose; scoppio aereo / fulmine / deposito di petrolio nelle vicinanze esplode / qualsiasi altro scenario plausibile ma di fondo.

Ognuno di questi ha un piano di mitigazione specifico che potrebbe essere messo in atto, ma suggerirei che - come indicato nella mia clausola sopra - non ha senso farlo . Come Schneier sta cercando di evidenziare nella competizione sopra collegata, solo perché puoi immaginare che qualcosa di terribile accada non lo rende una minaccia contro la quale una pianificazione specifica è utile o addirittura desiderabile. Ciò che ha senso dal punto di vista commerciale è un piano di continuità aziendale ben documentato e ampiamente documentato.

Dovresti chiederti quali sono i costi aziendali di una perdita completa del sito per vari periodi di tempo (ad esempio, 24 ore, 96 ore, una settimana, un mese) e tentare di quantificare la probabilità di ogni occorrenza. Deve essere un'analisi onesta dei costi aziendali, acquisita da tutti i livelli dell'azienda. Ho lavorato in un sito in cui la cifra generalmente accettata per i tempi di inattività era di £ 5,5 milioni / ora (e quello era 20 anni fa, quando cinque milioni di sterline erano un sacco di soldi); avere quella cifra generalmente accettata ha reso così tante decisioni molto più facili, perché sono diventate solo una questione di matematica semplice.

Il budget è la perdita prevista moltiplicata per la probabilità annuale di tale perdita; ora vedi cosa puoi fare per mitigare quella minaccia per il budget.

In alcuni casi, questo verrà eseguito su un data center di standby completo, con apparecchiature fredde, pronto per essere utilizzato 24 ore su 24, 7 giorni su 7. Può significare un piccolo data center di standby, in modo che l'interazione con i clienti possa continuare con un numero molto ridotto di agenti telefonici e un avviso del sito Web segnaposto di interruzione. Può significare una seconda connessione Internet indirizzata in modo ridondante sul tuo sito principale, che giace fredda fino al momento del bisogno. Può significare, come osserva Mark Henderson sopra, un'assicurazione (ma un'assicurazione che copre le perdite aziendali nonché i costi effettivi di recupero); se puoi spendere il tuo budget BC su un singolo pezzo di carta che coprirà tutti i costi previsti in caso di catastrofe, potrebbe avere senso acquistare quel pezzo di carta, ma non dimenticare il fattore fallimento del sottoscrittorenel piano di rischio aziendale. Può significare aggiornare i contratti di manutenzione su alcune apparecchiature di base a quelle di quattro ore estremamente costose da riparare. Solo tu puoi sapere cosa ha senso per la tua azienda.

E una volta che hai questo piano, devi davvero testarlo (con la possibile eccezione di quelli basati sull'assicurazione). Ho lavorato in un sito in cui disponevamo di un sito freddo su piccola scala completo, pronto per il taglio, a 45 minuti di auto dalla nostra struttura principale. Quando abbiamo avuto un problema che ha bloccato la rete principale, abbiamo finito per provare a risolverlo dal vivo invece di passare al sito freddo e quindifissaggio del nucleo e taglio. Uno dei motivi alla base del fallimento del taglio era che non avevamo idea di quanto tempo ci sarebbe voluto per tagliare e tagliare. Pertanto, nessuno sapeva davvero per quanto tempo sarebbe stato possibile eseguire le operazioni senza ritaglio prima di prendere la decisione di tagliare, quindi - comprensibilmente - c'era reticenza nel decidere di tagliare. Le teste sono rotolate dopo che siamo tornati online, 14 ore dopo; non a causa dell'interruzione di per sé , ma perché erano stati spesi molti soldi in una struttura per mitigare un'interruzione di un giorno in più che era rimasta inutilizzata proprio durante tale interruzione.

Come ultimo punto, tieni presente che i componenti in outsourcing del tuo piano aziendale non sono garantiti per funzionare. Il tuo senior management potrebbe essere seduto lì a pensare " se mettiamo i server nel cloud, saranno sempre lì e potremo licenziare gli amministratori di sistema ". Non così. Le nuvole possono fallire come qualsiasi altra cosa; se hai esternalizzato componenti critici a un fornitore, tutto ciò che hai fatto è rimuovere la tua capacità di stimare le possibilità di guasto di tali componenti. Gli SLA vanno benissimo, ma a meno che non siano sostenuti da sostanziali penali per inadempienza, sono privi di significato: perché il tuo provider dovrebbe spendere soldi extra per rimanere disponibile se potesse solo ansimare i soldi e rimborsare le spese di servizio per il periodo di non disponibilità? Per essere affidabili, i tuoi SLA devono prevedere penali che approssimano i costi per l'interruzione della tua attività. Sì, ciò aumenterà notevolmente i costi dell'outsourcing; e sì, è assolutamente prevedibile.

Dipende sempre da quanto vuoi spendere. Non ho una conoscenza abbastanza profonda per parlarne a lungo, ma sono stato in un grande datacenter farmaceutico che ha preso un fulmine e ha fatto esplodere qualcosa che doveva essere uno scaricatore a moltiplicatori ridondanti (ed è stato progettato correttamente , ma è stato implementato in modo errato, quindi qualcosa è riuscito.)

Qual è stato il picco massimo che l'UPS avrebbe potuto prevenire? Dovrebbe avere un punteggio. Apparentemente, lo sciopero è stato abbastanza diretto da superarlo, o qualcosa trapelato attorno all'alimentazione dell'UPS, come una brutta terra. Quindi, forse riesci a rivedere il tuo progetto di potenza, a determinare la probabilità di un altro attacco, a confrontare il costo della probabilità di inattività X rispetto alla riparazione e forse un elettricista a dare alla struttura un buon sondaggio per assicurarsi che tutto sia correttamente messo a terra - e alcuni spettacoli di lettura rapida che la messa a terra per sicurezza / codice non è così intensa come la messa a terra per la prevenzione di danni da fulmini.