《AWS歷次事故分析及啓示》讀後感

#####################################################

##若有轉載，請務必保留本文連接及版權信息

##歡迎廣大運維同仁一塊兒交流linux/unix網站運維技術!

##QQ:335623998

##E-mail:335623998@qq.com

##博客： http://dreamway.blog.51cto.com/

##weibo：http://weibo.com/zhaixiangpan

#####################################################

  

     今天上午weibo上看到網易汪源的《AWS歷次事故分析及啓示》便有了此讀後感，一點我的拙見，還請你們拍磚。

   《AWS歷次事故分析及啓示》摘要

  

 

 《AWS歷次事故分析及啓示》原文連接http://vdisk.weibo.com/s/txo-W

   AWS歷史上的4次事故說明了公有云或私有云，尚不夠穩定，對設備、系統、技術等各個方面的要求仍是很全面苛刻的，某一個忽略或不在乎的點均可能產生雪崩效應，波及整個業務。因而可知運維團隊的重要性以及技術能力的全面性。  

  網站運營事故的發生是不可避免的，出現故障也正是檢驗網站架構、運維團隊能力的時候。當出現問題進行分析、排查、解決、恢復並進行故障根源詳細的分析總結、完善，避免重蹈覆轍，使網站架構更健壯、穩定。

  AWS出現的事故並非曇花一現，也有可能在任何一個網站發生，咱們更應該借鑑和規避相似事故。 網站應用的架構設計就應該將諸多方面考慮進去，如下是個人一些想法：

    1、強化運維制度規範，避免「想固然」，減小誤操做，對於生產環境的較敏感的變更，例如網絡的擴容，服務器的上下架、硬盤的更換等，須要對操做的必要性、步驟流程、潛在問題的預估、指定操做人員及負責人員、操做時間的選擇等以文檔等形式進行報備審批後才能實施。

    2、提升運維人員技能，知識的積累儲備和共享，對新技術的敏感、研究儲備。

    3、IDC的選型（例如：網絡質量的穩定性、超帶寬容量的臨時增長，機房電源的冗餘不間斷性、容災性（若是一個機房故障，將業務切至其餘機房繼續提供應用）），服務器及網絡設備硬件的穩定性（進行設備加電測試穩定後再上線使用），操做系統的選擇（將操做系統安裝在已經測試可用的服務器型號上，進行操做系統熟悉掌握及經常使用應用測試後再上線使用），應用程序（版本的穩定可靠性、安裝目錄、文件名、配置參數的規範統一性，一樣前期須要通過測試的版本才能上線使用）。

    4、運維工具的選擇：安全的、統一的，甚至一些特殊配置也要標準化。

    5、操做系統權限的控制、審計。

    6、工做業務責任制，分配到人，明確崗位職責。

    7、常見故障的處理文檔化、標準化，提交至運維知識庫，出現相同或相似問題便可到知識庫參考，提升效率。一切以肯定的、可行的爲依據，減小模糊的、想固然的作法，避免人爲操做失誤。

    8、業務上線的規範，開發完畢測試環境測試、審覈完畢，而後再上線。

    9、應用架構的設計：冗餘性、可靠性、高可用性。

    10、數據備份（配置文件及數據的備份機制、異地備份，備份的可用性按期進行自我檢驗）

    11、系統、網絡、IDC設備的硬防安全（按期自我檢測或請第三放進行安全評估）

    12、系統、應用的監控及監控機制的規範（完善監控內容、標準監控參數、報警發現通知流程、報警級別的劃分）

    13、未雨綢繆，對網站業務運營自我進行風險預估。

    網站架構不可能一直能知足需求，也不可能一直是穩定的，他就像矛與盾的關係，隨着生產發展而不斷完善、優化。這也是運維團隊的職責與重要性。

     以上本身的一點想法，不妥之處還請指正，都是結合工做中接觸到的一點思想認知吧，並沒太具體的實操性。