Using API Gateway as DynamoDB Proxy 一文提及可以透過 API Gateway 直接整合 DynamoDB ，而不一定要透過 Lambda，其實 Lambda 只是大家最常整合的服務而已。同樣的概念，其實 API Gateway 可以直接整合除了 Lambda 之外的很多服務，像是 DynamoDB、SQS、Step Functions、Kinesis、 … 等。
延伸這個應用，我很常被問的一個問題：
發送給 API Gateway 的請求，會不會掉？怎樣避免 Request 遺失？
這個問題很多人都問過我，本文提供一個架構設計的想法。
這篇的想法是埋藏在心裡很久的，因為工作關係、身份關係，常常需要被灌輸一些觀念，但是每次聽到哪些『說法』怎麼聽，都是覺的怪。
管理工作經常需要量化產能，量化產能經常的會拿工廠生產線來比喻，最後就把軟體開發的管理度量，用生產線的思維來比喻，然後就把軟體開發者、軟體工程師當作產線作業員來管理，荒謬至極的想法。
以下是我下班坐公車時，寫下積累、醞釀的 隨筆 (2019/07/09)。
管理工作範圍廣大，人事管理 (People Management) 是其中一個重要的工作範圍，本文整理身為一個管理者必須面對的課題：資遣、解僱、辭呈。
2018/10/21 GitHub 發生重大的異常，服務中斷超過 24h。事後官方釋出完整的事件分析報告，包含非常詳盡的事件過程、架構、應變等。這篇是我當時整理在 SRE 社群的簡譯，原始連結。
如同電影 薩利機長，SRE 應該要多閱讀 異常事件報告，從中學習應變的方法與經驗，同時也了解別人的 系統架構 為何如此設計，有什麼問題？
這個事件，讓 Github 整個組織認真思考 Site Reliability Engineering 的重要性。
整理如何設定 AWS SSO 的流程，主要參考： How to Set Up Federated Single Sign-On to AWS Using Google Apps 這篇文章，用 SAML 2.0 (Security Assertion Markup Language) 協議做使用者的 認證管理 (Authentication)，並且延伸管理上實際遇到的問題。
議題追蹤 (Issue) 最重要的就是資料來源的管理，讓需要被關注的事情都放到同一個籃子 (Pool)，然後才得以檢傷、分類、處理。而 SaaS 年代，如何讓使用者的聲音，快速的被蒐集與處理，則是非常重要的。
本文整理如何設定讓 Email 訊息，自動導入 Redmine，變成可以追蹤管理的設定方式。
Step Functions 在 2016 re:Invent 發佈後我就一直放在心裡，他是令人興奮的功能。本文整理 Step Functions 的學習筆記。
去年翻譯了這本書： 分散式系統設計 (Designing Distributed Systems, DDS) 在 2019/05/20 上市了。以下純粹是譯者自己的筆記與心得，非官方。
Redmine 的安裝流程相對於一般的網站應用程式來講，是複雜的，特別是如果不熟悉 Ruby on Rails 的生態系，或者不熟悉 Nginx 的配置，那麼整個安裝過程會是非常挫折的。
本文記錄如何在 Ubuntu 16.04 安裝與配置最新版 Redmine 4.0.3 (201905) 筆記，相關資訊放在 GitHub 供參考。
敏捷三叔公 David Ko 的邀約，讓我有機會到新竹交大跟大家分享 持續交付 2.0 的心得～
底下整理這次分享的簡報、摘要與錄影。
現在各個語言都有 Version Manager，像是 node 的 nvm、ruby 的 rvm、golang 的 gvm，Java 沒有官方的工具，但也有類似的工具。
底下整理的都是針對 macOS。
整理 VPC 一些常見的問答。
AWS CTO 在他的 Blog 提到 Amazon 產品規劃的方法: Working Backwards，最近我把這想法放在 個人、團隊、還有 企業發展 三個地方。
上週 (2019/03/28) DevOps Meetup 分享的主題：聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)，我提出了 軟體交付四大支柱 (Four Pillars of Software Delivery) 的想法，如下圖：
支柱 (Pillar) 的意思就是在交付軟體過程，如同蓋房子，要先蓋地基與支柱，然後才能疊加其他的東西、蓋牆壁、放水電管線等，對應到軟體開發也就是開發、測試、維運任務。
Pillars 的命名想法參考自 AWS Well-Architected
Updated 2023/07/19: 本文收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市
依照四大支柱的描述，整理過去寫的文章列表，以及對應到這四個 Pillars 的關係：
整理導入 EC2 Auto Scaling 到新的系統、新架構過程中，在團隊協作溝通、前中後的技術確認、以及常見問答 … 等問題。
EC2 Auto Scaling 系列文章
整理導入 EC2 Auto Scaling 過程中，常見的問答。
EC2 Auto Scaling 系列文章
EC2 Auto Scaling 是自動控制 EC2 橫向擴展 (Scalable) 的機制，名稱有個 Auto 的字眼，很多同事就會問這樣問題：
不是
Auto了，為什麼還要設定？
這是個好問題，因為大家都以為自動了，就啥都不要管了 XD
實際上自動只是一種最終目的，而整個機制必須保留彈性，讓過程中，如果有非預期的狀況，可以做各種適度的橋整與安排，而這就叫做 Scaling Policies。
EC2 Auto Scaling 系列文章
Auto Scaling 會自動增加機器，也會自動刪除機器，那 Auto Scaling 怎麼知道要砍哪一台？看最舊的？看最新的？還是看心情？
如同前面說描述，一個通用的機制的考慮必須是全面性的，所以接下整理的就是很多人會關心的問題：EC2 Auto Scaling 對 Instance 的 刪除策略 (Termination Policies)。
EC2 Auto Scaling 系列文章
寫文件，對很多人是很痛苦的事情，特別是工程師。不過，我卻一直很享受這件事情，享受重新組織整理知識的過程，因為這個過程獲得最多的是我自己。
我喜歡有這種特質的人：
讀 整個系列的 小說看 整個系列的 電影玩 整個系列的 遊戲聽 整個系列的 音樂用 整個系列的 產品他們對於這些作品，有一系列、完整的體驗、心得、想法、延伸、甚至是創作。
很多技術背景的工程師，隨著年紀與歷練，會有機會帶團隊，成為 Team Lead / Techincal Lead，甚至轉換身份成為管理者。這些轉換很常是學而優則仕、公司上級的期待、被逼上火線 … 但這都算是被動因素，也就是不是自己願意的。
管理 實際上是另一個高度專業的工作，所需要的技能與技術工作者是截然不同的，像是協調、溝通、用人、管人、管事、領導、激勵 … 等看起來像是打雜的任務。因為需要漸漸地放手最熟悉技能 (技術) 讓團隊去執行，也因此很多初任管理工作會常常出現 患得患失 的狀況。
這一收一放，一段時間之後會發現，自己對技術會越來越陌生，跟團隊成員比較起來會越來越不如，很常會被底下的人質疑自己的技術能力，可是頭上戴著主管的帽子，需要做技術決策、選擇、提出建議 … 等，很多人因此就打退堂鼓放棄了，回到純粹的 Tech Leader 的角色。
接下來，我打算整理一些心得，分享從工程師到技術管理者的心得，先以這個問題開始：
管理者如何持續學習技術？
Artifacts Management (以下簡稱 AM) 這個題目很少人在談，大部分 持續交付 也不太會著墨，有趣的是大家每天都在用它，卻從來不知道他是什麼，所以 AM 有以下這三個特色：
大概就是這樣：
有趣的是，Google “Artifacts Management“ 這個關鍵字，我的文章居然是排在第一位。。。表示這題目真的不多人在討論 XD
Updated 2023/07/19: 本文部分內容收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市
延續 K8s 學習筆記 - kubeadm 手動安裝 的整理，本文整理 K8s Cluster 安裝或者維護過程遇到的問題。
K8s Cluster 安裝分幾種選擇：
全自動: Master / Worker Nodes 安裝都不用管，連升級 K8s 版本都不用管，像 GCP 的 GKE半自動: Cluster 的建置與管理是半自動，需要自己處理 K8s 升級。類似產品如下：半手動: 從 VM / Machine 開始就要自己來，也就是本文，主要是使用 K8s 官方工具 kubeadm。全手動: 全都自己來，每個 k8s 的角色都自己安裝，從 kube-apiserver、etcd、kube-proxy … 等。本文整理的是半手動的安裝筆記，也就是以 kubeadm 為主，嘗試過的排列組合 (K8s version x OS x Hypervisor) 如下：
針對開發者本機環境，請參考 Experience minikube、microK8s、K3d、K3s … 等
延續 K8s 學習筆記 - kubeadm 手動安裝 的整理，本文整理一些 K8s 常用的工具，主要參考自 K8s 官方的 Addons。
自從 Ruddy 老師提倡：《專案之初，首重看見全貌》的觀念，這想法與我過去引導團隊的 視野 很雷同。因為我一直用 視野 在思考全貌這件事，這反映了各個組織層面的運作、協作、溝通、產能。
我這邊講的『視野』一詞，可以是 Perspective (遠景)、Aspect (觀點)、View (視圖)、Dimension (維度)、 …
視野包含的 X、Y、Z 軸，三軸構成的整體全貌：
X 軸 - 產品 (Product): 抽象的事，也就是產品的概念，例如 ERP、CMS 都是一些產品Y 軸 - 團隊 (Team): 具象的人群，可以是 技能團隊、跨職能團隊 (任務團隊) 或者 管理團隊Z 軸 - 架構 (Architecture): 具象的物，也就是技術架構與實踐，包含單體架構、微服務、分散式架構 … 等。這些會構成三種主要排列組合 (XY、XZ、YZ)，形成了全貌的層次。除了三軸，另外看不到的是 時間軸 (T)，會牽動 X / Y / Z 的改變，講的是 企業的發展階段。我畫了一張圖，呈現如何用三軸看到視野與全貌在組織運作的關係，底下分別說明三軸的關係。
updated 2019/04/27
這張圖於新竹敏捷社群 Meetup 的分享：導讀持續交付 2.0 - 談當代軟體交付之虛實融合
在 協同合作系統建制與導入 一文中，有個段落在說明 文件管理，主要概念就是如何讓 文件的持續交付 這件事情，在組織裡能夠落實。底下文字整理自今年 02/22 的 草稿
很久以前在研究 nginx 時，過程針對他的 I/O Model 有了初步的了解，但是追本朔源還是經典著作 UNIX Network Programming Chapter 6. I/O Multiplexing，本文整理 BIO、NIO、AIO 等著名的 I/O Models 筆記。
W. Richard Stevens 美國電腦科學家，有多本經典著作，像是
UNIX Network Programming、TCP/IP Illustrated 系列。
整理並且簡譯 Google Blog 文章：Do you have an SRE team yet? How to start and assess your journey 的摘要，這篇文章描述如何建立 SRE 團隊，以及三種階段的 SRE 團隊。
這篇整理去年公車上寫的三段 memo：
基本的概念如下圖：
