SRE 實踐與開發平台指南：從團隊協作、原則、架構和趨勢掌握全局，做出精準決策

【專業推薦】
「本書就像教科書一樣，包含了所有你必須知道SRE領域的基礎知識，涵蓋完整且紮實。而在此同時，本書也像成功人士的傳記一樣，記錄了作者的作法及如何邁向成功的祕訣。」

—技術部落格「安德魯的部落格」作者 | Andrew Wu

「本書乍看是在談論如何實踐SRE，實則深入探討了能幫助團隊和組織運作順暢的各種架構和原則。不論你是不是SRE，只要你仍是IT與軟體圈的知識工作者，你都應該與團隊一起結伴細讀這本能幫助你們學習Complete Think的好書。 」

—DevOps Taiwan Community 志工 / 前Organizer | 陳正瑋（艦長）

「業務引領著技術發展，技術支援業務的運行。若要看見業務運作的真相，那麼你應當擁抱多元利益關係人，了解他們的需要與困難，進而完善可靠性工程任務。」

—亞馬遜網路服務有限公司 資深解決方案架構師 | 高翊凱（Kim Kao）

「本書中含括維運線上服務所必須知道的各種知識，你不需具有N年的從業經驗，只需透過SRE，就可以快速釐清自己該怎麼解決當前遇到的問題，幫助SRE在維運服務的路上撥雲見日。」

—MaiCoin Head of SRE | smalltown

【本書特色】

全台第一本結合實務與趨勢SRE專書！
全方位說明軟體工程的三體問題、四維思考

♚維運難題應對策略：針對真實維運與協作深度分析與策略
♚維運事件有效協作：事件管理在組織與團隊裡的協作方法
♚開發與維運標準：為自動化立下憲法標準，找到真實的價值
♚SRE邁向產品化之路：解密開發平台的設計思路與架構實踐
♚各種企業階段的維運思路：不同規模的維運團隊佈局與策略

【內容簡介】

[(產品開發團隊+維運團隊)×產品線×系統服務] ×企業階段(t)

本書從最實際、最真實的維運問題開始，例如：「維運的價值是什麼？SRE只能拿香蕉嗎？維運團隊該跑敏捷嗎？該值班還是待命呢？」等常見且務實的問題，接著介紹如何讓開發與維運之間有著明確且標準的介面，提供更實際且真實的經驗，搭配大量的看圖說故事的方法，讓人力匱乏的狀況之下，穩定且有章法、有策略地往前進，並引導讀者如何看清一個局，協助團隊往適當的方向前進。最後，作者以SRE與架構師的角度，用軟體工程與架構設計的系統性思維，討論如何設計內部開發平台及產品化的思路。

【本書精采維運論點】
✪SRE會包山包海的「稀缺資源」，卻只能獲得香蕉嗎？
要會架構設計、部署應用程式、監控系統建置、值班、On-Call，很稀缺但薪資水準卻讓人覺得不如歸去嗎？

✪星期五不應該部署嗎？
這是業界不成文的共識，為了減少部署事故，因而週末加班，出發點是風險管理，但也有人認為應該可以在任何時間部署，兩派誰是誰非？棋該怎麼下？

✪維運團隊該用Scurm、Kanban、Waterfall嗎？
現代軟體開發有很多框架，SRE一半的時間在開發、一半在維運，應該用哪個方法？

✪大樓理論
SRE處理現場問題，須精準掌握系統架構，而描述架構的方法從生活中就可以找到。軟體架構的概念源自於建築業，直接類比於建築是最直覺的。

✪平台工程標準化
應用程式都有兩種層次介面，一是給使用者的公開介面，如Web API、標準函式庫；另一種是團隊看到的內部介面，如Config、CLI，只有標準化才能產生效率。

黃冠元（Rick Hwang）
軟體開發者、音樂愛好者，擁有超過20年專業軟體工程經驗、10年主管經驗，曾任翔威國際駐IBM資深軟體工程師、Oplink SQA Manager / SDET Lead、91APP Operation and Infrastructure Manager / Architect，且2021年獲得AWS授予「Community Hero」榮譽稱號。

專注分散式系統架構設計、系統分析與設計、軟體測試、AWS、DevOps、SRE、經營管理等領域，著有技術部落格「Complete Think」、共同著作《軟體測試實務》、《分散式系統設計》（譯著）。

工作之餘，喜歡金庸武俠、科幻小說、經典文學、哲學、人文藝術，同時也是音樂愛好者，涉略涵蓋吉他、鍵盤、編曲、教學，著有音樂部落格「喝咖啡聊音樂」。

✪技術部落格「Complete Think」：https://rickhw.github.io/
✪音樂部落格「喝咖啡聊音樂」：https://www.gtcafe.com/

Part 01 真實世界的普遍問題
|Chapter 01| 維運團隊的普遍現象
1.1 現象：招募傳統維運工程師做SRE的工作
1.2 現象：自動化其實是個錯覺？
1.3 現象：維運需求與價值的選擇
1.4 現象：SRE會包山包海，卻只能獲得香蕉？
1.5 現象：星期五不應該部署？
1.6 本章回顧

|Chapter 02| 維運時間殺！SRE需要制度！
2.1 制度：為何而戰，談需求與價值
2.2 制度：讓維運團隊自主運作的制度框架
2.3 制度：維運團隊該用Scurm、Kanban、Waterfall？
2.4 制度：值班還是待命？
2.5 本章回顧

|Chapter 03| 團隊的介面，合作共創
3.1 溝通介面：時間在哪，成就就在哪
3.2 介面：Go Live
3.3 介面：SRE需要負責部署？
3.4 介面：版本管理
3.5 本章回顧

|Chapter 04| 事件管理
4.1 讓組織對異常事件有一致性的理解
4.2 計畫中的事件
4.3 非預期事件與異常處理方法
4.4 從失敗中學習：訓練與事件報告
4.5 本章回顧

Part 02 開發維運治理
|Chapter 05| 系統架構之大樓理論
5.1 大樓理論
5.2 描述架構的具體方法
5.3 本章回顧

|Chapter 06| 服務治理
6.1 服務目錄
6.2 定義與實例
6.3 服務類型
6.4 服務範圍
6.5 本章回顧

|Chapter 07| 軟體交付的四大支柱
7.1 產出物：軟體交付的基礎單位
7.2 環境建置
7.3 應用程式配置：軟體的內部介面與依賴反轉
7.4 交付流水線
7.5 本章回顧

|Chapter 08| 觀測與監控
8.1 觀測、監視與控制
8.2 設計指標
8.3 服務健康
8.4 本章回顧

Part 03 開發平台與平台工程
|Chapter 09| 開發平台：設計概念與整體藍圖
9.1 以終為始
9.2 使用者介面
9.3 系統架構
9.4 本章回顧

|Chapter 10| 平台工程：服務標準化
10.1 應用程式標準化：生命週期
10.2 由外往內的標準化
10.3 開發樣板
10.4 本章回顧