🥇Meklējam problēmu ne tur, kur vajag

Šī ir īsa stāsta izstāde no reālās prakses, kad neliela problēma, labi maskēta ar noturību pret kļūdām, pārvēršas par galvas sāpēm.

Neliela ievadvārdi:

Mazs filiāle ar savu PBX (asterisk + FreePBX) uz galda aparatūras un tādu pašu vietējo terminālo serveri ar 1C, failu krātavu un virtuālo RO domēna kontrolieri. Internets tiek dalīts caur Mikrotik. Filiāle ir maza, viņiem tā ir pietiekami.
Viss sākās ar monitoringu (laika trūkuma un slinkuma dēļ nekontrolē visu), kas ziņoja par viena serveris (ar PBX) filiālē notikušu pārkaršanu. Kamēr vietējie risināja problēmu, vecais aparāts aizmiga un nedaudz sabojāja MySQL datubāzi.

Daudz kas liecināja par nelaimi, bet ne šo…

Nav problēmu, datubāzi izdevās salabot, viss, šķiet, darbosies. Bet vietējie sūdzas, zvanīšana pārtrūkst. Labi — problēmas ar FreePBX mēdz būt, paņemu dublējumu, atveru, viss OK.
Bet nelaime ir klāt, vietējie joprojām sūdzas, zvanīšana nenotiek normāli. Viņiem šķiet, ka zvans iet cauri normāli, bet, kad viņi paši zvana vai zvanās savā starpā, rodas vairāku sekunžu aizture. Sāku skatīties apjomīgas un neskaidras Asterisk un FreePBX žurnālus, tajos uzskatāmā problēma nav saskatāma. Atceros, bija problēma ar STUN un ICE, kas radīja līdzīgas aiztures. Izslēdzu visu, un rezultāts ir nulle.

Izmisums — ceļš uz sliktu lēmumu pieņemšanu:

Ielaižos izmisumā, daudzu stundu rakņāšanās PBX nesniedz nevienu labu rezultātu, jau ir dziļa nakts, bet problēma netiek atrisināta.
Atstāju problēmu rītam, cerot uz svaigām idejām. No rīta tika pieņemts vēl viens neveiksmīgs lēmums: ja jau sistēma ir sabojāta (lai gan aizmigt nevarēja būt tik postoši), mēģinu labot sistēmu, pārinstalējot visus paketus. Rezultāts nedaudz pārsniedza nulli, aizture samazinājās (ne ievērojami, bet jau panākums).
Pieņemu vēl vienu sliktu lēmumu: ja daļēja operētājsistēmas (un datubāzes no rezerves kopijas) atjaunošana bija nedaudz veiksmīga, bet problēmas sakne vēl joprojām nav skaidra, un tajā pašā laikā jau ir pavadīts ļoti daudz laika cēloņa meklēšanā, tad nolemju rīkoties radikāli: uzstājam operētājsistēmu no jauna (paldies automatizācijas procesam, kas to paveic saprātīgā laikā). Uzstādīju FreePBX konfigurāciju no dublējuma. Vēl viena neveiksme. Rezultāts ir nulle!

Izmisls — prāts ir apmākts, risinājumi kļūst vēl sliktāki

Es iekrītu izmisumā. Sāk ienākt pavisam dīvainas domas, domāju: varbūt konference dublējumā ir nepareiza (man tā ir noticis pēc virknes atjauninājumu, kad pēc tiem viss pārstāja darboties, un man neizdevās atrast iemeslu), nekas cits neatliek: jāuzliek viss no jauna ar rokām. Kāds kauns! Rezultāts ir stingri nulle, turklāt pavadīts liels laiks!

Pieņemšana — ceļš uz apzināšanos

Izmisīgās pūlēs izprast notiekošo, sāku uzmanīgi pētīt žurnālus. Pamanīju likumsakarību. Papildinājums tiek izsaukts tieši pēc 5 sekundēm, bet grupā no 3 papildu izsaukumiem — pēc 15! Sāku meklēt informāciju par izsaukuma aizturi, bet jau norādot konkrētu aizturi. Un uzdūros jau atrastajam atbildei, cilvēki saka, ka problēma ir DNS, bet es taču precīzi zinu, ka problēmu nav, visi adreses tiek izšķirtas!

Acīmredzamais — ne ticamais

Nav ko darīt, ņemu rokās nslookup un bingo (kā būtu jau uzreiz to izdarījis)! Primārais DNS nestrādā (virtuālā mašīna ar kontrolieri), un es pat nepamanīju! Ja būtu viens DNS, tūlīt tiktu izsniegta kļūda 😉

Rezultāts

Elementāra problēma, kuru varētu redzēt monitorings (kurš jānosaka visiem mezgliem), maskēta DNS labad, noveda pie gandrīz divu darba dienu zuduma muļķīgas situācijas risināšanā. Slinkums ir visu problēma, uzstādīt monitoringu ir minūte — meklēt problēmu tur, kur tās nav — divas dienas.

Tikai reģistrētie lietotāji var piedalīties aptaujā. Pieteikties, lūdzu.