Il s'agit d'une courte histoire tirée de la pratique réelle, lorsqu'un petit problème, bien camouflé par la tolérance aux pannes, se transforme en mal de tête.
Petite disposition
Petite succursale, elle possède son propre PBX (astérisque + FreePBX) basé sur le fer de bureau et le même serveur terminal local avec 1C, stockage de fichiers et un contrôleur de domaine RO virtuel. Internet distribue Mikrotik. La petite branche leur suffit.
Tout a commencé par la surveillance (en raison du manque de temps et de la paresse, pas de tous les moniteurs), qui a signalé la surchauffe d'un serveur (du PBX) dans la branche. Alors que les habitants ont résolu le problème, le vieil homme s'est écrasé et a cassé un peu de la base de données MySQL.
Beaucoup de problèmes présumés, mais pas ça ...
Peu importe, la base a été réparée, tout devrait fonctionner. Mais les locaux se plaignent, les appels tombent en panne. D'accord - il y a des problèmes dans FreePBX, je prends une sauvegarde, je la déploie, tout va bien.
Mais le problème est en place, les habitants se plaignent toujours, les appels ne se passent pas bien. Devant eux, l'appel passe normalement, mais lorsqu'ils s'appellent eux-mêmes ou s'appellent mutuellement, un délai de plusieurs secondes est obtenu. Je commence à regarder les journaux volumineux et obscurs d'Asterisk et FreePBX, ils ne peuvent pas discerner le problème. Je me souviens qu'il y avait un problème avec STUN et ICE, qui a donné un délai similaire. Je l'éteins en enfer, le résultat est nul.
Le découragement est le moyen de prendre de mauvaises décisions
Je suis découragé, ramasser le PBX pendant plusieurs heures ne mène à rien de bon, il est déjà tard dans la nuit, mais le problème n'est pas résolu.
Il a laissé le problème jusqu'au matin, espérant une nouvelle tête. Le matin, une autre décision infructueuse a été prise: le système étant tombé en panne (bien que la dépendance ne puisse pas être aussi destructrice), j'essaie de réparer le système en réinstallant tous les packages. Le résultat est légèrement supérieur à zéro, le délai a été réduit (non significatif, mais déjà un succès).
Je prends une autre mauvaise décision: si la réparation partielle du système d'exploitation (et des bases de données à partir de la sauvegarde) avait peu de succès, et la racine du problème n'était toujours pas claire, et en même temps beaucoup de temps avait déjà été consacré à trouver la cause, alors je décide d'agir radicalement: nous supprimons le système d'exploitation et nous roulons tout à partir de zéro (l'avantage de l'automatisation du processus le fait dans un délai acceptable). Je lance la configuration FreePBX à partir de la copie. Un autre échec. Le résultat est nul!
Désespoir - l'esprit est éclipsé, les décisions empirent
Je tombe dans le désespoir. De très mauvaises pensées commencent à venir, je pense: peut-être que la conf dans la sauvegarde est une courbe (je l'ai eu après un certain nombre de mises à jour que cela n'a pas fonctionné après eux, et je n'ai pas pu trouver la raison), rien ne reste: vous devez tout rouler à partir de zéro avec vos mains. Quelle honte! Le résultat est strictement nul, et a même passé beaucoup de temps!
L'acceptation est le chemin de la prise de conscience
Dans des tentatives désespérées de comprendre ce qui se passe, je commence à étudier attentivement les journaux. Je remarque un motif. Les appels de poste en 5 secondes exactement, et pour un groupe d'appels de 3 postes en 15! Je commence à google sur le délai d'appel, mais indiquant déjà un délai spécifique. Et je tombe sur une réponse que j'ai déjà trouvée, les gens disent que le problème est dans le DNS, mais je sais pour sûr, il n'y a pas de problème, toutes les adresses sont résolues!
L'évident est l'incroyable
Rien à faire, ramasser nslookup et bingo (j'aimerais pouvoir le faire tout de suite!) Le DNS primaire se trouve (virtualka avec le contrôleur), mais je ne l'ai pas remarqué! Il y aurait un DNS, il y aurait immédiatement une erreur;)
Résumé
Un problème élémentaire que la surveillance pouvait voir (il devrait toujours être configuré pour tous les nœuds), masqué par la résilience DNS, a entraîné la perte de près de deux jours ouvrables pour résoudre la situation stupide. Trop paresseux tout le charbon, mettez en place une surveillance d'une minute - recherchez un problème là où il n'existe pas - deux jours.