本文整理 SRE 讀書會 Round 2 的討論與筆記。問題是：

團隊 Release 的角色是否應該專職？ (不管是叫 DevOps Engineer, Release Engineer, or SRE)

那天 (2018/09/13) 討論的章節是 第七章 提交階段，我在回程公車上寫下這段 筆記，重新整理成文章，也補充一些想法。 這問題討論通常到最後會分成兩種：

• 不該專職：團隊成員輪著做，不應該專職 (偏向 Agile 的概念)
• 應該專職：技術 know how 很深，應該專人專職 (偏向傳統、大型組織)

我想想都對、也都不對，因為這兩個都沒有提到 前提條件與背景，這樣的討論不會有結論。我從以下幾個面向分析：

• 企業階段
• 架構與組織
• 產品特性

Updated 2023/07/19: 本文收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市

本文整理 2018/12/07 我寫的一篇論述：DevOps 8 字環的誤區。

整理 AWS CTO - Werner Vogels 著名的論文: Eventually Consistent (ACM), (Blog) 重點與筆記。

整理 IPv6 的基本概念。2016 AWS VPC 支援 IPv6 之後，就沒在研究相關課題，只大概做過一些資料。

我心裡一直有這樣問題：

AWS 有些產品用 Amazon 開頭（像 Amazon EC2、Amazon API Gayeway、Amazon CloudWatch），有些則是用 AWS 開頭（像是 AWS CloudFormation、AWS Lambda、AWS IoT），如下圖：

底下整理我對於命名前置詞命名的猜測。

今年 (2018) 三月，我在公司內完成長達半年的 SRE (Site Reliability Engieering) 讀書會，快結束時就在盤算下一本候選書，希望激盪團隊更多想法。那時候首選就是當代軟體工程的經典之作：持續交付 (Continuous Delivery)。

在讀書會開始不久，有次跟朋友聊到持續部署想法，當時我提到因為時空背景的關係，這幾年各種新的概念與技術快速發展，特別是雲端架構應用、微服務與分散式架構的實踐概念，彷彿不斷的在提醒大家，持續部署 應該有不同的想法與實踐。當時的筆記如下圖：

同時 DevOps 與敏捷開發 (Agile Development) 概念鋪天蓋地的出現，大家意識到 霧卡世界（VUCA) 正在驅動整個軟體產業，除了持續部署，持續交付商業價值將面對更大的挑戰！VUCA 是 Volatility（易變性）、Uncertainty（不確定性）、Complexity（複雜性）、Ambiguity（模糊性）的縮寫。

戰爭之前，不管做了多少參謀作業，戰爭第一聲槍響的時候，所有計畫都會隨之改變。

– 美國名將 麥克阿瑟

雖然世界變化之快，常常讓人迷失，但變化越快，越要靜下心思考。正當我在思考，是否將這些資訊做通盤整理，彙整成更有意義的文字時，十一月七日早上，是立冬之日，Ruddy 老師在我桌上放了一本書，作者是人稱喬幫主的喬梁老師大作，書名：持續交付 2.0。當時的我心裡想：『嗯，我想要的，應該都在這裡面了。』

2019/04/27 於新竹敏捷社群 Meetup 的分享：導讀持續交付 2.0 - 談當代軟體交付之虛實融合

整理一些關於 Chaos Engineering 的資料。

上一篇 薪資 討論商討薪資背後的考量，這一篇整理薪資確認後要做的後續工作：確認報到時程

上一篇簡單整理了招募的 第三篇：價值觀，這一篇繼續整理很多人很在意的：薪資。

盡量用客觀角度來討論這件事情，但這是不容易的。

補充在 DevOpsDays 演講中，為啥在會特別強調 SRE 是面對落地的架構，而不是設計架構？這段內容本來是放在 Slide 要講的，後來拿掉了。我用 樂團總譜、練團溝通 來比喻 架構圖呈現、團隊溝通，其實要表達的是 康威定律：

系統架構與組織有著一定的關係，同時這關係會帶來團隊溝通成本問題。

接續上一篇 招募第一關 面試，這篇整理的是第二次面試 (以下簡稱二面)。二面不見得每個公司都有，有些可能會在一面就一次談完。依照面試的職位、職等、企業類型會有所不同，創業公司通常會直接跟 VP、CTO、CEO … 等階層聊，大型企業可能只到 Director，如果是高階通常都會到 CEO 或者 Co-founder。

一面最重要的是確認技能，二面確認價值觀。

接續上一篇 萬事起頭難：面試名單從哪來？，這篇整理的是面試篇。

面試是很多管理者（特別不習慣面對人的技術管理者）要學習的重要課程，也可能是第一個面對公司內部、客戶以外的人：從社會來的任意一個陌生人。

面試的目的在於找到 適合的人，要清楚以下本質：

• 面試是用人手段，透過面試了解是否適任，了解彼此，為彼此找到適合方向
• 面試是雙向的，面試官在面試別人，面試者也在面試這家公司
• 用人不只是技能，還有價值觀，反過來也是考驗企業文化是否對到面試者的頻率
• 面試只是其中一種篩選方法，吃飯喝茶、喇低賽、三顧茅廬也是面試。

底下整理面試方要準備的工作。

DevOpsDay Taipei 2018 兩天半的盛會，今天總算順利落幕。今天我分享了過去工作上，面對緊急事件的心得與歷程，同時彙整了 SRE 的重點，分享了這個在大會中，相對特殊的主題。不同於兩個月前的 AWS Summit，這次我不談技術、也不談高大上的數據、也不用新潮的用語，而只談如何面對 緊急異常 這件事，同時也分享了如何培養應變能力的方法與思路。

Updated 2023/07/19: 本文部分內容收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市

接續 前一篇：準備篇 的介紹，繼續整理招聘的心得：萬事起頭難，名單從哪來？

一般人找工作要不是主動投履歷，要不就被動等待通知面試。從招募角度也是，用人單位的面試名單不會從天上掉下來，這些名單要不是主動找來源，要不就被動等待。不管主動、被動，都要面對以下的幾個問題：

• 面試名單從哪來？
• 如何過濾、篩選名單？
• 為什麼面試意願不高？

整理人力招募的起手式 準備篇：確認需求、條件、定位、市場狀況。

今年 (2018) 有很多時間都放在如何作 人力招聘 (Hiring)，這系列文是整個過程中的心得、想法、遇到的問題。文章是從管理者、用人主管 角度出發，談到如何從需要資源開始、如何向上溝通、與人力資源協作、面試名單從哪裡來、如何面試、如何談薪資、報到之後如何確認符合需求 … 等。

2021/04/24: 本文授權 1111 人力銀行 轉載：聊聊人力招募：你到底是在Hiring還是Recruiting？

整理 CAP 理論的筆記。

研讀 分散式系統 時，遇到兩個常出現的議題：

1. 分散式一致性問題 (Distributed Consistency Problems)
2. 共識演算法 (Consensus Algorithm)

這兩個問題也是分散式系統很重要的核心議題，底下整理相關研讀的資料。

SRE 全名是 Site Reliability Engineering 網站可靠性工程，是 Google 提倡的系統管理實踐之道、指導思想，這個名詞同時也是 軟體工程師 (Software Engineer) 的角色，可以類比於傳統的維運工程師或系統工程師，但是 SRE 是用 計算機科學 和 軟體工程 手段，實踐 大型系統維運、分散式系統 的設計與開發。

Updated 2023/07/19: 個人著作 《SRE 實踐與開發平台指南》 於 2023/08 上市，內容整理個人過去數年實踐的經驗與總結。

本文整理重新摘分在 淺談軟體測試的階段與策略 整理的效能測試部分。

應 AWS 的邀請，在 06/28 讓我有機會站上台灣技術研討會的至高點之一：AWS Summit ，分享在公司導入 API Gateway 的心得！這是個難得而且讓人興奮的機會！同時 AWS User Group Taiwan 也是邀請我分享心得，兩場時間很近，所以同樣主題，兩個時間點 06/28、07/28 我用不同的形式，跟不同的族群做了分享！

Artifacts 是 CI/CD 很關鍵的點，他承接著接下來整個 Development Pipeline 的樞紐因子，能否有靈活、有彈性的佈署，都仰賴於 Artifacts Management。

Artifact 的目的就如同交付軟體給另一個陌生人，他可以透過取得一個檔案 (通常是壓縮檔)，然後解開後，依據 README.md 的說明，不管手動還是自動，可以自行完成部署或者安裝。而這個過程交付的 一個檔案 就稱作 Artifacts，在 github 上來講，就是 releases 上的檔案，像是 awscli

Updated:

• 這段整理後來的在社群 Meetup 的分享：聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)
• Updated 2023/07/19: 本文部分內容收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市

昨天跟同事聊到識人、用人，我提出這樣的想法，要知道一個人能否解決問題的前提，這個人要意會到什麼『是真實的世界』，舉例個誇張點的例子，例如：

有些人是活在被保護的環境之下長大的，從來就不知道：坐車是要錢的、漢堡不是從樹上長出來的、飛機是人造的，牛肉不見得是牛做的 …

這例子聽起來很誇張？是嗎？

分散式系統 的架構概念跟 Design Patterns 脫離不了關係，Kubernetes 的架構師 Brendan Burns 發表：Design patterns for container-based distributed systems, 2016 就以 Design patterns 為主軸，搭配 K8s 應用講述如何設計分散式架構。

整理資料，回顧之前寫的東西，常常覺得這些就是要不斷地拿出來提，特別是 分散式系統 (Distributed Systems) 已經是現代架構的常態，他就跟組織一樣，要面對各式各樣 依賴性、內外聚合、可控性、可治理、可觀測、網路拓墣、效能、快取、事件處理 … 等問題，這些問題不只可以對應到系統，也可以對應到人、組織 (康威定律)。

• 一、分散式系統核心問題
• 二、理論基礎與方法概念
• 三、當代工程方法與實踐
• 四、分散式系統、組織運作、腦科學、宇宙、意識

整理 分散式通訊系統 (Distributed Message Systems) 相關的基本概念，包含名詞定義、常用情境、實作技術、架構樣式、以及參考資料。

在整理 Overview API Gateway 一開始就提到關於 架構的可視性 (Visibility) 的問題，討論了可能的應用場景與實務架構問題。當時 AWS 的 API Gateway 並沒有 Private 的概念，預設只有 Regional 和 Edge 兩種類型，而且都是 Public。跟同事討論架構時，大家提出內部服務也需要 Gateway 達到類似限速、安全性控管的功能。

今天一早起來看到 API Gateway Private Endpoint 終於發佈了！期待已久，簡單整理筆記與心得！

上上週在一個 公開的演講 (Monitoring) 之後，去搭捷運時遇到一個陌生朋友，走過來跟我握手，說他聽了我某次的 演講之後 (Ops as Code) ，很有感，講到他遭遇的問題、處境，這次他又特別來聽我講，我心想：大概就是遇到同溫層吧，我只是把那些問題點出來而已～很高興他的 Feedback，讓我又更確認這些問題不是只有我一個人遇到。

Role And Responsibility 簡稱 R&R，用軍中術語就是：

• 軍階 / 官階：士官長 (兩粗三細)、上校 (三顆梅花)、將勳
• 職務 / 任務：連長、營長、旅長、總司令、部長

Role 談的是能力，也就是 技能 (Skills)
Responsibility 談的是責任，達成什麼 任務 (Mission)

底下整理我在思考這件事情過程的思路以及分析。

整理 某天 (2018/04/14) 跟同事聊到 獨立思考 這個題目，整理一些想法。

整理在 OS X 使用 Go Version Manager 的筆記，類似於 Node.js 的 NVM ，方便設定 golang version 的管理工具。

《產品、組織有沒有靈魂，看名字就知道了。》

《軟體開發流程要有 魂 與 體，敏捷精神 是魂，協作系統則是 體。》

新版的 AWS Certified Developer (Release June 2018)，考試代號 (DVA-C01)，範圍果然改了，多不少東西。

關於 SRE CH34 章提到跨領域的 緊急應變 (Emergency Response) 例，我舉了比較不同的領域：音樂 驗證同樣的概念。