---
title: "淺談DevOps"
tags: 2022IT鐵人, DevOps
date: 2022-08-28
---

# 淺談DevOps

## DevOps的歷史
**2007年**比利時的一位IT顧問[Patrick Debois](https://twitter.com/patrickdebois?lang=zh-Hant), 他興趣是從各角度研究IT組織.
他為比利時政府的一個大型資料中心遷移的項目提供諮詢, 主要負責這次遷移的測試與驗證工作.所以需要跟開發團隊與運維團隊一起協同工作. 時常某一天要在開發團隊跟隨敏捷的節奏, 過幾天又要以傳統瀑布的形式去逐步維護這些系統.
看到這兩個團隊的運作方式之間的顯著差異時, 兩個團隊在不同的世界裡, 但彼此又堅守著各自的利益, 所以在這之間工作時到處都是衝突.
為此Debois感到很組喪, 所以開始思考怎解決這問題.

**2008年8月**, 在多倫多的Agile Conference上, 一位開發者Andrew Shafer提出一個名為"**Agile Infrastructure**"的臨時話題, 當時只有Debois參加這話題. 他倆在走廊裡, 就私下的進行漫長的討論. 也就是因為有這次對話, 之後他倆就決定了在Google Group上建立了一個Agile System Administration的討論組繼續討論下去.

然後兩人決定新開一個Blog來紀錄這些內容跟自己的經驗, 於是乎一個名為[The Agile Admin](https://theagileadmin.com/)的部落格誕生了.

**2009年6月**, Debois回到比利時,觀看了O'Relly Velocity'09大會的直播, 這次的最大亮點是一個名為"**[10+ Deploys Per Day: Dev and Ops Cooperation at Flickr](https://youtu.be/LdOe18KhtT4)**(每日10次佈署; 在Flickr的開發與運維協作)"的演說內容, 幾乎後來很多和DevOps有關的資料都會把這場加入引用(我這次參賽也是XD).
該場內容有兩個核心觀點, 以業務敏捷為中心, 打造出適應快速發布軟體的**工具**與**文化**.

Debois看到這場直播, 心有所觸, 怦然心動(?)
於是乎立刻在Twitter上發問, 自己如何能參加Velocity大會.
就有人回覆說, 可以在比利時召開自己的Velocity? 這一定很棒！！
於是Debois真的就在比利時開創了他自己的研討會, 邀請開發(Dev)與運維(Ops)人員一起討論各種協作方法, 以及如何管理基礎件建設並重新思考團隊協作的方式.
Debois最早想到Dev和Ops做會議名稱, 且這會議維持2天, 所以就加上了**DevOpsDays**; 但當時Twitter每條訊息最多只能140個字, 為了近可能在每條訊息保存針對資訊, 所以把tag ``#devopsdays``縮短成``#devops``, 於是乎**DevOps**這稱謂就誕生了.

**2010年**, The Agile Admin部落格發表了一篇"**[What is DevOps](https://theagileadmin.com/what-is-devops/)**".
在第一屆DevOpsDays之後, DevOps被越來越多人給認可. 也逐漸認同這正是IT部門的正確運作方式, 所以DevOps成為了一種促成開發與運維合作的運動. 在各種場合與活動過程中不斷分享自己的經驗與見解, 並且催生了很多工具與實踐歷程的產生. 但是每個人對於DevOps這稱謂的離解還是有所不同, 爭議在所難免的.

該文章給出了詳細的DevOps定義, 並且根據敏捷的體系給出了DevOps的體系, 包含了一系列的價值觀、原則、方法、實踐與對應的工具.

文章中在DevOps定義中給出三個主要的實踐領域
1. Infrastructure Automation
2. Continuous Delivery
3. Site Reliability Engineering
- operate your systems; monitoring and orchestration, sure, but also designing for operability in the first place.

這次我想著重學習並且分享的點就是第三點內的Monitoring Tools與其衍生出來的Observability(可觀測性), 之前([分布式可觀測性 Logging 淺談](https://ithelp.ithome.com.tw/articles/10277525))有分享過一點點而已, 今年想更深入的學習研究.


## 今日小總結
DevOps是敏捷文化應用在軟體開發與組織中的結合與延伸.
DevOps強調在整個軟體開發生命週期中, 所有團隊之間的職責共擔.
運維團隊承擔了以往傳統上更側重於開發人員所關注的任務, 並且開發團也會做相同的事情, 有共同的能力與經驗, 協作上會更順暢.

如果今天開發團隊把Ops團隊當作客戶, 套用在[敏捷宣言](https://agilemanifesto.org/iso/zhcht/manifesto.html)中來看, 似乎就呼應了DevOps最早想解決的痛點.
> 個人與互動 重於 流程與工具
> 可用的軟體 重於 詳盡的文件
> 與客戶合作 重於 合約協商 
> 響應變化 重於 遵循計劃

> 多跟Ops團隊互動
> 開發出來的軟體可以被Ops團隊給使用且好管理監控
> 多跟Ops團隊合作
> 大家一起響應變化.

### 參考資料
[為什麼會出現DevOps？](https://www.ithome.com.tw/news/96861)
[The Agile Admin](https://theagileadmin.com/)
[Operations Anti-Patterns, DevOps Solutions](https://www.manning.com/books/operations-anti-patterns-devops-solutions)
[非同步系統的服務水準保證 淺談非同步系統的 SLO 設計-91APP](https://www.91app.tech/static/97979df17dd25408c24c20ae74e27155/SLO-design-of-the-asynchronous-system-Andrew.pdf)
[淺談DevOps & Observability](https://ithelp.ithome.com.tw/articles/10284118)