# 1/11 SRE 讀書會共筆 / 第十六章 ～ 第十八章

---

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

# 第十六章 - 跟蹤故障 by 曾義格 (正瑋代打)

## 可靠性
- 可靠性的基礎是建立在一個 baseline，並持續的追蹤

- 有持續性的追蹤，可以累積事故的資料，進而有系統性的案例學習以及事後檢討
- 事後檢討通常是針對某一個單一重大事件
- 平日的瑣碎事情也不要放過，避免只抓了大魚，忽略小魚

## Escalator
- 警報閒置沒人處理的話，升級通知更多的人

## Outalator
- 例如 Dashboard ，集中警報事件彙整在一起，在單一工具管理

## 故障追蹤工具需具備的特性？
- 聚合：工具應有能力消除重複警報，以避免重工
- 標籤：資訊的分類，方便下一位人員迅速進入狀況
- 分析：有每日每週每月歷史數據，根據數量層面分析，是否有誤報等等 ; 根據時間軸分析趨勢 ; 容易作縱向或橫向的比較，比如跨團隊/跨服務去比較，可能某團隊的誤報較多
- 報告與公告：寄發 email，有助於後人工作交接、review，看見全貌

## 意外用途及好處
- 可以把高權限使用者設定為是某種警報，登入時被記錄下來，藉此知道他們的足跡
- 自動化任務的軌跡，例如自動化升級
- 可以手動建立問題與問題的關聯性，把警報與故障建立連結

## 討論
- jnlin: 大家實際用的追蹤工具是什麼？例如都自己開發或使用開源軟體
- 正瑋: 例如 issue tracking 工具 ?
- jnlin: 我們沒有，用比較傳統人工方式在做，用 issue tracking 在做，比較費工，所以好奇有沒有自動化的解決方案
- Rick: 去年有實驗，但作不起來，把 CloudWatch 串 Redmine，一早睡醒就炸了，警報太多（有 event 就自動開 ticket)，超過門檻就爆了，數千個。
- 已經根據 Alert 產生
- 與會人 David (灰色上衣)：用 CloudWatch 串 Jira ，自動開 ticket，後來就沒有使用了，僅止於概念驗證
- 與會人 (墨綠色上衣)：我覺得是 Google 系統龐大到需要長期追蹤各種事件才會這樣作
- 正瑋: 資訊量太大，人無法好好處理
- Rick：應該回到需求面，後面有個團隊需要這東西作些事情才作
- 與會人 (墨綠色上衣)：我覺得串得到 Slack 讓手機收得到通知就可滿足需求了
- 與會人 David (灰色上衣)：我們之前會做是源自於客戶要求
- jnlin: 有公司會作每週每月的故障分析數量這種東西嗎？
- 與會人 (墨綠色上衣)：我們公司會有，寄出來給團隊參考，今年發生多少問題，跟其他團隊比較相對高，就會提高注意

# 第十七章 - 測試可靠性 by Arrack
- 「如果你沒有測試過某個東西，他一定會掛掉，你一定要假設他會壞掉」

## 軟體測試類型
- 傳統測試分三種
- Unit Tests （金字塔底層）
- Integration Tests
- System Tests (金字塔尖端)
- 冒煙測試
- 早期製造業在做管道的時候，想知道有無隙縫，就把煙灌進去，如果有隙縫，煙就會冒出來
- 性能測試
- 生產環境測試，也分三種
- 配置測試，我們自己沒經驗
- 壓力測試，例如 Google GKE YAML 檔
- 我們曾經遇到 container 的值比線上的還要大，就會炸掉
- Apache AB
- 金絲雀測試
- 隨機抽樣檢查，導流量
- 公式的概念類似比例越高出錯機會就越高
### 建立測試環境
- SRE 的夢想：專案開始就在，現實通常是到中途才被抓進來
- 用最小力氣得到最大收益：例如優先對購物車寫測試，核心 API 等等
- 把遇到的問題寫成測試案例
- 要建立一套良好的測試基礎建設
- 增加持續建置的系統，每次程式碼異動都做建置
- Jenkins
- PHP
- 當異常時，負責的工程師應優先處理，否則持續擱置可能衍生更多問題
- 定時建置失去意識：Jenkins 第一天建置失敗會很緊張，沒有當下修好的話，之後幾天就麻痺了
- 緊急發布能力受到嚴重影響
### 大規模測試
- ~~(場地線路中斷)~~
- 進行容量規劃
- SRE 工具有兩個特點
- 副作用是在良好的測試過的主流 API 範圍內
- 由於現存的驗證和發布流程，這些工具基本不會對用戶造成直接的影響
- 針對危險性高的軟體設立防護等級
### Testing Disater
- 災難恢復工具都設計為離線，主要作這些事情
- 可紀錄狀態
- ...
- 修復後應該要 100% 不可重現
- 如果多試幾次就會重現，那問題可能比想像的嚴重，可針對性的升級優先程度和嚴重程度
### 對速度的渴求
- 針對感興趣的情境設立假設，需要對所有場景同時進行估算
- 工程師比較關心他的程式碼是否有預料之外的 race condition

### 發布到正式環境
- 在 SRE 模性下，測試與生產環境分離，可能導致難以重製生產環境的問題

### 允許測試失敗
- 早期軟體是每年發布一次，例如 office，每次的修改相當多，上次更新的可靠度數據對下次來說沒有任何意義
- 就 Web 而言，你可以快速的測試，快速的失敗
- 發布之前，對文件的修改要等待發布測試完成
- 提供一種應急機制，可以在尚未測完就發布佈署

### 整合
- 使用現成語法比如 YAML 降低撰寫配置的時間成本
- 當一個工具出現異常時，要對他有足夠的信心，變成負面循環，沒有任何系統可使用
- 確保某些測試可以冒出問題
- 發現問題的時候僅通知 勿自動修復

### 正式環境探針 (Probes)
- 測試機制是通過提供確定的數據驗己案系統行為是否可以接受
- 可以將錯誤請求類型分類：
- 已知的錯誤請求
- 已知的正確請求，可以重製
- 已知的正確請求，不能重製

### 小結
- 寫測試是投報率高的手段
- 建議推行寫測試的文化，我覺得蠻困難的

## 討論
- 正瑋: 這章跟你在看的軟體測試是相同的東西，有一段金絲雀測試的公式，有人可以解釋嗎？ "CU=RK"
- Arrack: RD 要有強制寫測試的觀念是蠻困難的
- 正瑋: 自從接觸測試之後，得到的最大感想是，測試提供安全防護，你可以信任你的程式碼是安全沒有問題。 不管是程式碼本身，還是基礎建設，配置等等，其實許多環節都需要測試。
- 正瑋: 出一個包就補一個測試
- Arrack: 我們公司有作這樣的事，例如寄信有詭異的 bug，就把他寫成測試案例
- 有的 RD 對這種事抱持信仰，一定會去作，有的以時程優先，壞掉就壞掉讓他放在那邊
- Win: 我們開發初期會先進 QE 人工去測，這時期的 bug 就很值得寫測試
- Win: 我們有個專案覆蓋率高達 9x%，可是最近改需求就發現很痛，同時要改架構功能與測試，就變得雙倍甚至三倍時間
- Arrack: 主要是他這個沒辦法變成你的 KPI，因為老闆看不到，可是某個專案沒寫測試，一天到晚出包，可是很快就改好了，他 KPI 就很高
- jnlin: 所以可以用修 bug 的速度當作 API
- 與會人 fripig：我們公司目前沒有自動化配置，要除錯就要先配置很久
- 正瑋: 我們對於 VM / container 的使用方式與看法相較於以前，在照顧伺服器比較多當成畜生看待。你是照顧一隻寵物還是一隻牛，牛死了就換一隻。 如果是一個需要精心照顧，上面有許多配置的機器，你要作測試就很累，可是如果是取代性很高的就輕鬆許多。
- 正瑋: 怎麼測得快又測得好是很傷腦的事情
-

# 第十八章 - SRE部門中的軟件工程實踐 by Raix

## Google 幕後軟體工程實踐
- 許多不為人知的軟體來自 SRE team
- 正式環境是人造最複雜的系統之一
- 有豐富的運維經驗，適合開發內部工具解決問題
- 開發的工具也是一個完整軟工項目
- 制定未來發展方向
## 為什麼軟工對 SRE 很重要
- 複雜度太高需要自己開發
- SRE 非常適合以及有效
- 需要設計出實現大規模佈署與災難處理，以及容易與基礎建制整合的工具
- SRE 是工具直接使用者，了解開發重點
- 容易獲取直接和高品質的使用者回饋
- 團隊大小不應該與用戶服務規模比例成長
- 以 Google 的使用者數量級，這樣團隊就得擴張到幾百萬人了

## Auxon 案例分析
## 傳統的容量規劃方法
- 蒐集未來專案需求的預測
- 根據擁有的數據來計畫明天
- 預測長度一般是幾個季度到幾年
- 制定資源的採購和分配計畫
- 如何最好的滿足未來資源需求？
- 需要在哪裡建構多少資源？
- 評審並且核准此計畫
- 計畫合理嗎？
- 是否符合產品的期望？
- 佈署和配置對應的資源
- 哪些服務最終會使用？
- 如何把資源合理分配？

## 傳統規劃方法的缺點
- 不可靠
- 出現效率衰退的問題，被逼著開更多機器來滿足業務需求
- 或是用戶需求增加，例如行銷案成功，出現流量高峰，導致資源也隨之增加
- 新的計算叢集或資源限制導致上線推遲
- 產品的決策變化（備份從一份增加到多份），導致資源需求大幅成長
- 事倍功半
- 蒐集足夠的數據以預測未來的需求是很麻煩且容易出錯
- 把帶有限制的資源請求與實際可用資源進行結合也是麻煩的過程
- 使用的工具時常不可靠或是很難用
## 解決方案：基於意圖的容量規劃
- 列出你的要求，不要拘泥於具體實作細節
- 把服務的依賴和資源的參數用程式設計的方式記錄下來
- 使用演算法自動產生資源的配給方案
- 好處
- 由電腦自動處理可以節省大量人力
- 服務負責人員可以專注在更高級的目標，例如要服務多少萬人用戶，回應時間要在幾秒以內，達到更高的計畫精確度，最後降低成本
- 提供更高...
- 意圖是服務負責人對如何維運的一個理性表達
- 1) 我需要 50 個 CPU 資源，必須在集群 X,Y,Z 中，為了服務 Foo 使用
- 具體的資源請求
- 為什麼需要這麼多資源？一定要在指定的集群中嗎？
- 2) 我需要 50 個 CPU 資源，必須在地理區域 YYY 任意三個集群中
- 增加自由度了，仍然沒有回答到為什麼要三個集群
- 3) 我想要滿足 Foo 在每個地理區域的需求成長，同時保障 N +2 冗餘
- 有了更多自由度，同時更好理解
- 4) 我們想要把 Foo 以 99.99% 的可靠度運行
- 最大自由度，當容量得不到滿足的後果也最清楚
- Google 最常使用第三個表達方式

## 表達產品意圖的先決條件
- 依賴關係
- 服務依賴的其他服務和基礎建設會影響位置的決策
- 效能指標
- 服務需要多少計算資源來服務使用者？
- 優先級

## Auxon 架構圖

## 需求和實現：成功與不足
- Auxon 起源於一位 SRE 與一位技術專案經理
- 任何一個複雜的軟工專案都會遇到一定程度的不確定性
- 不要過於關注完美的解決方案，尤其是問題還不夠清楚的時候
- 應該更快的發布與迭代
- Auxon 一開始先建構簡單的邏輯來處理資源分配，讓團隊更有實際的體感
- 不確定性不意味專案無法推進，可以促使開發更具備通用與模組化的軟體系統
- 經過很多很多次的發布與迭代，逐漸形成一個產品的模樣
- 要確保提供的解決方案有真實的使用案例，在開發的時候才會一直有一個真實可解決的問題，知道可行與否

## 提升了解程度，推進採用率
- 不要低估人們對產品了解的難度
- 別人跟你推坑使用工具時都會有抗拒感
- 向大型團隊推廣內部軟體工具需要以下幾點：
- 持續和完整的推廣方案
- 想辦法得到使用者擁護你
- 拉到資深工程師或是主管的背書協助，有助於接下來的推廣
- 如果解決方案使用起來太困難，SRE 就會自己開發，不要用你的
- 設立期望值，給產品設定一個最小成功條件，或是 MVP
- 辨識合適的目標族群使用者
- Google 內部有些團隊已經使用別的解決方案，用得好好的也不會想要採用你這套還在開發中的軟體
- 初期目標是沒有容量規劃流程的團隊
- 早期的成功案例會變成工具的推廣者
- 提供這些用戶協助，想辦法幫助他們更好的使用工具
- 在適合的層次上進行設計：不可知性，你不知道他們會怎麼去使用你的軟體，確保他們不管有什麼類型數據都可以採用 Auxon
- 盡量避免落入 100% 採用率的陷阱，一直想著要達成的話你可能要付出非常多成本，不同的客戶需求一發過來就滿足，最後可能兩邊都不滿意

## 團隊組成
- 最好的團隊是合併通用型人才和領域專家
- 例如與統計分析部門合作
- 通用型人才可以快速開始工作
- 資深領域專家提供知識和經驗
- 多樣化團隊可以避免設計盲點

## 在團隊培養軟工風氣
- 什麼因素使 Auxon 可以演化為一個長期軟工專案？
- 相關領域專家表示興趣
- 技術力很強的用戶群體
- 提供足夠明顯的優勢，可以明確減少 SRE 瑣事，優化既有的基礎建設
- 跟組織發展的目標是一致的
- 哪種專案不適合？
- 同時改變太多架構或元件
- 要求全部都有或是全部沒有的上線方式，風險太高
- 目標太大或是太抽象，沒有足夠的實際案例來證明可行性
## 招募和開發時間
- SRE 通常是通用型人才
- 廣度優先學習方式讓 SRE 對全局知識掌握
- 但缺少產品討論和挖掘需求的經驗
- 結合對使用者需求經驗豐富的 PM
- 更好培養一個兼顧開發和實戰經驗的份為
- 確保專注、沒有干擾的開發時間
- 內部的主要軟體專案都是從一個小專案開始，並非一開始就有遠大目標
- 停留在某個工程師的草根項目，在業餘時間開發
- 通過某種正式內部管道成為正式專案
- 從主管層獲得可，擴展成一個完整的軟體開發產品
## 如何達成這一點
- 建立並且宣揚戰略目標非常重要
- 此軟體持續性的產生加速作用
- 減少同樣任務的執行方式
- 評估組織的能力
- 需要找人來彌補團隊中缺少的角色和技能
- 在 Google 通過內部招募人才是最好的策略
- 不斷發布與迭代
- 別降低標準
- 想辦法抵抗走捷徑的誘惑
- 問自己如果是其他團隊開發的，你會不會想此用
- 可靠度很重要 (五個 9 ?)
- 用戶不滿意就不用了，你就沒辦法提升產品的佔有率
## 結論
- 成功和失敗的產品項目是為了以後的項目鋪路
- SRE 驅動的軟體開發專案對公司建立可持續的維運團隊是很有幫助的
- 不斷開發工具來簡化流程，或者是自動化
- 不需要隨著服務規模呈現線性成長
- SRE 花在軟體開發的經歷最終會對整個公司團隊以及個人得到回報

## 討論
- 與會人 (jnlin 左手邊): 雲端都有 Quota 需求，在 AWS 會長什麼樣子？GCP 會問你一系列問題，應變流量成長
- Google 真的會問你一系列問題，像是作用是什麼，為什麼要開那麼多
- GCP 會讓你資源慢慢的增加，讓你增進可以使用的資源
- 與會人 "GCP 代表" (墨綠色上衣)：分享 capsity planning ：實體機年代你可能很在意，但在 VM 年代，so ? 信用卡刷下去就對了 到 container 又更不重要，你可能只是開個 200MB 的 container 出來，丟上去，像 AWS EKS 就可以讓你不用浪費太多錢。老闆問的話可能只想知道每個月大概的數字支出
- 與會人 "GCP 代表" (墨綠色上衣)：我們會作 Cost Review，解釋年度成長量是否正常，是否預期。 他們會以為最多的錢花在開機器，其實不是，是花在每天儲存太多 Log (數 GB) -- 把所有 HTTP Request Header 都印出來了， S3 每個月的支出就佔總成本的 30%，這是不合理的事情
- 作 cost review 可以發現 RD 在設計沒有考量的點 ; 前人都承襲前前人開 C4 大絕，但其實 M系列就夠用了。
- john: 我們公司有句話：前人這麼作一定有他的道理，不要自作主張
- john: 容量規劃部分，一方面的壓力來自財務，他們那邊不能很含糊，一定要有個數字，他們每年定期要作財務規劃，要花多少錢等等。 講太多細節又會被砍，變成攻防戰
- Arrack: 習慣是很難改變的，我們在內部登入系統做了一鍵登入，上線後使用比例還是 50%，後來去詢問同事才知道很多人瀏覽器都紀錄了帳號密碼，另類的一鍵登入