---
# System prepended metadata

title: DevOps Handbook 前半生導讀

---

# DevOps Handbook 前半生導讀

> 以下是我在 2020/01/04 參加 `Agile Hsinchu 一月聚會: DevOps Handbook 前半生導讀` 的筆記

這本書如何閱讀？
> 書中有 reference，精華在裡面

如何讓學習有效

* 課堂上做筆記
* 一天內溫習筆記
* 一週內人前分享

`備註`： 以下內容只包含書中 Part 1 和 2

## 什麼是 DevOps ?

有人覺得

* 持續整合、持續交付
* 自動化測試
* 一種文化
* 快速交付
* ...

> 無論如何 DevOps != 工具

## 前言

> 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr: [Youtube](https://www.youtube.com/watch?v=LdOe18KhtT4) and [Slides](https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr)

傳統思維
  * Devs 的工作是 `增加功能`
  * Ops 的工作是確保系統 `穩定和快速`

Devs 與 Ops 真正目標應該是 `幫公司發大財`

產品運作上常常會要求許多 `改變` ，但是這些改變常造成 `系統中斷`，究竟要 `為了穩定性而不鼓勵改變` 還是 `有需要就允許改變發生` ？

這邊引入我曾經在 `Continuous Deliver` 書中看過的一句話
> 假如覺得某件事困難或者痛苦，那就重複頻繁地作到駕輕就熟

因此
  * Ops 應該像 Devs 一樣地 `做法`
  * Devs 應該有 Ops 一樣的 `思維`

透過 `工具` 和 `文化` 來降低改變的風險
  * 沒有角色別，只有事情別
    * Waterfall: 開發 | 測試 | 運維
    * Agile: 開發 + 測試 | 運維
    * DevOps: 開發 + 測試 + 運維 
  * 快速交付價值

Wiki 說

> DevOps 是一種重視 `軟體開發人員 (Dev)` 和 `IT 運維技術人員 (Ops)` 之間溝通合作的文化、運動或慣例。透過自動化 `軟體交付` 和 `架構變更` 的流程，來使得構件、測試、發布軟體能夠更加地快捷、頻繁和可靠。

Devops 的技術體系

  * Clouds
  * Containers
  * Micorservices
  * 8字循環

`DevOps 目標`: Deliver High Quality Working Software Faster
  * `時間` 快到一定程度
  * `品質` 好到一定水準

> DevOps 的落實度是 `個人和公司的工程競爭能力`

出自 `鳳凰專案`

| 公司     | 部數頻率   | 交付時間 | 可靠性 | 客戶反應 |
|----------|------------|----------|--------|----------|
| Amazon   | 23000/days | minutes  | 高     | 高       |
| Netflix  | 500/days   | minutes  | 高     | 高       |
| Facebook | 1/days     | hours    | 高     | 高       |
| Twitter  | 3/weeks    | hours    | 高     | 高       |
| 傳統企業  | 1/9 months | Months   | 低/中  | 低/中    |

## 三步工作法

* 流動原則
  * 了解如何讓 `開發到運維` 的工作，`快速` 地從左向右流動

* 回饋原則
  * 如何持續 `快速` 獲得工作反饋，以在 `源頭` 解決問題 `避免返工`

* 持續學習與實驗原則
  * 如何建立 `持續學習` 文化，鼓勵 `探索` 與 `實驗` 

### 流動原則 - 系統思考

經典名句

> 大多失敗來自於 `系統或流程` 問題，管理層責任是去 `改善流程`，而非個人

> 如果你無法描述你的做事流程，代表你不知道你在做什麼

可以了解系統狀況的方式有

* 價值流程圖
  * 怎麼畫？
    * 定義 End 2 End Scope
    * all roles 都要考慮
  * 把每一階段時間畫出來
  * 階段切換時間也要畫
  * 找出 `瓶頸`
    * 目前狀態與期待

* 可利用 Kanban 驅動開發
  * 綜觀全局
  * 工作視覺化
  * 消除浪費
    * 半成品太多
    * 額外功能
    * 過度處理
    * 多工
    * 等待
    * 交接
    * 錯誤
  * 規劃改善
    * 限制 WIP
    * 避免多工
    * 避免交接
    * 持續識別和改善約束點 - 五步聚焦法
  * 度量回饋
    * 利用看板統計 Lead Time
    * 由 Lead Time 趨勢看是否變好

### 反饋原則 - 加強反饋迴圈

> 持續部暑，監控生產環境，Dev/Test/Sec/Op 合作

* 遇到問題
  * 問題發生，如無法在指定時間內解決，需拉下安東繩大家協同處理
* 為下游工作而優化
* 在源頭保證質量 `寫好就測! 先寫完小批量，Bug 先修重要的`


  * 需求： `TDD 定義需求，定義好輸入及輸出`
  * 開發： `Pair programing`
  * 測試： 
  * 發佈： `監控`

### 持續學習與實驗原則 - 建立持續學習與實驗的文化

> 積極 `探索和分享` 訊息，所有員工 `共同` 承擔責任，對事故積極 `反思`，會真的做 `根本原因分析`

* 建立學習型組織與文化
  * 在複雜系統工作，管理層 `對事故負責人進行處罰`，不但會 `引起恐懼感`，還會導致有問題時 `隱瞞不報，逃避責任`，並且滋生 `自我保全` 的意識
  * `公正文化 (Just Culture)` 是指一個 `不會` 對自願舉報個人或系統錯誤的前線員工 `作出懲罰` 的文化
  * 探討 `什麼 (what) 和這件安全事件有關`， 而不是 `誰 (who) 和這件安全事件有關`

* 比日常工作更重要的，是 `對日常工作` 的持續改進

* 把局部發現轉化為全局優化，例如
  * Code Review & 共同函式庫
  * 研討會參與心得分享
  * 測試自動化的經驗和工具分享
  * 每季 / 月 經驗報告分享

* Improvement Theme Kata
  * `Theme` 主題名稱
  * `Now/Problem` 目前狀態、問題
  * `Definintion of Awesome` 定義期望狀態
  * `Next Target Condition` 定義下一個階段性目標
  * `First Step` 第一步驟應該採取哪些行動

> 例如 改善產品品質
>
> `Now/Problem`: 用戶測試找到太多 bug、開發時沒有進行功能測試、回歸測試是隨意測試
> `Definintion of Awesome`: 所有測試功能都能自動化、每次程式 check-in 都執行功能測試
> `Next Target Condition`: 在 3 周後， CI 要加入功能測試，顯示多少測試成功執行，失敗
> `First Step`: 建立功能測試環境、撰寫測試自動化

## 如何開始

* 組建專門的轉型團隊
  * `專門` 執行 DevOps 的轉型工作
  * 找懂 `多個領域的通才`
  * 找 `與其他部門關係良好` 的人作為團隊成員

* 找內部有意願的意見領袖支持 `技術狂熱者` 和 `高瞻遠矚者`

* `贏得` 沉默的大多數
  * 避免和唱反調者發生衝突

* `識別` 永遠的反對者
  * 除非你獲得壓倒性支持，否則別對付他們

* 如何轉型
  * 擁有共同目標 `規劃可度量的目標`、`以迭代和增量方式進行`
  * 小步改進計畫 `降低還沒有成果就被中止的風險`
  * 保留還技術債時間 `約 20 ％`
  * 提高工作的可視化 `了解每個人目前工作的狀態`

### 案例研究

* Nordstrom
  * 轉型前
    * 著重於 Cose
    * 資源共享
    * 計畫以年為單位
    * Waterfall
    * 大批次發布
  * 轉型後
    * 著重於 Speed
    * 採用 Agile
    * 價值流/Cycle time
    * Improvement Kata
    * 每月發佈
  * 先從 `某些系統開始`，而非全面轉型
  * 收集團隊週期時間，視覺化，並逐步改善
  * 單一 backlog `包含 Feature, bugs, product`

* Google
  * 參考書 How Google Tests Software

* Facebook
  * 2009 FB 急速成長，在代碼部暑遇到重大問題，團隊常處於救火狀態
  * 決定讓 `所有工程師、工程經理和架構師輪班`，讓開發知道自己的系統有什麼問題和影響，進而改變開發心態和做法

### 將運維融入日常開發工作

* 創建自助服務

* Ops 融入產品團隊
  * 啟動階段就開始加入
  * 過程中逐漸知識轉移

* 邀請運維工程師參加團隊會議 `每日會議、回顧會議`

* 加入運維工作到看板流程

> DevOps 是一種哲學運動，不論從嚴謹或鬆散的定義來說，它都不是一堆工程實踐而已

> 若是要成功地實踐 DevOps ，你必須改變整個組織 `如何看待` 軟體開發的文化

> 不管組織目前走到哪裡，只要它能意識到它需走在一條` 要不斷改善` 的旅程上，這才是最重要的
