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

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) 例，我舉了比較不同的領域：音樂 驗證同樣的概念。

由 DevOps Taiwan 主辦的活動： Monitoring Tools 大亂鬥

準備的時候思考要講什麼，整理以下的觀點：

• 談「武」、還是論「俠」？ (務實、務虛；肉體、靈魂)
• Target Audience (TA) 為什麼來？
• 我能給什麼？

淺談軟體測試的階段與策略 提到過去因為需要自動化 Regression Test，然後設計、開發 Test Framework / Architecture 的經驗。最近也有人在問我怎麼做這件事情，重新整理一下這段經歷的分享，補充了一些資料。

本文延續 Amazon API Gateway 裡很重要的觀念：限速 Rate Limit、Throttling、Burst 等概念。

Rate Limit 概念在 SRE CH21: 處理系統超載 (Handling Overload)、Service Mesh 都有直接關聯。

整理如何使用 Amazon API Gateway 當作 Proxy 直接存取 DynamoDB，而不需要透過 Lambda。

接續前一篇 Compare GCP VPC Network with AWS 的整理，繼續整理如何透過 VPN 把 GCP 和 AWS 的 VPC 串接起來，形成 Hybrid Cloud 架構。

在 PTT Soft_Job 看到這篇討論： 敏捷課程觀察心得

我的看法跟這位差不多，不是反對敏捷，覺得敏捷就是種『軟體開發管理』的『原則』、『方法』、『概念』、『精神』 … 用我個人的詞彙來說，就是『有節奏的軟體開發方法』

音樂沒有節奏，就不是音樂。

導入能否成功，跟團隊、組織、文化很有關係。

敏捷宣言 沒有啥規則，就是概念，換言之『抽象』。抽象的好處是，怎麼解釋都可以，最後太抽象會衍生出各式各樣的分支，或者因為講者個人特色，變得很有特色，有點像是宗教。如果團隊、組織沒意會到是在做 軟體開發 的工作，而是用工廠的思維在管理，那『敏捷』到最後是穿西裝打領帶的宗教儀式。

底下整理一些觀察到的現象與想法。

前一篇 『導入 CI/CD 的第一步』提到了一些基本觀念、想法，這篇繼續整理一些關於 軟體開發過程，怎樣的 CI/CD 才算是有品質。一般介紹 Jenkins、Gitlab CI、Drone 的課程重點在於怎麼利用工具串接 CI/CD Pipeline 的 Task / Jobs，除了這些，怎麼讓 CI/CD 真正達到團隊合作，我想是非常重要的。

底下是我看 CI/CD 做得好不好的 驗證點 (Verification Point)，夠不夠 Quality 就看這些了 (好像在做認證一樣 XD)：

1. (主詞) 可否任意建立需要的環境？
2. (主詞) 可否驗證任意版本？
3. (主詞) 如何配置 (Configure) 整個系統？
4. (主詞) 可否隨意建立模擬資料？
5. 收集回饋機制
6. 產品開發團隊有哪些人？

由 DevOps Taiwan 主辦的活動： Monitoring Tools 大亂鬥

我會用：人們不會買你買什麼；他們買你的為什麼 這個角度切入，分享一些想法、實務經驗，有興趣的朋友一起來聊。

延伸閱讀

• Serverless All-Star - Ops as Code using Serverless
• 淺談系統監控與 CloudWatch 的應用 - AWS User Group Taiwan
• What is Monitoring?
• Observability and Monitoring

這是今天 (2018/03/29) 在 iThome 主辦的活動 - Serverless All-Star 分享的主題： Ops as Code using Serverless，主軸如同過往，用問題開場、以說文解字切入，然後帶到 現場 (Live, 真實案例)，帶出新技術的價值，強調 軟體工程 的重要性，最後帶到反思。

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

先不談 CI/CD 的定義，或者 DevOps 是啥。

企業導入 CI/CD 的第一步，先在內部解放 Build / Artifact / Configuration 的觀念，目的是要讓 Developer 以外的人員，能夠獨立部署產品，獨立確認產品的樣貌，提高靈活度。

• 如果開發出來的軟體，無法讓開發人員以外的人自行安裝或者部署，那麼這整個開發流程就是不敏捷。
• 相關參閱 Artifacts Management

在 淺談軟體測試的階段與策略 一文有提到 系統驗證測試 (System Verification Test) 的基本概念，基本的想法就是：

• 功能驗證 (FVT)：假設功能還沒好，目的是確認商業功能正確性，像是邏輯完整性、資料正確性、驗證與錯誤處理、探索功能的可能性 … 等，強調功能本身的 內聚力。
• 系統驗證 (SVT)：假設功能都好了，增加 外在環境因素 之後，把這些 功能 放到不同的環境會有什麼問題？強調外在 耦合性、真實世界 的情境。

這裏整理前一個工作做教育訓練的資料，主要描述的是以 User-Facing 為主的系統，像是 iOS / Android 的差異。這 Slide 用比較自嘲、調侃的方式呈現，配合當時的熱門的話題，時間點是在 iPhone5 (2012/09) 上市的時候。

20230523 更新: 本文部分收錄在 共同著作《軟體測試實務》 第一冊 第五章之中，歡迎大家彭場。

整理前一個工作做教育訓練的資料，本來對象是給 SQA (Software QA) Team 的教育訓練，後來發現這個題目，所有人都要會，也就是 如何有效的回報問題。

所有人 指的是：團隊裡的每一個人。實務上很難，所以要一起討論、學習。以測試角度來看，就是 如何有效的回報 Defect / Bug，底下的截圖是以前教育訓練的資料，隨著時間的演進，現在看起來還是有一些參考價值吧？

文中用 Issue 統稱 Defect、Bug 這些 議題。更多參閱 Issue Tracking in Redmine

20230523 更新: 本文部分收錄在 共同著作《軟體測試實務》 第一冊 第五章之中，歡迎大家彭場指導。

繼續整理 Amazon API Gateway 的整合應用：如何使用 API Gateway 透過 NLB (Network Load Balancing) 整合 VPC 內部的服務與資源。

原定時間是 2017/12/07 ，後來改到 2018/03/29，活動名稱改為 Serverless All-Star，我的主題沒有改變: Ops as Code using Serverless，歡迎大家來彭場！

這場演講的 Slide 請參考 Serverless All-Star in 2018 (Public Slide)

SRE 這本書並不是很容易入門的，書中有不少東西是滿技術性的，但也很多屬於觀念、原則、經驗方法。所以如果非技術背景或者管理階層的朋友，想要閱讀 SRE，推薦閱讀以下章節，可以了解一些原則與概念。

太技術性的章節我先過濾掉，以下是原文的 Link (英文)。

• Part I Introduction
  • CH01 緒論 Introduction
• Part II Principles (指導原則)
  • CH03 Embracing Risk 擁抱風險
  • CH04 Service Level Objectives 服務水準的目標
  • CH08 Release Engineering 發行工程
• Part III Practices 具體實踐
  • CH11 Being On-Call
  • CH12 Effective Troubleshooting
  • CH13 Emergency Response 緊急應變
  • CH14 Managing Incidents 緊急事件管理
  • CH15 Postmortem Culture: Learning from Failure 事後檢討：從失敗中學習
  • CH16 Tracking Outages 事件追蹤
• Part VI Management 管理
  • CH31 SRE Communication and Collaboration in SRE 與其他團隊的溝通與協作
• Part V Conclusions 總結
  • CH33 Lessons Learned from Other Industries 其他產業的實務經驗

如果只能挑一章來讀，我推薦 CH15 事後檢討：從失敗中學習 ，建立良好的回饋與循環，讓團隊漸進式地變好。這也是 “DevOps” 的精神之一。

如果可以選擇一段主題，我推薦 CH11-16，都在討論 上線後 要面對的問題還有平常的訓練。

API Gateway 是直接面對使用者的，所以除了 API 本身的描述，面對 Client 的 Endpoint / URL Path 的規劃也很重要，相對應的就會帶出 DNS、SSL、CDN … 等議題，而這些問題，通常上線後都才會注意到。但實際上規劃的不好，不只門面不好看，同時也會造成開發、測試、管理、溝通 … 等成本。

本文整理如何使用 Amazon API Gateway 和 AWS 的 Certificate Manager (ACM)、Route53 設定 Custom Domain Name，還有更重要的是規劃完整的 Service 與 Endpoint 要注意的事情。

本文延續 Overview API Gateway 相關筆記，整理在 Amazon API Gateway 中， 如何使用 CloudWatch Logs (以下縮寫 CWL) 找問題、Debugging，設定包含以下：

• Enable CloudWatch Logs for API Gateway
• Enable API Logging for Stage
• Custom Access Logging