# 2018/4/12 SRE 讀書會共筆
----------

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

# Ch 27 可靠地進行產品的大規模發布

## 發布本身就是一個考驗

- Deadline 固定了
- 大規模的宣傳行銷活動
- 數百萬的人群
- 集中的流量

## 發布協調工程師：發布的諮詢團體

- 由 SRE, OP, Dev 組成團隊
- 審核新服務與內部流程
- 團隊成員是發布過程中各單位的聯絡人，與其他單位合作
- 監控發布進度與處理技術問題
- 確認發布的安全性
- 培訓與建立更好的發布機制

## 需要特質？

- 廣泛的經驗
- 跨職能的視角：從行銷、業務、地區的角度來看事情
- 客觀性

## 開始建立發布流程

### 好的發布流程

- lightweight：不耽誤開發時間，越短越好
- Robotness 強健性：避免發布中斷
- 完整性：可以追蹤紀錄
- 可擴展性：可以擴展到更大的
- 適應性

以上很多都是相互衝突的目標，所以需要取得平衡

- 簡化
- 高度訂製
- 保證通用路徑快速完成：可以模組化去完成

## 發布檢查列表

- 預想發布可能遇到的問題，並預想解決方案
- 從之間發布的問題作為經驗
- 必須具體可行

## 推動融合與簡化

- 通用發布的流程
- 每次發布流程當中有回饋機制
- 相同問題能否自動化＆簡化

## 當面對發布未知的產品

- 全新的檢查列表
- 有經驗的團隊或相關領域的專家
- 問題的目的是否緊扣產品的設計

## 檢查列表怎麼做？

- 架構與依賴
- 環境配置
- 容量規劃
- 故障模式
- 客戶端行為
- 流程與自動化：常見的流程需要自動化
- 開發流程
- 外部依賴
- 發布計畫

## 可靠發布所需的方法論

- 階段性發布
- 金絲雀發布
- 逐步增加以確保可靠性
- 功能開關框架
- 能作不同對象作發布
- 能作階段性發布到一定數量的用戶
- 能根據不同向量的訊息，讓不同的 server 處理
- 能自動應對新的程式出現的問題
- 能快速關閉功能，或回溯改變的部分
- 度量每個改變對用戶體驗的影響
- 應對客戶端濫用的行為
- 重複呼叫的延遲或停止
- 隨機性
- 客戶端配置文件
- 過載行為與壓力測試
- 衡量上線後有多少流量

## LCE 發展
- 工作越來越複雜
- 發布的守門人

## 檢查列表的變遷
- 越來越多
- 越來越複雜

## 仍面對的問題
- 擴展性要求更高
- 增加維運壓力
- 基礎設施的改變

# 討論

* 正瑋：大家有沒有 LCE？（笑聲）那表示沒有
* 正瑋：那有沒有上線檢核表？有，那可以分享一下檢核的標準嗎？
* 冠維 (91APP)：檢核表與時俱進，例如以前沒有容器化，後來容器化了，檢核表要重作
* Rick (91APP)：架構上有哪些角色？角色跟哪些角色講話？是外對內或內對外？把 Elastic Search 直接對外不好。在架構 review 的時候要 senstive 到。如果對外的架構需要 Token。
* Rick (91APP)：畫圖是用來溝通的，留下來再作整理。
* 瑞男（PIXNET）：會對 CDN 檢查，開發的時候不會用 CDN，上線的時候會使用
* 正瑋：組態檢查的意思
* 與會人：會作安全性檢查、確認是否有單點故障
* 正瑋：大家覺得 LCE 需要哪些經驗？
* 小明：之前在 gamebase，有一個人LCE做的很好，因為他上線前會 review code，有 Power，規定下去大家必須要遵守
* 正瑋：大家有沒有跟發布的意外經驗？