這是一個真實實踐中的小故事，當一個被容錯很好地掩蓋的小問題變成一個令人頭痛的問題時。
小性格：
一個小型分支機構，它擁有自己的基於桌面硬體的 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 位用戶棄權。
來源： www.habr.com