{"id":32682,"date":"2019-10-31T21:48:22","date_gmt":"2019-10-31T18:48:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ishhem-problemu-ne-v-tom-meste\/"},"modified":"2019-10-31T21:48:22","modified_gmt":"2019-10-31T18:48:22","slug":"ishhem-problemu-ne-v-tom-meste","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ishhem-problemu-ne-v-tom-meste","title":{"rendered":"Stiamo cercando il problema nel posto sbagliato.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Questa \u00e8 una piccola storia da una pratica reale, in cui un piccolo problema, ben mascherato dalla resilienza, si trasforma in un mal di testa.
\n<\/a><\/noindex><\/p>\n

Una breve esposizione:<\/h2>\n

\nUn 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 \u00e8 distribuito tramite Mikrotik. L'ufficio \u00e8 piccolo e per loro \u00e8 sufficiente.
\nTutto \u00e8 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<\/a> (del centralino) nell'ufficio. Mentre il personale locale cercava di risolvere il problema, il vecchio si \u00e8 bloccato e ha danneggiato un po' il database MySQL.<\/p>\n

\u041c\u043d\u043e\u0433\u043e\u0435 \u043f\u0440\u0435\u0434\u0432\u0435\u0449\u0430\u043b\u043e \u0431\u0435\u0434\u0443, \u043d\u043e \u043d\u0435 \u044d\u0442\u0443…<\/h3>\n

\nNessun problema, hanno riparato il database, tutto dovrebbe funzionare. Ma il personale lamenta interruzioni delle chiamate. Va bene \u2014 problemi con FreePBX possono capitare, prendo il backup, lo ripristino, tutto ok.
\nLa situazione \u00e8 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 \u00e8 nullo.<\/p>\n

La disperazione \u00e8 la via verso decisioni sbagliate:<\/h3>\n

\nSprofondo nella disperazione; ore di confusione con l'PBX non portano a nulla di buono, \u00e8 gi\u00e0 tarda notte e il problema persiste.
\nHo deciso di rimandare il problema a stamattina, sperando in una mente fresca. Al mattino, ho preso un'altra decisione sfortunata: siccome il sistema si \u00e8 rotto (anche se il crash non poteva essere cos\u00ec devastante), ho provato a ripararlo reinstallando tutti i pacchetti. Il risultato \u00e8 un po' migliore di nulla, il ritardo \u00e8 diminuito (non di molto, ma \u00e8 gi\u00e0 un successo).
\nPrendo 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 \u00e8 ancora poco chiara, e intanto \u00e8 gi\u00e0 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!<\/p>\n

Disperazione \u2014 la ragione viene offuscata, le decisioni diventano ancora peggiori.<\/h3>\n

\nVado in disperazione. Iniziano a venirmi in mente pensieri del tutto assurdi, penso: forse la configurazione nel backup \u00e8 corrotta (mi era gi\u00e0 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!<\/p>\n

Accettazione \u2014 strada verso la consapevolezza.<\/h3>\n

\nNella disperata ricerca di capire cosa stia succedendo, inizio a esaminare attentamente i log. Notando una certa regolarit\u00e0. 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\u00e0 il ritardo concreto. E mi imbatto nella risposta che avevo gi\u00e0 trovato, le persone dicono che il problema \u00e8 nel DNS, ma io so perfettamente che non ci sono problemi, gli indirizzi vengono risolti correttamente!<\/p>\n

Evidente \u2014 non probabile<\/h3>\n

\nNon avendo altro da fare, prendo in mano nslookup e bingo (perch\u00e9 non farlo subito)! Il DNS primario \u00e8 gi\u00f9 (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 \ud83d\ude09<\/p>\n

Risultato<\/h3>\n

\nUn 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 \u00e8 stress, configurare il monitoraggio ci vuole un minuto \u2014 cercare problemi dove non ce ne sono \u2014 due giorni.<\/p>\n

Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

Ti \u00e8 mai successa una cosa simile?<\/h2>\n