这是一个真实实践中的小故事，当一个被容错很好地掩盖的小问题变成一个令人头痛的问题时。
小性格：
一个小型分支机构，它拥有自己的基于桌面硬件的 PBX（星号 + FreePBX）以及带有 1C、文件转储和虚拟 RO 域控制器的相同本地终端服务器。 互联网分发 Mikrotik。 树枝很小，对他们来说已经足够了。
这一切都从监控开始（由于缺乏时间和懒惰，并未监控所有内容），监控报告了分支机构中一台服务器（带有 PBX）的过热情况。 当当地人正在解决问题时，老人愣住了，稍微破坏了MySQL数据库。
很多事情都预示着麻烦，但这个却不是……
没问题，底座已经修复，一切正常。 但当地人抱怨说，电话一直挂断。 好的 - FreePBX 有问题，我备份并部署它，一切正常。
但问题就在那里，当地人仍在抱怨，电话无法正常接通。 在他们之前，通话似乎很正常，但是当他们给自己打电话，或者给对方打电话时，却出现了几秒钟的延迟。 我开始查看 Asterisk 和 FreePBX 的大量且难以理解的日志，但我无法发现其中的问题。 我记得 STUN 和 ICE 有一个问题，导致了类似的延迟。 我把一切都关掉，结果为零。
沮丧是做出错误决定的途径：
我很沮丧，摆弄ATS好几个小时并没有带来任何好处，已经是深夜了，问题还没有解决。
我把这个问题留到了早上，希望能有一个新的头脑。 早上，又做出了一个不成功的决定：由于系统损坏了（尽管依赖关系不可能具有如此大的破坏性），我试图通过重新安装所有软件包来修复系统。 结果略大于零，延迟减少了（不是很明显，但已经成功了）。
我做出了另一个错误的决定：如果对操作系统（以及备份副本中的数据库）进行部分修复收效甚微，并且问题的根源仍然不清楚，并且已经花费了大量时间寻找原因，然后我决定采取激进的行动：我们拆除操作系统，并从头开始一切（幸运的是，流程的自动化在可接受的时间内完成了这一切）。 我正在从副本中汇总 FreePBX 配置。 又是一次失败。 结果是零！
绝望——头脑变得阴沉，决策变得更糟糕
我陷入了绝望。 非常糟糕的想法开始出现，我想：也许备份中的conf是歪的（我在多次更新后发生了这样的情况，之后就不起作用了，而且我找不到原因），什么都没有留下：我必须用手从头开始把一切都翻过来。 真是耻辱！ 结果严格为零，浪费了很多时间！
接受是通往觉知的道路
为了了解正在发生的事情，我开始仔细研究日志。 我注意到一个模式。 一个分机呼叫恰好在 5 秒内发生，对于 3 个分机的一组呼叫则需要 15 秒！ 我开始在谷歌上搜索有关呼叫延迟的信息，但已经指出了具体的延迟。 我遇到了我已经找到的答案，人们说问题出在 DNS 中，但我确信没有问题，所有地址都已解析！
明显 - 不太可能
没什么可做的，我拿起 nslookup 和 bingo（我希望我能立即做到这一点）！ 主 DNS 就在那里（带有控制器的虚拟机），但我什至没有注意到！ 如果只有一个 DNS，就会出错 😉
总
一个本来可以通过监控（应该为所有节点配置）发现的基本问题，被 DNS 容错掩盖，导致浪费了近两个工作日来解决这个愚蠢的情况。 懒惰是一件令人头疼的事情，设置监控需要一分钟，而寻找没有问题的问题则需要两天。
只有注册用户才能参与调查。 拜托
你曾经发生过这些事情吗？
-
是的，很少
-
是的，很少
-
经常
-
常常
-
不，与任何人，只是不与我！
-
不，我是绝对正确的！
2 位用户投票。 1 位用户弃权。
来源： habr.com