這段個別剪接出來的三分鐘錄影，是今年 (2019) 四月我在新竹敏捷 (交大) 分享的，我稱為 軟體交付的三體問題。

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

整理相關 EKS 的學習筆記，包含規劃 (Planning)、建置 (Provisioning)、管理 (Management / Operation) 等。

上一篇 整理了使用 kubeadm 安裝 K8s Cluster / Worker Nodes / CNI … 等，同樣的，本文整理使用 AWS EKS 安裝 K8s v1.14 的筆記，安裝過程則以 AWS CLI 為主，同樣方式也可以使用 eksctl、AWS Console、CloudFormation 執行。

如同之前提及，雖然 EKS 是 Managed Service，但是實際上只有針對 Master Nodes，而 Worker Nodes 還是需要自行管理以及維護的，另外針對 Ingress、使用者權限、Log 蒐集、資源監控、網路 (CNI 相關) … 等，還是需要額外規劃。

筆記內容：

1. 準備: IAM User, IAM Role, VPC Subnets
2. 建置: EKS Master Nodes, ConfigMap, CNI, Worker Nodes
3. Q and A

這也是個朋友問的問題，問題截圖如下：

先不管誰有沒有穿褲子，從整體來看，重新整理問題：

系統發生異常時，第一時間如何快速止血？

底下整理我經常在處理分析時的思路。

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

淺談效能測試 整理了關於 Capacity、Reliabilty、Stability 的概念與定義。本文針對如何量測 系統容量 (Capacity)，整理怎麼做的方法論，可以當作 Capacity Plan Guideline。

系統容量是透過 量測 (Measure) 出來的，結果是數據統計的報表，而 測試 的結果通常是 pass or fail，故本文的描述不用 測試 這個動詞。

這篇文章整理的是如何執行的概念，但不包含以下：

1. 介紹工具
2. 環境如何建置
3. 如何設計架構
4. 如何優化架構

20230523 更新: 本文全文收錄在 共同著作《軟體測試實務》 第二冊 第一章之中，歡迎大家彭場指導。

CloudWatch Agent (底下簡稱 CWA) 是 awslogs 的後續版本，提供了更強大的功能與整合能力。整理 CWA 的基本概念、如何安裝與配置、以及常見問題。

本文範例為 地端 (On-Premise) Linux (Ubuntu 16.04) 為例。

1. 體驗
2. 簡介
3. Q and A

朋友 Scott Liao 問了一個好問題：

底下整理當時在 FB 上的想法。

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

幾段隨筆，談 IoC / DI 與管理的想法。

一段在公車上寫的 memo，問題是：

什麼是好軟體？

這段 memo 談的是： 逆向工程與系統架構

以下這張照片是 Jan, 2015 在 AWS Virginia Data Center 火災的照片：

圖片來源： Amazon data center on fire in Virginia - CNN

其實災難，不管是個人還是在企業，隨時隨地都有可能發生。當企業成長到一定的規模，災難還原計畫，就越來越重要。但是做災難還原準備工作，本身在公司裡面不是所謂的 產出 任務，他屬於 備援 計畫，而且災難復原在傳統的 IT 架構裡，所需要的預算、人力、資源、時間是相當龐大的，大部份的老闆，對於這件事情是不會支持，或者也不太願意投資的。最多做所謂的 異地備援 就算是很不錯的了。

以下整理 Whitepaper - Using AWS for Disaster Recovery (Oct, 2014) 內容。大部份的圖檔都是文件裡擷取出來。

整理 Linux 效能工具 top 的一些資訊，範例是在 ubuntu 16.04, AWS EC2 c5.large 上的資訊。

原文是我 03/26 在公車上寫下的 memo，主要是依照 開會原則 提及的想法，整理看到的問題。

簡譯這篇精彩的分享：Scaling Infrastructure Engineering at Slack

才 2.5y ，就可以把整個 Infrastructure Engineering 弄成這樣的規模。她提到的有很多情境，架構、招募、組織 … 很有感 … XD

要聽她說 (她有點激動 XD) 。。。

這篇也是我在上下班路上，在 Facebook 寫的 隨筆。問題如下：

朋友問：要不要去考證照？

這算是老問題。我分成幾個層次來看這件事情：

1. 基本技能
2. 解決問題

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) 是其中一個重要的工作範圍，本文整理身為一個管理者必須面對的課題：資遣、解僱、辭呈。

這段文章原本是寫在 FB 的 memo，放在 分類的哲學 一文中，獨立成專文。

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 供參考。

記錄 之前 寫下的 Service Catalog 的概念。

敏捷三叔公 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 系列文章

• Study Notes - EC2 Auto Scaling 基礎介紹
• Study Notes - EC2 Auto Scaling - Scaling Policies
• Study Notes - EC2 Auto Scaling - Termination Policies
• Study Notes - EC2 Auto Scaling - Lifecycle and Hooks
• Study Notes - EC2 Auto Scaling 導入與應用
• Study Notes - EC2 Auto Scaling 常見問答

整理導入 EC2 Auto Scaling 過程中，常見的問答。

EC2 Auto Scaling 系列文章

• Study Notes - EC2 Auto Scaling 基礎介紹
• Study Notes - EC2 Auto Scaling - Scaling Policies
• Study Notes - EC2 Auto Scaling - Termination Policies
• Study Notes - EC2 Auto Scaling - Lifecycle and Hooks
• Study Notes - EC2 Auto Scaling 導入與應用
• Study Notes - EC2 Auto Scaling 常見問答

EC2 Auto Scaling 是自動控制 EC2 橫向擴展 (Scalable) 的機制，名稱有個 Auto 的字眼，很多同事就會問這樣問題：

不是 Auto 了，為什麼還要設定？

這是個好問題，因為大家都以為自動了，就啥都不要管了 XD

實際上自動只是一種最終目的，而整個機制必須保留彈性，讓過程中，如果有非預期的狀況，可以做各種適度的橋整與安排，而這就叫做 Scaling Policies。

EC2 Auto Scaling 系列文章

• Study Notes - EC2 Auto Scaling 基礎介紹
• Study Notes - EC2 Auto Scaling - Scaling Policies
• Study Notes - EC2 Auto Scaling - Termination Policies
• Study Notes - EC2 Auto Scaling - Lifecycle and Hooks
• Study Notes - EC2 Auto Scaling 導入與應用
• Study Notes - EC2 Auto Scaling 常見問答

Auto Scaling 會自動增加機器，也會自動刪除機器，那 Auto Scaling 怎麼知道要砍哪一台？看最舊的？看最新的？還是看心情？

如同前面說描述，一個通用的機制的考慮必須是全面性的，所以接下整理的就是很多人會關心的問題：EC2 Auto Scaling 對 Instance 的 刪除策略 (Termination Policies)。

EC2 Auto Scaling 系列文章

• Study Notes - EC2 Auto Scaling 基礎介紹
• Study Notes - EC2 Auto Scaling - Scaling Policies
• Study Notes - EC2 Auto Scaling - Termination Policies
• Study Notes - EC2 Auto Scaling - Lifecycle and Hooks
• Study Notes - EC2 Auto Scaling 導入與應用
• Study Notes - EC2 Auto Scaling 常見問答