這篇是我在 2021/05/23 寫的一篇關於 Developer 的條件寫的文章，我自己覺得這樣的要求是不過分的，但是，可能跟很多現代的過念有所差異，特別是一些從外面的培訓機構訓練出來的學生。

應用程式 在啟動 or 初始化 (Initial / Startup)的時候，配置 (Configuration) 載入的流程經過這麼多年的發展，基本上已經有一個常見的策略模式了，這些概念很重要，卻也很常被忽略，最後系統上線後只能夠透過改 Code 重新部署才能處理問題，好的設計應該是改配置就能滿足需求。

這篇原文是寫在 SRE 社群的一篇 筆記，借保哥的 整理 發揮另一個常見的東西：配置與設定的讀取策略設計

幾年前的分享 聊聊軟體交付的濫觴 - 談產出物管理，簡報最後面留幾個問題讓大家思考。

最近有朋友私下敲我，問了最後一個問題：

分支策略 跟 Artifact Management 的關係？

問題背後是他在新創團隊裡，遇到在處理分支策略的同時，也遇到如何打包 Artifact ，兩者的衝突與矛盾。

底下是我針對這個問題整理的摘要。

本文重新整理我在 FB 寫的草稿，之後嘗試錄了一段口述，提供給大家參考。

怎樣做好溝通、有效的溝通一直以來都是管理者的工作範疇之一。也因此我一直在探索背後的本質問題，像是 溝通的原理、表達與溝通的差異、會議原則、一場有效的會議

底下整理幾篇今年隨筆寫下的想法，主要是關於 團隊溝通的通訊協議 的想法。

• 2021/09/24: 通訊協議與團隊溝通
• 2021/05/10: 團隊溝通的標準化

AWS 把 EKS 本身開源了，稱為 EKS Anywhere，除了在 AWS 自己之外，也可以安裝在私有 (on-premises) 的環境。

本文整理體驗的筆記，我在 macOS、ubuntu20.04 都有做過，本文記錄則以 ubuntu 20.04 為主，內容以參考 EKS Anywhere 官方文件為主。

一直以來，都有朋友會找我聊 職涯規劃 的問題，整理幾段我敲在 Facebook 上的隨筆

• 2021/06/25: 談探索自我
• 2019/04/21: 談退休

內容以職涯角度切入，談的是 探索自己，然後延伸到 生死、退休 … 等。

很高興有機會被推薦成為 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) 午休睡醒後迷迷糊糊寫下的， 原始文章連結 … 過程中，陸續修補一些想法和參考資料。

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

原文是 2020/08/13 寫下的 memo，主要是有效的會議，最後一段則是 08/06 寫的一段想法，也是會議效率化的想法。與標題相對應的，則是 一場失敗的會議。

整理 同步機制 (Synchronization) 的基礎概念，基本上就是作業系統概念的第六章內容。

Operating System Concepts，俗稱恐龍書，整理筆記時最新是第十版 (2018)。

這段是我跟同事分享、也是放在心裡很久，沒有寫下的東西：溝通與表達的差異。原文點這裡。

面試是雙向的，資方要用人，勞方要找機會，雙方透過面試找到彼此的交集、找到共事的可能與機會。本文整理數百次面試經驗過程中，常見的面試問題，希望可以協助更多求職者順利找到理想工作。

問題分成以下幾類：

• 一、履歷的問題
• 二、自我介紹的問題
• 三、面試過程的問題

這些問題種類，裡面各有代表性的各別整理問題的現象。

最後整理一些建議做法，給求職者參考。

分散式交易 (Distributed Transactions) 指分散在各個運算單元的一系列任務操作 (Operations) 或任務 (Tasks)、有次序的 (Ordered)、且彼此是隔離 (Isolation)、最終達成一致的過程。達成一致 指的是全部動作都成功、或者全部動作都失敗，後者則透過 Rollback 還原。

分散式交易對應的就是單機交易，也就是在一個運算資源上，完成交易動作，電商最常見的案例就是：

• 1. 完成訂單 (含付款)
• 2. 完成扣庫存

這兩的操作 (Operations) 滿足次序性、最後達成交易，也就是關聯式資料庫常說的 ACID 原則。如果這個過程是在分散式系統，就必須有其他機制達到此需求。

常見的分散式交易有幾種協議，像是：

1. 基於 X/Open 國際聯盟的 Distributed Transaction Processing Model (DTP)，簡稱 XA，用來達到強一致性，符合 ACID 原則的協議：
   1. 二階段提交 (Two Phase Commit, 2PC)
2. 三階段提交 (Three Phase Commit, 3PC)
3. 另外就是屬於最終一致性、符合 BASE 原則的消息對列 (Message Queue) 方式。

本文整理 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)¹ 是系統工程的子項目之一，概念上非常類似於 可用性 (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% 知道彼此的感受、體驗、想法，藉由此相互的理解，然後進一步的合作、協作、或者是情感交流。一般透過語言的溝通程序大概如下圖：

整個過程有幾個階段：

1. 你想說的
2. 你說出來的
3. 我聽到的
4. 我理解的

本文同步發佈在 Matters: 廢文：溝通的原理

整理一些 密碼學 (Cryptography) 與 資訊安全 (Information Security) 的專有名詞、重要概念、密碼學演算法、應用協議、資訊安全概念，主要資料都參考自 Wikipedia。

• 本文非一次性整理，相關筆記漸進式整理上來。
• 本文只是個人學習的梳理，可能有誤，如有建議歡迎給予指導，感謝。

整理 Key Management Service (KMS) 的學習筆記，包含以下：

• 一、基本概念
• 二、基本使用
• 三、整合應用
• 四、常見問答

KMS 需要有密碼學與資訊安全的概念，所以另外整理 摘要密碼學與資訊安全 的筆記。

下班前 (02/07 Fri) 同事問 Container 除了可以讓應用程式在本機與正式環境一樣，跟 VM 比較起來還有什麼好處？認真說可以說很多，簡單整理 我在三分鐘內口述的東西，因為要趕公車，三分鐘到了我就先跑了XDD，這段文字是在公車上敲下的，原文點 這裡。

當下第一個直覺就是清楚的資源邊界：隔離性，衍生的議題就是 資源管理 與 成本。第二個想到的就是 資安，衍生議題就是 系統維運 (Operations) 。所以先針對這兩個部分描述。

最近因為武漢肺炎事件，國家必須用各種方式通報國民，包含嚴重性、通報的方法、交付有意義的資訊。

這整個過程就是事件管理是一樣的。摘錄我在 2017 年分享的一段想法：淺談系統監控與 CloudWatch 的應用，其中第四部分談的異常通報 就是談事件通報與管理的核心概念。

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

整理我認識的計算機科學家。

去年針對 文件持續交付 找了一些工具，當時以 K8s 官方網站作為目標，研究他使用的工具以及架構，後來這件事情就沒有時間持續往下。最近想把個人的入口網站，做更完善的整理，試了一些東西，最後腦海還是出現去年研究 Hugo 的想法，所以整理一下研究的筆記。

在組織裡推動事情，最困難的往往不是技術上的執行問題、不是成本問題、溝通問題、協作問題，困難的是：

如何讓高層、主管、團隊成員 意識 (Awareness) 到：這是一個必須被正視的問題。

當問題被正視了，大家都 Awareness 了，接下來才有開始討論如何解決、如何 有效定義目標與執行、落地、資源才會進來 …

SRE 讀書會 Round 3 從今年 2019/03/15 開始，在 2019/12/05 (四) 的寒流之下完結了，大家頂著 15 度低溫、加上下著雨，依舊準時出席讀書會，走完這次最後的章節。

今年一整年，起了好幾個跨部門、跨組織的任務，在這過程一直在嘗試讓一個成員、或者讓一個團隊可以自主完成任務的方法，過程中踩了很多雷，像七傷拳一樣，常常是還沒發拳自己就先中了內傷，內力不夠深厚打七傷拳才會傷到自己，後來慢慢梳理出一套可以執行的方法，年底也看到成果了。

除了這些大範圍的協作，工作上經常交付任務給團隊執行，交辦的方式會是口頭交辦、公開的指派、正式的賦予權責，交辦的對象則有自己團隊的資深、到資遣成員，協作團隊的成員 … 不管怎樣的交付任務，都需要一個有效的方法來確立目標是可以執行。

這篇整理了一些歷程與土炮方法，分成以下幾個部分：

• 一、給任務前，管理者的思考
• 二、情境領導：不同成員的引導
• 三、執行與落地