691
逸創雲客服
關於2015-04-09服務故障修複的公告【簡版】
鑒於2015年4月9日，逸創雲客服的服務故障問題，下麵我們對我們服務的基礎設施服務進行一定陳述
服務構架
功能 | 備份計劃 | 災備 | |
功能和服務層 | 作為逸創雲客服的程序交互功能 | 每周2次快照與備份，最近一次備份為4月7日 | 遇到災難性故障可完全恢複配置數據，需要耗費10-15分鍾，本次故障屬於例外，本來完全可以避免，請見下麵描述 |
數據庫存儲層 | 作為企業數據存儲層，作為服務的數據存儲和數據展示 | 每周3次快照與備份 最近一次備份為4月7日 | 遇到災難性故障可完全恢複存儲數據，需要耗費5-10分鍾 |
靜態文件存儲層 | 作為靜態文件存儲，網頁靜態文件，如圖片、文檔、樣式表、壓縮包等靜態文件 | 每周2次快照與備份 | 遇到災難性故障可完全恢複存儲數據，需要耗費5-10分鍾 |
應用服務層 | 作為第三方附屬功能，如郵件、推送PUSH、IM等 | 每2周快照與備份 | 遇到災難性故障可完全恢複存儲數據，需要耗費<5分鍾 |
本次問題故障描述和排查進程
從今早9點開始，顯示功能和服務層就開始連接緩慢，其他層服務都是正常的。功能和服務層是服務的入口，入口出問題了，其他層即使都是正常的，服務也無法正常訪問，但這次是例外，我們以往對功能和服務層進行的單點故障架構也失效了。我們在之前沒有對配置文件、程序文件等進行任何改動，在早上9點，網絡自動就變得很緩慢。
我們開始對各種可能的情形進行排查，先後進行了：網絡排查、漏洞排查、負載排查、安全排查、內存泄露排查、程序自身排查、APACHE配置排查、PHP服務排查、MYSQL結構和數據庫連接配置排查等等，把可能想到的可能都排查一遍。
通過近4個小時的排查，故障依然不能解決。後來我們請來了全國知名的網絡尖刀小組高級運維工程師協助排查和解決問題。
問題結論與修複方法
通過偶然的測試發現，是我們的IaaS服務商 (U****k) 給我方提供的功能和服務層的入口IP地址出現了故障，具體是通過他們同網段的雲服務器來CURL服務層的網站地址，訪問速度是正常的，外網訪問就很慢很慢；他們提出的解釋是說我們的程序有問題，導致APACHE故障，一啟動APACHE就會讓PING值飆升很高而導致網絡就變得無比卡頓，我們重啟服務依然無濟於事，以至於我們一直在我們的程序和配置上找問題耽誤時間。
後來我們緊急的更換了一個新的IP地址，將所有域名綁定遷入新IP地址，在下午2點左右陸續恢複正常。
SLA
逸創雲客服承諾的SLA服務目標控製在每年99.5%以上，但經曆了4月9日事件後，本年的SLA不能達標，後續將加強此類問題的預測和做好預先防護，避免此次問題再次發生。
最後更新：2017-02-07 22:27:03