運維說給研發測試的心底話

網際網路，講究快速迭代，快速上線，敏捷開發。

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

為保住KPI，運維有很多心裡話想和研發測試說一說：

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

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

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

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

（5）“快速故障報警”的KPI，真不是增加運維人手就能解決的，需要監控系統的支援（作業系統和運維層面的監控，我們可以實施，但錯誤日誌、介面、業務的監控呢？），另外報警簡訊能少一點麼，過度報警會讓人變得“麻木不仁”的

（6）“快速故障定位”的KPI，真不是增加運維人手就能解決的，需要資料量化健康資訊的支援（58到家的守望者平臺做的還是不錯的），需要快速診斷的支援（58到家的呼叫鏈跟蹤系統做的還是不錯的）

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

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

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

大家還有什麼苦水？一起說一說。