🥇Stiamo cercando il problema nel posto sbagliato

Questa è una piccola storia da una pratica reale, in cui un piccolo problema, ben mascherato dalla resilienza, si trasforma in un mal di testa.

Una breve esposizione:

Un piccolo ufficio filiale, dotato del proprio centralino (Asterisk + FreePBX) su hardware desktop e di un terminale locale con 1C, un cestino di file e un controller di dominio virtuale RO. Internet è distribuito tramite Mikrotik. L'ufficio è piccolo e per loro è sufficiente.
Tutto è iniziato con il monitoraggio (a causa della mancanza di tempo e della pigrizia non si monitora tutto), che ha segnalato il surriscaldamento di uno server (del centralino) nell'ufficio. Mentre il personale locale cercava di risolvere il problema, il vecchio si è bloccato e ha danneggiato un po' il database MySQL.

Molti segni preannunciavano il disastro, ma non questo…

Nessun problema, hanno riparato il database, tutto dovrebbe funzionare. Ma il personale lamenta interruzioni delle chiamate. Va bene — problemi con FreePBX possono capitare, prendo il backup, lo ripristino, tutto ok.
La situazione è preoccupante; tutti qui lamentano che le chiamate non funzionano correttamente. Sembrano arrivare bene, ma quando provano a chiamare o a chiamarsi a vicenda, ci sono ritardi di alcuni secondi. Inizio a esaminare i log voluminosi e confusi di Asterisk e FreePBX, ma non riesco a individuare il problema. Ricordo di aver avuto problemi con STUN e ICE in passato, che causavano ritardi simili. Disattivo tutte le impostazioni, ma il risultato è nullo.

La disperazione è la via verso decisioni sbagliate:

Sprofondo nella disperazione; ore di confusione con l'PBX non portano a nulla di buono, è già tarda notte e il problema persiste.
Ho deciso di rimandare il problema a stamattina, sperando in una mente fresca. Al mattino, ho preso un'altra decisione sfortunata: siccome il sistema si è rotto (anche se il crash non poteva essere così devastante), ho provato a ripararlo reinstallando tutti i pacchetti. Il risultato è un po' migliore di nulla, il ritardo è diminuito (non di molto, ma è già un successo).
Prendo un'altra decisione sbagliata: se la riparazione parziale del sistema operativo (e del database dal backup) ha avuto solo un successo limitato, e la causa principale del problema è ancora poco chiara, e intanto è già stato speso molto tempo per cercare di capire la causa, allora decido di agire radicalmente: rimuoviamo il sistema operativo e reinstalliamo tutto da zero (fortunatamente, l'automazione del processo rende tutto accettabile in termini di tempo). Ripristino la configurazione di FreePBX dal backup. Un altro fallimento. Risultato nullo!

Disperazione — la ragione viene offuscata, le decisioni diventano ancora peggiori.

Vado in disperazione. Iniziano a venirmi in mente pensieri del tutto assurdi, penso: forse la configurazione nel backup è corrotta (mi era già capitato dopo alcuni aggiornamenti, che dopo di essi non funzionasse, e non ero riuscito a trovare la causa), non mi resta che reinstallare tutto da zero a mano. Che vergogna! Risultato totalmente nullo, e ho sprecato un sacco di tempo!

Accettazione — strada verso la consapevolezza.

Nella disperata ricerca di capire cosa stia succedendo, inizio a esaminare attentamente i log. Notando una certa regolarità. La chiamata all'Extension avviene esattamente dopo 5 secondi, mentre per un gruppo di chiamate di 3 Extension ci vogliono 15! Inizio a cercare su Google riguardo ai ritardi nelle chiamate, ma specificando già il ritardo concreto. E mi imbatto nella risposta che avevo già trovato, le persone dicono che il problema è nel DNS, ma io so perfettamente che non ci sono problemi, gli indirizzi vengono risolti correttamente!

Evidente — non probabile

Non avendo altro da fare, prendo in mano nslookup e bingo (perché non farlo subito)! Il DNS primario è giù (una macchina virtuale con il controller), e non me ne sono nemmeno accorto! Se ci fosse stato un solo DNS, ci sarebbe stata subito un'errore 😉

Risultato

Un problema elementare, che il monitoraggio avrebbe potuto rilevare (che andrebbe configurato per tutti i nodi), mascherato dalla tolleranza ai guasti del DNS, ha portato a quasi due giorni lavorativi persi per risolvere una situazione sciocca. La pigrizia è stress, configurare il monitoraggio ci vuole un minuto — cercare problemi dove non ce ne sono — due giorni.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.