Ini adalah cerita pendek dari praktik nyata, ketika masalah kecil, disamarkan dengan baik oleh toleransi kesalahan, berubah menjadi sakit kepala.
Disposisi kecil
Cabang kecil, ia memiliki PBX sendiri (asterisk + FreePBX) berbasis desktop besi dan server terminal lokal yang sama dengan 1C, penyimpanan file, dan pengontrol domain RO virtual. Internet mendistribusikan Mikrotik. Cabang kecil sudah cukup untuk mereka.
Semuanya dimulai dengan pemantauan (karena kurangnya waktu dan kemalasan, bukan semuanya monitor), yang melaporkan terlalu panasnya satu server (dari PBX) di cabang. Sementara penduduk setempat memecahkan masalah, orang tua itu jatuh dan merusak sedikit dari database MySQL.
Banyak masalah, tapi bukan ini ...
Tidak masalah, pangkalan diperbaiki, semuanya harus bekerja. Tapi penduduk setempat mengeluh, teleponnya rusak. Oke - ada masalah di FreePBX, saya akan mengambil cadangan, menyebarkannya, semuanya OK.
Tapi masalahnya ada di tempat, penduduk setempat masih mengeluh, panggilan tidak berjalan dengan baik. Di depan mereka, panggilan berlalu dengan normal, tetapi ketika mereka sendiri memanggil, atau saling memanggil, penundaan beberapa detik diperoleh. Saya mulai melihat log Asterisk dan FreePBX yang tebal dan tidak jelas, mereka tidak dapat melihat masalahnya. Saya ingat ada masalah dengan STUN dan ICE, yang memberikan penundaan serupa. Saya mematikannya ke neraka, hasilnya nol.
Kesedihan adalah cara untuk membuat keputusan yang buruk
Saya berkecil hati, mengambil PBX selama berjam-jam tidak mengarah pada sesuatu yang baik, sudah larut malam, tetapi masalahnya tidak terpecahkan.
Dia meninggalkan masalah sampai pagi, berharap kepala baru. Di pagi hari, keputusan lain yang gagal dibuat: karena sistem telah rusak (walaupun ketergantungan tidak dapat begitu merusak), saya mencoba untuk memperbaiki sistem dengan menginstal ulang semua paket. Hasilnya sedikit lebih dari nol, penundaan berkurang (tidak signifikan, tetapi sudah sukses).
Saya membuat satu lagi keputusan buruk: jika perbaikan sebagian OS (dan basis data dari cadangan) tidak banyak berhasil, dan akar masalahnya masih belum jelas, dan pada saat yang sama banyak waktu telah dihabiskan untuk menemukan penyebabnya, maka saya memutuskan untuk bertindak secara radikal: kita menghapus OS dan kami menggulung semuanya dari awal (manfaat dari otomatisasi proses melakukan ini dalam waktu yang dapat diterima). Saya menggulung konfigurasi FreePBX dari salinan. Kegagalan lain. Hasilnya nol!
Keputusasaan - pikiran dibayangi, keputusan menjadi lebih buruk
Saya jatuh dalam keputusasaan. Pikiran yang sangat buruk mulai datang, saya pikir: mungkin conf di cadangan adalah kurva (saya memilikinya setelah sejumlah pembaruan yang tidak berhasil setelah mereka, dan saya tidak dapat menemukan alasannya), tidak ada yang tersisa: Anda perlu menggulung semuanya dari awal dengan tangan Anda. Sayang sekali! Hasilnya benar-benar nol, dan bahkan menghabiskan banyak waktu!
Penerimaan adalah jalan menuju kesadaran
Dalam upaya putus asa untuk memahami apa yang terjadi, saya mulai mempelajari log dengan hati-hati. Saya perhatikan sebuah pola. Ekstensi panggilan tepat 5 detik, dan untuk sekelompok panggilan dari 3 Ekstensi dalam 15! Saya mulai ke Google tentang penundaan panggilan, tetapi sudah menunjukkan penundaan tertentu. Dan saya menemukan jawaban yang sudah saya temukan, orang mengatakan bahwa masalahnya ada di DNS, tapi saya tahu pasti, tidak ada masalah, semua alamat diselesaikan!
Yang jelas adalah yang luar biasa
Tidak ada yang bisa dilakukan, ambil nslookup dan bingo (saya berharap bisa segera melakukannya!) Kebohongan DNS primer (virtualka dengan controller), tapi saya tidak melihat! Akan ada satu DNS, akan segera ada kesalahan;)
Ringkasan
Masalah mendasar yang dapat dilihat oleh pemantauan (masih harus dikonfigurasi untuk semua node), ditutupi oleh ketahanan DNS, menyebabkan hilangnya hampir dua hari kerja untuk menyelesaikan situasi bodoh. Terlalu malas semua api kecil, mengatur pemantauan sebentar - mencari masalah di mana itu tidak ada - dua hari.