持續改善 - 模式
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | DORA | ✅ 追蹤部署頻率;行動最快的小組依需求部署,通常每天多次部署 |
| 平台 | DORA | ✅ 變更的前置時間會測量從代碼認可到生產部署;子日前置時間表示效能優良的傳送,子小時表示能力優異 |
| 平台 | DORA | ✅ 變更失敗率會作為導致需要補救的生產事件的部署百分比進行追蹤,並持續保持低 |
| 平台 | DORA | ✅ 測量失敗的部署復原時間;不到一小時的復原表示傳送成熟 |
| 平台 | DORA | ✅ 將部署重試率追蹤為因生產事件所導致非預定部署的比率 |
| 平台 | DORA | ✅ 度量會組織成輸出 (前置時間、部署頻率、失敗的部署復原時間) 和不穩定性 (變更失敗率、重試率) 因素 |
| 平台 | 度量 | ✅ DORA 度量會持續測量並隨著時間趨勢分析,改善的軌道加權高於絕對值 |
| 平台 | 顯示面板 | ✅ 度量會在整個組織可看見的作業顯示面板中進行追蹤,以建立有關營運績效的透明度 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | DORA | ⚡️ 低部署頻率反映了部署小組避免的難題,從而建立一個惡劣的循環,不常進行部署會使每個部署變得更有風險 |
| 平台 | DORA | ⚡️ 較長的前置時間會反映過度流程負擔、自動化不足或組織功能故障 |
| 平台 | DORA | ⚡️ 高變更失敗率反映測試不足、部署驗證不足,或在沒有適當品質檢查的情況下快速變更 |
| 平台 | DORA | ⚡️ 復原時間較長會反映部署驗證不足、缺少自動回復或生產事件擁有權不明確 |
| 平台 | DORA | ⚡️ 高重試率顯示生產事件會定期推動緊急部署、在生產前測試、版本驗證或變更管理中顯示缺口 |
| 平台 | 度量 | ⚡️ 度量會作為時間點快照而非趨勢隨時間的趨勢,隱藏營運效能是否改善或降低 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 程序 | ✅ 定期發生衝刺追溯 (每個衝刺或每月) 以建立反思的節奏,而非等待危機 |
| 平台 | 程序 | ✅ 追溯使用結構化格式 (開始/停止/繼續、瘋狂/悲傷/快樂、時程表),以鼓勵參與和可採取動作的成果 |
| 平台 | 程序 | ✅ 會輪替參與者,以防止任何個人控制討論 |
| 平台 | 程序 | ✅ 追溯洞察會轉換為具有擁有者和完成日期的具體動作項目,為每個工作階段產生少量改善方式 |
| 平台 | 程序 | ✅ 動作項目完成度會追蹤追溯,讓小組負責追蹤 |
| 平台 | 作業 | ✅ 營運審查會每季或每月評估彙總營運健康狀況,並檢查趨勢資料並對照目標進行比較 |
| 平台 | 作業 | ✅ 作業審查會與領導階層互動,為競爭功能開發的作業改善工作保護資源 |
| 平台 | 作業 | ✅ 檢閱包含作業度量:依照旅程的目標可用性、依百分位的延遲趨勢、依照偵測與解決平均時間的事件嚴重性計數、部署頻率和成功率,以及營運負載,例如通話頁面和工時 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 程序 | ⚡️ 追溯階段會等待危機,而非以一般的順序發生 |
| 平台 | 程序 | ⚡️ 追溯會產生長時間的討論,但沒有採取行動,浪費時間並產生疑惑 |
| 平台 | 程序 | ⚡️ 動作項目定義時沒有擁有者或完成日期,因此會討論改善方式,但絕對不會實作 |
| 平台 | 程序 | ⚡️ 動作項目完成度永遠不會在追溯時進行追蹤,因此不會顯示追蹤結果 |
| 平台 | 作業 | ⚡️ 系統會將作業視為僅在危機期間受到注意的隱藏背景工作,而不會定期進行作業審查 |
| 平台 | 作業 | ⚡️ 營運審查缺乏領導階層的參與,因此當配置資源時,改善工作會失去功能開發 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 作業 | ✅ 作業整備檢閱會在生產開始前評估新功能或系統是否符合作業需求 |
| 平台 | 作業 | ✅ 檢閱會在生產開始的新解決方案、主要功能或具有營運影響的結構變更之前進行 |
| 平台 | 作業 | ✅ 檢閱時間平衡,因此實作足以完成以供評估,而無需解決的作業疑慮太晚 |
| 平台 | 監視 | ✅ 檢閱確認已計畫足夠的度量、存在失敗情況的警示,且顯示面板顯示健康狀態 |
| 平台 | 文件 | ✅ 檢閱確認執行手冊適用於常見作業、已為回應者記錄結構,且升級程序已清楚 |
| 平台 | 部署 | ✅ 檢閱確認部署可靠執行、存在結轉程序,且部署已在暫存中驗證 |
| 平台 | 效能 | ✅ 檢閱確認在實際負載下驗證績效目標、存在成長前置空間,且評估管理員限制風險 |
| 平台 | 安全性 | ✅ 檢閱確認安全性審查已完成、已符合稽核需求,且存取控制符合需求 |
| 平台 | 相依性 | ✅ 檢閱確認已識別外部相依性、整合合作夥伴有服務層級協議,且相依性失敗存在回復行為 |
| 平台 | 監管 | ✅ 生產啟動會在檢閱完成時完成,使作業疑慮的部署需求而非精心嘗試 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 監管 | ⚡️ 新功能在沒有營運整備評估的情況下投入生產,累積了營運負債,進而使未來的卓越營運變得越來越困難 |
| 平台 | 作業 | ⚡️ 審查執行時間太晚,因此營運上的疑慮感覺像是部署封鎖者,並會造成略過修正的壓力 |
| 平台 | 監管 | ⚡️ 系統會將營運整備視為精心嘗試,而非部署需求 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 文化 | ✅ 心理安全可讓您誠實地討論問題、錯誤和近乎錯誤,而不必擔心受到懲罰 |
| 平台 | 文化 | ✅ 透過無罪的死亡後服務、慶祝問題發現,以及透過討論自己的錯誤來建模領導階層的漏洞來建立心理安全 |
| 平台 | 度量 | ✅ 度量可透過營運度量、事件趨勢、DORA 指標和使用者滿意度分數來顯示營運狀態,讓改善工作能達到目標優先順序 |
| 平台 | 作業 | ✅ 工程容量刻意保留供營運改善、技術債務減少,以及工具和自動化投資 |
| 平台 | 作業 | ✅ 回饋意見迴圈會將作業體驗連接至設計決策,因此事件會推動結構改善、監視會驅動最佳化,以及部署失敗會驅動測試涵蓋範圍改善 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 文化 | ⚡️ 缺乏心理安全性的小組會隱藏問題,直到這些問題變成災難,進而防止早期介入 |
| 平台 | 作業 | ⚡️ 小組將所有容量花在功能上,而沒有時間進行營運改善,進而累積技術和營運債務,進而強制執行危機回應 |
| 平台 | 作業 | ⚡️ 作業體驗並未填入設計中,因此相同的劣勢會循環出現,且作業會漸進降低而非改善 |