什麼是DevOps？
「Dev」和「Ops」的縮寫是指取代孤立的開發和營運團隊。 這個想法是在多學科團隊中創造共同工作環境，讓他們一起運用共享的實踐、工具，並對結果承擔共同責任。 基本的 DevOps 實踐包括敏捷規劃、持續整合、持續交付和應用程式全面監控。 DevOps 是一個持續的改進之旅，而不是目的地。
DevOps 的商業價值
實施 DevOps 實踐的組織通常會在關鍵運營指標上看到可衡量的改進：
- 部署頻率：從不頻繁的發行增加到定期、可預測的部署
- 交貨時間：從延長的開發週期縮短到較短的交付時間
- 平均復原時間 （MTTR）：更快的事件解決和系統恢復
- 變更失敗率：由於改進的測試和自動化，減少了生產問題
預期的好處包括：
- 縮短新功能的上市時間
- 減少部署相關事件
- 提高開發人員的生產力和滿意度
- 透過自動化降低營運成本
了解並計算您的週期時間
讓我們從使用 OODA（觀察、定位、決定、行動）循環進行軟體開發的基本概念開始。 最初設計 OODA 循環是為了防止戰鬥機飛行員在空中被擊落，而它如今成為在商業世界中保持領先於競爭對手的一個絕佳框架。
OODA 循環實踐：
- 觀察： 監控業務指標、市場趨勢、用戶行為和遙測數據
- 導向：分析您可以交付的選項，可能透過實驗進行
- 決定：根據數據和業務優先事項確定要追求什麼
- 行動：將工作軟體交付給真實使用者並收集回饋
週期時間計算練習： 想想你目前的開發過程。 從這裡到那裡需要多長時間？
- 程式碼提交→生產部署？
- 功能要求→客戶意見反應？
- Bug 報告 → 是否接在生產環境中修復？
範例：如果部署單行組態變更需要 2 週，則您的週期時間為 2 週。 這會成為您的速度限制。
成為「以資料為參考」，而非完全「資料驅動」
我們建議使用數據來為下一個週期的決策提供信息，但避免因分析而癱瘓。 許多組織的經驗表明，部署通常會產生不同的結果：
- 某些部署 會產生負面的業務結果
- 某些部署 將產生積極的結果
- 某些部署 不會產生可衡量的差異
關鍵原則：在無法推動業務發展的計劃上快速失敗，並在支持業務目標的成果上加倍努力。 這種方法通常稱為「轉向或堅持」。
實際應用：
- 為新功能設定 A/B 測試
- 在部署前定義成功指標
- 建立失敗實驗的復原程序
- 建立意見反應迴圈以快速衡量影響
爭取經過驗證的學習
您能多快地快速失敗或加倍投入，取決於您的迴圈時間 - 也就是這個意見反應迴圈完成所需的時間。 您在每個週期中收集的反饋應該是：
- 事實：基於真實使用者行為和系統指標
- 可操作：導致明確的後續步驟和決策
- 及時：可用速度足夠快，足以影響下一次迭代
這種基於證據的方法稱為 驗證學習 ——根據經驗證據而不是假設或意見做出決策。
驗證學習的範例指標：
- 使用者參與率和功能採用率
- 系統效能和錯誤率
- 客戶滿意度分數和支援票證
- 業務 KPI（收入、轉換率、留存率）
縮短您的週期時間
當您採用 DevOps 做法時：
- 您可以藉由以較小的批次工作來縮短週期時間。
- 使用更多自動化。
- 強化您的發行管線。
- 改善您的遙測。
- 更頻繁地部署。
優化已驗證的學習
您部署的頻率愈高，您可以進行實驗愈多。 您在每個週期有越多的機會可以進行樞軸旋轉或堅持不懈，並取得經驗證的學習。 這個在經驗證的學習方面的加速是改良的價值。 請將它視為您達成的進度總和，以及您避免的失敗。
