運(yùn)維說給研發(fā)測試的心底話

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

有些固定上線時(shí)間的項(xiàng)目，可能因?yàn)榧夹g(shù)方案變化，導(dǎo)致測試時(shí)間壓縮，最終導(dǎo)致上線出問題，而由運(yùn)維來背鍋。

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

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

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

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

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

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

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

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

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

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