Thinking, Coding, and Learning.

先生不知來自何方,亦不知歸去何處,年過而立,參悟生與死,淡泊名與利,但憂天下蒼生。蹤跡走紅塵,藏身山林田野,撫琴於搖滾,振筆於網路,傳道於教學;神遊金庸武俠,往返程式思考,常以此樂而忘眠。... 更多關於我

Read More

EC2 Auto Scaling 是自動控制 EC2 橫向擴展 (Scalable) 的機制,名稱有個 Auto 的字眼,很多同事就會問這樣問題:

不是 Auto 了,為什麼還要設定?

這是個好問題,因為大家都以為自動了,就啥都不要管了 XD

實際上自動只是一種最終目的,而整個機制必須保留彈性,讓過程中,如果有非預期的狀況,可以做各種適度的橋整與安排,而這就叫做 Scaling Policies

EC2 Auto Scaling 系列文章

Read More

Auto Scaling 會自動增加機器,也會自動刪除機器,那 Auto Scaling 怎麼知道要砍哪一台?看最舊的?看最新的?還是看心情?

如同前面說描述,一個通用的機制的考慮必須是全面性的,所以接下整理的就是很多人會關心的問題:EC2 Auto Scaling 對 Instance 的 刪除策略 (Termination Policies)

EC2 Auto Scaling 系列文章

Read More

再談『為什麼寫文件?』 2019/04/03 10:30:00

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

Read More

將與才之『縱觀全局』 2019/04/02 01:21:00

我喜歡有這種特質的人:

  • 整個系列的 小說
  • 整個系列的 電影
  • 整個系列的 遊戲
  • 整個系列的 音樂
  • 整個系列的 產品
  • ….

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

Read More

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

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

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

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

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

Read More

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

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

大概就是這樣:

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

Read More

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

Read More

K8s 學習筆記 - 工具篇 2019/03/17 19:41:58

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

Read More

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
    • 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 … 等

Read More

自從 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 - 談當代軟體交付之虛實融合

Read More

文件的持續交付 2019/03/10 19:55:31

協同合作系統建制與導入 一文中,有個段落在說明 文件管理,主要概念就是如何讓 文件的持續交付 這件事情,在組織裡能夠落實。底下文字整理自今年 02/22 的 草稿

Read More

Study Notes - I/O Models 2019/02/27 22:30:00

很久以前在研究 nginx 時,過程針對他的 I/O Model 有了初步的了解,但是追本朔源還是經典著作 UNIX Network Programming Chapter 6. I/O Multiplexing,本文整理 BIO、NIO、AIO 等著名的 I/O Models 筆記。

W. Richard Stevens 美國電腦科學家,有多本經典著作,像是 UNIX Network ProgrammingTCP/IP Illustrated 系列

Read More

SRE Team Lifecycles 2019/02/04 12:43:00

整理並且簡譯 Google Blog 文章:Do you have an SRE team yet? How to start and assess your journey 的摘要,這篇文章描述如何建立 SRE 團隊,以及三種階段的 SRE 團隊。

Read More

這篇整理去年公車上寫的三段 memo:

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

基本的概念如下圖:

Read More

閱讀能力的重要性 2019/01/20 21:42:30

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

Read More

天賦與努力 2019/01/12 21:42:30

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

Read More

2018 的思考隨記:上半年 2019/01/10 21:42:30

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

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

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

2018 的思考隨記:下半年 2019/01/10 21:42:30

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

Read More

關於 DevOps 的討論與想法 2019/01/08 12:39:00

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

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

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

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

Read More

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

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

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

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

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

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

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

Read More

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

Read More

IPv6 基本概念 2018/11/29 10:30:00

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

Read More

Products Naming for AWS 2018/11/18 19:35:00

我心裡一直有這樣問題:

AWS 有些產品用 Amazon 開頭(像 Amazon EC2、Amazon API Gayeway、Amazon CloudWatch),有些則是用 AWS 開頭(像是 AWS CloudFormation、AWS Lambda、AWS IoT),如下圖:

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

Read More

心得:持續交付 2.0 2018/11/14 22:30:00

今年 (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 - 談當代軟體交付之虛實融合

Read More

混沌工程 (Chaos Engineering) 2018/10/08 18:53:00

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

Read More

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

Read More

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

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

Read More

事件管理與康威定律 2018/09/23 12:43:00

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

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

Read More

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

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

Read More

接續上一篇 萬事起頭難:面試名單從哪來?,這篇整理的是面試篇。

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

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

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

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

Read More

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

Read More

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

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

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