# 11/30 SRE 讀書會共筆
---

# 第5章減少瑣事 by Wnlin
(Ref: https://goo.gl/o8UBce)
- 「唯一不變的事情就是一直在改變」

## 瑣事的定義
- 可以自動化的事情你偏偏要手動作
- 隨著系統或流量規模成長的時候，而產生的零碎事情，不管是監控或告警
- 沒有持續價值的事情
- 不是很重要的事情，你又花很多時間處理
- PIXNET 案例
- VPN 去哪裡下載？
- 同事的機器（筆電）倒入咖啡
- 又有同事不小心把水灑入機器（筆電）
- 電腦很貴，防水要做好
## 為什麼瑣事越少越好？
- 軟體工程 (33%)
- 撰寫自動化腳本, infra as code
- 系統工程 (33%)
- 服務的 infra 基礎建設
-
- 雜事或文書流程 (33%)
- 預期應該要 13%
- 我們實際上 53%，其他剩下 23%
- 下班後連回來作順便兼 on call
- 我們終於用 50% 作研發的事情，但是剩下一半在做瑣事
- SRE 應該專心投入在研發以及維護

## 利用溝通技巧減少雜事
- 跟主管溝通或是同事的重點
- 講重點就好，節省 SRE 的時間
- [圖片] Ref FB 的 美食什麼見習生

## Q&A，大家覺得瑣碎的雜事定義是？
- 書裡面的定義，手動性，手動執行腳本來作一些事情，定義為瑣事
- Google 認為這樣的事情也應該要減少
- Rick: VIM 例子，往左邊刪除的方法，同事認為用 IDE 的熱鍵更方便
- afu: d ^ 可以從游標處往左邊刪除至行首
- Rick 同事：有人來問你問題，一定得思考，不能直接重複問題，難以被分類在維運或工程工作，認為這是雜事
- 正瑋: 大概像是董事長來問你說：我的手機要如何操作 OOO 這種情境
- 職涯發展停頓，造成士氣低落，一直被打斷，怎麼辦？
- 正瑋：可以使用番茄鐘 ; 但是遇到小孩子打斷還是無解
-

---

# 第六章 Monitoring System by Tim @ Droi

## 定義
- Monitoring 監控
- 分為 white-box & black-box
- white-box 系統內明確噴出來的訊息
- black-box: user 的 behavitor，我知道 user 現在做了麼行為
- Dashboard
- 讓大家更明確知道可以看到哪些東西

- Alert
- 理論上發生問題或從 Dashboard 看出異常要發出告警
- Root cause
- 問題發生根源的原因
- Push
- code 有作變更，定義為 Push

## Why monitoring ?
- 做長期趨勢的分析

- 透過監控了解系統的狀態
- 例如想要知道目前效能如何，可以設定兩種不同 path 看最後結果，來決定公司的決策
- 如果系統都沒有作監控，出事情也沒人知道，最後難以收拾
- 打造儀表板是蠻重要的事情，出問題有了地方可以去看
-

## Reasonable Expectations
- 要做合理的監控
- 當系統複雜時，需要大量的工程人員投入，不是容易的事情
- Google 一個 SRE 團隊大概是 10 ~ 12 人
- 他們希望 SRE 專注在開發層面，希望把重複或瑣碎的事情自動化解決
- 把共同的基礎建設或監控拉出去，不要讓每個團隊都做一樣的事情
- 準則，不希望有專職的人24小時盯著看，這樣很浪費人力
- 建立系統時應該簡單明瞭，不要有 Magic 系統，例如要針對門檻或指標比較智慧的發出告警
- 發生問題時 RD 要能快速地的定位到問題根源
- 希望不要有誤報，盡量保持良好的告警品質

## Sympyom vs Causes
- 什麼東西壞了？是一種 Sympom 現象
- 帶過

## Black Monitoring vs White
- 黑箱就是告訴你出問題了，白箱是有一些指標讓你作監控

## 四大黃金訊號
- Latency
- 正常跟異常要分開，例如 server 拋出 500 是很快速的，沒辦法正確呈現系統狀態
- Traffic
- 例如 RPS, IOPS 數據，By Request 去看你想要的型態，蠻具有監控的意義
- Errors
- 分為隱性與顯性
- 顯性是 http 回 404 或 500 之類有明確錯誤的情況
- 隱性的是即使回 OK，但裡面其實有 Bug，得透過 E2E 測試才能知道有問題
- 例如頁面少顯示了某個元件
- Saturation (飽和度)
- 多久可以到達上限
- 到達上限前的前指標，例如 CPU usage，到 100% 之前服務就會出問題，不能等到 100% 才發告警
- Chooing an Appropriate Resolution
- 避免長尾問題，例如想監控 CPU，每分鐘收一次資料，可能有其中幾秒使用率超級高，剩下的 5x 秒用量都不高，最後的結果會被那幾秒影響，不能代表這一分鐘的狀況
- 要考慮系統效能，是要作即時 Real-time 的，還是 Batch
- 例如要作 99.99 % ? 你不需要那麼頻繁作監控的話可以把時間拉長，增加服務可用性

- ASAP, no simpler
- 讓你的系統可預測而且可靠
- 監控的基本標準
- 不常用或沒用到的監控指標可以定期刪掉
- 訂定監控的原則
- 必須要是緊急的
- 告警出來時應該有對應的行動，不要只是看著他
- 告警的東西應該是需要人力介入的
- 瑣碎的 script 可以解決的事情不見得需要告警
- 同樣的東西不要告警多次
- 一個 symptom 背後可能有多個原因
- 盡量不要對原因作告警，而是對 symptom 作告警
- (例如 500 增加)
- Monitoring for the Long Term
- 以長遠發展為考量，才是一個好的監控系統
- Big Table 案例
- 內在有個長尾問題會發海量 alert，老闆會常來問
- Google 作法：不讓老闆看到，disable email
- Gmail 案例
- 要不要把權宜之計放進去，放的話就沒問題，可是會留下技術債
- 這是一個 tradeoff
- 盡量減少告警讓 RD 有時間去改善系統
- 結論
- 清楚簡單
- 專注在 Symptom 而不是 root cause
- 不要假警報，一定要建立 Dashboard ，才能有歷史資料回顧

- 公司案例分享：E2E Testing 之前接微信，容易壞掉，老闆會很緊張，後來作 white-box ，接 prometheus 再接 Slack，後來被老闆發現後也加入了 Slack 群組

- Pjack (Trendmicro)：E2E 是某種現象，代表使用者的行為，如果是白箱會看比較細，例如磁碟空間夠不夠。
- 一個現象背後可能有多個原因，例如硬碟滿了，或是 Process crash, I/O 太高等等
- 也可能反過來，某台機器 I/O 有問題，但 E2E 沒問題，為什麼？機器可能很多台，那你半夜是不需要起床修的
- 專注在很緊急的 Symptom，再利用 white-box 幫助你判斷找出問題根源
## 討論，你們配多少人力來處理監控，例如安排一個人24小時監控？
- Rick (91APP) 分享：盡量讓人員專注，上班時間互相支援，無法有專人作監控。原則上不固定人員，輪流。週末的操作等等
- 我們沒辦法 white-box，系統太複雜，例如今天 Facebook 驗證出問題，我們也束手無策
- 有事情能解就解，不行的話往後丟，打電話
- SRE 對商務邏輯了解有限，找可以解決的人求助，例如交易系統
- ELB 的 health 數量，如果是 1 我們要立刻處理
- jnlin (PIXNET) 分享：原則一樣，每個元件或產品有負責的 RD 團隊，無法處理就找到對的人
- Rick (91APP) 分享：業務團隊可能會一直問原因，要有人指揮，跟其他部門溝通，避免有誤解
- 熟悉現場狀況的人可以跳出來，不見得要主管指揮
- 例如 Domain Name 跳轉，之類之類的
- 正瑋：慘的是不同同事各自作不同的行動，互斥
- 新人教育訓練有經典案例分析，當下的重大問題，誰處理的，所有紀錄都有
- 某一次在山上外訓，接到告警，只好一起開車回公司
- Earou (91APP) 分享：讀完這章對我的衝擊，一個 Symptom 可能造成另一個。
- 不要貪心監控太多指標
- 要慎選指標，例如我就專看 Latency，其他的就事後分析再拿出來看
- 時間有限，一個服務十個指標都跳起來會造成混亂
- 先把現場狀況排除後事後再分析
- 正緯：大家都有建 Dashbaord 嗎？
- 大部分人都有建。
- 會擺一台電視專門顯示嗎？ 平常不放，宣傳意味大於實質意味（91 APP)
- John: 監控通常不可能都是綠燈，一定有些是黃燈，例如空間不夠。給老闆看的最好只秀綠燈的，黃燈的不要顯示
- 正緯：鬆耦合系統，大家實務上會這樣作嗎？例如有的老牌監控會所有事都做，Google 傾向多個小服務，定義出個接口
- wnlin (PIXNET): 例如我們會監控 E2E 的東西，例如 www.pixnet.net，我們只要監控 80/443 port ，跳起來時深入去看 IRC 拋出什麼錯誤導致不穩定的紅燈
- Tim: 大家越來越多人用 K8S，AWS (不確定有沒有聽錯) 的人說接下來要開源他們的 monitoring solution
- wnlin: 資料都被 Google 蒐集了覺得哪裡怪怪的
- jnlin: 用資料去交換便利性
- 正緯：有些法律規定個資不能放在第三方國家 storage
-

---
# 第七章 Google 的自動化系統的演進 by Levi Chen @ 91 APP

## 此章節的三位作者都是 SRE 主管，不同國家
## 自動化是一種力量倍增器，但不是萬靈丹
## 對力量的倍增並不能改變力量用在哪裡的準確性
## 自動化的價值
- 一致性
- 人類執行數百次相同動作時，無法保證一定是正確的
- 平台性
-
- 錯誤集中化
- 容易擴展，設計系統時間可能會很常，但是比教人快

- 我們公司帶一個人至少要三個月才能上手
-
- 修復速度更快
- 降低常見故障的修復時間
- 可以把時間花在其他事情上
- 一個問題越晚被發現，代價越高
- 聽過的趨勢案例分享：被使用者回報一個 bug，成本非常高
- 行動速度更快
- 人類不能像機器一樣反應
- 加開機器人工執行會慢很多
- 沒有自動化，系統很難長久運行，尤其google 早已遠遠超過人工可以處理的地步
- 節省時間
- 如何說服你的老闆作自動化
- 這種優勢比較難立刻被計算出來
- 一旦你用自動化風裝任務，任何人都可以執行他
- 以前參加研討會 (2015, 12) 聽到的金句：系統管機器，人管系統。
## 自動化對 Google SRE 的價值
- 高度一致的基礎建設
- 很多機器都是 G 自己設計的
- 如果 provider 沒 API ，Google 就自幹
- 看得比較遠，能自己設計未來對公司比較有幫助

## 自動化分類的層次結構
- 很少被測試的自動化系統很脆弱，因為系統不斷在演進。像是故障轉移 (failover) 可能數個月才發生一次
- 自動化演進路徑
- 沒有自動化
- 手動執行
- 外部維護系統特定的自動化系統
- 外部維護的通用自動化系統
- 內部維護的系統特定的自動化
- 資料庫自己作故障移轉
- 不需要作自動化的系統

## 讓自己脫離工作
- Google 的廣告數據存在 MySQL
- SRE 對於維護這樣的系統太簡單，沒挑戰性，所以開始想下一代的開發，把 MySQL 遷移到 K8S 的前身 Borg
- 希望帶來以下益處
- 有效利用容器化資源
- 遇到的問題
- 遷移頻率達一週數次，對 relica 是可以的，但是對 master 無法
- 每次轉移都需要花 30 ~ 90 分鐘
- 需要花大量人力處理
- 為了滿足錯誤預算 ....
- 成功後，他們在無聊的維運上減少 95% 時間，釋放 60% 資源

## 使用 Prodtest 檢測不一致的狀況
- 隨著 cluster 數量成長，一些需要手動改設定，除錯浪費太多時間
- 用 Pyhton 設計系統，針對佈署也做了單元測試
- 確保每次佈署的服務都是正確的
- Google 有機制是發現錯誤時，自動修復它

## 專業化的傾向
- 很多自動化依賴 sshd，Google 認為很不安全，因為每個人都要有 root 才能執行
- 要把 SRE 權限降到最低，透過一個伺服器，透過他來審計，追蹤誰下過了什麼指令
- 跳板機可能很多公司都有，但審計是另一個問題（正瑋）
- 你看到的 GKE 其實已經疊了四層，K8S 開發者之前到公司提到的
- 自動化作太好時，OP 很少機會接觸實際情境，如果工具壞掉，就沒能力可以處理
- 但從 Google 經驗看，自動化與自主化已經不是可以避免的選項

## 自動化允許大規模故障發生
- Google 拆除機器上的硬碟與刪除資料的過程都是自動化
- 某個程式錯誤，很不幸整個資料中心的硬碟都 earse 了
- 但他們有良好的容錯計畫，所以流量自動的避開這個機房，對使用者而言，只有增加一點點延遲，沒有損害

## 討論與分享
- 有時候連 script 設計者都忘記來龍去脈，只要執行就完成了
- 航空業有注意到機師太依賴自動降落，不太熟悉手動降落了
- 大家寫自動化腳本時，有人寫測試嗎？ (正瑋)
- arrack: 感覺會變成循環？
- playbook (Ansible ?) 的文件有建議最好也要寫測試
- arrack (PIXNET): 自動化的困擾：如果用 Google 雲端服務，會不知道是改版的影響，還是自動化腳本的問題
- 什麼東西應該自動化？ 投資報酬率 (正瑋)
- jnlin (PIXNET): 會重複用到的，例如每個月甚至每天都會作，自動化就有用。第二種是也許不是常常過，而是一個團隊很多人都會作。自動化可以事情變得比較一致，比較快，不出錯。
- Rick (91APP)：symptom 跟自動化要可以對得起來，如果不幸選錯了 ... 如果問題當下很複雜，自動化就 .... ; 沒有 pattern / 症狀模糊時，自動化不是萬靈丹。
- 正瑋: Google 寫這本書的附加價值是順便賣 K8S 跟 GCP
- jon：自動化系統變複雜後，其他人學習的曲線會增長，無法 100% 傳授，因為他沒有經歷過當時的時空背景 ; 自動化系統是基於多個工具打造，都是要學習成本的
- Rick: 三千多個 UT Case，跑下去就下班了，結果隔天來上班來看第一個 case 就失敗，停止了 ; 其他系統 300 多個 case，但有一半是假的，會 pass 但沒實質作用
- jnlin: 自動化要針對比較單純的指標，相對來說是問題根源的指標，而不是一種現象，現象背後的原因可能很多，例如 latency 變高去作一些事情，但可能沒辦法收到成效。 例如硬碟空間不夠就自動加大來緩解，就是適合的自動化應用
- Earou (91APP)：大家寫自動化程式時會先寫需求嗎？還是說直接先寫程式，別人就越不知道在幹什麼，就會不知道如何測試它，大家如何把它文件記錄下來
- 正瑋：小程式的話會把需求與註解寫在程式碼裡面
我最終的目的是把知識共享，所以會把該補的文件補完。
- Levi：我們會有小的 code review，這樣人員流動比較不會那麼痛，系統流程如何如何，從自動化腳本就知道事情
- jnlin: 有沒有同事很討厭寫文件？各位如何解決這個問題
- Rick: 我們的案例是會寫但是寫出來的文件別人看不懂？
- Rick: 我寫 script 的原則是 follow Linux 指令設計哲學，不知道怎麼下就輸入程式名稱，會吐出基本的範例，最小單位的範例一定要可以跑
- Pjack (Trendmicro)：我覺得要每個人做到這件事情很難。Python 網站上面看到一個工具，叫 clime, 可以幫助寫出有統一風格且好用的 Script
- https://github.com/moskytw/clime
- 註解即 Command line 的 help
- 功能模組化, 可以一直重覆利用