这是实际操作中的一个简短故事，当一个由容错能力很好地掩盖的小问题变成头痛时。
小气质
它是一个小型分支机构，拥有自己的基于台式机的PBX（星号+ FreePBX），以及具有1C，文件存储和虚拟RO域控制器的同一本地终端服务器。 互联网分发Mikrotik。 小树枝就足够了。
一切都始于监视（由于缺乏时间和懒惰，并非所有监视器都如此），该监视报告了分支机构中一台服务器（来自PBX）的服务器过热。 当当地人解决问题时，老人坠毁并破坏了MySQL数据库的一部分。
很多预示着麻烦，但不是这个...
没关系，基地已经修复，一切正常。 但是当地人抱怨，通话中断了。 好的-FreePBX中有问题，我进行了备份，进行了部署，一切正常。
但是麻烦已经到位，当地人仍然在抱怨，电话进展不顺利。 在他们之前，呼叫正常通过，但是当他们自己呼叫或互相呼叫时，会获得几秒钟的延迟。 我开始看看Asterisk和FreePBX庞大而晦涩的日志，它们无法识别问题。 我记得STUN和ICE出现了问题，这也造成了类似的延迟。 我将其关闭，结果为零。
沮丧是做出错误决定的方式
我很灰心，长时间拿起PBX并不能带来任何好处，它已经很晚了，但是问题仍未解决。
他把问题留到早晨，希望能有个新的头绪。 早晨，另一个不成功的决定是：由于系统崩溃了（尽管依赖关系破坏性不强），我试图通过重新安装所有软件包来修复系统。 结果略大于零，延迟减少了（不明显，但已经成功了）。
我做出了一个更糟糕的决定：如果对操作系统（以及备份中的数据库）的部分修复没有取得成功，并且问题的根源仍然不清楚，同时已经花了很多时间来寻找原因，那么我决定采取彻底的行动：我们关闭了操作系统，我们从头开始滚动一切（流程自动化的好处是可以在可接受的时间内完成此操作）。 我从副本中滚动FreePBX配置。 另一个失败。 结果为零！
绝望-头脑蒙上阴影，决策变得更糟
我陷入绝望。 我认为，非常糟糕的想法开始浮出水面：也许备份中的conf是一条曲线（我经过多次更新后才知道它在它们之后不起作用，但我找不到原因），什么也没剩下：您需要用手从头开始滚动所有内容。 真可惜！ 结果严格为零，甚至花费了大量时间！
接受是提高认识的途径
为了尽力了解正在发生的事情，我开始仔细研究日志。 我注意到一个模式。 分机通话仅需5秒钟，而来自3分机的一组通话仅需15秒！ 我开始在Google上查询通话延迟，但已经指出了特定的延迟。 我遇到一个已经找到的答案，人们说问题出在DNS中，但我可以肯定地知道，没有问题，所有地址都已解决！
显而易见的是不可思议
没事做，拿起nslookup和bingo（我希望我能马上做到！） 主要的DNS位于（控制器带有virtualka），但是我没有注意到！ 只有一个DNS，马上就会出现错误；）
总结
监控可能会看到的一个基本问题（仍应为所有节点配置），被DNS弹性掩盖，导致损失了将近两个工作日来解决这种愚蠢的情况。 懒惰所有的黑穗病，设置监视一分钟-寻找一个不存在的问题-两天。