🥇Hľadáme problém nie tam, kde by mal byť

Toto je krátky príbeh z reálnej praxe, keď sa malý problém, dobre zamaskovaný vysokou dostupnosťou, stal bolestivou záležitosťou.

Krátka dispozícia:

Malá pobočka má vlastnú ústredňu (Asterisk + FreePBX) na desktopovom hardvéri a rovnaký lokálny terminálový server s 1C, súborovým úložiskom a virtuálnym doménovým riadiacim systémom. Internet zdieľa Mikrotik. Pobočka je malá, im to stačí.
Všetko sa začalo monitorovaním (kvôli nedostatku času a lenivosti nemonitorujem všetko), ktoré nahlásilo prehriatie jedného servera (s ústredňou) na pobočke. Kým miestni riešili problém, staručký sa zasekol a trochu poškodil databázu MySQL.

Mnohé naznačovali nešťastie, ale nie toto…

Nie je to problém, databázu opravili, všetko by malo fungovať. Ale miestni si sťažujú, hovory sa prerušujú. Dobre — problémy vo FreePBX sa stávajú, vezmem zálohu, rozbehnem ju, všetko je v poriadku.
A problém je na mieste, miestni sa stále sťažujú, hovory neprechádzajú normálne. Znie to, ako keby hovor prechádzal normálne, ale keď sami volajú alebo si volajú navzájom, vznikne niekoľkosekundové oneskorenie. Začínam skúmať objemné a nezrozumiteľné logy Asterisk a FreePBX, v nich sa problém nájsť nedarí. Spomínam si, že bola problém so STUN a ICE, ktoré spôsobilo podobné oneskorenie. Vypínam všetko, výsledok nulový.

Zúfalstvo — cesta k prijatiu zlých rozhodnutí:

Presúvam sa do zúfalstva, dlhé hodiny skúmania ústredne neprinášajú nič dobrého, už je hlboká noc a problém nie je vyriešený.
Nechal som problém do rána, v nádeji na čerstvú hlavu. Ráno padlo ďalšie neúspešné rozhodnutie: pokiaľ sa systém pokazil (aj keď sa zašmykol nemohol byť taký deštruktívny), pokúšam sa opraviť systém preinštalovaním všetkých balíčkov. Výsledok je niečo viac ako nula, oneskorenie sa skrátilo (nie zásadne, ale už je to úspech).
Prijímam ďalšie zlé rozhodnutie: ak malá oprava OS (a databázy zo zálohy) mala malý úspech, a korene problému sú stále nejasné, a pritom už bolo strávené veľmi veľa času na hľadaní príčiny, rozhodujem sa konať radikálne: zrušíme OS a nahráme všetko z čistého štartu (našťastie automatizácia procesu to zvládne za prijateľný čas). Nahrávam konfiguráciu FreePBX zo zálohy. Ďalšie zlyhanie. Výsledok nulový.

Bezradnosť — rozum sa zatmieva, rozhodnutia sú ešte horšie.

Zúfalo sa cítim. Začínajú prichádzať úplne hlúpe myšlienky, myslím si: možno je konfigurácia v zálohe pokrivená (mal som to tak po niekoľkých aktualizáciách, že po nich to nefungovalo a nenašiel som príčinu), nič iné nezostáva: musím všetko preinštalovať odznova ručne. Aký hanebný zážitok! Výsledok je úplne nulový a navyše som strávil obrovské množstvo času!

Prijatie — cesta k uvedomeniu

V zúfalých pokusoch porozumieť tomu, čo sa deje, začínam dôkladne študovať logy. Všimol som si vzorec. Vyvolanie rozšírenia nastáva presne po 5 sekundách, zatiaľ čo pre skupinu vyvolaní z 3 rozšírení za 15! Začínam googliť o oneskorení vyvolania, ale už konkrétne uvádzam oneskorenie. A narazím na odpoveď, ktorú som už našiel, ľudia hovoria, že problém je v DNS, ale ja presne viem, že problém nie je, všetky adresy sa prekladajú!

Zrejmé — nie pravdepodobné

Nič iné nezostáva, vezmem do rúk nslookup a bingo (škoda, že som to neurobil hneď)! Primárny DNS leží (virtuálka s kontrolérom), a ja som si to ani nevšimol! Keby bol len jeden DNS, hneď by bola chyba 😉

Záver

Elementárny problém, ktorý by mohol odhaliť monitoring (ktorý sa oplatí nastaviť pre všetky uzly), zakrytý odolnosťou DNS, viedol k strate skoro dvoch pracovných dní na riešenie hlúpej situácie. Lenivosť je veľký problém, nastaviť monitoring trvá minútu — hľadanie problému tam, kde nie je — dva dni.

Len registrovaní používatelia sa môžu zúčastniť prieskumu. Prihláste sa, prosím.