C'est une petite histoire tirée de la pratique réelle, où un petit problème, bien dissimulé par la redondance, se transforme en un véritable casse-tête.
Petite disposition :
Une petite filiale, avec son propre système de téléphonie (Asterisk + FreePBX) basé sur du matériel de bureau, ainsi qu'un petit serveur local avec 1C, un dépôt de fichiers et un contrôleur de domaine virtuel RO. L'Internet est distribué par Mikrotik. La filiale est petite, cela leur suffit.
Tout a commencé par une surveillance (faute de temps et de paresse, je ne surveille pas tout), qui a signalé une surchauffe de l'un de serveurs (avec le système de téléphonie) dans la filiale. Pendant que les locaux résolvaient le problème, le vieil appareil a planté et a un peu endommagé la base MySQL.
Beaucoup de signes annonçaient le désastre, mais pas celui-ci…
Pas de problème, la base a été réparée, tout devrait fonctionner. Mais les locaux se plaignent, les appels sont interrompus. D'accord — les problèmes dans FreePBX arrivent, je prends une sauvegarde, je la déploie, tout va bien.
Mais le problème persiste, les locaux se plaignent toujours, les appels ne passent pas correctement. Lorsque quelqu'un les appelle, il semble que tout se passe normalement, mais quand ils appellent eux-mêmes, ou s'appellent entre eux, il y a un délai de plusieurs secondes. Je commence à examiner des journaux volumineux et peu clairs d'Asterisk et de FreePBX, sans réussir à identifier le problème. Je me souviens qu'il y avait eu un problème avec STUN et ICE, qui donnait un délai similaire. Je désactive tout, rien n'y fait.
Le découragement — le chemin vers de mauvaises décisions :
Je sombre dans le découragement, des heures de fouille dans le système de téléphonie ne mènent à rien de bon, il est déjà tard dans la nuit, et le problème persiste.
J'ai laissé le problème pour le matin, espérant avoir l'esprit plus frais. Le matin, une nouvelle décision malheureuse a été prise : puisque le système est tombé en panne (bien que le plantage ne puisse pas être si destructeur), j'essaie de réparer le système en réinstallant tous les paquets. Le résultat est légèrement au-dessus de zéro, la latence a diminué (pas de manière significative, mais c'est déjà un succès).
Je prends une autre mauvaise décision : si la réparation partielle du système d'exploitation (et de la base de données à partir de la sauvegarde) a eu un succès modeste, et que la racine du problème n'est toujours pas claire, et que beaucoup de temps a déjà été perdu à chercher la cause, je décide d'agir de manière radicale : je supprime le système d'exploitation et je recommence tout à zéro (heureusement, l'automatisation du processus le rend faisable en un temps raisonnable). Je déploie la configuration FreePBX à partir de la sauvegarde. Nouvel échec. Le résultat est nul !
Le désespoir — l'esprit s'obscurcit, les décisions deviennent encore pires.
Je suis désespéré. Des pensées complètement folles commencent à surgir, je pense : peut-être que la conf est mal intégrée dans la sauvegarde (j'ai déjà eu ce problème après plusieurs mises à jour, où rien ne fonctionnait, et je n'ai jamais réussi à en trouver la cause), il ne reste rien d'autre : il faut tout réinstaller manuellement depuis le début. Quelle honte ! Le résultat est strictement nul et j'ai perdu une quantité incroyable de temps !
L'acceptation — le chemin vers la compréhension
Dans ma lutte désespérée pour comprendre ce qui se passe, je commence à étudier attentivement les journaux. Je remarque une régularité. L'appel d'Extension se produit exactement après 5 secondes, tandis que pour un groupe d'appels de 3 Extensions, cela prend 15 secondes ! Je commence à googler sur le retard d'appel, mais en précisant déjà le retard spécifique. Et je tombe sur une réponse que j'avais déjà trouvée, les gens disent que le problème vient du DNS, mais je sais pertinemment qu'il n'y a pas de problème, toutes les adresses se résolvent !
L'évident — pas le probable
Que faire, je prends nslookup et bingo (si seulement j'avais fait cela tout de suite) ! Le DNS primaire est tombé (une machine virtuelle avec le contrôleur), et je ne l'avais même pas remarqué ! S'il n'y avait eu qu'un seul DNS, l'erreur aurait été immédiatement visible 😉
Conclusion
Un problème élémentaire que la surveillance aurait pu détecter (qui devrait être configurée pour tous les nœuds), masqué par la tolérance de panne du DNS, a conduit à une perte de presque deux jours ouvrables à résoudre cette situation ridicule. La paresse cause un véritable casse-tête, configurer la surveillance prend une minute — chercher un problème là où il n'y en a pas — deux jours.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Vous est-il déjà arrivé quelque chose de similaire ?
Oui, très rarement
Oui, rarement
Oui, souvent
Oui, très souvent
Non, avec qui que ce soit, sauf avec moi !
Non, je suis infaillible !
2 utilisateurs ont voté. 1 utilisateur s'est abstenu.
Source : habr.com
