底下整理的是這個 Blog 最近更新的文章記錄，如果您是第一次來這裡、或者是老朋友，想要知道我最近更新哪一些文章，可以從這裡知道。

這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的全貌：

• [理念] 思考本質、實踐、抽象、想像力、教育: 這是獨立文章，也是我最想推廣的概念。
• [目錄] 經營管理: 整理我的管理經驗談、管理哲學、經營、領導、用人之道、學習方法、專案管理
• [目錄] 軟體工程實踐之道: 包含軟體架構、開發、測試、維運等 … 實踐的心得。
• [目錄] 雲端應用，包含 AWS、GCP: Cloud 是我這幾年專注的技術領域，這裡會整理相關的學習筆記。
• [參考] 參考書、資訊技術與工程專有名詞、計算機科學專有名詞、經營管理專有名詞
• [關於] 這個部落格、關於作者、學習法則、經營之道、一些領悟

不管是程式、文章、資料還是房間，我都會定期重新整理，基本的概念來自於這篇 分類的哲學

一直很想找一些人，這些人有個特質：喜歡思考事物的本質性、背後的故事、問題、原理、抽象化、延伸、想像，像是：

• 使用 Slack 的時候，他背後可能的系統架構是什麼？
  • 如何讓使用者建立完整的帳號？付費用戶跟沒有付費的架構是一樣的？
  • 他的 AppStore 怎麼設計的？通知機制怎麼設計？
  • API 的架構怎麼規劃？歷史資料如何讓使用者查詢？
• 使用 iPhone 的時候，他對人類的貢獻是？
  • 你會思考他是如何生產的？有多少公司提供零件給他？怎麼整合這些資訊？iPhone 最後如何銷毀？
  • 循環式經濟：智慧型手機十年進化史，有一些事情必須要知道
• 電商帶給消費者方便，他背後的系統是如何運作的？如何面對巨大的交易？電商帶來的社會問題你注意到了？便利另外一面是什麼？人類交易的本質是什麼？
  • 中國電商污染，5 千萬噸垃圾誰來買單
  • Steve Cutts - 諷刺漫畫
  • 過度包裝的迷思：你只是買了更多垃圾
  • 2018/06/15: 超商年丟70億食物？ 300超商加盟店聯手抗議
  • 2019/04/07: 台灣網購1年估計產生8000萬個物流貨箱，「過度包裝」法規卻還管不到
  • 2018/06/28: 亞馬遜爆出巨大醜聞！全新商品「直接銷毀」只為省錢，便利服務全來自資源浪費、勞工血汗
• 聽演唱會的時候，你會注意演唱會整體想表現的情緒？你會注意演唱會主角以外的人事物？最後組成的整體性？
  • LIVE 節目導播在忙什麼
  • 樂團的主唱
• 看電影時，你會注意每個鏡頭想要表達的是什麼？鏡頭是如何取的？有多少個鏡頭？拍攝現場要怎麼準備？演員走位。。。
  • 體育賽場如戰場 攝影師拍攝…跟在後面跑
  • 电影最TOP 104：涨姿势！盘点影史十大经典长镜头
• 看小說時，為什麼會寫出這麼精彩的故事？為什麼會想出 星艦企業號 這樣的劇情？
• 金庸怎麼把小說寫成歷史，把歷史變成小說？ (虛實融合？)

這個 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 的分類、Solution … 等，整理過去的心得筆記。

經營管理 是我正在學習的領域。因為工作職務關係，斷斷續續都有在讀類似的書籍，工作上經常需要思考相關的事情。因為這樣寫了一些比較屬於筆記性質的文字，有時候回來翻翻看看，覺得似乎慢慢形成自己的一套方法與哲學，雖然很多都還不夠成熟與完整，但總是自己的思考的足跡。

分類這些心得如下：

• 思考本質
• 人才、角色
• 經營、領導

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

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

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

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

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

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

一段埋藏在心裡很久的設計想法，有天 在公車上把他敲下來，主要是 IoC (Inversion of Control) 的設計概念。

一段在公車上寫的 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)。

管理工作範圍廣大，人事管理 (Peopele Management) 是其中一個重要的工作範圍，本文整理身為一個管理者必須面對的課題：資遣、解僱、辭呈。

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

2018/10/21 GitHub 發生重大的異常，服務中斷超過 24h。事後官方釋出完整的事件分析報告，包含非常詳盡的事件過程、架構、應變等。這篇是我當時整理在 SRE 社群的簡譯，原始連結。

如同電影 薩利機長，SRE 應該要多閱讀 異常事件報告，從中學習應變的方法與經驗，同時也了解別人的 系統架構 為何如此設計，有什麼問題？

整理如何設定 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 Well-Architected Framework Whitepaper (June 2018) 時，提到的 各種架構師 的說明。

AWS CTO 在他的 Blog 提到 Amazon 產品規劃的方法: Working Backwards，最近我把這想法放在 個人、團隊、還有 企業發展 三個地方。

上週 (2019/03/28) DevOps Meetup 分享的主題：聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)，我提出了 軟體交付四大支柱 (Four Pillars of Software Delivery) 的想法，如下圖：

支柱 (Pillar) 的意思就是在交付軟體過程，如同蓋房子，要先蓋地基與支柱，然後才能疊加其他的東西、蓋牆壁、放水電管線等，對應到軟體開發也就是開發、測試、維運任務。

Pillars 的命名想法參考自 AWS Well-Architected

依照四大支柱的描述，整理過去寫的文章列表，以及對應到這四個 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 常見問答