開發維運合一 (DevOps)

DevOps 是一種組織內文化與既有職責變革（movement），用以回應大型組內常見分工謬誤的問題。通常組織會成立以下獨立專責單位

• 開發單位
• QA品保單位
• 維運活動

極端狀況下，這些獨立的單位可能會

• 分散在不同地點
• 效力於不同組織
• 隸屬於不同管理階層

通常，單位間的額外溝通成本與激勵不足，是導致協同流程進度緩慢與障礙的主因

這是 Devops 致力要解決的問題. Devops 不是一種方法論或框架, 而是一些指導原則與致力於打破組織藩籬的決心。Devops 特別是針對下列項目:

• 組織文化
• 自動化
• 量測
• 共享

組織文化

組織若想要推動Devops 需先改變員工態度，讓「責任共享」與「協同合作」的精神融入打造服務的各個步驟。這種文化變革對具規模之組織顯得特別重要

自動化

許多商業流程其實可以被自動化，特別是針對需手動操作、容易出錯的工作。自動化效益可顯現於以下領域

• 釋出管理(軟體釋出)
• provisioning
• 組態管理
• 系統整合
• 流程監控
• 系統協同運作整合 (複雜電腦系統間協同與維護)
• 測試

量測

資料本身對實現變革的重要性超乎想像。當來自不同團隊的量測資料能夠突顯與過去單位內變革成果之差異時，這些資料可促成不同單位的成員加入參與，共同提升遞交「end to end」數位服務的品質改善。

共享

來自不同背景的成員 (例如開發與維護團隊)通常各自具備不同但是領域可能重複的技能團隊間交流會促進成員間分享彼此的成功經驗，所以請多多鼓勵分享. 透過促成相互合作解決遭遇難題，而非浪費精力在協商談判上。

為什麼要推行 Devops？

如果以下領域的團隊成員無法在一起合作，將導致服務品質低落：

• 建造與測試軟體的成員
• 最終使用軟體的成員

導致品質低落的根因，是將上述兩類成員功能上獨立區隔開來;當一團隊專注某一領域（例如品質）會導致另一團隊認為該領域與自身無關，進而忽略關注。

這種態度是「有害」的，將危及以下領域：

• 服務品質
• 發佈管理
• 整體服務綜效

高品質的數位服務需要能夠快速回應使用者的需求，而唯一達成的辦法就是讓這些團隊彼此緊密的合作。

確保你的團隊成員都有以下共識/文化：

• 當責意識，服務成敗取決成員表現，不是其他人的責任
• 成員都清楚了解待解決的問題
• 營造「讓成果可被量測」組織文化

好習慣

Devops並不是一套專案管理方法論，而是讓組織普遍使用這些好習慣. Devops 當然（也不例外）有一些普遍適用守則，有助於打破組織內的各自為政：

• 跨部門團隊 – 確保團隊由不同功能背景人組成，(有助於成員共享服務品質意識並打破組織藩籬)
• 共享服務指標 –讓所有人明瞭「多好才算好」十分重要。當廣泛納入各種量測高低指標，有助所有人於形成品質認知。
• 將重複性工作自動化 –使用軟體開發工具來自動化工作，當:
  • 鼓勵團隊更深入了解整體服務
  • 將員工從重複手動繁瑣任務中解放出來
• 事後檢討(驗屍）–相同議題可能重複發生在其他團隊上，一起從中學習是必要的 ;事後驗屍檢討(事件發生後的分析檢討) 特別是與不同部門的人一起檢討有助於深入理解問題與經驗分享。
• 定期釋出 –功能區隔的組織中，軟體釋出能力通常會受到限制，因為釋出組件由各自負責團隊完成 –這導入一個觀點，如果團隊緊密合作與聰明的自動化工作協助下，要定期釋出（甚至一天數次）將不是難事。

警示訊號

類似 agile, 「Devops」名詞常用於行銷或推廣目的。也因此導致Devops理念受到誤會，請小心以下這些字眼：

• Devops 工具 (幾乎等於行銷面)
• 一個 Devops 團隊 (許多案例顯示這又是一種獨立的技能與知識集合而已)
• Devops用於職稱(就像你不會稱呼“一個敏捷人”一樣)

相關服務手冊指引

對 Devops 主題有興趣者，通常也會閱讀:

• 構型管理
• Monitoring
• 釋出管理

進階閱讀

• Devops 對我的有何意義？
• 簡單來說，Devops 是什麼?
• Devops 是什麼？ ( Devops 釋疑（困惑之牆） )
• 其實，“Devops 團隊” 不存在？

譯者：學治
校稿者：
原始出處：https://www.gov.uk/service-manual/operations/devops.html