感悟---故障級別應該怎麼定？

做爲一名運維工程師，不免會遇到各類各樣的，大大小小的故障，提及這個故障，什麼樣的異常狀況就構成了故障，就如同犯罪同樣，什麼樣的行爲構成犯罪，但是做爲服務性質的互聯網電子商務平臺,以什麼樣的標準來評定呢？跟錢掛鉤仍是跟服務質量掛鉤呢？這二者絕對不等同,一分錢都不影響，一天不能提供服務到底哪一種算故障？

2013年1月5號，21:30接到一個產品工程師的電話說，有故障了，須要協助恢復
而後技術支持建立臨時討論羣召集相關技術人員肯定故障點，以及恢復操做。其級別肯定爲3級，這個級別應該算很普通故障的級別

過程是這樣的
1.1 13:30變動完，因爲應用的特殊性，在辦公室的網絡裏測試都是正常的。（那就坐等投訴吧）
    其實團隊中的其餘人可不止一次有這樣的問題，莫非人以類聚？？哈哈，開玩笑，仍是繼續說故障過程吧。
1.2 下午15：30又變動了一個，跟上一個是關聯的，只是這個變動影響的範圍比較大，本身下意識的斟酌了一會，前思後想，理清思路了就處理了，結果到晚上20點30 微博上陸續有人抱怨說訪問***異常，公司內部人有看到的就下意識去試，畢竟是本身公司的應用，不試則罷，一試果真尷尬了，就開始找相關責任人，看是否是本身網絡問題仍是個別點的問題
1.3 到21:30 才定位是IP地址ACL問題，一個對公網服務的應用，居然ACL權限是隻針對辦公網開放
1.4 若是遇到網絡ACL的問題後，到底應該怎麼去恢復纔算最快，或者影響最小，若是要我是這位產品工程師，確定第一時間是恢復最後一步的變動，可他的思路倒是補充ACL漏掉的部分，其實遇到每一個問題後都是不一樣的但是接到通知就趕忙恢復吧

從故障各個點來看，第一反應就是產品工程師的問題，這個問題很明確，讓變動人或者網絡的人替你判斷應用須要的ACL權限，那很不現實，因此有多少SA，NA都不夠使，所以他們不是一個合格的產品工程師，是一個純發佈工程師，有問題時找開發，有需求發佈時，賦權限給開發.就這樣的運維工程師反而會給填麻煩，畢竟多一道溝通環節。那麼應該怎麼作呢？我以爲應該具有冷靜的頭腦，全面分析問題的能力，還有學習業務的能力，不要作一個純技術的產品工程師

還有一個點就是故障級別定義，記錄故障的屬於A部門，參與肯定級別的是B部門，形成故障的A部門，並且B部門項目的任何進度起決定性做用的都須要看A部門產品工程師臉色，高興就配合好點，那不高興天然就......像這種錯綜複雜的互相牽制，怎麼能公平的對待一我的員失誤而形成的損失呢

就拿這個故障來講吧，從中午1點半到晚上9點半，並且在微博上都有人叫喚了，應該定成什麼級別呢？或者說應該怎麼定義，談錢？一分很多，談重要性，那天然不用說，談時間，8小時，那該怎麼定義呢？到如今爲止仍是摸不着頭腦呢！

好比發佈一個應用或者是新的項目上線，做爲產品工程師須要考慮的如下幾個問題，
1，新的項目上線須要什麼樣的架構來支持，其實在開發的前期就須要 溝通清楚，這樣有充分的時間準備硬件、軟件環境的測試支持等，在開發的同時，本身也須要把環境部署完成，包括環境的測試來驗證架構是否合理，或者產生瓶頸 的地方,這裏包括程序運行軟件環境的各個版本號，以及通用，可移植性
2，等到產品真正發佈的時候須要拿到一些數據來保障應用正常的運行，壓力測試結果，業務量評估數據，以及功能測試報告是否符合預期
3，後期維護相關的工具開發，包括應用的監控點，服務器資源，日誌管理等
4，不是項目上線完成就萬事大吉了，要作個有心人，去看看這個應用之間的調用關係，通常配置文件中都會有配置的，這樣把這個應用理順後，畫出來一個完整的調用關係圖。等到有告警的時候，你始終會領先一步判斷出來故障點的。