1. 程式人生 > >58沈劍:運維說給研發測試的心底話

58沈劍:運維說給研發測試的心底話

58到家沈劍

作者:沈劍,58技術委員會主席,58高階架構師,58到家技術總監。C2C技術部負責人,58技術學院優秀講師。

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

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

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

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

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

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

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

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

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

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

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

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

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