🥇Hledáme problém na špatném místě

Toto je malý příběh ze zkušenosti, kdy se malý problém, dobře skrytý rezistencí systému, stává noční můrou.

Malá dispozice:

Malá pobočka, má svůj PBX (Asterisk + FreePBX) na desktopovém zařízení a také místní terminálový server s 1C, souborovým úložištěm a virtuálním řízením domény RO. Internet poskytuje Mikrotik. Pobočka je malá, pro ně je to dostačující.
Všechno začalo sledováním (kvůli nedostatku času a lenosti nesleduji všechno), které informovalo o přehřátí jednoho serveru (s PBX) na pobočce. Zatímco místní řešili problém, starý server zamrzl a trochu poškodil databázi MySQL.

Mnoho věcí předznamenávalo neštěstí, ale ne toto...

Nejhorší není, databáze byla opravena, všechno by mělo fungovat. Ale místní si stěžují, hovory přerušují. No jo — problémy ve FreePBX se stanou, vezmu zálohu, obnovím, všechno je v pořádku.
Ale problém přetrvává, místní se stále stěžují, hovory neprobíhají normálně. Zdá se, že hovor k nim přichází v pořádku, ale když sami volají nebo si volají navzájem, vzniká zpoždění několika sekund. Začínám zkoumat objemné a nesrozumitelné logy Asterisk a FreePBX, v nichž se nedaří problém odhalit. Vzpomínám, byla tu problém se STUN a ICE, což způsobovalo podobné zpoždění. Všechno vypínám, výsledek nula.

Deprese — cesta k přijetí špatných rozhodnutí:

Upadám do deprese, dlouhé hodiny šťourání se v PBX nevedou k ničemu dobrému, už je hluboká noc a problém není vyřešen.
Nechal jsem problém do rána, doufaje v čerstvou hlavu. Ráno bylo přijato další neúspěšné rozhodnutí: jelikož se systém pokazil (i když zamrznutí nemohlo být tak destruktivní), pokusím se systém opravit přeinstalací všech balíčků. Výsledek je o trochu lepší než nula, zpoždění se zkrátilo (ne významně, ale už je to úspěch).
Přijímám další špatné rozhodnutí: pokud částečná oprava OS (a databáze ze zálohy) měla malý úspěch, a kořen problému stále není jasný, a zároveň už bylo vynaloženo hodně času na hledání příčiny, rozhodnu se jednat radikálně: zrušíme OS a naklonujeme všechno znovu (naštěstí automatizace procesu to dělá za přijatelný čas). Nakládám konfiguraci FreePBX ze zálohy. Další neúspěch. Výsledek nula!

Bezradnost - mysl je zastřená, rozhodnutí se stávají ještě horšími

Padejte do bezradnosti. Začínají přicházet zcela špatné myšlenky, myslím si: možná je konference v záloze špatně (mně se to stalo po několika aktualizacích, kdy to po nich nefungovalo a já už nenašel příčinu), nic jiného nezbývá: musím všechno začít znovu ručně. Jaký ostud! Výsledek je zcela nulový a ještě jsem ztratil hromadu času!

Přijetí - cesta k uvědomění

Ve zoufalých pokusech pochopit, co se děje, začínám pečlivě zkoumat logy. Všiml jsem si zákonitosti. Volání Extension probíhá přesně za 5 sekund, a pro skupinu volání ze 3 Extension za 15! Začínám googlovat o zpoždění volání, ale už uvádím konkrétní zpoždění. A narážím na už dříve nalezenou odpověď, lidé říkají, že problém je v DNS, ale já vím, že problém není, všechny adresy se resolveují!

Evidentní - nikoli pravděpodobné

Není co dělat, vezmu do ruky nslookup a bingo (kdybych to udělal hned)! Primární DNS nefunguje (virtuální stroj s kontrolerem), a já jsem si toho ani nevšiml! Kdyby byl pouze jeden DNS, hned by byla chyba 😉

Výsledek

Elementární problém, který by monitoring (který se musí nastavovat pro všechny uzly) mohl vidět, zamaskovaný odolností DNS, vedl ke ztrátě téměř dvou pracovních dní na řešení hloupé situace. Líná hlava - problém, nastavovat monitoring trvá minutu - hledat problém tam, kde není - dva dny.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.