將營運整合到開發的日常工作中#

本章探討如何透過更有效的跨功能協作，特別是將 Operations 的能力整合到 Development 的日常工作中，來實現更好的業務成果。

技術採用曲線與 DevOps 推廣#

在推動 DevOps 實踐時，組織中不同團隊對新想法的接受程度差異很大。Geoffrey A. Moore 在 Crossing The Chasm 中描繪了技術採用生命週期：

• Innovators（2.5%）：「先試再說」的技術愛好者
• Early Adopters（13.5%）：有遠見的先驅者
• Early Majority（34%）：務實主義者，「跟著大家走」
• Late Majority（34%）：保守派，「跟著已證實的走」
• Laggards（16%）：懷疑論者，「直接說不」

在 DevOps 推廣的早期階段，應聚焦於與 Innovators 和 Early Adopters 合作創造成功案例，避免花費精力試圖說服保守群體。成功案例會自然產生影響力。

建立共享服務以賦能開發團隊#

將 Operations 整合到開發工作中的一個關鍵策略是建立共享服務平台，使開發團隊能夠自助式地取用所需的基礎設施和工具。

自助服務模式#

• 開發團隊應能按需建立開發和測試環境，無需提交工單等待
• 營運團隊從「為每個團隊手動配置環境」轉變為「建立和維護自助服務平台」
• 這種模式讓營運團隊能槓桿化其專業知識，服務更多團隊

在服務中嵌入營運工程師#

另一種模式是將營運工程師嵌入到產品團隊中，成為團隊的一員。這些嵌入的工程師：

• 參與團隊的日常站會和規劃
• 協助設計可運營的系統（Design for Operations）
• 建立監控和告警
• 參與 on-call 輪值

Value Stream Mapping 的實務應用#

為了理解和改善工作流程，建立 Value Stream Map 是關鍵工具。

價值流圖中的關鍵指標：

• Lead Time（前置時間）：從工作請求到完成的總時間
• Process Time（處理時間）：實際投入工作的時間
• %C/A（完整且準確百分比）：下游工作中心接收到的工作中，無需返工即可使用的比例

範例中的匯總值非常典型：總前置時間 10 週、實際增值時間 7.5 天、%C/A 僅 8.6%。這意味著絕大部分時間都花在等待和返工上，而非真正的價值創造。

讓開發團隊擁有營運技能#

傳統上，Development 和 Operations 被視為完全獨立的功能，有著不同的目標和激勵：

• Development：追求快速交付新功能
• Operations：追求系統穩定性和可靠性

這種分離導致了 DevOps 運動的核心問題：「開發和營運之間的衝突牆」。解決方案不是讓每個開發人員都成為營運專家，而是：

• 建立共同的目標和指標（如部署頻率、前置時間、MTTR、變更失敗率）
• 讓開發團隊對其服務的生產行為負責
• 提供工具和平台，降低營運工作的門檻

建立有效的合作模式#

聯絡人模式（Liaison Model）#

• Operations 為每個主要開發團隊指定一位聯絡人
• 聯絡人負責理解開發團隊的需求並代表營運觀點
• 適合作為轉型初期的過渡方案

嵌入模式（Embedded Model）#

• 營運工程師全職加入開發團隊
• 深度參與產品開發，從設計階段就考慮可運營性
• 更高程度的整合和知識分享

平台團隊模式（Platform Team Model）#

• 建立專門的平台團隊，提供自助式的基礎設施和工具
• 開發團隊作為平台的客戶，按需使用
• 平台團隊專注於提升開發者體驗和生產力

非功能需求的優先化#

為了實現開發和營運的真正整合，非功能需求（如架構、效能、穩定性、可測試性、可配置性和安全性）必須與使用者功能同等優先對待。

這意味著：

• 在產品 backlog 中明確包含非功能需求
• 在每個迭代中保留固定比例的容量處理非功能需求
• 將非功能需求的達標作為服務上線的門檻

當非功能需求持續被功能開發擠壓時，技術債會不斷累積，最終導致系統脆弱、部署困難、事故頻發。保留每個迭代 20% 的容量用於基礎設施改進和技術債償還，是確保長期健康的關鍵實踐。

結論#

將營運整合到開發的日常工作中，不是要消除兩者的專業分工，而是要打破阻礙協作的組織壁壘。透過共享目標、自助服務平台、嵌入式合作、以及對非功能需求的重視，我們能讓開發和營運團隊共同為客戶和業務創造更好的成果。