這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的全貌：
不管是程式、文章、資料還是房間，我都會定期重新整理，基本的概念來自於這篇 分類的哲學
底下整理的是這個 Blog 最近更新的文章記錄，如果您是第一次來這裡、或者是老朋友，想要知道我最近更新哪一些文章，可以從這裡知道。
| 更新時間 | 更新方式 | 文章標題 | 發布時間 |
|---|---|---|---|
| 2020/03/22 | 重構文章 | Study Notes - EC2 Auto Scaling 常見問題 | 2019/04/04 |
| 2020/03/10 | 增加段落 | 你的靈魂 - 談產品名稱的命名 | 2018/06/08 |
| 2020/03/04 | 增加段落 | Chaos Engineering (混沌工程) | 2018/10/08 |
| 2020/02/29 | 增加段落 | Why Container | 2020/02/08 |
| 2020/02/08 | 增加段落 | Whitepaper - AWS Well-Architected Framework | 2016/11/27 |
| 2020/01/08 | 增加段落 | Whitepaper - Using AWS for Disaster Recovery | 2019/09/09 |
| 2020/01/31 | 增加資料 | 再談啥是維運？ | 2018/06/14 |
| 2020/01/02 | 增加段落 | 關於軟體測試，一些觀察到的現象 | 2019/10/30 |
一直很想找一些人，這些人有個特質：
喜歡思考事物的本質性、背後的故事、問題、原理、抽象化、想像、實踐方法
像是：
星艦企業號 這樣的劇情？這個 Index 整理跟 軟體工程實踐 相關的文章，重點在 實踐與執行，主要內容包含以下：
(Research)：研究新技術相關資料，計算機科學、網路、資料結構、演算法，新技術應用(Execution)：執行管理的實踐方法，像是 Redmine 應用與整合、相關工具 (VSTS)、敏捷、看板等概念(Development)：程式、Design Patterns、OOP、資料庫應用(Acceptance)：Quality Assurance and Testing(Go Live)：軟體到 現場 (Live) 的前、中、後，像是 Provisioning、CI/CD、部署流水線、環境、SRE、Monitoring、Observability、事件管理AWS 範圍很大，有系統的學習是必要的。就像以前學音樂一樣，從各個面向整理 學習地圖，試著拼這張圖，過程中就可以知道自己哪裡還有缺，把缺的補上 (擁有技能)、把圖拼出來 (擁有知識)、把他們連結 (Connected and Linked) 起來 (產生智慧)、用他們創造 (產生創意)。
底下這張 mindmap 則是我自己的分類、重要性、以及學習的進度狀況，用以看到全貌：
以下依照 AWS Services 的分類、Solution … 等，整理過去的心得筆記。
經營管理 是我正在學習的領域。因為工作職務關係，斷斷續續都有在讀類似的書籍，工作上經常需要思考相關的事情。因為這樣寫了一些比較屬於筆記性質的文字，有時候回來翻翻看看，覺得似乎慢慢形成自己的一套方法與哲學，雖然很多都還不夠成熟與完整，但總是自己的思考的足跡。
分類這些心得如下：
溝通就是把資訊從自己腦袋裡挖出來，然後透過載體，像是用語言、文字、圖畫、藝術、肢體 …. 傳達給另一個人，讓對方知道你在想啥。溝通的理想結果是彼此 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 度低溫、加上下著雨，依舊準時出席讀書會，走完這次最後的章節。
今年一整年，起了好幾個跨部門、跨組織的任務，在這過程一直在嘗試讓一個成員、或者讓一個團隊可以自主完成任務的方法，過程中踩了很多雷，像七傷拳一樣，常常是還沒發拳自己就先中了內傷，內力不夠深厚打七傷拳才會傷到自己，後來慢慢梳理出一套可以執行的方法，年底也看到成果了。
除了這些大範圍的協作，工作上經常交付任務給團隊執行，交辦的方式會是口頭交辦、公開的指派、正式的賦予權責，交辦的對象則有自己團隊的資深、到資遣成員，協作團隊的成員 … 不管怎樣的交付任務，都需要一個有效的方法來確立目標是可以執行。
這篇整理了一些歷程與土炮方法，分成以下幾個部分：
CloudFront 是 AWS 非常重要的服務，用了幾年，斷斷續續有一些心得與想法，這次換個方式整理筆記，先全部用 Q and A 方式記錄學習。
本文整理的 Delivery Method 以 Web 為主
最近有朋友問我一些測試的問題，問題層面很廣，像是去一家新創 Startup 如何 Build Up QA Team？自動化測試該用哪一套？測試的方法論該怎麼落地？聊到後來我發現問題背後的期待有問題，期待是什麼？
測試想要一步到位
基於這個前提，後來我把觀察到的現象與問題寫下，起筆是 2018/07/03 的隨筆，陸陸續續整理以下文章：
這篇文章整理上述文章的想法與整合。
本文的思路，後來整理成專文： 如何意識到問題的存在
這幾年工作關係，經常讀一些資料，但有幾篇是經常重複閱讀、重複分享，這幾篇文字影響我很多，整理起來需要分享時比較快 XD
所有文章標題都是原文連結。
整理 EKS 的 Networking 相關的問題，主要有規劃、管理 … 等觀測，如下：
這段個別剪接出來的三分鐘錄影，是今年 (2019) 四月我在新竹敏捷 (交大) 分享的，我稱為 軟體交付的三體問題。
整理相關 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 相關) … 等，還是需要額外規劃。
筆記內容：
這也是個朋友問的問題，問題截圖如下：
先不管誰有沒有穿褲子，從整體來看，重新整理問題：
系統發生異常時，第一時間如何快速止血？
底下整理我經常在處理分析時的思路。
淺談效能測試 整理了關於 Capacity、Reliabilty、Stability 的概念與定義。本文針對如何量測 系統容量 (Capacity)，整理怎麼做的方法論，可以當作 Capacity Plan Guideline。
系統容量是透過
量測 (Measure)出來的，結果是數據統計的報表，而測試的結果通常是 pass or fail，故本文的描述不用測試這個動詞。
這篇文章整理的是如何執行的概念，但不包含以下：
CloudWatch Agent (底下簡稱 CWA) 是 awslogs 的後續版本，提供了更強大的功能與整合能力。整理 CWA 的基本概念、如何安裝與配置、以及常見問題。
本文範例為
地端 (On-Premise)Linux (Ubuntu 16.04) 為例。
幾段隨筆，談 IoC / DI 與管理的想法。
以下這張照片是 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 上的資訊。
簡譯這篇精彩的分享：Scaling Infrastructure Engineering at Slack
才 2.5y ，就可以把整個 Infrastructure Engineering 弄成這樣的規模。她提到的有很多情境，架構、招募、組織 … 很有感 … XD
要聽她說 (她有點激動 XD) 。。。
Using API Gateway as DynamoDB Proxy 一文提及可以透過 API Gateway 直接整合 DynamoDB ，而不一定要透過 Lambda，其實 Lambda 只是大家最常整合的服務而已。同樣的概念，其實 API Gateway 可以直接整合除了 Lambda 之外的很多服務，像是 DynamoDB、SQS、Step Functions、Kinesis、 … 等。
延伸這個應用，我很常被問的一個問題：
發送給 API Gateway 的請求，會不會掉？怎樣避免 Request 遺失？
這個問題很多人都問過我，本文提供一個架構設計的想法。
