前面的文章中介紹了DevOps的概念以及其落地經(jīng)驗(yàn)卷雕，參考如下：
Devops 落地的核心和13條經(jīng)驗(yàn)總結(jié)
今天我來介紹一下在Devops體系中對項(xiàng)目團(tuán)隊(duì)效能方面的考核指標(biāo)藏姐！
度量指標(biāo)的選擇
在度量Devops團(tuán)隊(duì)效能方面，避免采用像代碼行數(shù)、故事點(diǎn)數(shù)這種面向過程、局部的度量指標(biāo)，而是采用像部署頻率通砍、前置時(shí)間、恢復(fù)時(shí)間烤蜕、變更失敗率和可用性等等這些面向結(jié)果的封孙、全局性指標(biāo)。具體指標(biāo)如下：
前置時(shí)間
是指從代碼提交讽营，到代碼成功運(yùn)行虎忌，到生產(chǎn)環(huán)境的時(shí)間。好的團(tuán)隊(duì)的變更前置時(shí)間一般不到一個(gè)小時(shí)橱鹏。
部署頻率
是指團(tuán)隊(duì)將應(yīng)用程序部署到生產(chǎn)環(huán)境頻率的度量膜蠢。好的團(tuán)隊(duì)會按需部署并且每天都會部署多次
變更失敗率
是指應(yīng)用程序部署到生產(chǎn)環(huán)境后需要回滾的百分比堪藐。好的團(tuán)隊(duì)的變更失敗率一般小于百分之十五。
恢復(fù)時(shí)間
是指服務(wù)故障到服務(wù)恢復(fù)所需要的時(shí)間挑围，好的團(tuán)隊(duì)恢復(fù)時(shí)間一般在 1 小時(shí)以內(nèi)礁竞，有的業(yè)務(wù)恢復(fù)時(shí)間要求5分鐘以內(nèi)。
可用性
是指團(tuán)隊(duì)確保軟件產(chǎn)品或服務(wù)可用的能力杉辙，可以通過 SLA 度量模捂，好的團(tuán)隊(duì) SLA可以達(dá)到99.99%，即一年 52.6分鐘不可用蜘矢，及個(gè)別公司要求業(yè)務(wù)的SLA達(dá)到99.999%狂男，那么一年只有5.26分鐘應(yīng)用時(shí)不可用的！
缺陷逃逸率
是指用戶或者測試人員在生產(chǎn)環(huán)境中發(fā)現(xiàn)的問題占整體發(fā)現(xiàn)問題的比率品腹。
在制品數(shù)量
這個(gè)指標(biāo)以暴露工作內(nèi)容過載的團(tuán)隊(duì)或團(tuán)隊(duì)成員岖食，使得每個(gè)團(tuán)隊(duì)成員的工作更加均衡。
停留時(shí)間
該指標(biāo)用來度量未完成的工作在系統(tǒng)里停留了多長時(shí)間舞吭，如果超過設(shè)置的閾值則進(jìn)行預(yù)警以暴露風(fēng)險(xiǎn)泡垃。
指標(biāo)落地
有了明確的指標(biāo)，我們就可以考慮如何利用這些指標(biāo)幫我們準(zhǔn)確地定位到項(xiàng)目中存在的問題了羡鸥，如下圖所示：
收集數(shù)據(jù)
我們可以借助平臺記錄事件（包括需求兔毙、故事點(diǎn)、事故兄春、bug，以及部署頻率锡溯、前置時(shí)間赶舆、恢復(fù)時(shí)間、變更失敗率祭饭、可用性上述五個(gè)指標(biāo)）的開始時(shí)間和結(jié)束時(shí)間芜茵，每個(gè)事件都有發(fā)生、處理倡蝙、解決的時(shí)間記錄九串。平臺具備收集這些數(shù)據(jù)的能力外，還可以提高統(tǒng)計(jì)報(bào)表寺鸥，用更直觀的方式進(jìn)行透明展示（對所有人都展示猪钮，類似學(xué)生時(shí)代的小紅花評比）。
分析數(shù)據(jù)
通過平臺的統(tǒng)計(jì)數(shù)據(jù)胆建，找到當(dāng)前存在的問題烤低。例如：當(dāng)我們發(fā)現(xiàn)需求完成的數(shù)量在減少，代碼行數(shù)在增加笆载，缺陷的數(shù)量在增長能說明什么呢扑馁？我們可以分析得出結(jié)論：項(xiàng)目進(jìn)入到測試階段后涯呻，問題很多，導(dǎo)致開發(fā)團(tuán)隊(duì)需要花費(fèi)大量的時(shí)間修復(fù)bug腻要，從而影響了正常的需求開發(fā)复罐。
調(diào)整流程
從上面的分析中，我們可以發(fā)現(xiàn)開發(fā)人員在開發(fā)階段對軟件質(zhì)量的控制效果不好雄家，開發(fā)人員沒有進(jìn)行有效自測效诅。然后跟開發(fā)人員進(jìn)行溝通，發(fā)現(xiàn)問題的原因是：需求太多咳短，開發(fā)人員的精力都在完成新的需求開發(fā)中填帽，并沒有時(shí)間自測代碼！進(jìn)一步跟需求人員溝通發(fā)現(xiàn)咙好，現(xiàn)在的需求提交方式是——前方收到用戶的反饋就會作為需求提交篡腌，而并沒有對需求的有效性進(jìn)行甄別。最終我們加入了需求評審環(huán)節(jié)勾效，讓有效的新增需求數(shù)量大幅度降低嘹悼，從而給開發(fā)人員爭取到了自測代碼的時(shí)間來保障代碼質(zhì)量！
重復(fù)執(zhí)行
重復(fù)上面的步驟层宫，不斷收集指標(biāo)杨伙，不斷觀察指標(biāo)的變化，并根據(jù)指標(biāo)的值調(diào)整流程萌腿，直到滿足要求限匣。
