Questa è una piccola storia di una pratica reale, in cui un piccolo problema, ben mascherato dalla tolleranza ai guasti, si trasforma in un mal di testa.
Una piccola disposizione:
Un piccolo filiale, con il suo centrale telefonico (Asterisk + FreePBX) basato su hardware desktop e un piccolo server locale con 1C, un deposito di file e un controller di dominio virtuale RO. L'Internet è fornito da Mikrotik. Il filiale è piccolo, questo basta per loro.
Tutto è iniziato con il monitoraggio (a causa della mancanza di tempo e pigrizia non si monitora tutto), che ha segnalato un surriscaldamento di uno server (con il centrale telefonico) nella filiale. Mentre i locali cercavano di risolvere il problema, il vecchietto si è bloccato e ha danneggiato leggermente il database MySQL.
Molte cose preannunciavano una catastrofe, ma non questa...
Non è un problema, hanno riparato il database, tutto dovrebbe funzionare. Ma i locali si lamentano, le chiamate si interrompono. Va bene — i problemi con FreePBX capitano, prendo un backup, lo ripristino, tutto ok.
Ma il problema è ancora presente, i locali continuano a lamentarsi, le chiamate non vanno bene. La chiamata sembra passare normalmente, ma quando cercano di chiamarsi a vicenda, c'è un ritardo di qualche secondo. Comincio a esaminare i log Asterisk e FreePBX, voluminosi e incomprensibili, ma non riesco a scorgere il problema. Ricordo che c'era stato un problema con STUN e ICE, che causava un ritardo simile. Disattivo tutto e il risultato è nullo.
La disperazione è la strada per prendere decisioni sbagliate:
Cadendo nella disperazione, ore di frustrazione con il centrale telefonico non portano a nulla di buono, è già notte fonda e il problema non si risolve.
Ho lasciato il problema fino al mattino, sperando in una mente fresca. Al mattino è stata presa una nuova decisione sbagliata: dato che il sistema si era rotto (anche se il blocco non poteva essere così distruttivo), cerco di riparare il sistema reinstallando tutti i pacchetti. Il risultato è leggermente migliore di zero, il ritardo è diminuito (non sostanzialmente, ma è comunque un successo).
Prendo un'altra decisione sbagliata: se la riparazione parziale del sistema operativo (e del database dal backup) ha avuto un certo successo, e se la radice del problema è ancora poco chiara, ed è già stato speso molto tempo nella ricerca della causa, decido di agire in modo radicale: cancello il sistema operativo e reinstallo tutto da capo (per fortuna l'automazione del processo lo rende possibile in tempi accettabili). Ripristino la configurazione di FreePBX dal backup. Un altro fallimento. Risultato nullo!
La disperazione oscura la mente, le decisioni diventano ancora peggiori.
Mi sento disperato. Comincio a ricevere pensieri davvero brutti, penso: forse la conferenza nel backup è difettosa (mi era capitato dopo alcuni aggiornamenti, e non sono mai riuscito a trovare la causa), non resta che ricominciare tutto da capo a mano. Che vergogna! Il risultato è assolutamente nullo, e ho anche sprecato un sacco di tempo!
Accettazione - la via verso la consapevolezza
Nei miei disperati tentativi di comprendere quanto sta accadendo, inizio a esaminare attentamente i log. Notando una regolarità. La chiamata all'Extension avviene esattamente dopo 5 secondi, mentre per un gruppo di 3 chiamate all'Extension ci vogliono 15! Comincio a cercare su Google riguardo ai ritardi nelle chiamate, ma già specificando un ritardo concreto. E mi imbatto nella risposta che avevo già trovato: la gente dice che il problema è nel DNS, ma io so per certo che non c'è problema, tutti gli indirizzi vengono risolti!
L'ovvio - non il probabile
Non ho nulla da fare, prendo in mano nslookup e bingo (ma perché non l'ho fatto subito)! Il DNS primario è giù (una macchina virtuale con il controller), e io non me ne sono neanche accorto! Se ci fosse un solo DNS, ci sarebbe stato subito un errore 😉
Risultato
Un problema elementare, che il monitoraggio (che andrebbe configurato per tutti i nodi) avrebbe potuto vedere, mascherato dalla resilienza del DNS, mi ha fatto perdere quasi due giorni lavorativi per risolvere una situazione stupida. La pigrizia è una seccatura, impostare un monitoraggio richiede un minuto - cercare problemi dove non ci sono - due giorni.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Vi è mai capitato qualcosa del genere?
Sì, molto raramente
Sì, raramente
Sì, spesso
Sì, molto spesso
No, con chiunque, tranne che con me!
No, sono infallibile!
Hanno votato 2 utenti. Si è astenuto 1 utente.
Fonte: habr.com
