🥇Leter etter problemet ikke der det er

Dette er en liten historie fra ekte praksis, hvor et lite problem, godt maskert av feilfrihet, blir til en hodepine.

Liten disposisjon:

Et lite filialkontor, med sin egen PBX (asterisk + FreePBX) basert på stasjonær maskinvare, samt en lokal terminalserver med 1C, filavfall og en virtuell RO-domene kontroller. Internett distribueres gjennom Mikrotik. Filialen er liten, og dette er tilstrekkelig for dem.
Alt startet med overvåkning (på grunn av mangel på tid og latskap overvåkes ikke alt), som rapporterte om overoppheting av en serveren (PBX) i filialen. Mens lokale aktører forsøkte å løse problemet, frøs maskinen og ødela litt av MySQL-databasen.

Mye varslet ulykke, men ikke dette...

Det er ikke noe problem, databasen ble fikset, alt skal fungere. Men lokalbefolkningen klager, samtaler blir avbrutt. Vel — det oppstår problemer i FreePBX, jeg tar en sikkerhetskopi, og gjenoppretter, alt ser ok ut.
Men problemet vedvarer, lokalbefolkningen klager fortsatt, samtaler går ikke normalt. Når de mottar samtaler, ser alt greit ut, men når de ringer hverandre, kommer det med flere sekunders forsinkelse. Jeg begynner å se på de omfattende og uforståelige loggene fra Asterisk og FreePBX, men finner ikke problemet. Jeg husker, det var et problem med STUN og ICE, som ga lignende forsinkelse. Jeg deaktiverer alt helt, resultatet er null.

Fortvilelse — veien til dårlige beslutninger:

Jeg blir frustrert, timevis med stusslende PBX fører ikke til noe godt, det er allerede sent om natten, og problemet er fortsatt ikke løst.
Jeg lar problemet ligge til morgenen, i håp om klarere tanker. Om morgenen ble en ny mislykket beslutning tatt: siden systemet brøt sammen (selv om fryseren ikke kunne være så ødeleggende), prøver jeg å fikse systemet ved å reinstallere alle pakkene. Resultatet er litt bedre enn null, forsinkelsen reduseres (ikke betydelig, men allikevel en suksess).
Jeg tar enda en dårlig beslutning: hvis delvis reparasjon av OS (og databasen fra backup) hadde liten suksess, og roten til problemet fortsatt ikke er klar, og på toppen av dette er mye tid allerede brukt på å finne årsaken, så bestemmer jeg meg for å handle radikalt: vi fjerner OS og installerer alt på nytt (heldigvis gjør automatiseringen dette på en akseptabel tid). Jeg laster opp FreePBX-konfigurasjonen fra kopien. Nok et nederlag. Resultatet er null!

Fortvilelse — sinnet blir overskyet, beslutningene blir enda dårligere.

Jeg blir fortvila. Dårlige tanker begynner å komme, jeg tenker: kanskje backupen er feil (jeg opplevde slik etter flere oppdateringer, at ingenting fungerte, og jeg klarte aldri å finne årsaken), det er ingenting å gjøre: jeg må installere alt fra bunnen av med hånda. For en skam! Resultatet er strengt null, og en hel del tid er bortkastet!

Aksept — veien til forståelse

I desperate forsøk på å forstå hva som skjer, begynner jeg å studere loggene nøye. Jeg merker et mønster. Kall av Extension skjer nøyaktig etter 5 sekunder, mens for en gruppe av 3 Extension-kall skjer det etter 15! Jeg begynner å google om forsinkelse på kall, men spesifiserer allerede den konkrete forsinkelsen. Og jeg støter på et svar jeg har funnet tidligere, folk sier at problemet ligger i DNS, men jeg vet jo sikkert at det ikke er noe problem, alle adresser oppløses!

Det åpenbare er ikke det sannsynlige

Det er ikke noe å gjøre, jeg tar fram nslookup og bingo (hadde bare gjort dette med en gang)! Primær DNS er nede (virtuell maskin med kontroller), og jeg la ikke merke til det! Hadde det vært bare én DNS, ville det vært en feil med en gang 😉

Resultat

Et elementært problem som overvåkingen kunne ha sett (som bør konfigureres for alle noder), maskert av DNS-sikkerhet, førte til at jeg mistet nesten to arbeidsdager på å løse en dum situasjon. Latskap er en hodepine, å sette opp overvåkingen tar ett minutt — å lete etter problemet der det ikke finnes — to dager.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.