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

我喜歡有這種特質的人：

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

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

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

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

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

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

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

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

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

大概就是這樣：

有趣的是，Google “Artifacts Management“ 這個關鍵字，我的文章居然是排在第一位。。。表示這題目真的不多人在討論 XD
Updated 2023/07/19: 本文部分內容收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市

延續 K8s 學習筆記 - kubeadm 手動安裝 的整理，本文整理 K8s Cluster 安裝或者維護過程遇到的問題。

延續 K8s 學習筆記 - kubeadm 手動安裝 的整理，本文整理一些 K8s 常用的工具，主要參考自 K8s 官方的 Addons。

K8s Cluster 安裝分幾種選擇：

1. 全自動: Master / Worker Nodes 安裝都不用管，連升級 K8s 版本都不用管，像 GCP 的 GKE
2. 半自動: Cluster 的建置與管理是半自動，需要自己處理 K8s 升級。類似產品如下：
   • kops: Master / Worker Nodes 都自己裝，除了這些，也包含網路規劃、權限等
   • EKS: Master Node 由 AWS 管理，使用者管理 Worker Nodes，詳細筆記參閱：K8s 安裝筆記 - AWS EKS
   • Experience EKS Anywhere: AWS OpenSource 的 EKS 版本，可以安裝在自己的環境。
3. 半手動: 從 VM / Machine 開始就要自己來，也就是本文，主要是使用 K8s 官方工具 kubeadm。
4. 全手動: 全都自己來，每個 k8s 的角色都自己安裝，從 kube-apiserver、etcd、kube-proxy … 等。

本文整理的是半手動的安裝筆記，也就是以 kubeadm 為主，嘗試過的排列組合 (K8s version x OS x Hypervisor) 如下：

• QNAP Virtualzation Station
  • Ubuntu 20.04:
    • 1.21.1
    • 1.23.4 (2022/03)
  • Ubuntu 18.04:
    • 1.16.14
    • 1.18.0, 1.18.6
    • 1.14.7, 1.14.9
• Proxmox
  • Ubuntu 18.04:
    • 1.18.0, 1.18.6
    • 1.14.7, 1.14.9
  • Ubuntu 16.04:
    • 1.11.3
• VMWare Fusion (macOS)
  • Ubuntu 18.04:
    • 1.18.0, 1.18.6
    • 1.14.7, 1.14.9
  • Ubuntu 16.04:
    • 1.11.3
• AWS EC2
  • Ubuntu 16.04:
    • 1.11.3

針對開發者本機環境，請參考 Experience minikube、microK8s、K3d、K3s … 等

自從 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：

1. 2018/10/16: 談 Issue Tracking 在組織裡的價值 - 知識管理
2. 2018/12/05: 談議題管理層次
3. 2018/11/28: 複雜的資訊流，造成的資訊落差

基本的概念如下圖：

這篇文章是我在 FB 上寫的 隨筆，重點在於閱讀能力的重要性。

整理關於 天賦 與 努力，一些普遍人錯誤的認知，原文是我 2018/07/07 寫在 facebook 的 草稿。

有時候樂手在舞台上表演的時候，同一首歌彈了幾百次、甚至幾千次，彈久了即興是理所當然的。但可能因為現場氣氛、溫度、當天晚餐的食物、空氣的味道、聽眾的情緒 …. 眾多因素，最後即興出一段自己都不知道怎麼彈出來的經典，事後也很難彈出那樣的感覺與味道。有些我個人喜歡樂手的 Live ，同一首歌重複找了 n 個版本，錄音室版、Live、Unplugged、Rock、Orchestration、Pinao、Acoustic Guitar …. 通常會有幾版本特別的棒，但也就出現那一次而已。

很多想法，是在特定情境、時空背景之下疊加出來的，而那些時空背景激盪的想法，在事後回顧的時候，會想，為什麼平常的我想不出這樣的東西？底下的截圖，是 2018 年我在特定條件之下，寫下的想法整理，有些有公開，有些則沒有。

• 因為是私人的筆記，所以圖中的人名就馬賽克了。
• 整理過程發現有點多，拆分成 H1、H2 兩篇。

延續 上一篇 的整理，這篇整理 2018 年下半年的思考隨記。

這篇整理我 2018 年在 DevOps Taiwan 發言過的文字，談論到的包含軟體測試、持續交付、Artifact Management、軟體開發流程、維運 … 等，主要是記錄一些想法、觀念、觀察、經驗分享，然後截圖作紀錄。

這些文字發文的時間大多在上下班的公車路上，可以集中精神的狀況留下的，一些想法都是透過討論以及問題激盪出來的。

• 因為是公開發言，所以文中的人名我就不馬賽克啦 XDD
• 為了避免爭議，發言以截圖方式紀錄。

經過漫長的 確認需求、撈單、一面、二面、談薪資、確認報到時程，新人總算報到了，然後就可以放鬆了？是這樣嗎？這篇整理新人報到後，要做的工作有哪些。

2021/09/24: 本文授權 1111 人力銀行 轉載：【HR懶人包】新人到職教戰守則：訓練、目標、關切和評核

本文整理 SRE 讀書會 Round 2 的討論與筆記。問題是：

團隊 Release 的角色是否應該專職？ (不管是叫 DevOps Engineer, Release Engineer, or SRE)

那天 (2018/09/13) 討論的章節是 第七章 提交階段，我在回程公車上寫下這段 筆記，重新整理成文章，也補充一些想法。 這問題討論通常到最後會分成兩種：

• 不該專職：團隊成員輪著做，不應該專職 (偏向 Agile 的概念)
• 應該專職：技術 know how 很深，應該專人專職 (偏向傳統、大型組織)

我想想都對、也都不對，因為這兩個都沒有提到 前提條件與背景，這樣的討論不會有結論。我從以下幾個面向分析：

• 企業階段
• 架構與組織
• 產品特性

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

本文整理 2018/12/07 我寫的一篇論述：DevOps 8 字環的誤區。

整理 AWS CTO - Werner Vogels 著名的論文: Eventually Consistent (ACM), (Blog) 重點與筆記。

整理 IPv6 的基本概念。2016 AWS VPC 支援 IPv6 之後，就沒在研究相關課題，只大概做過一些資料。

我心裡一直有這樣問題：

AWS 有些產品用 Amazon 開頭（像 Amazon EC2、Amazon API Gayeway、Amazon CloudWatch），有些則是用 AWS 開頭（像是 AWS CloudFormation、AWS Lambda、AWS IoT），如下圖：

底下整理我對於命名前置詞命名的猜測。

今年 (2018) 三月，我在公司內完成長達半年的 SRE (Site Reliability Engieering) 讀書會，快結束時就在盤算下一本候選書，希望激盪團隊更多想法。那時候首選就是當代軟體工程的經典之作：持續交付 (Continuous Delivery)。

在讀書會開始不久，有次跟朋友聊到持續部署想法，當時我提到因為時空背景的關係，這幾年各種新的概念與技術快速發展，特別是雲端架構應用、微服務與分散式架構的實踐概念，彷彿不斷的在提醒大家，持續部署 應該有不同的想法與實踐。當時的筆記如下圖：

同時 DevOps 與敏捷開發 (Agile Development) 概念鋪天蓋地的出現，大家意識到 霧卡世界（VUCA) 正在驅動整個軟體產業，除了持續部署，持續交付商業價值將面對更大的挑戰！VUCA 是 Volatility（易變性）、Uncertainty（不確定性）、Complexity（複雜性）、Ambiguity（模糊性）的縮寫。

戰爭之前，不管做了多少參謀作業，戰爭第一聲槍響的時候，所有計畫都會隨之改變。

– 美國名將 麥克阿瑟

雖然世界變化之快，常常讓人迷失，但變化越快，越要靜下心思考。正當我在思考，是否將這些資訊做通盤整理，彙整成更有意義的文字時，十一月七日早上，是立冬之日，Ruddy 老師在我桌上放了一本書，作者是人稱喬幫主的喬梁老師大作，書名：持續交付 2.0。當時的我心裡想：『嗯，我想要的，應該都在這裡面了。』

2019/04/27 於新竹敏捷社群 Meetup 的分享：導讀持續交付 2.0 - 談當代軟體交付之虛實融合

整理一些關於 Chaos Engineering 的資料。

上一篇 薪資 討論商討薪資背後的考量，這一篇整理薪資確認後要做的後續工作：確認報到時程

上一篇簡單整理了招募的 第三篇：價值觀，這一篇繼續整理很多人很在意的：薪資。

盡量用客觀角度來討論這件事情，但這是不容易的。

補充在 DevOpsDays 演講中，為啥在會特別強調 SRE 是面對落地的架構，而不是設計架構？這段內容本來是放在 Slide 要講的，後來拿掉了。我用 樂團總譜、練團溝通 來比喻 架構圖呈現、團隊溝通，其實要表達的是 康威定律：

系統架構與組織有著一定的關係，同時這關係會帶來團隊溝通成本問題。

接續上一篇 招募第一關 面試，這篇整理的是第二次面試 (以下簡稱二面)。二面不見得每個公司都有，有些可能會在一面就一次談完。依照面試的職位、職等、企業類型會有所不同，創業公司通常會直接跟 VP、CTO、CEO … 等階層聊，大型企業可能只到 Director，如果是高階通常都會到 CEO 或者 Co-founder。

一面最重要的是確認技能，二面確認價值觀。

接續上一篇 萬事起頭難：面試名單從哪來？，這篇整理的是面試篇。

面試是很多管理者（特別不習慣面對人的技術管理者）要學習的重要課程，也可能是第一個面對公司內部、客戶以外的人：從社會來的任意一個陌生人。

面試的目的在於找到 適合的人，要清楚以下本質：

• 面試是用人手段，透過面試了解是否適任，了解彼此，為彼此找到適合方向
• 面試是雙向的，面試官在面試別人，面試者也在面試這家公司
• 用人不只是技能，還有價值觀，反過來也是考驗企業文化是否對到面試者的頻率
• 面試只是其中一種篩選方法，吃飯喝茶、喇低賽、三顧茅廬也是面試。

底下整理面試方要準備的工作。

DevOpsDay Taipei 2018 兩天半的盛會，今天總算順利落幕。今天我分享了過去工作上，面對緊急事件的心得與歷程，同時彙整了 SRE 的重點，分享了這個在大會中，相對特殊的主題。不同於兩個月前的 AWS Summit，這次我不談技術、也不談高大上的數據、也不用新潮的用語，而只談如何面對 緊急異常 這件事，同時也分享了如何培養應變能力的方法與思路。

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

接續 前一篇：準備篇 的介紹，繼續整理招聘的心得：萬事起頭難，名單從哪來？

一般人找工作要不是主動投履歷，要不就被動等待通知面試。從招募角度也是，用人單位的面試名單不會從天上掉下來，這些名單要不是主動找來源，要不就被動等待。不管主動、被動，都要面對以下的幾個問題：

• 面試名單從哪來？
• 如何過濾、篩選名單？
• 為什麼面試意願不高？

整理人力招募的起手式 準備篇：確認需求、條件、定位、市場狀況。

今年 (2018) 有很多時間都放在如何作 人力招聘 (Hiring)，這系列文是整個過程中的心得、想法、遇到的問題。文章是從管理者、用人主管 角度出發，談到如何從需要資源開始、如何向上溝通、與人力資源協作、面試名單從哪裡來、如何面試、如何談薪資、報到之後如何確認符合需求 … 等。

2021/04/24: 本文授權 1111 人力銀行 轉載：聊聊人力招募：你到底是在Hiring還是Recruiting？

整理 CAP 理論的筆記。