事件回顧：
事情發生在乙個呼叫中心，裡面外呼的不單單只有人工坐席，還有ai機械人，當天伺服器異常斷電後重啟，業務啟動之後發現人工坐席無能正常外呼，但是ai機械人又可以外呼，仔細回想自己沒有改過什麼東西，因為從來沒遇到過這樣的問題，所以一下子不知從何下手，只能不斷的檢查和回憶自己的配置跟做過的操作，但是並沒有發現什麼不對的地方。突然想到之前看過的sip呼叫信令，想起是內網ip，人工是使用的內網，內網目前異常不能使用，然後馬上就去伺服器檢查網絡卡，發現eth1網絡卡的ip位址不正常。進入eth1的網絡卡配置檔案看ip位址是正常，說明是網絡卡異常。
1.重啟網絡卡，出現以下錯誤資訊：
可以看到eth1網絡卡重啟失敗了，看來就是eth1網絡卡的問題了。繼續往下排查。
2.啟動eth1網絡卡
這裡的報錯資訊就比較直觀了，可以看到顯示的是這個ip位址被下面這個mac位址的主機占用了，所以eth1網絡卡啟動不起來，那怎麼去查到這個mac是哪一台主機呢，這麼多主機也不可能一台一台的檢視mac位址然後想起去路由器裡面看路由表。
3.登入路由器管理頁面
4.檢視路由器中客戶端列表
可以看到路由器列表中確實是有乙個主機占用了這個ip位址，但是還是找不到是哪一台主機，但是機智如我，看到這個列表中註冊了很多ip位址，想到今天休息公司不可能這麼多台主機都開機，所以想到了ip座機，應該是ip座機搶了伺服器的ip位址，果然直接訪問這個ip位址進入了座機登入介面。
5.登入ip座機
6.修改ip座機網路配置
修改完成之後，再到路由器中檢視這個ip位址還在不在註冊中，發現路由器中已經沒有這個ip位址了。
7.重啟伺服器網絡卡
這個時候eth1網絡卡已經成功啟動，然後去測試人工外呼，但是還是失敗，最後一步重啟虛擬機器。
重啟虛擬機器後網絡卡正常，業務恢復。
記一次伺服器斷電nginx重啟的坑
周一一到公司，前端同事就給我說，測試伺服器是不是掛了，什麼資料都沒有。我突然想到週六大廈斷電了大約三分鐘，於是就想到應該是伺服器上部署的服務都沒有啟動。由於h5靜態資源通過nginx做了 猜想是nginx還未啟動，但是nginx卻啟動不了，用命令檢視錯誤如下 看來是檔案訪問許可權的問題，但是看了ng...
重啟伺服器ORACLE DataGuard的方法
dg原理 主機向備機傳送日誌檔案，備機執行日誌檔案，藉此與主機資料同步。依此原理，不難推導出dg的開關機順序 關機順序 先主機再備機，先例項後監聽，這樣日誌就不會斷了 開機順序 先備機再主機 先監聽後例項，這樣的目標也是日誌不斷 具體步驟 關機1.在主庫上執行 shutdown immediate ...
linux 重啟伺服器命令
linux有如下的關機和重啟命令 shutdown,reboot,halt,poweroff，那麼它們有什麼區別呢？shutdown是最常用也是最安全的關機和重啟命令，它會在關機之前呼叫fsck檢查磁碟，其中 h和 r是最常用的引數 plain view plain copy h 停止系統服務並關機...