互聯(lián)網(wǎng)，講究快速迭代，快速上線，敏捷開發(fā)。

有些固定上線時間的項目，可能因為技術方案變化，導致測試時間壓縮，最終導致上線出問題，而由運維來背鍋。

為保住KPI，運維有很多心里話想和研發(fā)測試說一說：

（1）“敏捷開發(fā)，頻繁交付”的KPI，真不是增加運維人手就能解決的，需要自動化回歸的支持，需要自動化上線的支持

（2）“上線失敗，快速回滾”的KPI，真不是增加運維人手就能解決的，需要回滾方案的支持，而回滾方案真的測試過么

（3）“快速擴容，快速響應”的KPI，真不是增加運維人手就能解決的，需要架構設計的支持（很多系統(tǒng)無法水平擴展，來了機器，無法擴容），需要快速部署的支持，需要服務發(fā)現(xiàn)的支持（所有上游修改配置重啟肯定是不行的），需要壓力測試和容量評估的支持

（4）“系統(tǒng)高可用”的KPI，真不是增加運維人手就能解決的，需要優(yōu)雅降級的支持，需要架構設計的支持，如何評判系統(tǒng)是否高可用？這個簡單，關掉線上任何一臺機器試試，看用戶服務是否受影響，如果受影響，研發(fā)哥哥們拜托了

（5）“快速故障報警”的KPI，真不是增加運維人手就能解決的，需要監(jiān)控系統(tǒng)的支持（操作系統(tǒng)和運維層面的監(jiān)控，我們可以實施，但錯誤日志、接口、業(yè)務的監(jiān)控呢？），另外報警短信能少一點么，過度報警會讓人變得“麻木不仁”的

（6）“快速故障定位”的KPI，真不是增加運維人手就能解決的，需要數(shù)據(jù)量化健康信息的支持（58到家的守望者平臺做的還是不錯的），需要快速診斷的支持（58到家的調(diào)用鏈跟蹤系統(tǒng)做的還是不錯的）

（7）“快速故障恢復”的KPI，真不是增加運維人手就能解決的，需要故障轉(zhuǎn)移的支持，相信我們，故障發(fā)生時，如果運維人員不知道怎么抉擇，且又必須做出抉擇，這時的抉擇往往是錯的（我們能做的，是重啟），我們也不想凌晨打給你們，但希望你們能實現(xiàn)自動化方案

（8）“內(nèi)審合規(guī)”的KPI，真不是增加運維人手就能解決的，在資源允許的情況下，請不要手動刪除任何資源，數(shù)據(jù)是很重要的資源。訪問控制和權限申請的流程，真的不是限制大家，相反，哪一次數(shù)據(jù)的誤刪除，不是我們加班來恢復的？寶寶心里苦呀

我們的KPI都掌握在大家的手里，技術一家人，希望研發(fā)測試的同學理解。