Menilai kerusakan peralatan setelah sambaran petir - Haruskah saya merencanakan lebih banyak?

Salah satu situs klien saya menerima sambaran petir langsung minggu lalu (kebetulan pada hari Jumat tanggal 13! ).

Saya berada jauh dari situs, tetapi bekerja dengan seseorang di tempat, saya menemukan pola kerusakan yang aneh. Kedua tautan internet terputus, sebagian besar server tidak dapat diakses. Sebagian besar kerusakan terjadi di MDF , tetapi satu IDF yang terhubung dengan serat juga kehilangan 90% port pada anggota stack switch. Cukup port cadangan yang tersedia untuk mendistribusikan kembali pemasangan kabel di tempat lain dan memprogram ulang, tetapi ada waktu henti sementara kami mengejar perangkat yang terkena dampak ..

Ini adalah gedung / fasilitas pergudangan baru dan banyak perencanaan masuk ke desain ruang server. Ruang server utama dijalankan oleh UPS online konversi ganda APC SmartUPS RT 8000VA , yang didukung oleh generator. Ada distribusi daya yang tepat untuk semua peralatan yang terhubung. Replikasi data di luar kantor dan cadangan sistem tersedia.

Secara keseluruhan, kerusakan (yang saya sadari) adalah:

• Kartu saluran 48-port gagal pada sakelar sasis Cisco 4507R-E .
• Saklar Cisco 2960 yang gagal dalam tumpukan 4 anggota. (Ups ... kabel susun longgar)
• Beberapa port flaky pada switch Cisco 2960.
• Motherboard dan catu daya HP ProLiant DL360 G7.
• Elfiq WAN penyeimbang tautan.
• Satu modem faks Multitech.
• WiMax / Antena internet nirkabel tidak bergerak dan injektor daya.
• Banyak perangkat yang terhubung dengan PoE (telepon VoIP, titik akses Cisco Aironet, kamera keamanan IP)

Sebagian besar masalah terkait dengan kehilangan seluruh blade switch di Cisco 4507R-E. Ini berisi beberapa jaringan VMware NFS dan uplink ke firewall situs. Host VMWare gagal, tetapi HA merawat VM setelah konektivitas jaringan penyimpanan dipulihkan. Saya terpaksa melakukan reboot / siklus daya sejumlah perangkat untuk menghapus status daya yang funky. Jadi waktu untuk pemulihan itu singkat, tetapi saya ingin tahu tentang pelajaran apa yang harus dipelajari ...

• Perlindungan tambahan apa yang harus diterapkan untuk melindungi peralatan di masa depan?
• Bagaimana saya harus mendekati garansi dan penggantian? Cisco dan HP mengganti item berdasarkan kontrak. Penyeimbang tautan WAN Elfiq yang mahal memiliki uraian di situs web mereka yang pada dasarnya mengatakan "terlalu buruk, gunakan pelindung lonjakan jaringan ". (Sepertinya mereka mengharapkan jenis kegagalan ini)
• Saya sudah berada di IT cukup lama untuk mengalami kerusakan badai listrik di masa lalu, tetapi dengan dampak yang sangat terbatas; misalnya antarmuka jaringan PC yang murah atau penghancuran sakelar mini.
• Apakah ada hal lain yang bisa saya lakukan untuk mendeteksi peralatan yang berpotensi terkelupas, atau apakah saya hanya harus menunggu perilaku aneh muncul?
• Apakah ini semua hanya kesialan, atau sesuatu yang harus benar-benar diperhitungkan dalam pemulihan bencana?

Dengan cukup $$$, adalah mungkin untuk membangun segala macam redudansi ke dalam lingkungan, tetapi apakah keseimbangan yang masuk akal dari desain preventif / bijaksana dan penggunaan sumber daya yang efektif di sini?

Beberapa pekerjaan yang lalu, salah satu pusat data untuk tempat saya bekerja adalah satu lantai di bawah antena yang sangat besar. Barang logam besar, tipis, ini adalah benda tertinggi di daerah itu dan terkena petir setiap 18 bulan atau lebih. Pusat data itu sendiri dibangun sekitar tahun 1980, jadi saya tidak akan menyebutnya hal yang paling modern di sekitar, tetapi mereka memiliki pengalaman panjang dalam menangani kerusakan petir (papan serial harus diganti setiap waktu , yang merupakan uji coba jika koms papan berada dalam sistem yang belum memiliki bagian baru yang dibuat dalam 10 tahun).

Satu hal yang diangkat oleh tangan lama adalah bahwa semua arus palsu dapat menemukan jalan di sekitar apa pun, dan dapat menyebar di tanah yang sama setelah menjembatani. Dan dapat menjembatani dari celah udara. Petir adalah kasus luar biasa, di mana standar keselamatan normal tidak cukup baik untuk mencegah busur dan akan sejauh energi. Dan itu banyak. Jika ada energi yang cukup, ia dapat melengkung dari kisi-kisi plafon gantung (mungkin salah satu kabel suspensi digantung dari loop dengan koneksi ke balok bangunan di semen) ke bagian atas rak 2 pos dan dari sana ke barang jaringan.

Seperti peretas, hanya ada begitu banyak yang dapat Anda lakukan. Feed daya Anda semuanya memiliki pemutus pada mereka yang menjepit tegangan palsu, tetapi gigi jaringan tegangan rendah Anda hampir tidak pernah dan mewakili jalur umum untuk arus yang sangat energik untuk dirutekan.

Mendeteksi kit yang berpotensi terkelupas adalah sesuatu yang saya tahu bagaimana melakukannya secara teori, tetapi tidak dalam kenyataannya. Mungkin taruhan terbaik Anda adalah menempatkan gigi yang dicurigai ke suatu daerah dan dengan sengaja membawa suhu di dalam ruangan ke ujung yang tinggi dari Rentang Operasi dan melihat apa yang terjadi. Jalankan beberapa tes, muat heck keluar dari itu. Biarkan di sana selama beberapa hari. Tegangan termal yang ditambahkan pada setiap kerusakan listrik yang sudah ada sebelumnya dapat menghilangkan beberapa bom waktu.

Ini memang memperpendek umur beberapa perangkat Anda, tetapi mencari tahu mana yang sulit. Sirkuit pengkondisian daya di dalam catu daya mungkin telah mengkompromikan komponen dan memberikan daya kotor ke server, sesuatu yang hanya dapat Anda deteksi melalui penggunaan perangkat khusus yang dirancang untuk menguji catu daya.

Sambaran petir bukan sesuatu yang saya pertimbangkan untuk DR di luar memiliki DC di fasilitas dengan penangkal petir raksasa di atap . Secara umum, pemogokan adalah salah satu dari hal-hal yang terjadi begitu jarang sehingga terseret di bawah 'tindakan tuhan' dan bergerak bersama.

Tapi ... kamu sudah punya satu sekarang. Ini menunjukkan fasilitas Anda memiliki kondisi yang tepat setidaknya sekali. Saatnya untuk mendapatkan penilaian untuk seberapa rentan fasilitas Anda diberikan kondisi yang tepat dan rencana yang sesuai. Jika Anda hanya memikirkan dampak DR dari kilat sekarang, saya pikir itu tepat.

Saya sudah memikirkan pertanyaan ini karena baru-baru ini diedit kembali ke bagian atas halaman depan.

Saya dengan bebas menetapkan bahwa, untuk orang-orang seperti sysadmin1138 yang harus berurusan dengan instalasi yang sangat menarik bagi sambaran petir besar di atap DC, perencanaan darurat khusus untuk pemogokan besar masuk akal. Tetapi bagi kebanyakan dari kita, ini adalah situasi yang hanya terjadi satu kali saja, dan saya pikir jawaban yang lebih umum cocok untuk kita semua mungkin memiliki beberapa nilai.

Dimungkinkan untuk membayangkan semua jenis ancaman plot film ; skenario yang pasti dapat terjadi, tidak diragukan lagi akan menurunkan operasi bisnis Anda jika mereka melakukannya, tetapi tidak ada alasan untuk berpikir kemungkinan peningkatan terjadi. Anda tahu hal-hal semacam itu; pemogokan pesawat / petir / depot minyak di dekatnya meledak / skenario risiko lain yang masuk akal tapi latar belakang.

Masing-masing memiliki rencana mitigasi khusus yang dapat diterapkan, tetapi saya akan menyarankan bahwa - memodulasi ketentuan saya di atas - tidak masuk akal secara bisnis untuk melakukannya . Seperti yang coba ditunjukkan oleh Schneier dalam kompetisi yang terkait di atas, hanya karena Anda dapat membayangkan sesuatu yang mengerikan terjadi tidak menjadikannya ancaman terhadap perencanaan tertentu yang berharga, atau bahkan diinginkan. Apa yang dilakukannya masuk akal bisnis yang baik adalah tujuan umum, terdokumentasi dengan baik, diuji rencana kesinambungan bisnis.

Anda harus bertanya pada diri sendiri berapa biaya bisnis dari kehilangan situs lengkap untuk berbagai periode waktu (misalnya, 24 jam, 96 jam, satu minggu, satu bulan) dan berusaha untuk menghitung kemungkinan setiap kejadian. Itu harus merupakan analisis biaya bisnis yang jujur, yang diterima oleh semua tingkatan bisnis. Saya telah bekerja di sebuah situs di mana angka downtime yang diterima secara umum adalah £ 5,5 juta / jam (dan itu 20 tahun yang lalu, ketika lima juta pound adalah banyak uang); memiliki angka yang disepakati umumnya membuat begitu banyak keputusan jadi lebih mudah, karena mereka hanya menjadi soal matematika sederhana.

Anggaran Anda adalah kerugian yang diproyeksikan dikalikan dengan peluang tahunan dari kerugian itu; sekarang lihat apa yang dapat Anda lakukan untuk mengurangi ancaman itu untuk anggaran.

Dalam beberapa kasus, ini akan berjalan ke pusat data siaga penuh, dengan peralatan dingin, siap digunakan 24x7. Ini mungkin berarti pusat data siaga kecil, sehingga interaksi pelanggan dapat berlanjut dengan jumlah operator telepon yang sangat berkurang, dan situs web placeholder yang memperingatkan gangguan. Ini mungkin berarti koneksi internet kedua yang dialihkan secara berlebihan di situs utama Anda, berbaring dingin sampai dibutuhkan. Ini dapat berarti, seperti yang dicatat oleh Mark Henderson di atas, asuransi (tetapi asuransi yang mencakup kerugian bisnis serta biaya aktual pemulihan); jika Anda dapat membelanjakan anggaran BC Anda pada selembar kertas yang akan menutupi semua biaya yang Anda harapkan saat terjadi bencana, mungkin masuk akal untuk membeli selembar kertas itu - tetapi jangan lupa untuk faktor kegagalan penjamin emisike dalam rencana risiko bisnis Anda. Ini mungkin berarti meningkatkan kontrak perawatan pada peralatan inti tertentu menjadi yang sangat mahal untuk perbaikan empat jam. Hanya Anda yang dapat mengetahui apa yang masuk akal untuk bisnis Anda.

Dan begitu Anda memiliki rencana ini, Anda benar-benar perlu mengujinya (dengan pengecualian yang berbasis asuransi). Saya telah bekerja di sebuah situs di mana kami memiliki situs dingin skala kecil yang lengkap, siap untuk dipangkas, 45 menit berkendara dari fasilitas utama kami. Ketika kami memiliki masalah yang mematikan jaringan inti, kami akhirnya mencoba memperbaikinya langsung daripada memotong ke situs dingin dan kemudianmemperbaiki inti dan memotong kembali. Salah satu alasan di balik kegagalan-untuk-cut-over adalah bahwa kita tidak tahu persis berapa lama untuk memotong dan memotong. Oleh karena itu, tidak ada yang benar-benar tahu berapa lama hal-hal harus dibiarkan berjalan tanpa pergantian sebelum membuat keputusan untuk memotong, jadi - cukup dimengerti - ada keengganan untuk memutuskan untuk memotong. Kepala berguling setelah kami kembali online, 14 jam kemudian; bukan karena pemadaman per se , tetapi karena banyak uang telah dihabiskan untuk fasilitas untuk mengurangi pemadaman satu hari plus yang tidak digunakan selama pemadaman seperti itu.

Sebagai poin terakhir, perhatikan bahwa komponen outsourcing rencana bisnis Anda tidak dijamin berfungsi. Manajemen senior Anda mungkin duduk di sana berpikir " jika kita meletakkan server di cloud, mereka akan selalu ada di sana, dan kita dapat memecat sysadmin ". Tidak begitu. Awan bisa gagal seperti yang lainnya; jika Anda mengalihdayakan komponen penting ke penyedia, yang Anda lakukan hanyalah menghilangkan kemampuan Anda untuk memperkirakan kemungkinan kegagalan komponen-komponen itu. SLA semuanya sangat baik, tetapi kecuali jika mereka didukung oleh penalti non-kinerja yang substansial, mereka tidak ada artinya - mengapa penyedia Anda menghabiskan uang ekstra untuk tetap tersedia jika mereka hanya bisa merapikan uang dan mengembalikan biaya layanan Anda selama periode ketidaktersediaan? Agar dapat diandalkan, SLA Anda harus disertai dengan penalti yang memperkirakan biaya untuk bisnis Anda yang terputus. Ya, itu akan banyak meningkatkan biaya outsourcing; dan ya, itu sepenuhnya diharapkan.

Itu selalu turun ke berapa banyak yang ingin Anda belanjakan. Saya tidak memiliki pengetahuan yang cukup dalam untuk berbicara panjang lebar tentang hal ini, tetapi saya sudah berada di pusat data farmasi besar yang melakukan sambaran petir dan meniup sesuatu yang seharusnya merupakan lonjakan arester berlipat ganda (dan dirancang dengan benar , tetapi salah diterapkan sehingga ada sesuatu yang berhasil.)

Berapa lonjakan maksimum yang dapat dicegah oleh UPS Anda? Itu harus memiliki peringkat. Rupanya, pemogokan itu cukup langsung untuk melampaui itu, atau sesuatu bocor di sekitar pakan UPS, seperti tanah yang buruk. Jadi, mungkin Anda meninjau desain daya Anda, menentukan seberapa besar kemungkinan pemogokan lain, membandingkan biaya downtime X kemungkinan dengan remediasi, dan mungkin meminta teknisi listrik memberikan fasilitas survei yang baik untuk memastikan bahwa semuanya terhubung dengan benar - dan beberapa bacaan cepat menunjukkan bahwa pentanahan untuk keselamatan / kode tidak seintensif pentanahan untuk mencegah kerusakan akibat petir.