Mencari masalah di tempat yang salah

Ini adalah cerita pendek dari amalan sebenar, apabila masalah kecil, yang disamarkan dengan toleransi kesalahan, bertukar menjadi sakit kepala.

Pelupusan kecil:

Cawangan kecil, ia mempunyai PBX sendiri (asterisk + FreePBX) berdasarkan perkakasan desktop dan pelayan terminal tempatan yang sama dengan 1C, pembuangan fail dan pengawal domain RO maya. Internet mengedarkan Mikrotik. Cawangannya kecil, cukup untuk mereka.
Semuanya bermula dengan pemantauan (kerana kekurangan masa dan kemalasan, tidak semuanya dipantau), yang melaporkan kepanasan melampau satu pelayan (dengan PBX) di cawangan. Semasa penduduk tempatan menyelesaikan masalah itu, lelaki tua itu terkaku dan memecahkan sedikit pangkalan data MySQL.

Banyak perkara meramalkan masalah, tetapi bukan yang ini...

Tiada masalah, pangkalan telah dibaiki, semuanya harus berfungsi. Tetapi penduduk tempatan mengeluh, panggilan diputuskan. Okay - ada masalah dalam FreePBX, saya ambil sandaran, gunakannya, semuanya OK.
Tetapi masalahnya ada, penduduk tempatan masih merungut, panggilan tidak berjalan seperti biasa. Di hadapan mereka, panggilan itu kelihatan seperti biasa, tetapi apabila mereka memanggil diri mereka sendiri, atau memanggil satu sama lain, terdapat kelewatan selama beberapa saat. Saya mula melihat log Asterisk dan FreePBX yang besar dan tidak dapat difahami, tetapi saya tidak dapat melihat masalah di dalamnya. Saya masih ingat terdapat masalah dengan STUN dan ICE, yang memberikan kelewatan yang sama. Saya mematikan segala-galanya kepada neraka, hasilnya adalah sifar.

Kemurungan adalah jalan untuk membuat keputusan yang buruk:

Saya semakin tertekan, bermain-main dengan ATS selama berjam-jam tidak membawa apa-apa yang baik, sudah lewat malam, dan masalahnya tidak selesai.
Saya meninggalkan masalah itu sehingga pagi, berharap untuk kepala segar. Pada waktu pagi, satu lagi keputusan yang tidak berjaya dibuat: memandangkan sistem itu rosak (walaupun pergantungan itu tidak boleh merosakkannya), saya cuba membetulkan sistem dengan memasang semula semua pakej. Hasilnya lebih sedikit daripada sifar, kelewatan telah berkurangan (tidak ketara, tetapi sudah berjaya).
Saya membuat satu lagi keputusan buruk: jika pembaikan separa OS (dan pangkalan data dari salinan sandaran) tidak berjaya, dan punca masalahnya masih belum jelas, dan banyak masa telah dibelanjakan untuk mencari punca, kemudian saya memutuskan untuk bertindak secara radikal: kami merobohkan OS dan kami melancarkan segala-galanya dari awal (nasib baik, automasi proses melakukan ini dalam masa yang boleh diterima). Saya sedang melancarkan konfigurasi FreePBX daripada salinan. Satu lagi kegagalan. Hasilnya adalah sifar!

Putus asa - fikiran menjadi kabur, keputusan menjadi lebih teruk

Saya jatuh ke dalam keputusasaan. Fikiran yang sangat buruk mula datang, saya fikir: mungkin conf dalam sandaran adalah bengkok (ia berlaku kepada saya selepas beberapa kemas kini bahawa ia tidak berfungsi selepas mereka, dan saya tidak dapat mencari sebabnya), tiada apa-apa lagi : Saya perlu menggulung semuanya dari awal dengan tangan saya. Sungguh memalukan! Hasilnya adalah sama sekali sifar, dan banyak masa terbuang!

Penerimaan adalah jalan menuju kesedaran

Dalam percubaan terdesak untuk memahami apa yang berlaku, saya mula mengkaji dengan teliti kayu balak. Saya perhatikan satu corak. Panggilan Sambungan berlaku dalam masa tepat 5 saat, dan untuk sekumpulan panggilan 3 Sambungan dalam 15! Saya mula googling tentang kelewatan panggilan, tetapi sudah menunjukkan kelewatan tertentu. Dan saya terjumpa jawapan yang telah saya temui, orang mengatakan bahawa masalahnya adalah dalam DNS, tetapi saya tahu pasti bahawa tidak ada masalah, semua alamat telah diselesaikan!

Jelas - tidak mungkin

Tiada apa yang perlu dilakukan, saya mengambil nslookup dan bingo (saya harap saya boleh melakukan ini dengan segera)! DNS utama ada di sana (mesin maya dengan pengawal), tetapi saya tidak perasan! Jika hanya ada satu DNS, akan ada ralat πŸ˜‰

Jumlah

Masalah asas yang boleh dilihat melalui pemantauan (yang sepatutnya dikonfigurasikan untuk semua nod), bertopengkan oleh toleransi kesalahan DNS, menyebabkan kehilangan hampir dua hari bekerja untuk menyelesaikan situasi bodoh. Kemalasan adalah sakit di pantat, menyediakan pemantauan mengambil masa seminit dan mencari masalah di mana tidak ada mengambil masa dua hari.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Adakah ini pernah berlaku kepada anda?

  • Ya, sangat jarang

  • Ya, jarang

  • Selalunya

  • Sangat kerap

  • Tidak, dengan sesiapa sahaja, bukan dengan saya!

  • Tidak, saya maksum!

2 pengguna mengundi. 1 pengguna berpantang.

Sumber: www.habr.com

Tambah komen