DevOpsDays Taipei 2021 簡短記錄

感謝所有的贊助商、講師、社群、以及報名參加的所有與會者的支持，最終經過多次延期的 DevOpsDays Taipei 2021 已於 2021/11/24 在臺北文創大樓 6F 順利舉辦。今年一樣擔任大會籌備人員之一，但老實說由於 COVID-19 疫情的緣故，所以個人能投入在籌備工作上的心力不比往年，這次活動能順利舉辦，真的要感謝 iThome 在籌備工作、金流、物流、人力全方位的全力支持，以及 iThome 辦活動大神 Chris 的辛勞。今年一樣用一篇簡短的文章，紀錄與本次大會相關的所見所聞。

活動基本資料

官網：https://devopsdays.tw
日期：2021/11/24 09:00 ~ 17:30
地點：臺北文創大樓 6F
議程：共 17 場（含 3 場 Keynote）
工作坊：共 13 場
贊助商：共 25 家
活動人數：超過 500 人
活動共筆：https://hackmd.io/@DevOpsDay/2021

開場

我的部分

今年還是被推坑負責 10 分鐘的開場，老實說直到活動舉辦的前一晚，我都還在思考開場到底應該要講些什麼？最後還是決定順著當時閱讀《一個 Scrum Master 的獨白》這文章時獲得的感動，想要提一下「反思」這件事情。

因此最終就如我事後在 FB 貼文中做的簡短分享，這次開場主要想分享幾件事情：

DevOps 從 2009 年出現至今，已經超過 10 年了。
台灣大約是從 2014 年開始有人浮上水面談論 DevOps 議題，至今也差不多 6-7 年了。
DevOps 是個「不新」的東西了，那麼你目前實踐 DevOps 了嗎？實踐的狀況如何？
DevOps 是個「開放」的議題，人們對於它有著不同的觀點、期待與想像，那麼你又是如何描繪你所謂的「實踐 DevOps」？
反思，當一個關鍵字熱門與普遍到一個程度之後，我們應該對它有更多的反思。同樣再回到前面幾點，過去、現在 DevOps 在談討哪些議題，世界的趨勢潮流正往何處發展？台灣的 IT 圈內又是如何看待它？更延伸的如何看待各界各方推崇的各種「實踐方法」、「認證」、「解決方案」、「工具」⋯⋯
延續反思，也許我們應該回歸初衷，思考為何當年會舉辦第一場 DevOpsDays，為何 Flickr 可以在 2009 就讓 Dev 與 Ops 合作，進而實現一天部署 10 次以上，以及為何 Patrick Debois 會說 DevOps is a human problem。也許 DevOps 最核心最單純的就只是想要解決「讓人(Dev)與人(Ops)可以良好的合作協作」，它的初衷目標想要解決這項「人」的問題，於是眾人圍繞著初衷，開始持續不斷運用各種方法及工具來「持續改善」的解決它。
最後一點是實踐，DevOps 是需要逐步實踐的，別人的 best practice 也許用在自己身上只剩下 good practice！？正是因為如此，我們期待未來可以有機會，在更多的場域，聽見來自不同產業及規模的組織，分享更多元的 DevOps 實踐經驗，彼此借鏡、彼此學習、彼此成長。

其實開場講稿，重寫了好幾遍，也腦中練習了好幾次，但上台時只記得「老東西、反思、初衷及實踐」這幾個關鍵字，希望最終在台上的表現不會太差，感謝大家的包容啦。

也要感謝 iThome 總編輯臨時更改上台順序，讓我可以先上台開場，第一個講壓力比較小，不用擔心梗被人講走。

iThome 總編輯吳其勳

總編輯的開場以 Status of DevOps Report 為主軸，說明在實踐 DevOps 的企業中，領先者與落後者的差距已大到驚人，並提到 DevOps 經歷了第一個 10 年，現在將往下一個 10 年邁進，已經有不少受到 DevOps 啟發而誕生的新議題在持續發酵，企業需要思考如何跟上這一波的轉型，因為未來企業交付價值的能力會與這些風潮息息相關。

議程心得與重點筆記

今年有很多主題都很有興趣，可惜我不會火影忍者的影分身術，幾經爭扎之後選擇了 Keynote > Keynote > Keynote > ABC > ABC > ABC > DE。（以下筆記內容如果有誤，歡迎通知我修正，畢竟難免有可能聽錯、寫錯、理解錯誤。）

TSMC DevOps Journey

來自護國神山台積電的 DevOps Journey。這場只能說是歎為觀止，記錄幾個有感的重點。

IT 部門人員約 2000 人，需要服務的使用者約 4~6萬人，因此每一個異動的影響範圍很大很廣。
講者在當年 iThome 剛開始自行舉辦 DevOps Summit 時就已接觸到 DevOps 議題，便開始想要導入 DevOps。
近年又因為台積電來了一位新任的 CIO，從 CIO 那邊獲得更多支持。
導入目標：
- 全面 IaC
- 獲得足以因應蓋廠速度的 Scale up 能力
- 促進文化轉變
- Project Mode -> Product Mode
台積電是一間完全仰賴「軟體」運作的企業，若沒有軟體，工廠將完全無法運作，而工廠沒有產出，公司就沒有收入，因此 IT 與公司能否交付價值是十分相關的。
導入期間請了很多講師來訓練 100 多人的 DevOps Team。
提到許多 IaC 帶來的好處
半年的時間完成全面導入 K8s、容器化。以 K8s 讓 Infra 變得更加可控、可管、一致化。
全面 as Code 反而讓一些審核、稽核、維護變得更容易。
透過舉辦 Boot Camp 逐漸轉變員工觀念，重視 Value 而非 Due Date。
重視 Quality，更優良的 IT 環境、撰寫品質更好的 Code。
梗：工廠早上跟你說，希望軟體可以趕快更新功能，但下午你真的要去更新時，又跟你說不要亂動我的環境！對工廠而言，他們真的是想要一個功能又好、但又令人可以安心作業的環境。
因為台積電本身已是重視數據驅動的企業文化，因此能以 KPI 來驅動變革。但也有輔以其他角度的 Review 措施，避免因為 KPI 而獲得錯誤的成果。

這幾年來我們經常能聽見純軟或偏軟體公司的 DevOps 經驗談，但像台積電這種高科技製造業的案例仍屬少見，這次台積電的經驗分享讓我們有機會一窺不同產業的 DevOps Journey，同時看見另一種「 IT 能力 = 交付價值能力」的真實情境。

談假設思維之下的開發者體驗

Ruddy 老師這次的主題「談假設思維之下的開發者體驗」並不是第一次講，這是我第二次聽老師談同樣的主題。但老師上一次是線上演講，當時的專注力頗差，沒有太多記憶點，這次可以聽見實體演講覺得收穫比上次多。這次的重點記錄如下：

為什麼要關注開發者體驗（Developer Experience，縮寫 DX）？問：「剛入職的新人很容易犯錯，這是誰的問題？」答：「要讓系統本身可以防範這樣的錯誤。」
開發者體驗：以開發者為中心，思考「人與人」、「人與程式」的互動。就算你是一人開發者，你也很難避免需要和其他人及程式互動。設置一條路徑，讓開發者可以更好地完成他的任務，避開路途中的坑，更專注在重要的開發任務。
假設思維：假設 + 驗證，可以更快速的解題。
假設思維：先做假設，收集數據，然後驗證它。快速做假設、快速驗證它。
軟體開發工作量中，9 成都消耗在附屬性工作，只有 1 成是在做有價值的本質性工作，因此消除附屬性工作，即可有效提升效率。
假設思維可對應三步工作法的第三步，持續假設、持續驗證、持續學習。
Debug 可能是工程師最快進入心流的時刻，特別是火燒起來的狀況下。（笑）
只是注重軟體發佈很快、一天可以交付很多次是沒有意義的。舉例來說，對銀行的使用者而言，一天交付多次他不一定會感到高興。（雖然開發者可能會很高興，因為可以快速收到回饋。）
API First 雖然乍看會覺得這種做法在某些地方很麻煩，但反之你要想這是一種「開發者體驗」良好的方法。
思考如何拿掉開發者的痛，最大化開發者的效率。

Ruddy 老師這場分享有兩個主軸，即是「假設思維」與「開發者體驗」。演講前面先說明了何為「開發者體驗」，接著說明什麼是「假設思維」，最後將兩者結合在一起，並且說明這些與 DevOps 的關聯。這場分享我最大的收穫是，發覺「實現更優良的開發者體驗」這不就是一條實踐 DevOps 的路線嗎？就如老師說的解決那些擾人的「附屬性工作」，投注在有價的「本質性工作」，或是開場提到的，讓系統本身可以防範會令人炸鍋的錯誤；你不覺得這些必須從組織、流程、架構、系統層面著手的改善措施，聽起來很 DevOps 嗎？或者我們換個範例，你為何想要實現所謂的「一鍵部署」？或想要盡可能將一切可以自動化的工作全都自動化？又或者是想要建立一個可以發覺各種問題的 Monitor Dashboard？這些措施聽起來又是不是有點像「開發者體驗」呢？回歸 DevOps 初衷，DevOps 有很多議題都是在談如何讓流程更順暢，既然如此從「開發者體驗」不也是一條很好的路線嗎？或者換句話說有沒有一條名為「Dev + Ops + ⋯⋯ 體驗」的路線呢？

Running and Operating Large Scale Real-time Data system on Cloud

來自趨勢科技 Cloud Architect 吳家威的分享，今年大會第三場 Keynote，很慚愧的是，這一場我注意力不集中，有聽沒有到，因此留下記憶比較少。

這次分享的 Real-time Data system 是已經運作於 Production 的服務。
需要及早思考會造成瓶頸的原因，例如假設每秒你都需要送一次 Qurey 到 DB，這樣你一分鐘至多能處理多少 Qurey？那當量級繼續擴大時你該怎麼辦？
善用 Dashboards 來察覺系統是否有潛藏的問題。例如：他們有遇到一個狀況是理論上負載應該是會平均分配至各主機，但透過 Dashboard 發現就是有一台主機很閒，因而追查到是某個環節有一個 Bug 導致的。
Fix tech-debt v.s. Building features。這需要與公司討論可以在日常工作中安排多少比例投入在處理技術債，將技術債納入應該要做的工作項目。
Speed v.s. Quality。設定一個可被員工接受的指標，例如請問測試做到多少覆蓋率時，你會覺得晚上可以睡得比較安穩？
Rewrite、Rebuild、Replace。要強調「Re」並不意味著否定前人的作為或認為前人沒有做出貢獻，要知道是前人寫出來的程式，解決了當年的需求，成為現在的基礎，要看重先行者們貢獻的價值，「Re」是為了讓產品可以邁向下一哩路。

整場最有印象的就是講者在談到「Rewrite、Rebuild、Replace」那一段提到要看重先行者們貢獻的價值，我覺得這是一個很正向的心態與想法，當時的事就該留給那個時候，我們應該要感念前人奠定的基礎，因為有這些基礎，此時此刻你才有機會延續它繼續邁進。（謎之音：畢竟不管前人寫的 Code 好壞或 Bug 與否，總是讓現在的你有一份工作可以做下去啊！）（謎謎之音：不要亂解讀好嗎！？）

過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱

由於有私下與 Tim 交流過，知道他對於實踐 DevOps 有一套自己的見解與看法，因此他這場分享我也是期待了很久，這次聽完果然令人滿意，重點記錄如下：

重新調整目標
- Dev: 建立工程管理加速遞交價值
- Ops: 導入新工具提升流程效率
- Biz: 獲取回饋拓展銷售機會
成效
- 提早發現合規性的問題。
- 減輕維護實體機的壓力，導入虛擬化技術，也實現仿真環境壓測。
- 借助虛擬化 + 雲端，讓展銷變得更容易。
實踐 DevOps，越是能實現多次交付價值，就越有機會從前線收集回饋，進入假設、交付、驗證、學習的循環。
藉由 DevOps 打穿整個價值交付。這才是 DevOps 帶來的真正的好處，做再多 CI / CD 內的優化與改善，但沒有與價值產生關聯，那也會是無意義的。
工作流程的建立，本身就是一種知識管理。讓開發者可專注在有價值的工作上。
Product Team v.s. Function Team，後者其實是一種先求分工再求合作的模式，那個合作所指的是自己同部門的合作，而跨部門之間擁有的只是分工。
當 IT 團隊的目標不含「軟體產品服務」時，你的 IT 團隊就只是成本中心。
在 Wiki 上我們都看過一張 DevOps 圖片，圖片內容是 Dev + Ops + QA 三個圈的交集。但在現實情境中，邁向 DevOps 的路途過長，經常是 Dev 被迫自幹 QA 與 Ops，因為難以在初期立即撼動既有的 QA 與 Ops 部門加入這淌混水。
2C 與 2B 的交付流程與價值流是不同的。
BizDevOps = 以 Biz 引領 DevOps 推動。當你建立具有商業價值的循環後，才更有力持續推動 DevOps。
三步工作法是玩真的。
實踐 DevOps，你需要平衡每個人的期待，然後讓企業持續交付價值。
總結
- 處理人與組織的問題。
- 自動測試是加速循環的關鍵。
- 釐清價值流，以商業目標驅動。
- 目標與溝通重於工具與流程。
- 持續演化才是最佳策略。

聽完 Tim 這次的分享，覺得他的 DevOps 人生體悟又往前進了好幾步。我個人很喜歡也認同 Tim 對於 BizDevOps 的見解，透過這場分享，幫助我更釐清對於 BizDevOps 的一些想法，同時也再次感受到，似乎當企業的 DevOps Journey 走到一定程度之後，在其中推動 DevOps 實踐的主事者或參與者，都會產生一些類似的見解，這是否也可以說是一種驗證，證明多年來 State of DevOps Report 中提到的各種觀察與見解都是真的，IT Revolution 的那一票專家們提出的觀點與出版的書籍也不是隨便亂講亂寫的。（謎之音：你看了這麼多人家做的 Report、寫的好書，居然還懷疑它嗎？）

貧困老舊保守環境下的 DevOps／敏捷實踐？

先說聆聽這場演講的內心感受大概是這樣的：

好棒的題目，一定要好好的聽一下。
喔喔喔，看起來內容非常豐富！
好可惜，這邊快速帶過。
好可惜，又只能快速跳過。
這一點講得好棒，可惜不能再多深入一點。
這點很重要，想聽，啊，又加速了。
啊，沒時間，要進總結了。

董大偉老師分享的內容很棒，有很多基於擔任顧問從實務而來的經驗談，也是我拿起手機拍照最多次的一場演講，不過我現在回憶起來最大的感想則是「一種好匆忙的感覺啊～」，一樣記錄幾個重點：

The Facts：台灣大多數是 200 人以下的中小企業；大多數的就業人口在中小企業；中小企業相對缺乏數位化基礎。
持續整合：持續頻繁地整合，到團隊像是只有一份程式碼；而這一份程式碼必須隨時可以交付運行。好比 Trunk based development。
持續交付：使用者可以隨時取得最新的、高品質的、符合需求的系統。
在輔導客戶接受這些實踐方法時，應該要回歸簡單，這些方法其實它們的本質很單純，但為何導入卻很困難？因為會遭遇與現況的衝撞。
整條 DevOps Pipeline 每一個 Stage 都有好多議題可以討論，如何測試、測試策略、如何部署、環境管理、如何協作⋯⋯
面對這麼多議題，到底該如何開始 DevOps？先簡化需求，設立短期目標，
Scrum 可能沒辦法幫你解決問題，只是幫助你知道自己在哪裡。
很多尋找顧問的客戶其實自己都知道問題在哪裡，他們只是不想為改變負責，所以希望由顧問帶來變革。
沒有帶來安全感，就沒有辦法帶來改變；沒有設立明確的目標，就沒有辦法帶來價值。
顧問在協助變革時，不可能產生無限的「推力」，一昧的加大推動力道，只會引發更多「阻力」，你需要建立「成果」，讓「阻力」自然下降，使「推力」大於「阻力」。
TOC，Theory of Constraints 限制理論、Value Stream Mapping 價值流程圖是好工具，例如價值流程圖可用來突顯 Pipeline 的改善成效。
問：「怎麼樣的一群人才是『一個團隊』？」，答：「有共同的目標。」
需要有願景、目標，以及落後指標和領先指標。
- 願景 = 成為一個健康的人。
- 目標 = 減重。
- 落後指標 = 三個月內減少 10 公斤。
- 領先指標 = 減少攝取的卡路里，增加運動量。
敏捷的回顧會議（Retrospective）與不究責的 Postmortem 很重要，但可能不容易做到，舉例：電商網站員工設錯價格，導致公司損失數十萬元，如果你是主管，你會怎麼做？
沒有犯錯就不會成長，沒有成長就不會自我管理。
視覺化、透明度、持續改善、交付價值。

董大偉老師分享的內容很多很廣，感覺上超出演講題目「貧困老舊保守環境下的 DevOps／敏捷實踐」，根本是將需要花費數日的企業內訓內容直接拿來演講，我覺得董大偉老師應該自己單獨開一場 David Days 的活動，給他無限制的時間一直講下去。

接案公司的 DevOps 之路

有別於大型研討會經常出現的大企業、大架構、大團隊，各種高大上主題，這場由五倍紅寶石帶來的接案公司 DevOps 經驗，反而更吸引了我的注意。再加上知道「蒼時弦也」這號人物很久了，卻一直沒有機會目睹他的廬山真面目，這又更加讓我下定決心要聽這場演講。

一開場講師就說自己今天是來說故事的，會從他 2016 加入五倍紅寶石開始至今為止，按著年份逐一說明每一年在開發流程上做了哪些改變。

2016
- 看情況才寫測試，重要的功能才寫測試。
- 嘗試了 Jenkins。
2017
- 試試傳說中的敏捷開發、估點數、燃盡圖。
- 寫更多測試，但不知道測試是否有產生實際的價值。
- 開始使用 GitLab CI。
- 開始有完整的 Lint 與 Unit test，以測試作為 DevOps 的起步，發覺有助於找出常見的漏洞。
2018
- 試了 K8s，但最後放棄，因為生態系尚不完善，且客戶那邊不給用、用不到。
- 開始使用 Ansible，讓過往手動配置組態的工作，全面標準化、自動化。
2019
- 開始使用 Packer，為了配合 Auto Scale up，用來打包 VM。
- 開始讓專案皆能被容器化。
- 導入了 Proxmox 虛擬化技術。
2020
- 導入 Sentry 作為 Error tracking。
- 導入 Sonarqube 協助評估技術債。
- 公司工程師數量邁入 20 人。
- 導入 Traefik，選用原因是它可以不用跑在 K8s 上單獨使用。
- 導入 Consul 作為 service discovery。
- 導入 Nomad。
- 以上面三個工具作為組合技，加上專案都已經能被容器化，因此不再需要人工設置測試環境，可以自動長出來。
2021
- K8s 又回來了，因為使用 Nomad 在某些地方卡住了。
- 續上，因為想要動態生成 branch 測試環境，如果要用 Nomad 實現，變成要動態生成 Nomad 設定檔，有點麻煩。
- 導入 Longhorn。
- 整合 GitLab Auto DevOps，但覺得 Auto DevOps 的 Templates 有很多地方寫得不好，速度很慢，可以自己改良。
Review
- 為什麼要走這麼多年？因為很多事情自己想做，但同事、客戶不一定想做。接案公司並不是所有的專案都能導入任何東西。
- 為什麼作法改來改去？以 K8s 為例，當年接觸時生態系不完善，但現在已經很成熟。重點是持續改善。
- 為什麼要做這些改善？減少附屬性工作，讓時間可以更多投入在有價值的工作。
- 做這些的好處？更容易及早發現錯誤，修正錯誤。
- 未來希望 DevOps 的每一個環節都能實現。

五倍紅寶石的 DevOps Journey 乍聽之下沒什麼高潮迭起，但我覺得這才是平易近人的真實人生，就像前面董大偉老師提到的那些中小企業的 The Facts，畢竟並非每一家企業都能快速順暢地走上變革之路，推力與阻力、企業資源分配、工具與技術的演進，這些都會對持續改善帶來不同程度的影響，DevOps Journey 是一條比耐力的漫漫長路啊。

大型團隊落實 CI/CD 的挑戰

這場我只能說「不愧是首席架構師！」，令人開闊視野，整場滿滿的都是寶，就不條列重點了，因為全部都是重點，大家自己去看講師簡報吧，而且依據 Andrew 的習慣，應該幾週後，他又會有感而發，撰寫數篇相關的文章公開在部落格上，因此我就只簡單分享一下我的心得感想——如果用一句話來說的話，就是 Ruddy 老師常說的那句「看見全貌」。

我覺得這場演講主題雖然掛上了「大型團隊」，但其實 Andrew 提出來的解決方案並不限用於「大型團隊」，就如他所說的「大型」是有很多面向的，是流量大？架構大？複雜度大？還是哪邊大？而 Andrew 點出的 CI/CD 挑戰關鍵是「複雜度」；如果你的產品或 Pipeline 很單純，沒什麼複雜度，那本場演講的情境可能不適用你，又或者你並不需要走向 Andrew 構思的解決方案也能夠應付 CI/CD 遇到的問題。但若是你也開始感覺你的 CI/CD Pipeline 越來越複雜，Config、Code、Environment、Artifacts 的管理開始耗盡心力，那這場演講的內容就可以為你帶來許多啟發。

條列幾個自己很有感的地方：

清楚的解明造成 CI / CD 複雜度增加的關鍵因素，Infra、Code、Config、Environment。
思考如何將 A x B x C 的複雜狀況，轉變成 A + B + C 的單純解法，用簡單來化解複雜問題。
以 docker-compose.yml 為例，簡單明瞭的解釋了 Deploy 需要處理的三種 As Code。
DevOps 精神，落實從 Ops 取得回饋，透過 Dev 來實現，推動不斷改善的循環。需要持續改善的不只是產品，也包含了整個流程，如果改變 Code 或 Application 的架構有助於降低 CI/CD 的複雜度，你改不改？
實際可用的改善建議。（參閱講師簡報 P.38）

如果你也聽過 Andrew 不止一次的演講，你應該會發現他經常會說「以架構師的觀點⋯⋯」，雖然乍聽之下他只是在分享一個觀點上的轉換，但這不就是一種「退後 n 步，看見全貌」嗎？因為改變觀點，視野也就跟著改變了，架構師站在一個更高的觀點去看待需求與問題，尋找更高層次且全面的解決方案。有時第一線的工程師們真的會太糾結在處理眼前的問題而陷入盲點，急著想找各種能立即套用的解決方案，但也許真正該做的就是「退後 n 步，看見全貌」，從更高層次的角度切入問題的關鍵，就如這場演講內容那樣。

講師簡報

附上目前在 FB 上看見已公開的講師簡報。

【補充】有部分講師是勾選不提供簡報的，其餘願意提供的講師簡報，iThome 會在收集完畢後，直接在官網上提供下載。

結語

除了感謝還是感謝，總之一句話，期盼我們明年能繼續在 DevOpsDays Taipei 活動上相見！所以說「想要當『大神』嗎？」可以從現在開始準備投稿議題喔！

轉貼本文時禁止修改，禁止商業使用，並且必須註明來自「艦長，你有事嗎？」原創作者 Cheng Wei Chen，及附上原文連結。

DevOpsDays Taipei 2021 簡短記錄

活動基本資料

開場