# 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 ，你必須改變整個組織 `如何看待` 軟體開發的文化

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