# DevOps Handbook ch16 **Enable feedback so development and operations can safely deploy code**(en) 应用反馈实现安全部署(zh-cn) 啟動回饋機制，安全地部署程式碼(zh-tw) --- ## Table of Contents 1. 開發跟維運的最大共同點 2. 當全世界一起 oncall 3. 讓開發團隊參與觀察使用者行為 4. 把 Ops 的名稱改為 SRE --- ## 開發跟維運的最大共同點  ---- ### 全自動化佈署只會讓開發更恐懼 **~~因為再也不能甩鍋給維運~~** ---- ### 夜不能昧 佈署之後幾天之內都害怕被老闆叫起床尿尿 ---- ### 問題不一定會馬上反映到客戶端 當接到電話時可能為時已晚，DB 資料全髒 ---- ## 解決方案：自動化監測的重要性 1. 早期發現，早期治療 * 最小化佈署可能對 value stream 造成的傷害 2. 在放置測試階段就顯示問題 * 從測試階段就可以觀察運作情形 3. 在客戶發現前就及早上 Fix 大家就不用背鍋 * value stream 不中斷 4. 給大家勇氣按下佈署 * 讓團隊佈署後也能一夜好眠 5. 快速了解運作情形 * 可快速定義何謂正常，何謂異常 ---- ### Summary 問題：大家害怕佈署後可能爆炸 方案：用自動化監測讓大家可以及早發現及早治療 **This ensures that the services are production ready even at the earliest stages of the project.** ---- ### Extra By DevOps expo * All change should less than one page * Pull more engineers into one change * Let failure been rollback before your CTO found it * Rollback should be automatically * Dev&Ops should use the same tooling --- ## 自動化監測的 Case study ---- ### Case study : Etsy 一次佈署的 php 代碼有問題  ---- ### 自動化監測帶來的好處 1. 快速發現問題 * 佈署後三分鐘內就發現狀況 2. 團隊溝通更順暢 * 大家可以看圖溝通，了解問題 3. 快速確認問題解決 * 看圖確認上 hotfix 之後問題解決 ---- ### 補充：先決條件 1. 鼓勵大家佈署之後要記得看 Metrics 2. 自動化警告通知 --- ## 當全世界一起 oncall 本書鼓勵全部參與過 value stream 的人都要 OnCall 上從 VP, Architect, Manager.... RD & OP 出事全部的人都要立刻一起起床尿尿  ---- ### 凌晨2點修 Issue 效果特別好 書上說 > 我們發現，當凌晨2點請開發人員上線一起修復故障時，問題解決的速度要比以前快得多。 沒有證據沒有數據沒有比較的廢話  ---- ### 為什麼我說這是廢話 來投票一下，今天 2 a.m. 時在座的各位全部被叫起床了，因為新上的功能噴了個 P0 好像沒在動，這個時候有兩個選擇。 1. 開始認真討論分析能不能在 10 分鐘內上 hotfix，再花 10 分鐘觀察 Metrics 的狀況來確認服務恢復正常。 2. 找個人按下 rollback。 ---- ### Summary 1. 所有參與 value stream 的人都要 OnCall ~~交了這個 commit 你就是我們的人了~~ 2. 臨晨開會效果特別好 > 但我認為這只是因為臨晨兩點並不會有人想思考，只會丟出一個最簡單最快的解決方案，但這並不一定是最佳解 ~~最近我前公司正在實踐這塊~~ --- ## 讓開發團隊參與觀察使用者行為 建立同理心，知道客戶需要的是什麼樣的功能 就更能專注在開發「對用戶有 Value」的產品 ---- ### 對做 Service 的我們可以有什麼樣的改進空間 以下列出一些個人想法 1. 可以向下了解一下接我們 service 的團隊覺得我們提供的 API 有什麼雷? 2. 他們最常叫的是哪一隻 API，為什麼? 3. 如果開發時能多個 API 他們會希望是什麼 API? ---- ### Summary 1. 用開闊的胸襟持續接受 Feedback 2. 有同理心的思考怎樣的服務對方會比較好用和方便。 --- ## ~~把 Ops 的名稱改為 SRE~~ 新增一個叫做 SRE 的職位，並且參與 design 與 commit review，只有審核過的才能上線，一旦上線出問題就是 SRE 背鍋，就是接 Ops 工作的 Dev  ---- ### SRE 帶來的改變是什麼 還記得前面有一章是「讓 Ops 參與開發的會議」 我認為這是結合了這種個方向，並且賦予參與會議的 Ops 職責跟權限 ---- ### SRE 要做什麼 1. 以一個將來要背鍋之人的身分參與及審核 Design * 審核 Design 出來的 service 有沒有辦法在線上滿足需求 * 審核 Design 出來的 alert level * 審核 Design 出來的上線流程 * 審核 Design 出來的監控指標及覆蓋率 2. 以一個將來要背鍋之人的身分 review commit * 審核 commit 是否符合 Design * 審核交付的 service 是否符合 Design ---- ### Service Handback 指一個服務在交接給 SRE 一陣子之後，如果有要特別修改的部分會在回傳該部分給 Dev 團隊，讓 Dev 有時機~~全部重構~~了解線上狀況，解決技術債，建立同理心。 過大概六個月左右再交接回 Ops ---- ### Service Handback Process <img src="https://i.imgur.com/gTP1nck.png" width="70%"> ---- ### Case study : LRR & HRR 一種上線交接流程 <img src="https://i.imgur.com/ciQZq8R.png" width="70%"> ---- ### LRR & HRR 差別 在 LRR 的時候 SRE 只~~動嘴不負責~~，提供 Dev 線上維護的建議和改進方向，等到六個月之後 HRR 過了 SRE 才接手 ---- ### Summary 1. 可以新增 SRE 當 Dev & Ops 之間的橋樑 2. 讓服務的維護責任在 Dev & Ops 之間輪替，建立同理心 > 所以 google 也不會去做上面說的所有人一起 oncall 這種事 > ---- ### Extra 話說維護責任在 Dev 身上時，Ops 該做啥？ 還是說 google 採用的是 ops pool 的概念，當 handoff 一個 service 出去就可以再接一個這樣？ --- ## Conclusion 1. 追加自動化監測 2. 讓開發團隊觀察用戶使用狀況，接受 Feedback 3. 新增 SRE 作為 Dev & Ops 的橋樑 4. 讓維護責任在 Dev & Ops 之間輪替，建立同理心