爲了推動整個組織實現DevOps，公司高層制定了一些“簡單粗暴”的KPI——今年的發佈數量要比去年翻倍，故障數量要比去年減半。這些KPI成了所有IT系統負責人的共同目標。
乍一看，這樣的目標很不合理。
單純增加發布數量，其實是可以作弊的，把一個發佈硬生生地拆成幾個發佈便可（也確實有團隊在這麼幹！）。
而且，這樣做，對業務真的有意義嗎？到頭來，還不是IT自己在自嗨，業務痛點並沒有減少？
然而，只要我們端正對這些目標的態度，結果則大不一樣。
如果我們狹隘地追求數字，應付考覈，當然不會得到好的結果。
但如果我們把它當成驅動力，不斷審視自己的團隊和系統還有哪些方面可以改進，則會有很多意外收穫。
作爲其中一個IT系統負責人，我也要接受這些目標的要求。但通過圍繞着這些目標對自己系統的持續改進，我們獲得了以下成果：
實現了某些變更類型的在工作日的自動化發佈，從而使發佈數量比去年同期增長了192%，差不多是過去的3倍，遠遠拋離要求的目標。具體措施可參閱《另闢蹊徑，傳統銀行供應商系統持續交付之路》
改進工單排序流程，把時間精力用在刀刃上。具體措施可參閱《從急診室故事聯想到系統運維》
每週故障分析會議，持續跟進故障長期解決方案的交付，分析故障和請求類型，建立知識庫減少重複故障和請求。
加強監控，包括系統指標監控和業務流量增長，感知系統健康情況，防範於未然，也能減少人工登陸服務器的次數和工單數量。
標準化運維流程，把具體的標準運維流程寫成分步文檔，並提供審批申請模板，便於每個運維人員嚴格按照規範執行，減少出錯和降低風險。
在合規的情況下，標準化發佈後系統檢查清單，爲發佈質量提供最基本的保障。
我們也一直強調，每個系統的情況都很不一樣，有些是新建的，有些是遺留的，有些是自主開發的，有些是依賴供應商的，“家家有本難唸的經”。
所以不應該把不同團隊進行橫比。這些目標，更重要的是驅動每個團隊對自己進行持續改進，所以對自己的縱比更有意義。
以我們公司的實踐，KPI驅動的DevOps轉型是可行的，但是這需要管理層對KPI背後的目的有明確的闡釋，各團隊也要對KPI有正確的理解，視之爲工具，而不是考覈，才能避免異化，達到持續改進的目的。
相關閱讀：
關於作者
劉華（Kenneth）
就職於世界500強銀行，負責基金服務業務軟件開發與交付
敏捷、精益、DevOps專家
精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧
曾在GDevOps、DevOpsDays Meetup、中國軟件技術大會、ArchSummit等論壇發表主題演講
著有《獵豹行動：硝煙中的敏捷轉型之旅》一書
小說體敏捷/DevOps轉型教科書
和實戰經驗分享
購書指南
—
紙質書、電子書在京東、噹噹、亞馬遜、微信讀書等渠道已全面上架，搜索關鍵字“獵豹 敏捷”即可找到。點擊閱讀原文可直接購書。
有聲書已登錄喜馬拉雅、微信讀書，適合路上聽書的你。
關注公衆號看其他原創作品
覺得好看，點個“在看”或轉發給朋友們，歡迎你留言。