Esta es una breve historia de la práctica real, cuando un pequeño problema, bien disfrazado de tolerancia a fallos, se convierte en un dolor de cabeza.
Pequeña disposición:
Una sucursal pequeña, tiene su propio PBX (asterisco + FreePBX) basado en hardware de escritorio y el mismo servidor de terminal local con 1C, un volcado de archivos y un controlador de dominio RO virtual. Internet distribuye Mikrotik. La rama es pequeña, les basta.
Todo empezó con un monitoreo (por falta de tiempo y pereza no se monitorea todo), que reportó el sobrecalentamiento de un servidor (con PBX) en la sucursal. Mientras los lugareños resolvían el problema, el anciano se quedó paralizado y rompió levemente la base de datos MySQL.
Muchas cosas presagiaban problemas, pero ésta no...
No hay problema, la base ha sido reparada, todo debería funcionar. Pero los lugareños se quejan y las llamadas se cortan. Bien, hay problemas en FreePBX, hago una copia de seguridad, la implemento y todo está bien.
Pero el problema está ahí, los lugareños siguen quejándose, las llamadas no llegan con normalidad. Ante ellos, la llamada parece realizarse con normalidad, pero cuando se llaman a sí mismos, o se llaman entre sí, hay un retraso de varios segundos. Empiezo a mirar los voluminosos e incomprensibles registros de Asterisk y FreePBX, pero no puedo detectar el problema en ellos. Recuerdo que hubo un problema con STUN e ICE, que dieron un retraso similar. Apago todo a la mierda, el resultado es cero.
El abatimiento es el camino para tomar malas decisiones:
Me estoy deprimiendo, jugar muchas horas con el ATS no conduce a nada bueno, ya es tarde en la noche y el problema no se soluciona.
Dejé el problema hasta la mañana, esperando tener una cabeza fresca. Por la mañana, tomé otra decisión fallida: como el sistema estaba roto (aunque la dependencia no podría haber sido tan destructiva), intenté arreglar el sistema reinstalando todos los paquetes. El resultado es ligeramente superior a cero, el retraso ha disminuido (no significativamente, pero ya es un éxito).
Tomo otra mala decisión: si la reparación parcial del sistema operativo (y de la base de datos a partir de la copia de seguridad) tuvo poco éxito, y la raíz del problema aún no está clara, y ya se ha dedicado mucho tiempo a buscar la causa, Entonces decido actuar radicalmente: derribamos el sistema operativo y revertimos todo desde cero (afortunadamente, la automatización del proceso lo hace en un tiempo aceptable). Estoy actualizando la configuración de FreePBX a partir de una copia. Otro fracaso. ¡El resultado es cero!
Desesperación: la mente se nubla, las decisiones se vuelven aún peores
Estoy cayendo en la desesperación. Me empiezan a venir pensamientos muy malos, pienso: tal vez la configuración en la copia de seguridad está torcida (me pasó después de varias actualizaciones que no funcionó después de ellas y no pude encontrar el motivo), no queda nada : Tengo que darle la vuelta a todo desde cero con las manos. ¡Qué desgracia! El resultado es estrictamente cero y ¡se pierde mucho tiempo!
La aceptación es el camino hacia la conciencia.
En un intento desesperado por comprender lo que está sucediendo, empiezo a estudiar cuidadosamente los registros. Noto un patrón. ¡Una llamada de Extensión ocurre exactamente en 5 segundos, y para un grupo de llamadas de 3 Extensiones en 15! Empiezo a buscar en Google sobre el retraso de la llamada, pero ya indico un retraso específico. Y me encuentro con la respuesta que ya encontré, la gente dice que el problema está en el DNS, pero estoy seguro que no hay ningún problema, ¡todas las direcciones están resueltas!
Obvio - no probable
No hay nada que hacer, tomo nslookup y bingo (¡desearía poder hacer esto de inmediato)! El DNS principal está ahí (máquina virtual con un controlador), ¡pero ni siquiera me di cuenta! Si solo hubiera un DNS, habría error 😉
Total
Un problema elemental que podría haber sido detectado por el monitoreo (que debería configurarse para todos los nodos), enmascarado por la tolerancia a fallas de DNS, provocó la pérdida de casi dos días hábiles para resolver una situación estúpida. La pereza es un dolor de cabeza, configurar el seguimiento lleva un minuto y buscar un problema donde no lo hay lleva dos días.
Solo los usuarios registrados pueden participar en la encuesta. por favor
Le ha sucedido esto a usted?
-
Si, muy raramente
-
Si, raramente
-
A menudo
-
Muy a menudo
-
¡No, con nadie, pero conmigo no!
-
¡No, soy infalible!
2 usuarios votaron. 1 usuario se abstuvo.
Fuente: habr.com