iT邦幫忙

2022 iThome 鐵人賽

DAY 1
3

淺談DevOps

DevOps的歷史

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

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

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

2009年6月, Debois回到比利時,觀看了O'Relly Velocity'09大會的直播, 這次的最大亮點是一個名為"10+ Deploys Per Day: Dev and Ops Cooperation at Flickr(每日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".
在第一屆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/upload/images/20220930/20104930hn8kOl6491.png
感謝艦長幫忙補充

今日小總結

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

如果今天開發團隊把Ops團隊當作客戶, 套用在敏捷宣言中來看, 似乎就呼應了DevOps最早想解決的痛點.

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商 
響應變化 重於 遵循計劃

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

ps. 有公司缺菜鳥SRE工程師嘛(?), 但後端與系統整合9年以上的:)
或需要後端系統工程師, 有系統規劃與SLO規劃設計等經驗
履歷在這(揮手)

參考資料

為什麼會出現DevOps?
The Agile Admin
Operations Anti-Patterns, DevOps Solutions
非同步系統的服務水準保證 淺談非同步系統的 SLO 設計-91APP
淺談DevOps & Observability


幹話王部落格

OpenTelemetry 入門指南:建立全面可觀測性架構


下一篇
淺談Observability(上)
系列文
淺談DevOps與Observability36
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
1
json_liang
iT邦研究生 5 級 ‧ 2022-09-01 13:18:00

感謝大大分享 Observability 優文!

1
harry xie
iT邦研究生 1 級 ‧ 2022-09-01 18:34:03

圖好精美啊~好文推推

2
Cheng Wei
iT邦新手 5 級 ‧ 2022-09-30 05:19:58

嚴格說來,Taiwan 在 2015 是 iThome 先獨自舉辦 DevOps Summit。
2017 才開始舉辦 DevOpsDays Taipei。

雷N iT邦研究生 1 級 ‧ 2022-09-30 08:57:33 檢舉

感謝艦長補充
我來改一下 加上參考

我要留言

立即登入留言