底下整理的是這個 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 … 等，整理過去的心得筆記。

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

分類這些心得如下：

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

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

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

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 在 re:Invent 發佈後，是我非常有興趣的功能。本文整理 Step Function 的學習筆記。

去年翻譯了這本書： 分散式系統設計 (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 常見問答

整理導入 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 常見問答

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 常見問答

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 常見問答

寫文件，對很多人是很痛苦的事情，特別是工程師。不過，我卻一直很享受這件事情，享受重新組織整理知識的過程，因為這個過程獲得最多的是我自己。

我喜歡有這種特質的人：

• 讀 整個系列的 小說
• 看 整個系列的 電影
• 玩 整個系列的 遊戲
• 聽 整個系列的 音樂
• 用 整個系列的 產品
• ….

他們對於這些作品，有一系列、完整的體驗、心得、想法、延伸、甚至是創作。

很多技術背景的工程師，隨著年紀與歷練，會有機會帶團隊，成為 Team Leader / Techincal Leader，甚至轉換身份成為管理者。這些轉換很常是學而優則仕、公司上級的期待、被逼上火線 … 但這都算是被動因素，也就是不是自己願意的。

管理 實際上是另一個高度專業的工作，所需要的技能與技術工作者是截然不同的，像是協調、溝通、管人、管事、領導、激勵 … 等看起來像是打雜的任務。因為需要漸漸地放手最熟悉技能 (技術) 讓團隊去執行，也因此很多初任管理工作會常常出現 患得患失 的狀況。

這一收一放，一段時間之後會發現，自己對技術會越來越陌生，跟團隊成員比較起來會越來越不如，很常會被底下的人質疑自己的技術能力，可是頭上戴著主管的帽子，需要做技術決策、選擇、提出建議 … 等，很多人因此就打退堂鼓放棄了，回到純粹的 Tech Leader 的角色。

接下來，我打算整理一些心得，分享從工程師到技術管理者的心得，先以這個問題開始：

管理者如何持續學習技術？

Artifacts Management (以下簡稱 AM) 這個題目很少人在談，大部分 持續交付 也不太會著墨，有趣的是大家每天都在用它，卻從來不知道他是什麼，所以 AM 有以下這三個特色：

• 沒啥存在感
• 很少人知道這是什麼
• 大部分『持續交付』的書不會談

有趣的是，Google “Artifacts Management“ 這個關鍵字，我的文章居然是排在第一位。。。表示這題目真的不多人在討論 XD

整理安裝 Kubernetes 的筆記，主要是以 kubeadm 為主。

K8s Cluster 安裝管理的四種選擇：手動 (kubeadm)、半自動 (kops)、自動 (EKS)、全自動 (GKE)

自從 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 (2018/10/16)，主要是討論 Issue Tracking 在企業裡的價值，我的結論：

隨著時間的前進與企業的發展，他 應該 是內部的 知識管理庫 (KM)。

基本的概念源自底下這張圖：