這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的大方向，介紹分成 置頂文、熱門文章、最新更新、一些 Q&A 幾個部分。
底下是置頂文（也是目錄），也是希望第一次來的讀者可以從這裡看到全貌的：
不管是程式、文章、資料還是房間，我都會定期重新整理，基本的概念來自於這篇 分類的哲學
一直很想找一些人，這些人有個特質：喜歡思考事物的本質性、背後的故事、問題、原理、抽象化、延伸、想像，像是：
星艦企業號 這樣的劇情？這個 Index 整理跟 軟體工程實踐 相關的文章，重點在 實踐與執行，主要內容包含以下：
(Execution)：執行管理實踐方法，像是 Redmine 應用與整合、相關工具 (VSTS)(Research)：研究新技術相關資料，計算機科學、網路、資料結構、演算法，新技術應用，像是 AWS Study Roadmap(Development)：程式、資料庫應用(Acceptance)：Quality Assurance and Testing(Operation)：上線 現場 (Live) 前、中、後，像是 CI/CD、SRE、Monitoring、Observability、事件管理DevOps 我個人傾向於用整個企業的角度來看，而不是產品研發單位個別看，請參閱 經營管理
AWS 範圍很大，有系統的學習是必要的。就像以前學音樂一樣，從各個面向整理 學習地圖，試著拼這張圖，過程中就可以知道自己哪裡還有缺，把缺的補上 (擁有技能)、把圖拼出來 (擁有知識)、把他們連結 (Connected and Linked) 起來 (產生智慧)、用他們創造 (產生創意)。
底下這張 mindmap 則是我自己的分類、重要性、以及學習的進度狀況，用以看到全貌：
以下依照 AWS Services 的分類，整理過去的心得筆記。
經營管理 是我正在學習的領域。因為工作職務關係，斷斷續續都有在讀類似的書籍，工作上經常需要思考相關的事情。因為這樣寫了一些比較屬於筆記性質的文字，有時候回來翻翻看看，覺得似乎慢慢形成自己的一套方法與哲學，雖然很多都還不夠成熟與完整，但總是自己的思考的足跡。
分類這些心得如下：
整理一些關於 Chaos Engineering 的資料。
補充在 DevOpsDay 演講中，為啥在會特別強調 SRE 是面對落地的架構，而不是設計架構？這段內容本來是放在 Slide 要講的，後來拿掉了。我用 樂團總譜、練團溝通 來比喻 架構圖呈現、團隊溝通，其實要表達的是 康威定律：
系統架構與組織有著一定的關係，同時這關係會帶來團隊溝通成本問題。
接續上一篇 招募第一關 面試，這篇整理的是第二次面試 (以下簡稱二面)。二面不見得每個公司都有，有些可能會在一面就一次談完。依照面試的職位、職等、企業類型會有所不同，創業公司通常會直接跟 VP、CTO、CEO … 等階層聊，大型企業可能只到 Director，如果是高階通常都會到 CEO 或者 Co-founder。
一面最重要的是確認技能，二面確認價值觀。
接續上一篇 萬事起頭難：面試名單從哪來？，這篇整理的是面試篇。
面試是很多管理者（特別不習慣面對人的技術管理者）要學習的重要課程，也可能是第一個面對公司內部、客戶以外的人：從社會來的任意一個陌生人。
面試的目的在於找到 適合的人，要清楚以下本質：
底下整理面試方要準備的工作。
DevOpsDay Taipei 2018 兩天半的盛會，今天總算順利落幕。今天我分享了過去工作上，面對緊急事件的心得與歷程，同時彙整了 SRE 的重點，分享了這個在大會中，相對特殊的主題。不同於兩個月前的 AWS Summit，這次我不談技術、也不談高大上的數據、也不用新潮的用語，而只談如何面對 緊急異常 這件事，同時也分享了如何培養應變能力的方法與思路。
接續 前一篇：準備篇 的介紹，繼續整理招聘的心得：萬事起頭難，名單從哪來？
一般人找工作要不是主動投履歷，要不就被動等待通知面試。從招募角度也是，用人單位的面試名單不會從天上掉下來，這些名單要不是主動找來源，要不就被動等待。不管主動、被動，都要面對以下的幾個問題：
聊聊人力招聘的心得，起手式 準備篇：確認需求、條件、定位、市場狀況。
整理最近 人力招聘 (Hiring) 過程的心得、想法、遇到的問題。這系列文章是從管理者角度出發，也就是 用人主管，如何從需要資源開始、如何面試、如何談薪資、報到之後如何確認符合需求 … 等。
整理 CAP 理論的筆記。
最近研讀 分散式系統 時，遇到兩個常出現的議題：
整理最近瀏覽的資料。
SRE 全名是 Site Reliability Engineering 網站可靠性工程，是 Google 提倡的系統管理實踐之道、指導思想，這個名詞同時也是 軟體工程師 (Software Engineer) 的角色，可以類比於傳統的維運工程師或系統工程師，但是 SRE 是用 計算機科學 和 軟體工程 手段，實踐 大型系統維運、分散式系統 的設計與開發。
本文整理重新摘分在 Stages in Software Testing 整理的效能測試部分。
應 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
昨天跟同事聊到識人、用人，我提出這樣的想法，要知道一個人能否解決問題的前提，這個人要意會到什麼『是真實的世界』，舉例個誇張點的例子，例如：
有些人是活在被保護的環境之下長大的，從來就不知道：坐車是要錢的、漢堡不是從樹上長出來的、飛機是人造的，牛肉不見得是牛做的 …
這例子聽起來很誇張？是嗎？
分散式系統 的架構概念跟 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)
底下整理我在思考這件事情過程的思路以及分析。
整理某天 (04/14) 跟同事聊到 獨立思考 這個題目，整理一些想法。
整理在 OS X 使用 Go Version Manager 的筆記，類似於 Node.js 的 NVM ，方便設定 golang version 的管理工具。
《產品、組織有沒有靈魂，看名字就知道了。你的兒女會隨便取名？》
《軟體開發流程要有 魂 與 體，敏捷精神 是魂，協作系統則是 體。》
新版的 AWS Certified Developer (Release June 2018)，考試代號 (DVA-C01)，範圍果然改了，多不少東西。
關於 SRE CH34 章提到跨領域的 緊急應變 (Emergency Response) 例，我舉了比較不同的領域：音樂 驗證同樣的概念。
