接續上一篇 萬事起頭難：面試名單從哪來？，這篇整理的是面試篇。
面試是很多管理者（特別不習慣面對人的技術管理者）要學習的重要課程，也可能是第一個面對公司內部、客戶以外的人：從社會來的任意一個陌生人。
面試的目的在於找到 適合的人，要清楚以下本質：
底下整理面試方要準備的工作。
DevOpsDay Taipei 2018 兩天半的盛會，今天總算順利落幕。今天我分享了過去工作上，面對緊急事件的心得與歷程，同時彙整了 SRE 的重點，分享了這個在大會中，相對特殊的主題。不同於兩個月前的 AWS Summit，這次我不談技術、也不談高大上的數據、也不用新潮的用語，而只談如何面對 緊急異常 這件事，同時也分享了如何培養應變能力的方法與思路。
Updated 2023/07/19: 本文部分內容收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市
接續 前一篇：準備篇 的介紹，繼續整理招聘的心得：萬事起頭難，名單從哪來？
一般人找工作要不是主動投履歷，要不就被動等待通知面試。從招募角度也是，用人單位的面試名單不會從天上掉下來，這些名單要不是主動找來源，要不就被動等待。不管主動、被動，都要面對以下的幾個問題：
整理人力招募的起手式 準備篇：確認需求、條件、定位、市場狀況。
今年 (2018) 有很多時間都放在如何作 人力招聘 (Hiring)，這系列文是整個過程中的心得、想法、遇到的問題。文章是從管理者、用人主管 角度出發，談到如何從需要資源開始、如何向上溝通、與人力資源協作、面試名單從哪裡來、如何面試、如何談薪資、報到之後如何確認符合需求 … 等。
2021/04/24: 本文授權 1111 人力銀行 轉載：聊聊人力招募：你到底是在Hiring還是Recruiting？
整理 CAP 理論的筆記。
研讀 分散式系統 時，遇到兩個常出現的議題：
這兩個問題也是分散式系統很重要的核心議題，底下整理相關研讀的資料。
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 大亂鬥
準備的時候思考要講什麼，整理以下的觀點：
淺談軟體測試的階段與策略 提到過去因為需要自動化 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)：
由 DevOps Taiwan 主辦的活動： Monitoring Tools 大亂鬥
我會用：人們不會買你買什麼；他們買你的為什麼 這個角度切入，分享一些想法、實務經驗，有興趣的朋友一起來聊。
這是今天 (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 更新: 本文部分收錄在 共同著作《軟體測試實務》 第一冊 第五章之中，歡迎大家彭場。
