這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的全貌：
不管是程式、文章、資料還是房間，我都會定期重新整理，基本的概念來自於這篇 分類的哲學
底下整理的是這個 Blog 最近更新的文章記錄，如果您是第一次來這裡、或者是老朋友，想要知道我最近更新哪一些文章，可以從這裡知道。
| 更新時間 | 更新方式 | 文章標題 | 發布時間 |
|---|---|---|---|
| 2021/08/21 | 更新參照 | 資深軟體工程師 | 2015/08/22 |
| 2021/04/30 | 新增資料 | 關於軟體測試，一些觀察到的現象 | 2019/10/30 |
| 2021/04/20 | 新增資料 | 看見怎樣的全貌 - 軟體開發的三體問題 | 2019/03/17 |
| 2021/03/27 | 新增資料 | 摘要密碼學與資訊安全 | 2020/03/07 |
| 2020/09/13 | 新增資料 | 聊聊分散式系統 | 2018/06/18 |
| 2020/09/13 | 增加段落 | CAP Theorem | 2018/08/11 |
| 2020/08/09 | 調整結構 | K8s 學習筆記 - kubeadm 手動安裝 | 2019/03/17 |
| 2020/07/25 | 增加段落 | 一致性問題與共識演算法 | 2018/08/11 |
| 2020/06/07 | 增加段落 | 學習法則 | 2017/09/20 |
| 2020/05/26 | 重構文章 | 資深軟體工程師 | 2015/08/22 |
| 2020/05/09 | 文句修飾 | GitHub Post-Incident Analysis | 2019/06/05 |
一直很想找一些人，這些人有個特質：
喜歡思考事物的本質性、背後的故事、問題、原理、抽象化、想像、實踐方法
像是：
星艦企業號 這樣的劇情？怎樣做好溝通、有效的溝通一直以來都是管理者的工作範疇之一。也因此我一直在探索背後的本質問題，像是 溝通的原理、表達與溝通的差異、會議原則、一場有效的會議
底下整理幾篇今年隨筆寫下的想法，主要是關於 團隊溝通的通訊協議 的想法。
AWS 把 EKS 本身開源了，稱為 EKS Anywhere，除了在 AWS 自己之外，也可以安裝在私有 (on-premises) 的環境。
本文整理體驗的筆記，我在 macOS、ubuntu20.04 都有做過，本文記錄則以 ubuntu 20.04 為主，內容以參考 EKS Anywhere 官方文件為主。
很高興有機會被推薦成為 2021 年的 AWS Community Hero。
感謝 AWS Leslie 的推薦，過程中 Kim 得協助，讓我有機會可以有這份榮耀。
底下是 AWS 官方公告，截圖作紀念：
Announcing the latest AWS Heroes – August 2021
過去幾年，沈浸在 AWS 的技術領域，我自己很享受學習 AWS 的過程，很多想法都在研究過程中激盪出來，最終把想法實際落地。
今年 (2021) 我開始有機會專注在新一代基礎架構設計，過去累積的經驗與想法、從學習 AWS 中累積的能量，有機會動手一一實踐。
HTTPS 也稱 HTTP over TLS、HTTP over SSL、HTTP Secure，是透過計算機網路安全 通訊協議 (Protocol)。
在 摘要密碼學與資訊安全 整理了部分的關於 TLS 協議的資料，本文重新整理我自己對於 HTTPS 這個通訊協議的理解。
上一篇整理了 Dapr Secret Store，本文繼續整理分散式系統很重要的通訊模式： Pub/Sub
大部分開發者聊到 微服務架構、分散式系統，都會談到 服務發現 (Service Discovery) 這個東西，讓開發者的應用程式可以透過他知道別的服務的位置。
這是視角的問題，開發者習慣從 App 內部往外 看 (白箱)，由內而外通訊需要知道的就是一個服務清單，然後對照相關的資訊。服務發現 (Service Discovery) 就是這樣的東西，大部分也會順便負責一些 Health Check、Service Status 的提供，但是有個很關鍵的問題是大部分服務發現沒有的，就是服務的 生命週期管理 與 服務實例 (Service Instance) 管理 。
而實際上，系統是要給人用的，系統需要被治理、管理，這個角度則是 由外往裡 看的，也就是 黑箱 的概念。
特別整理一段跟朋友的對話，聊聊這幾年我對於服務治理的看法。
在這年代不管是開發單體應用架構、還是分散式系統，不管怎樣的語言、平台，都要處理這個問題：
機敏性資料，如
資料庫連線、第三方串接的API Token…
這些東西不管在哪個年代都要處理，在這個 DevOps、DevSecOps、經常有 資安事件 的年代，實際的解決方案就顯得更重要了，從 Key Management、Secret Management 都是很重要的過程。其實三大公有雲也都有對應的解決方案，像是 AWS Secret Manager, Azure Key Vault, GCP Secret Manager … 經過一些時日，對於 Dapr 的基本概念與實際架構有了初步認識之後，第一個我想了解的就是 Dapr 如何處理 Secret Manager 這件事情？
上一篇整理了 Dapr 概念與設計，本文整理 Dapr 如何透過 Building Block，實際整合各種 Secret Store 的方法，以及實際要注意的事項。
前面兩篇先從體驗 Dapr 開始，從 Self-Hosted 到實際 Run on K8s 的體驗，大概了解的 Dapr 實際上怎麼用。Dapr 背後實際上把 分散式系統概念 與 微服務架構實踐的挑戰 、以及 K8s 圍繞這三個主題做了全面性的考慮與設計，特別是 Kubernetes Patterns 一書的作者 Bilgin Ibryam 提出 Multi-Runtime Microservices Architecture 的概念之後，加上 Dapr 這樣的分散式應用框架的出現，我感覺到下一個世代的來臨。
Bilgin Ibryam 的 The Evolution of Distributed Systems on Kubernetes、Multi-Runtime Microservices Architecture (簡中翻譯)，還有 Kubernetes Patterns 這些資料很直得一讀。
本文整理在 Study Dapr 過程中，整理背後設計的思路與概念。
上一篇 整理了體驗 Dapr 在本機模式的 Hello World，Dapr 在官方文件稱為 Self-Hosted，這篇要體驗則是 Run on K8s。
最近看到一篇有趣的文章，標題是： Java and C# are Obsolete in the Age of Docker
很有趣的題目，可以梳理一些觀念，整理一些想到的比較與想法。
Dapr 是微軟開發的 Distributed Application Framework。核心概念是 Sidecar 模式，搭配 Building Blocks、Components 等類似 Middleware / Pipeline 的概念，以及 K8s CRD (Custom Resource Definition) 的 擴充 Extensions / Plugins 的機制，以這些為主要設計的結構，然後完善大部分分散式系統 (或者說 Microservice) 所必要的基礎建設、開發體驗、維運考量、及架構擴展的需求。
這些概念與特性疊加起來實在是非常吸引我，加上 Dapr 本身很輕量，版本也已經到了 1.0 版，官方宣稱 production ready，可以一試了！底下是探索性的整理使用體驗。
在這之前，我也 Study 過類似的框架，其中有 Line 的 Armeria、carousell 的 Orion … 不過概念以及考量的成熟度，還是 Dapr 比較完整。
Shell 是使用者與作業系統溝通的介面，人機介面的形式分成 CLI 與 GUI 兩種。CLI (Command Line Interface) 讓一堆指令可以透過 指令搞 (command script) 變成自動化 程序 (procedure)，提高工作效能，這樣的指令搞我們把它稱為 shell scripts，中文通常翻譯成 程式化腳本、Shell 指令搞。
Shell 本身也是一個程式，但是他並沒有一個表準的型態，不同作業系統使用的也不盡相同。Unix-like 上最基本的 Shell 叫做 sh，全名是 Bouren Shell，是個 POSIX 標準。Bash 全名是 Bourne Again Shell，是 sh 的 superset。sh 與 bash 有點像 vi vs vim 的關係。
Unix / Linux 上很常用 Bash Script 做一些工作，本文整理 Linux 上的 Shell 和 Bash Script 重要的概念 … 等 外在因子。
- 註一：Shell 中文為
殼，由法國計算機科學家 Louis Pouzin 在 1964-1965 年間提出來的概念，後來實作在 Multics 上，而 Multics 後來催促 Unix 的誕生。- 註二：中文的
程序一詞，有時候指的是作業系統的 process 概念，是個實際上佔有資源的單位；有時候也指的是 procedure，指的是一段作業流程 (workflow)，後面描述視狀況會增加英文註記。
標題是最近 (2020/10) 在 Facebook 上的熱門話題，經過幾天之後，看了很多業界高手、前輩、專家的熱烈討論之後，沈澱了幾天，昨天 (10/17 Sat) 午休睡醒後迷迷糊糊寫下的， 原始文章連結 … 過程中，陸續修補一些想法和參考資料。
原文是 2020/08/13 寫下的 memo，主要是有效的會議，最後一段則是 08/06 寫的一段想法，也是會議效率化的想法。
整理 同步機制 (Synchronization) 的基礎概念，基本上就是作業系統概念的第六章內容。
Operating System Concepts，俗稱恐龍書，整理筆記時最新是第十版 (2018)。
面試是雙向的，資方要用人，勞方要找機會，雙方透過面試找到彼此的交集、找到共事的可能與機會。本文整理數百次面試經驗過程中，常見的面試問題，希望可以協助更多求職者順利找到理想工作。
問題分成以下幾類：
這些問題種類，裡面各有代表性的各別整理問題的現象。
最後整理一些建議做法，給求職者參考。
分散式交易 (Distributed Transactions) 指分散在各個運算單元的一系列任務操作 (Operations) 或任務 (Tasks)、有次序的 (Ordered)、且彼此是隔離 (Isolation)、最終達成一致的過程。達成一致 指的是全部動作都成功、或者全部動作都失敗，後者則透過 Rollback 還原。
分散式交易對應的就是單機交易，也就是在一個運算資源上，完成交易動作，電商最常見的案例就是：
這兩的操作 (Operations) 滿足次序性、最後達成交易，也就是關聯式資料庫常說的 ACID 原則。如果這個過程是在分散式系統，就必須有其他機制達到此需求。
常見的分散式交易有幾種協議，像是：
本文整理 XA、二階段提交 (2PC)、三階段提交 (3PC)、TCC (Try-Confirm-Cancel) … 等基礎概念。文章資料主要參考自 Distributed Systems: Concepts and Design (5th Edition)、分佈式事務：All or nothing 兩篇的整理。
Using AWS for Disaster Recovery 整理 AWS 針對災難還原的實踐原則，而去年 (2019) 我在公司真實執行災難演練，這是第二次的經驗。這段過程，在年初 (2020/01/08) 的 AWS reInvent reCAP 2019 跟大家分享整個執行過程。
在整理 如何量測系統的容量？ 給自己挖了一個坑，整理這篇，先起個頭。可靠性工程 (Reliability Engineering)1 是系統工程的子項目之一，概念上非常類似於 可用性 (Available)，但不全然。依據 Practical Reliability Engineering 的定義，可靠性如下：
The probability that an item will perform a required function without failure under stated conditions for a statd period of time.
可靠性是指某套系統在指定的環境下，在要求的時間內成功持續執行某個功能的機率。
這段定義在 SRE 序中也有引用。
這篇整理個人的理解與簡單總結，不見得與一般的書本一樣，主要專注在 What (可靠性的定義)、How (工程實踐)。
溝通就是把資訊從自己腦袋裡挖出來，然後透過載體，像是用語言、文字、圖畫、藝術、肢體 …. 傳達給另一個人，讓對方知道你在想啥。溝通的理想結果是彼此 100% 知道彼此的感受、體驗、想法，藉由此相互的理解，然後進一步的合作、協作、或者是情感交流。一般透過語言的溝通程序大概如下圖：
整個過程有幾個階段：
本文同步發佈在 Matters: 廢文：溝通的原理
整理一些 密碼學 (Cryptography) 與 資訊安全 (Information Security) 的專有名詞、重要概念、密碼學演算法、應用協議、資訊安全概念，主要資料都參考自 Wikipedia。
- 本文非一次性整理，相關筆記漸進式整理上來。
- 本文只是個人學習的梳理，可能有誤，如有建議歡迎給予指導，感謝。
整理 Key Management Service (KMS) 的學習筆記，包含以下：
KMS 需要有密碼學與資訊安全的概念，所以另外整理 摘要密碼學與資訊安全 的筆記。
下班前 (02/07 Fri) 同事問 Container 除了可以讓應用程式在本機與正式環境一樣，跟 VM 比較起來還有什麼好處？認真說可以說很多，簡單整理 我在三分鐘內口述的東西，因為要趕公車，三分鐘到了我就先跑了XDD，這段文字是在公車上敲下的，原文點 這裡。
當下第一個直覺就是清楚的資源邊界：
隔離性，衍生的議題就是資源管理與成本。第二個想到的就是資安，衍生議題就是系統維運 (Operations)。所以先針對這兩個部分描述。
最近因為武漢肺炎事件，國家必須用各種方式通報國民，包含嚴重性、通報的方法、交付有意義的資訊。
這整個過程就是事件管理是一樣的。摘錄我在 2017 年分享的一段想法：淺談系統監控與 CloudWatch 的應用，其中第四部分談的異常通報 就是談事件通報與管理的核心概念。
整理我認識的計算機科學家。
在組織裡推動事情，最困難的往往不是技術上的執行問題、不是成本問題、溝通問題、協作問題，困難的是：
如何讓高層、主管、團隊成員
意識 (Awareness)到：這是一個必須被正視的問題。
當問題被正視了，大家都 Awareness 了，接下來才有開始討論如何解決、如何 有效定義目標與執行、落地、資源才會進來 …
SRE 讀書會 Round 3 從今年 2019/03/15 開始，在 2019/12/05 (四) 的寒流之下完結了，大家頂著 15 度低溫、加上下著雨，依舊準時出席讀書會，走完這次最後的章節。
今年一整年，起了好幾個跨部門、跨組織的任務，在這過程一直在嘗試讓一個成員、或者讓一個團隊可以自主完成任務的方法，過程中踩了很多雷，像七傷拳一樣，常常是還沒發拳自己就先中了內傷，內力不夠深厚打七傷拳才會傷到自己，後來慢慢梳理出一套可以執行的方法，年底也看到成果了。
除了這些大範圍的協作，工作上經常交付任務給團隊執行，交辦的方式會是口頭交辦、公開的指派、正式的賦予權責，交辦的對象則有自己團隊的資深、到資遣成員，協作團隊的成員 … 不管怎樣的交付任務，都需要一個有效的方法來確立目標是可以執行。
這篇整理了一些歷程與土炮方法，分成以下幾個部分：
