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

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

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

分類這些心得如下：

• 思考本質
• 人才、角色
• 經營、領導
• 軟體工程
• 系統維運, DevOps, SRE
• Redmine 應用與整合

AWS 範圍很大，有系統的學習是必要的。就像以前學音樂一樣，從各個面向整理 學習地圖，試著拼這張圖，過程中就可以知道自己哪裡還有缺，把缺的補上 (擁有技能)、把圖拼出來 (擁有知識)、把他們連結 (Connected and Linked) 起來 (產生智慧)、用他們創造 (產生創意)。

底下這張 mindmap 則是我自己的分類、重要性、以及學習的進度狀況，用以看到全貌：

以下依照 AWS Services 的分類，整理過去的心得筆記。

昨天跟同事聊到識人、用人，我提出這樣的想法，要知道一個人能否解決問題的前提，這個人要意會到什麼『是真實的世界』，舉例個誇張點的例子，例如：

有些人是活在被保護的環境之下長大的，從來就不知道：坐車是要錢的、漢堡不是從樹上長出來的、飛機是人造的，牛肉不見得是牛做的 …

這例子聽起來很誇張？是嗎

整理資料，回顧之前寫的東西，常常覺得這些就是要不斷地拿出來提，特別是分散式系統 (Distributed Systems) 已經是現代架構的常態，他就跟組織一樣，要面對各式各樣 依賴性、內外聚合、可控性、可治理、可觀測、網路拓墣、效能、快取、錯誤處理 … 等問題，這些問題不只可以對應到系統，也可以對應到人、組織 (康威定律)。

整理 分散式通訊系統 (Distributed Message Systems) 相關的基本概念，包含名詞定義、常用情境、實作技術、架構樣式、以及參考資料。

在整理 Overview API Gateway 一開始就提到關於 架構的可視性 (Visibility) 的問題，討論了可能的應用場景與實務架構問題。當時 AWS 的 API Gateway 並沒有 Private 的概念，預設只有 Regional 和 Edge 兩種類型，而且都是 Public。跟同事討論架構時，大家提出內部服務也需要 Gateway 達到類似限速、安全性控管的功能。

今天一早起來看到 API Gateway Private Endpoint 終於發佈了！期待已久，簡單整理筆記與心得！

上上週在一個 公開的演講 (Monitoring) 之後，去搭捷運時遇到一個陌生朋友，走過來跟我握手，說他聽了我某次的 演講之後 (Ops as Code) ，很有感，講到他遭遇的問題、處境，這次他又特別來聽我講，我心想：大概就是遇到同溫層吧，我只是把那些問題點出來而已～很高興他的 Feedback，讓我又更確認這些問題不是只有我一個人遇到。

幾個月前跟朋友聊到架構的問題，那時候我們在外面一起吃飯，我坐在一根柱子旁。

Role And Responsibility 簡稱 R&R，用軍中術語就是：

• 軍階 / 官階：士官長 (兩粗三細)、上校 (三顆梅花)、將勳
• 職務 / 任務：連長、營長、旅長、總司令、部長

Role 談的是能力，也就是 技能 (Skills)
Responsibility 談的是責任，達成什麼 任務 (Mission)

底下整理我在思考這件事情過程的思路以及分析。

整理某天 (04/14) 跟同事聊到 獨立思考 這個題目，整理一些想法。

整理在 OS X 使用 Go Version Manager 的筆記，類似於 Node.js 的 NVM ，方便設定 golang version 的管理工具。

《產品、組織有沒有靈魂，看名字就知道了。你的兒女會隨便取名？》

《軟體開發流程要有 魂 與 體，敏捷精神 是魂，協作系統則是 體。》

新版的 AWS Certified Developer (Release June 2018)，考試代號 (DVA-C01)，範圍果然改了，多不少東西。

關於 SRE CH34 章提到跨領域的 緊急應變 (Emergency Response) 例，我舉了比較不同的領域：音樂 驗證同樣的概念。

由 DevOps Taiwan 主辦的活動： Monitoring Tools 大亂鬥

準備的時候思考要講什麼，整理以下的觀點：

• 談「武」、還是論「俠」？ (務實、務虛；肉體、靈魂)
• Target Audience (TA) 為什麼來？
• 我能給什麼？

Stages in Software Testing 提到過去因為需要自動化 Regression Test，然後設計、開發 Test Framework / Architecture 的經驗。最近也有人在問我怎麼做這件事情，重新整理一下這段經歷的分享，補充了一些資料。

本文延續 Amazon API Gateway 裡很重要的觀念：限速 Rate Limit、Throttling、Burst 等概念。

Rate Limit 概念在 SRE CH21: 處理系統超載 (Handling Overload)、Service Mesh 都有直接關聯。

整理如何使用 Amazon API Gateway 當作 Proxy 直接存取 DynamoDB，而不需要透過 Lambda。

接續前一篇 Compare GCP VPC Network with AWS 的整理，繼續整理如何透過 VPN 把 GCP 和 AWS 的 VPC 串接起來，形成 Hybrid Cloud 架構。

在 PTT Soft_Job 看到這篇討論： 敏捷課程觀察心得

我的看法跟這位差不多，不是反對敏捷，覺得敏捷就是種『軟體開發管理』的『原則』、『方法』、『概念』、『精神』 … 用我個人的詞彙來說，就是『有節奏的軟體開發方法』

音樂沒有節奏，就不是音樂。

導入能否成功，跟團隊、組織、文化很有關係。

敏捷宣言 沒有啥規則，就是概念，換言之『抽象』。抽象的好處是，怎麼解釋都可以，最後太抽象會衍生出各式各樣的分支，或者因為講者個人特色，變得很有特色，有點像是宗教。如果團隊、組織沒意會到是在做 軟體開發 的工作，而是用工廠的思維在管理，那『敏捷』到最後是穿西裝打領帶的宗教儀式。

底下整理一些觀察到的現象與想法。

整理 AWS 2018Q2 還有 AWS Summit San Francisco 2018 發表的新功能。

前一篇 『導入 CI/CD 的第一步』提到了一些基本觀念、想法，這篇繼續整理一些關於 軟體開發過程，怎樣的 CI/CD 才算是有品質。一般介紹 Jenkins、Gitlab CI、Drone 的課程重點在於怎麼利用工具串接 CI/CD Pipeline 的 Task / Jobs，除了這些，怎麼讓 CI/CD 真正達到團隊合作，我想是非常重要的。

底下是我看 CI/CD 做得好不好的 驗證點 (Verification Point)，夠不夠 Quality 就看這些了 (好像在做認證一樣 XD)：

1. (主詞) 可否任意建立需要的環境？
2. (主詞) 可否驗證任意版本？
3. (主詞) 如何配置 (Configure) 整個系統？
4. (主詞) 可否隨意建立模擬資料？
5. 收集回饋機制
6. 產品開發團隊有哪些人？

由 DevOps Taiwan 主辦的活動： Monitoring Tools 大亂鬥

我會用：人們不會買你買什麼；他們買你的為什麼 這個角度切入，分享一些想法、實務經驗，有興趣的朋友一起來聊。

延伸閱讀

• Serverless All-Star - Ops as Code using Serverless
• 淺談系統監控與 CloudWatch 的應用 - AWS User Group Taiwan
• What is Monitoring?
• Observability and Monitoring

這是今天 (2018/03/29) 在 iThome 主辦的活動 - Serverless All-Star 分享的主題： Ops as Code using Serverless，主軸如同過往，用問題開場、以說文解字切入，然後帶到 現場 (Live, 真實案例)，帶出新技術的價值，強調 軟體工程 的重要性，最後帶到反思。

先不談 CI/CD 的定義，或者 DevOps 是啥。

企業導入 CI/CD 的第一步，先在內部解放 Build / Artifact / Configuration 的觀念，目的是要讓 Developer 以外的人員，能夠獨立部署產品，獨立確認產品的樣貌，提高靈活度。

在 Stages in Software Testing 一文有提到 系統驗證測試 (System Verification Test) 的基本概念。這裏整理前一個工作做教育訓練的資料，主要描述的是以 User-Facing 為主的系統，像是 iOS / Android 的差異。

這 Slide 用比較自嘲、調侃的方式呈現，配合當時的熱門的話題，時間點是在 iPhone5 (2012/09) 上市的時候。

整理前一個工作做教育訓練的資料，本來對象是給 SQA (Software QA) Team 的教育訓練，後來發現這個題目，所有人都要會，也就是 如何有效的回報問題

所有人 指的是：團隊裡的每一個人。實務上很難，所以要一起討論、學習。以測試角度來看，就是 如何有效的回報 Defect / Bug，底下的截圖是以前教育訓練的資料，隨著時間的演進，現在看起來還是有一些參考價值吧？

文中用 Issue 統稱 Defect、Bug 這些 議題。更多參閱 Issue Tracking in Redmine

繼續整理 Amazon API Gateway 的整合應用：如何使用 API Gateway 透過 NLB (Network Load Balancing) 整合 VPC 內部的服務與資源。

原定時間是 2017/12/07 ，後來改到 2018/03/29，活動名稱改為 Serverless All-Star，我的主題沒有改變: Ops as Code using Serverless，歡迎大家來彭場！

這場演講的 Slide 請參考 Serverless All-Star in 2018 (Public Slide)

SRE 這本書並不是很容易入門的，書中有不少東西是滿技術性的，但也很多屬於觀念、原則、經驗方法。所以如果非技術背景或者管理階層的朋友，想要閱讀 SRE，推薦閱讀以下章節，可以了解一些原則與概念。

太技術性的章節我先過濾掉，以下是原文的 Link (英文)。

• Part I Introduction
  • CH01 緒論 Introduction
• Part II Principles (指導原則)
  • CH03 Embracing Risk 擁抱風險
  • CH04 Service Level Objectives 服務水準的目標
  • CH08 Release Engineering 發行工程
• Part III Practices 具體實踐
  • CH11 Being On-Call
  • CH12 Effective Troubleshooting
  • CH13 Emergency Response 緊急應變
  • CH14 Managing Incidents 緊急事件管理
  • CH15 Postmortem Culture: Learning from Failure 事後檢討：從失敗中學習
  • CH16 Tracking Outages 事件追蹤
• Part VI Management 管理
  • CH31 SRE Communication and Collaboration in SRE 與其他團隊的溝通與協作
• Part V Conclusions 總結
  • CH33 Lessons Learned from Other Industries 其他產業的實務經驗

如果只能挑一章來讀，我推薦 CH15 事後檢討：從失敗中學習 ，建立良好的回饋與循環，讓團隊漸進式地變好。這也是 “DevOps” 的精神之一。

如果可以選擇一段主題，我推薦 CH11-16，都在討論 上線後 要面對的問題還有平常的訓練。

API Gateway 是直接面對使用者的，所以除了 API 本身的描述，面對 Client 的 Endpoint / URL Path 的規劃也很重要，相對應的就會帶出 DNS、SSL、CDN … 等議題，而這些問題，通常上線後都才會注意到。但實際上規劃的不好，不只門面不好看，同時也會造成開發、測試、管理、溝通 … 等成本。

本文整理如何使用 Amazon API Gateway 和 AWS 的 Certificate Manager (ACM)、Route53 設定 Custom Domain Name，還有更重要的是規劃完整的 Service 與 Endpoint 要注意的事情。

本文延續 Overview API Gateway 相關筆記，整理在 Amazon API Gateway 中， 如何使用 CloudWatch Logs (以下縮寫 CWL) 找問題、Debugging，設定包含以下：

• Enable CloudWatch Logs for API Gateway
• Enable API Logging for Stage
• Custom Access Logging

春節前一週個週末，因為一個服務系統異常，讓我又重新 review 關於 File Descriptor (以下簡稱 FD) 的概念。上次整理 已經是兩年前的，再重新讀了相關資料，整理以下部分：

• FD 基本概念
• 設定層級，以及各個層級的詳細設定方法和關係
• FD 應用場景與問題