12/14 SRE 讀書會共筆
場地提供：PIXNET
- 誠徵 [SRE 服務可靠度工程師](https://gist.github.com/jnlin/8329bea1c1ed92a1924da7e032304261)，有興趣的朋友可聯繫 [e-mail]

===

# 第八章 - Release Engineering 發行工程 by wanchia (婉佳 ?)
- About
- 寫 PHP 的工程師，小公司因此也有接觸 ops 的工作。
- 發行工程是什麼
- 從頭到尾：儲存 - 編譯 - 測試 - 封裝 - 佈署
- 跨領域的事情。釋出 (REs) 與支援 (SWs) 與網站可靠度人員 (SREs) 一起定義每個階段的作法
- 專注於整個發布流程的可重複性與自動化
-

- RE 的角色 (發行工程師)
- 定義流程
- 開發發行工具
- 搜集資料來優化流程

## 四個發行工程哲學
- 自我服務模型
- 開發團隊可以自己作佈署的程序
- 自動化 Building & Release
- RE 只負責工具開發以及問題解決
- 快速
- 可以變更很少，但是整串的流程要是很快速的，以便頻繁發行
- 根據團隊需求，有不同的策略，例如每小時建置，或是 push 後建置
- 密閉建置
- 確保一一致性與可重複性
- library 使用固定版本，不依賴外部環境
- 故障時可以回溯到當初時空的版本
- 確實控管策略與程序
- 只有特定權限人員才能執行以下程序
- 批准程式碼變更
- 指定發行過程的動作
- 什麼時候建立新的版本
- 核准整合計畫
- 修改建置組態

## 持續建置與佈署，Google 軟體的生命週期
- 建置 Build
- 使用內部工具 BLAZE，輸出結果可以依照 RAPID 組態設定檔決定
- 建置成果都有標記日期與版本號碼
- 分支
- master branch 策略
- 決定整合計畫後，另開分支
- bugfix 也 commit 到 master，再 cherry-pick 到發行分支
- 發行版分支永遠是獨立的，不會被合併回 master 主幹
- 這樣的優點是可以清楚得看到該發行版是從主幹的哪裡切分出來的
- 測試
- 主幹持續單元測試
- 發行分支另外有單元測試
- 發行分支 w/ cherry-pick -> 沒有與主幹上相同的程式碼
- 封裝好的完成品會持續進行系統性的測試
- 封裝
- 利用 MPM Midas Package Manager 分派軟體到正式環境機器
- 依據 BLAZE 規則封裝產物
- 封裝好的軟體會有套件資訊
- 套件名稱
- 標籤：Building ID & other tags
- 有 namespace, hash 雜湊確保安全性, 簽章
- 佈署
- Rapid 指定標籤，Sisyphus 佈署 (?)
- 佈署流程依服務的風險承受能力而變
- rolling-update ... etc
- 開發或預備環境
- 正式服務環境

## Rapid 系統
- 設定檔，Blueprint
- 建置目標 測試 部屬規則 以及權限控制
- 自動執行發行流程
- 取得版號建分支 -> 編譯 -> 建構 -> 佈署 -> 紀錄每個步驟的結果
- 管理發行分支以及 cherry-pick 請求
- 發行過程的步驟是可以平行處理的。配合 Google 的基礎建設，一次處理數千個發行請求
- 圖 8-1

Rapid Client <-> Rapid Service <-> Rapid Build Job

## 組態管理

- 組態檔是不穩定性的來源
- Google 組態管理模型的特性
- 有版本控制
- 有嚴格的 Code Review 審查機制
## Google 組態管理模型
- 第一種：使用主幹版本，與發行版脫鉤
- 第二種：把組態檔封裝在 MPM 套件裡面
- 適用單純的組態
- 最方便，但彈性相對也小
- 第三種：另外封裝一個"組態套件"
a. 符合密閉原則
b. 組態更新只要重新建置「組態套件」
c. 組態回朔容易
d. 可利用 MPM 標籤自動取得最新版本的同名套件

- 第四種：從外部儲存空間獲得組態檔
- 適合組態檔常常需要變動的情境

## 結論
- 團隊要定義自己的 Release 程序，選用或是自己開發適合的工具鍊
- 不同職能的技術人員緊密合作
- 說服團隊，預留資源，盡早實踐好的開發流程

## Q&A
- Q1 大家是否有 deployment 的區隔？Google 應該是有強大的管理工具才能切得這麼細（依據承受能力）
- Microservice 對 Google 是必然與容易的事情
- Q2：你每次佈署要超過十台機器的舉手
- Chengwei 有些人是打包放上去，有的是用 Git 抓取差異，搞不好大家不同的是抓取差異的這個細節
- Q3: 大家的團隊裡面有 RE 這樣的角色
- jnlin: 雅虎有這樣的角色
- Rick: 以前的經驗是把 build 完成的結果燒進光碟，稱作安裝測試，如果 Build fail 今天就不用下班了
- jnlin: 我們有作 5% 跟 100% 的正式環境，如果 5% 異常就做 rollback
- chengwei: 有點類似金絲雀發布
- Q4: chengwei: 大家有在用藍綠發布, 金絲雀, rolling-update 嗎？
- Rick: 91APP 有使用前兩者
- Q5: 你們的發布流程有無不同之處？特別的設計？哪些關卡作不一樣的事情？
- Q6: 大家使用哪種分支管理
- jnlin: 我們用 GitHub flow (feature-based)
- chengwei: Gitlab flow 是所有東西要進 production branch
- Q7: 除了程式碼以外，腳本 設定檔也要作管理，大家如何作版本控制
- Levi: 我們面臨的最大問題是，開發階段往往有 code 與組態檔沒有切分乾淨
- 與會人：template 應該是所有環境一致的，根據產品指定參數套用到樣板 ; k8s 有內建一個叫做 __ 的東西，作組態管理
- chengwei: 使用 .production, .staging 這樣的副檔名管理
- chengwei: 好奇使用第三方服務管理，容易程度？
- jnlin: AWS 的 metafile，在 VM boot 時就去抓取 metafile, userdata
- Rick: 我們有些 Lamda 是這樣，例如 connection string ，加密後再去拉
- Q8: 大家公司平均一天 deploy 幾次？(jnlin)
- 我們 PIXNET 大概 50 ~ 100 次
- 以前面試一位電商工程師提到這個，他驚訝覺得這樣不會很不穩定嗎
- 他之前待的日本某某某公司一天 deploy 一次大概就是上限了
- Rick: DB schema 動很多或是資料異動很大，就不能用佈署次數來看
- Q9: 大家佈署一次花多久？
- PIXNET: 15 mins 以內
- chengwei: 10 分鐘
- Q10: 大家的 branch 管理
- 91APP: master + code review
- 與會人發問：密閉建置，我們會去網路上拉一些東西下來，大家的作法是
- Rick: 嚴格講是要，例如用 checksum 驗證才 ship。如果第三方來源被植入木馬，整包都會有問題
- chengwei: 建自己的 package server; 有次經驗是客戶趕上線，但連不到國外無解
- 以 PHP 為例，build 的過程，如果你這次 build 過跟五分鐘後的版本是不一樣的，可能會爆炸

# 第九章 - Simplicity 簡單化 by win

## About
- 我是一般的 RD，對這塊領域比較不清楚，所以我挑了頁數最少的一個章節比較容易詮釋

## 可靠性的價值只有靠追求最大程度的簡化能得到
## 軟體系統本質是動態和不穩定的
- 修改程式碼就有機會引入新的瑕疵，除非永遠不異動。

## SRE 管理系統方法的總結：
- 在靈活性與穩定性上維持平衡
- 書上提到對於撰寫探索性程式碼的問題？

## 穩定性與靈活性
- 創造流程+實踐+依賴不同種類的工具
- SRE 希望可以最小化這些工作，對 Dev 的靈活性造成最低的影響
- 如果達到這幾個特性，我們可以快速發布可靠的產品
## 乏味是一種美德
- 對 SRE 而言，最大的敵人是正式環境的「意外」
- 不希望有太多意外的程式碼或無法掌控的環節
- SRE 團隊應該：在他們負責的系統引入意外複雜度時，跳出抗議
## 我絕對不放棄我的程式碼
- 工程師都有自己的堅持，不想砍掉自己的程式碼
- 如果以後還需要怎麼辦？所以我先註解起來，將來要用就很容易
- 為何不增加一個功能開關？
- 上述都是不佳的作法，版本控制系統可以輕易的復原修改
- 沒有使用的程式碼，將成為定時炸彈
- 沒有人敢動他的程式碼，我相信會 ... 永恆
- SRE 應推崇：每段程式碼都有存在的目的的實踐
- 定期刪除無用程式碼
- 在各層級測試中增加膨脹檢測
- 建議把 (Line of Code, LoC) 當作負面指標
- 當成指標每次釋出來檢核，確保每次增加的程式碼是不會太多的
- 一次一大包佈署後若出問題較難快速定位到問題根源
## 最小的 API
- 軟體工程：少就是多

## 模組化
- 透過 API 版本化
- 允許 Dev 繼續使用他們依賴的模組版本，不一定要強迫他們跟隨更新版本，可以有更謹慎的方法來升級版本
- 各自掌握自己的進度與節奏
## 發布的簡單化
- 流程簡單化肯定好過複雜的發布流程
- 測量和理解單一變化也相對容易
- 依照更小的批次進行發不可以：
- 更有信心快速發布
- 每個變更在系統的影響可以獨立理解
- 考慮每次的變更對系統的最佳方案
## 小結
- 軟體的簡單性是可靠度的前提要件

## Q&A
- chengwei: 有在寫程式的對這章應該很有感覺
- Q1：大家都怎麼寫你的腳本？
- Dennis: 寫一段測試一段，不會當成一個系統很有架構的寫
- Q2: 大家有在用 Ansible, Chef, Puppet 這類工具嗎？
- 趨勢代表：我會用 high-level 一點，例如 Python, Node.js ，希望我的程式碼在 30 行內做得完才會考慮用 Shell Script。
- Q3: 想吐槽 Google API 很不穩定，版本變動太頻繁 (jnlin)
-
- Q4: 程式碼膨脹，真的有人在作嗎？
- Win: 我自己執行的 PHP 專案有用工具跑整體的程式碼品質，還沒有作 LoC 的 diff

# 第十章 - 基於時間序列數據進行有效報警 by 曾義格
- 導讀人缺席，用討論方式
- chengwei: 普羅米修斯似乎是目前的首選
- Q: 有在用時間序列監控的人：
- 與會人 A
- 監控 server 裡面 DB 的值
- 看每一檔廣告有多少存量
- 監控偏向 Applications layer
- 與會人
- influxDB
- 監控四大天王：CPU, I/O, 網路, ...
- 與 RD 討論要蒐集什麼資料進一步做蒐集
- 收集起來做 trouble shooting not monitor
- Afu
- sitespeed.io 開源專案
- 定時監測網頁的 resources 狀態
- e.g. js, css 有沒有一直變大 或者指標性網頁有沒有符合正常
-
- Q: 新的機器加入時，大家是如何把他們加入監控範圍
Rick: 有的自動有的手動

# 第十一章 - Being On-Call 輪值 by John

## on-call 是 SRE 團隊的重要職責，目標是確保服務可靠性
- 招募團隊時著重選拔有系統工程經驗和軟體開發經驗的人
- 重點是研發出更好的自動化與優化方法，而不是傻傻的一直在救火

## on-call 人員的一天
- 重要恢復五分鐘恢復，非重要服務三十分鐘內恢復
- 系統可用度為 99.99%，則每一季只有 13 分鐘的停機時間
- 主 on-call 和副 on-call 的配合方式，有的可能是副的處理雜事
- 我的經驗是副的只接受主的 call-help，不直接去接 ticket
- 下禮拜就交換，至少同時間有兩個人，不會說忙到掛掉，如果有第三張急單只好招喚主管

## 工作平衡
- 數量上保持平衡
- 50% 開發
-
- 25% on-call
-
- 25% 處理雜事
- 開會列入？
- 很多工作開會佔很大：日報、週報、等等
- 質量上保持平衡
- 有足夠的時間處理障礙和後續工作，事故報告
- 根源分析，事件處理，事後總結
- 平均處理一個緊急事件要花六個小時
- 一天就是兩個 ticket
- 補貼措施
- 不同公司有不同的作法
- 給錢或給假
- 安全感
- 面臨挑戰的兩種處理方法
- 被 call 到時挑戰就來了
- 依賴直覺 自動化 快速行動 ，大多數是這個選項
- 例如資料庫故障，這時候可能先讓他復原再說
- 通常都發生在你措手不及的時候

- 理性 專注 有意識地進行認知活動
- 人員重要的幫助
- 清楚的問題升級步驟
- 超出你能處理的範圍時，如何 call help ?
- 至少要查清問題的方向以便聚焦
- 處理不來時可能找 RD / DBA / Network Engineer
- 有些服務不是砍掉重啟就好，可能造成事後不完整，開與關有一定程序
- 對事不對人，允許犯錯的文化。
- 這個可能比較難，一般犯錯就會被檢討。
- 什麼都要快
- 快就容易犯錯
- 儘早修復，比較難預知會失敗
- 文化很重要，才能讓工程師去自動自發
- 作 10 件成功的事情，只錯一件就黑掉，就難以讓工程師自動自發去作
- 通常穩定的人會選擇那我就不要作就好
- 墨守成規並不會讓你失去飯碗
- 回答你「因為之前的人都這麼做就好」好像責任就釐清了耶？
- 避免工作壓力過大
- 移除不好的監控指標
- 有些是看就好，不是所有都要發出告警
- 每通告警必須是可操作的
- 減少同一事故所發出的告警 -- 非常難，假設網路掛掉，可能就發出一大波告警
- 很多告警的背後可能只是幾個原因點而已
- 和 RD 協同維運。第一線的人只能鎖定與聚焦，還是要與 RD 合作找出問題
- 極端狀況下，由開發人員維運系統
- 太平靜的生活，過太爽
- 對系統的了解度會降低，太久沒碰會生疏，出問題時笨手笨腳
- 定期輪班
- 案例宣導，類似莒光日，發生什麼事情，大家講講
- 只要有人酒駕全部開車的就會被抓去
- DiRT 備援演練 (Disaster Recovery Training)
- 通常半年或一年作一次，但確實與否就是個問號
- 預算如果有限通常會犧牲掉，慢慢的備援那塊就跟不上了
- 做到很徹底的不多
## Q&A
- Q1. 災後還原大家都有作嗎？
- Q2. AWS 怎麼辦？
與會人，GCP 代表：相信雲端
- 以前會有實體機器備援，之後都沒有了
- 可以開兩份就開兩份之類的，一定會開 HA
-