Peringatan dan Kesalahan penyimpanan, bagaimana menghadapinya?

Belum lama ini, di kota N, satu perusahaan IT yang berspesialisasi dalam bekerja dengan data pelanggan berhasil melakukan pekerjaannya di DC 24/7. Kasus yang sama ketika "pembuat sepatu bot", yaitu di perusahaan IT itu baik disadap. Hal yang menarik dimulai ketika, setelah bertahun-tahun bekerja, direktur teknis meninggalkan jabatannya, yang berdiri di dasar, di mana kontrol atas operasi yang tepat dari seluruh vertikal TI dipertahankan. Ia digantikan oleh seseorang yang tidak kurang berpengalaman (selanjutnya disebut sebagai "pro"), dan bahkan dengan cakrawala yang lebih luas, ia benar-benar memukau "bisnis" dengan cakrawala pembangunan baru. Tetapi, seperti yang sering terjadi, orang-orang yang terbang tinggi sangat enggan untuk turun ke tanah pada tingkat administrasi biasa.

Waktu kejadian:

Hari Pertama (April) : satu sistem penyimpanan lokal mulai menuangkan peringatan, dan kemudian kesalahan pertama muncul di antara mereka. Melihat ini, admin memberitahu atasannya sesuai dengan instruksi. Pro kami balas membalas dengan mengikuti "aturan emas programmer" - "Apakah itu berhasil?" Jangan sentuh!".

Mundur dari hari pertama - Biasanya sistem penyimpanan berkomunikasi menggunakan peringatan, di antaranya ada baiknya menyoroti Peringatan (dari "Peringatan") - alarm. Bahkan, ini adalah peringatan yang menandakan acara alarm atau mengingatkannya. Jenis peringatan:
Peringatan (dari "Peringatan") - peringatan; biasanya memberi waktu untuk berpikir dengan tenang.
Errora (dari "Kesalahan") - kesalahan; misalnya, disk macet, tetapi akses data tidak terganggu; di sini tidak layak menunda keputusan mereka sampai nanti.
( “Critical Error”) – , , .

(/) , ( /) , . ( ) ,

(): insinyur kami (Agat-A), mengerjakan proyek pelanggan yang lain, mencari tahu tentang kesalahan ini, dan bertanya-tanya "apa yang mereka lakukan?", jawabannya adalah "tidak ada, mereka mendapat kasus dalam sistem internal mereka, manajemennya mutakhir, ..." . Dari sisi admin lokal, semuanya dilakukan sesuai dengan proses standar, jelas sesuai dengan instruksi dua bulan lalu. Untuk pertanyaan - mungkin Anda perlu bantuan, admin menjawab bahwa ia telah menyelesaikan bagiannya, tetapi tidak ada tim.

Retret Hari Kedua:

Pengenalan dan penggunaan daftar periksa pemulihan bencana yang bijaksana akan membantu memulihkan gambaran umum tindakan, dan juga dapat membantu menghindari kesalahan yang jelas dan kerepotan yang tidak perlu.

Contoh daftar periksa untuk pemulihan bencana kompleks:
, .
— . — .

, , .

, — .



(): mengabaikan kesalahan menyebabkan fakta bahwa sistem penyimpanan menjadi kurang responsif dan sudah "karena suatu alasan" tidak selalu menarik keluar tugas yang menumpuk, keluhan pertama pelanggan tentang kecepatan kerja selama jam sibuk muncul. Dan di sini sudah dari pro (manajer TI) bertanya pada rapat perencanaan. Dia menyadari bahwa sudah waktunya untuk melakukan sesuatu dan pergi ke "ruang mesin". Intinya - pada siang hari, sebuah case dibuka pada portal vendor tentang ... controller yang gagal!

Setelah itu, insinyur pelanggan dengan sopan meminta kami untuk membantu. Secara terpisah, perlu disebutkan bahwa untuk menghemat kemitraan di tempat dan dukungan vendor saat membeli sistem, kami "memotong" dan de jure kita seharusnya tidak berurusan dengan masalah ini sama sekali, tetapi, karena adanya hubungan yang baik dengan pelanggan dan proyek yang dilaksanakan sekitar sekali setiap setengah tahun, Kami terhubung untuk menyelesaikan masalah atas permintaan pelanggan. Segera meminta untuk menghapus log, kami segera menerimanya, lebih jelas menggambarkan situasi untuk menghubungi vendor, mengatur pentingnya, dll. Log menunjukkan bahwa satu controller mati, dan yang kedua crash, tetapi memperbaiki kesalahan dengan cepat, dan baterai di controller kedua juga mati. Kami mengumumkan diagnosis (yah, itu bukan kalimat), kami mempercepat urutan pengendali dari pabrikan, seperti biasa, mereka tidak berada di gudang Rusia.

— , . . / .

.
:

.
: ____________________.
: ____________________.
.
: ____________________.
: ____________________.

, .
, .

, , , . , .

:

• , .. , , .
• , .. IT-.
• .
• IT-.

Hari keempat (Agustus) : beberapa minggu kemudian, pengontrol melewati bea cukai dan mencapai pelanggan server (sepanjang jalan, kami menulis ulang nomor seri, mereka akan diperlukan untuk menutup kasing untuk mendukung vendor ketika mengirim pengontrol lama). Jalur dari bea cukai ke server adalah 2 hari. Dan kemudian ... kenyataan santai dimulai lagi. Dan mengapa kita terburu-buru? Pelanggan menolak penggantian pengontrol yang diusulkan oleh spesialis kami, atau setidaknya menyertai proses ini, kami sendiri tidak akan bodoh, kami akan mengetahuinya (seperti yang ditunjukkan oleh praktik selama pekerjaan direktur teknis sebelumnya, ini 100% benar). Sesuai dengan kondisi layanan, perlu (sangat diinginkan!) Untuk mengirim pengontrol lama yang diganti kembali ke pabrikan dalam waktu dua minggu. Pabrikan mengingatkan pelanggan akan pengembalian lebih dari satu kali.

Mundurnya hari keempat - manusia menjadi manusia, jangan takut untuk bertanya, jangan ragu untuk meminta bantuan dan jangan meremehkan untuk mengecek diri sendiri. Tentu saja, ada orang yang dapat mengerjakan punuk, pengalaman, dan kemampuan untuk bekerja 12 jam sehari, menyeret seluruh komponen organisasi. Kerja tim menyiratkan bahwa setiap orang menggunakan kekuatan mereka, dan bukan sebaliknya. Sebagai spesialis, bekerja melalui opsi cadangan sebelum situasi kritis terjadi. Bersiaplah untuk mereka terlebih dahulu dan biarkan mereka lewat begitu saja. Dan bahkan jika sesuatu terjadi, Anda akan siap dan dapat lulus tes ini dengan kerugian minimal.

Hari Kelima (Oktober, Klimaks):

Berikut ini adalah teks yang ditulis oleh insinyur orang pertama kami.

Pagi-pagi, ketika kantor sekitar 5 menit berjalan kaki, telepon datang dari nomor yang tidak dikenal. Saya menjawab panggilan - suara khawatir meminta pro mereka untuk membantu memecahkan masalah dengan penyimpanan mereka, karena pelanggan tidak dapat mengakses layanan mereka. Selama percakapan, saya mencoba mengidentifikasi pelanggan. Dan, sama seperti mereka, saya ingat bahwa ia (pro) tampaknya telah menghilangkan SPoF (satu titik kegagalan) sebagai pengontrol yang sama sekali tidak beroperasi, tetapi ia terus-menerus menunda penggantian yang kedua, yang gagal. Oke, hanya teknisi yang akan memberi tahu lebih banyak rincian teknis, oleh karena itu kami berkoordinasi dan segera melakukan panggilan dengan pro dan administrator, dengan cara dengan administrator yang sama sekali baru, yang ternyata dipekerjakan pada awal September.

Saya mulai mengajukan pertanyaan, banyak pertanyaan yang lebih tepat, mencoba melokalisasi masalah. Saya mengutip beberapa jawaban di banyak admin + pro baru: "controller pengganti mati yang lama segera, pada akhir Agustus atau awal September" ... "mereka tidak mengubah yang kedua, mereka ingin melakukan beberapa pekerjaan dengan penggantian yang diperlukan mematikan sistem" ... "sejauh ini semuanya telah bekerja" ... "teroris dan kritik telah hilang" ... "dan di sini sistem penyimpanan telah padam" ... "tidak ada akses ke jaringan" ... "semua layanan telah mati" ... "sebagian lampu mati" ... "tidak berkedip di mana biasanya berkedip "..." Aku tidak mengerti apa artinya ini. "

Beberapa menit kemudian, berkat jawaban atas pertanyaan saya, sebuah gambar muncul, tetapi kemudian sampul pertama terjadi. Untuk pertanyaan lain: apakah ada salinan cadangan pengaturan controller, tiba-tiba saya mendengar keheningan total. Semenit kemudian, gambar selesai: Profi menggantikan (secara fisik menghapus yang lama dan memasukkan yang baru di tempatnya, saya kutip: kesalahan kritis menghilang) satu controller (yang benar-benar mati) tanpa mematikan sistem penyimpanan. Dan sebenarnya, itu dia! Setelah itu, dia tidak melakukan apa-apa lagi dengannya, TIDAK ADA !!! "Lampu menyala, kesalahan kritis hilang." Dia meninggalkan penggantian yang kedua (pengendali yang nyaris tidak hidup) sampai penyimpanan dimatikan, yang tertunda selama hampir satu setengah bulan (sekali lagi, aturan kedua dalam aksi). Kemudian saya meminta jeda untuk berpikir (sebenarnya mencerna, karena otak menolak untuk mempercayai apa yang mereka dengar).

Setelah sadar sedikit (mungkin saat hening), saya akhirnya menyadari: satu meninggal, digantikan oleh yang baru kosong, yang kedua menjalani kehidupannya (selama lebih dari tiga bulan orang miskin sendirian menarik seluruh sistemnya dengan baterai mati dan segera dikoreksi oleh satu kesalahan) dan juga mati. Tidak ada salinan pengaturan, di mana orang tidak dapat langsung mendapatkan pengaturan itu sendiri, mereka tidak dapat secara fisik memberikan remote ("sesuatu" dengan Internet), dan jam kerja hilang.

Pertama saya menemukan cara untuk memperbaikinya, kemudian saya mulai mengklarifikasi tentang jaringan, apakah mungkin untuk dengan cepat mendapatkan peta jaringan (tidak, tidak, hampir tidak ada di tangan). Setelah beberapa menit ketukan tak berbalas di gerbang yang berbeda ke berbagai layanan, penyimpanan, dan peralatan jaringan (saya bertanya dan mengatakan apa yang harus dilakukan, mereka menjawab saya bahwa ternyata, semuanya terjadi tanpa remote, karena "untuk beberapa alasan tidak ada internet juga." pertanyaan dan jawaban sampai kepada saya bahwa server dhcp adalah virtual dan mereka mulai dari sistem penyimpanan ini, Anda tidak memiliki statika di mana pun dan oleh karena itu SEGALA SESUATU tidak tersedia. Ini adalah sampul kedua (saya hanya berpikir ada tempat untuk turun di bawah, karena port kontrol dirobohkan tanpa statika itu jahat.) Oke, kali ini saya mendapati diri saya jauh lebih cepat, menggambar rencana tindakan kasar di kepala saya dan menjelaskannya kepada "kolega" saya:Anda memerlukan komputer atau laptop dengan kabel tambalan di sebelah sistem penyimpanan dan tangan di dekatnya. Maka kita memerlukan: instruksi untuk mengatur pengontrol (jika hilang / hilang, maka saya akan menemukan dan mengirimkannya sekarang) dan "bagian" dari peta jaringan di sekitar sistem penyimpanan ("bagian" = pengaturan jaringan dasar). Ketika semua ini sudah siap, pada dasarnya kami mengkonfigurasi pengontrol penyimpanan baru, menghubungkannya langsung dari laptop kami dengan kabel patch sesuai dengan instruksi, menggunakan pengaturan jaringan yang ditemukan, meningkatkan DHCP Anda dan mengkonfigurasi pengontrol penyimpanan yang sudah dalam pertempuran, mengangkat setiap sistem dan memeriksa apakah itu bekerja sesuai kebutuhan. Saya menemukan dan mengirim instruksi (omong-omong, surat perusahaan juga tidak berfungsi, karena itu juga tergantung pada SHD ini, oleh karena itu saya menggunakan surat pribadi ...), ditambah saat ini pro telah menemukan setidaknya pengaturan jaringan dasar untuk SHD (alamat ip dari kedua pengontrol dan .P.). Pro akhirnya mendapat pemahaman tentang apa yang harus dilakukan,dan dia berkata bahwa dia akan mengelola lebih lanjut. Saya ingat berhubungan dan melepaskan. Setelah beberapa waktu, layanan "24/7" dari klien ini telah diperoleh.

Bagi saya, seluruh kejadian cocok dalam empat lusin menit, dan di satu sisi saya senang bahwa itu mungkin untuk menyelesaikan masalah secara online dan melalui telepon, di sisi lain saya sangat terkejut bagaimana Anda bisa mendapatkan kehidupan seperti itu. Dan klien dari perusahaan IT ini juga tidak menghargai kejadian ini, karena layanan janji seharusnya bekerja 24/7 dan ini adalah awal dari hari kerja (dan mengingat zona waktu, seseorang bahkan memiliki ketinggian hari kerja).



Ini bisa menjadi akhir, tetapi bagi saya penyelesaian kasus ini bekerja pada bug. Karena itu, saya dan kolega saya mencoba menulis: apa yang bisa / harus diubah dalam pekerjaan kami (dan bukan hanya kami) untuk mencegah hal ini terjadi di masa depan.

Kasus ini ternyata hanya pekerjaan gratis, kami bahkan tidak menggerutu berkat kami. Jelas, karena kami melihat apa yang ingin segera dilupakan oleh pelanggan, dan mengubur para saksi di hutan. Tetapi kasus ini ditambahkan ke koleksi lembar contekan / templat kami untuk situasi paling umum yang dihadapi oleh administrator, insinyur, dan bisnis saat menggunakan dan memelihara sistem penyimpanan dan sistem terkait. Meskipun bagi sebagian orang, lembar contekan dan instruksi ini mungkin terlihat terlalu sederhana atau bahkan sempit. Dalam kasus apa pun, untuk setiap sistem, Anda perlu memasukkan data Anda dalam lembar contekan / templat ini (setelah semua, setiap orang memiliki lansekap mereka sendiri, persyaratan mereka sendiri untuk informasi dan layanan, dll.), Menggambar skema mereka sendiri, mengembangkan algoritma mereka sendiri.

Akhirnya, kami memberikan contoh kebijakan cadangan.


Lembar cheat serupa yang dibuat untuk sistem Anda dapat sangat membantu pemula dan master. Bahkan jika tuannya dapat menyimpan segala sesuatu di kepalanya, ia bukan biorobot dengan jadwal kerja 24/7. Dan bagaimanapun, alat apa pun membutuhkan penggunaan yang wajar.

Dan melantunkan “Dan bagi mereka yang pergi tidur, tidurlah yang nyenyak” kami menyelesaikan cerita kami.