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

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

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

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

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

由 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 內部的服務與資源。