DevOps

就用一篇部落格文章來紀念本次參與籌辦 DevOpsDays Taipei 2017。  約莫在今年二月底的時候，注意到了北京將會舉辦 DevOpsDays Beijing 的消息，看著網路上傳來的資訊，當時心裡並未多想，只是想著：「哇，沒想到北京在今年加入響應舉辦 DevOpsDays，去年亞洲區好像只有新加坡舉辦的樣子？北京辦得如此盛大，不知道會不會有哪個好心人願意舉辦一場屬於台北的 DevOpsDays。」 接下來的日子陸續傳出北京的各種消息，包含注意到 Ruddy 老師在臉書上貼出了北京的照片，因為老師受邀擔任北京的其中一位講者，老師還秀出他與 DevOps 之父 Patrick debois 的合影。接著在 2017/3/22 當晚，Ruddy 老師便主動傳訊息給我，鼓勵可以嘗試舉辦屬於台灣的 DevOpsDays，並且告知要與 DevOpsDays 官方搭上線並沒有想像中的困難。  雖然 Ruddy 老師推了一把，但其實在當時我自己心中的想法是：「想要辦這樣的大活動，必定要動用不少的資源，包含資金、人力、人脈與熱情。今年就先調查一下狀況，也許明年 2018 再來看看有沒有機會號召眾人一起來舉辦。」 不過萬萬沒有想到，雖然自己在心中是這樣許願，但現實世界卻默默之間急速運轉了起來。  接下來急速運轉了哪些事情呢？ 首先是 iThome 主動地表示希望能與社群有更多的合作機會，而我隨口一提的意見「那就一起來辦 DevOpsDays Taipei 吧？」，卻獲得 iThome 谷社長與吳總編輯一致表示有高度的興趣。 接著向 DevOps Taiwan 社群的志工們詢問意見，志工們也一致贊成。 最後，因為談到 DevOps 時，其主題與 Lean、Agile 密不可分，因此我嘗試邀約 Agile Community Taiwan 的前輩柯仁傑一起參與首次的籌辦會議，結果會議一次就順利談妥三方共同主辦 DevOpsDays Taipei。（其實那時還稱不上是正式的籌辦會議，比較像是先試著確認彼此有沒有共識，有沒有機會合作。） 原本我自己還想著明年才來考慮要不要籌辦的想法，在數週的時間內就被替換成「木已成舟，今年非辦不可」。 於是各式各樣的籌備工作就這麼迅速展開： 與 DevOpsDays 官方聯繫，取得官方 Guilde，遵照官方 Guilde 籌辦活動。 與官方進行線上會議，確認彼此沒有任何異議。 尋找評估合適的場地與日期。 請設計師設計 Logo。 公開徵稿與私下邀稿。 尋求贊助商。 送 PR 至官方網站，讓 DevOpsDays Taipei 的資訊可以刊登上 devopsdays....

今年（2017）的 COSCUP 採用與過往不同的徵稿方式，而 DevOps Taiwan 社群也共襄盛舉貢獻了三場分享。 縱然我們知道談到 DevOps 時，不該只談論其中的技術層面，更應該要包含文化層面的議題，不過在這種技術力爆表的場子，就請原諒我們還是會以技術為主要的分享內容。 （不過這麼說有失偏頗，因為 COSCUP 2017 還是有像是「如何將女友培養成開源貢獻者」這種軟性的主題，因此只要有心，還是能夠分享非技術主題的。） DevOps Taiwan 這次由三位講者，分別負責一場分享，首先我們邀請了部落格「小城故事不多-科技部」的蔡宗城（smalltown）為我們分享「Infrastructure As Code」。 第二位講者則是大家從小看到大的部落格「凍仁的筆記」其主人凍仁翔，為我們分享「DevOps 人一定要知道的 Ansible & GitLab CI 持續交付技巧」。 最後，則由小弟我延續凍仁翔的題目，帶來一場簡易的 Workshop 「Ansible & GitLab CI/CD workshop 101」。 Ansible & GitLab CI/CD workshop 101 這場 Workshop 在構思時，預定的難度是 101 的程度，但實際動手設計內容時發現要講多淺才算是 101？要多複雜才算是 201、301 或更高的難度？有一些難以拿捏，總之就請各位保持著一種開開心心的心情來跟著下面的內容操作練習即可，到底是 101、201、或甚至根本只是幼幼班就先拋在腦後吧（逃）。 回到正題，這場 Workshop 希望能幫助大家藉由實際操作，能夠體驗看看 CI / CD、Automation，以及當我們在談到開發流程的規劃，關於 workflow 或 pipeline 的規劃時可能要注意些什麼？ 要注意的是，這個 workshop 的案例只是一個簡單的示範，不同的公司、組織或團隊在規劃 pipeline 時會有各自的考量，因此在實際體驗之後，當你回到自己的團隊時，務必要根據你自身的情況進行規劃，如此才能建構出最適合你團隊的 CI / CD pipeline。 所需工具 本次我們會使用的工具如下： Ansible - 我們會利用 Ansible 撰寫一些簡易的自動化腳本。 Docker Community Edition - 用來運行你自己 CI Runner 與模擬 Web Server。 續上，一台可以跑得動 2-3 個 Container 的主機（可以是你自己的筆電、雲端的 VPS，或其他。），預計會消耗 5 GB 以內的硬碟空間，因為在 Workshop 使用的是個人自建又大又肥的 Container。 GitLab....

 （圖說：本次 Meetup 大合照） DevOps Taiwan 社群在 2017/5/17 舉辦了 Meetup #6，因為這是一場充滿實驗性質的 Meetup，因此將主題訂為「實驗、連結、對話與成長」。 感謝 104 資訊科技贊助所有的零食與飲料，以及所有的文具耗材。 感謝極客窩 (Geek Cave) 贊助場地。 感謝 tonypai 願意自告奮勇擔任 Ignite Talks 的其中一位講者。 感謝譚御丰擔任「非技術之主題分享」的講者。 感謝 John Yu 協助場地佈置並在 open space 的時段擔任小幫手。 感謝多位來自敏捷社群的朋友，open space 能順利進行你們每一位都功不可沒。 感謝 DevOps Taiwan 志工群的幫忙。 最後也感謝社群朋友的熱情參與！ 就以此文簡短紀錄一下本次活動。 籌備 Meetup #5 之後，社群又陷入缺講者的狀態，同時社群志工群們各個都被本職工作追著跑，Meetup #6 到底該如何是好？ 但很幸運的，譚御丰當時有參加 Meetup #5，在活動結束之後的閒聊當中，我忽然想起，他所任職的公司即是一間跨國的軟體公司，而這不正是我思思慕慕想要尋找「跨國團隊工作經驗分享」、「跨國企業工作經驗分享」這一類講者的最佳人選嗎？ 真的要感謝譚御丰的幫忙，當下隨口詢問他是否能夠分享與「跨國團隊經驗」相關的主題，內容不管是團隊文化、協同合作經驗、或任何相關的趣事皆可。而他便立即熱情地表示，只要時間上能夠配合，他自己也很願意嘗試挑戰這種非技術類型的主題。 於是，Meetup #6 的講者就這麼幸運的敲定了。而為了配合譚御丰可行的時間，原本兩個月一次的 Meetup，本該是六月才會舉辦 Meetup #6，也就順水推舟的改在五月舉辦。 另外與此同時，DevOps Taiwan 社群與 Agile Community TW 及 iThome 正默默地籌備要舉辦 DevOpsDays Taipei 2017，而其中一個令人擔憂的關鍵便是 DevOpsDays 的一項傳統與特色，即是 open space 開放空間會議。...

 最近沒新梗，只好使用相同的開場白，繼 Meetup #4 之後，很快的兩個月多的時間過去，DevOps Taiwan 在 2017/04/26 晚上舉辦了第五次的 Meetup。 感謝極客窩 (Geek Cave) 贊助場地，感謝 John Yu 擔任本次 Meetup 的講者與引導者，感謝志工群的幫忙。最後同樣也感謝社群朋友的熱情參與！ 就以此文簡短紀錄一下本次活動的林林總總。 籌備 記得應該是在兩個多月前（其實我有點不確定時間先後），也就是 Meetup #4 還沒舉辦之時，在微軟舉辦的 Leadership camp for Community Leaders 遇到了幾位 AgileCommunity.tw 社群的朋友，其中一位就是 John Yu，每次遇到他都會開個小玩笑，聊上一兩句，於是聊著聊著心中便想說，不如請敏捷社群的朋友來幫 DevOps Taiwan 社群補充一些 Agile 與 Lean 相關的主題吧？於是在聊天的當下，當機立斷挖個洞，看看有沒有人會願意跳坑，沒想到還真的成功讓 John Yu 落坑，實在是好人一枚。（顯示為已哭） 經過糾正，發現自已完全記錯事件的先後順序，但唯一不變的事實是，在某次與 John Yu 聊天的時候，我當時當機立斷挖了坑，想要看看有沒有人會願意跳坑，沒想到 John Yu 就這麼落坑了，實在是好人一枚。（顯示為已哭） 在那之後與 John Yu 聊了幾次，本來我個人的目標是從 Agile 或 Lean 的精神切入談 DevOps，但經過討論之後，最後我們將主題調整為直接談談「DevOps 文化」，並且定案讓活動能更具有互動性。 其實我個人這幾年參加了數次敏捷社群的活動，除了知識與經驗分享上的收穫，另一項最大的收穫是「舉辦活動的多樣性」，這也是為何個人目前十分認同社群活動必須建立在人際互動之上。 最後，活動的規劃包含了開場的「破冰 + 分組」與中間的「分組討論」，同時希望能在搶票之時，就盡可能讓多一些主管或意見領袖類的朋友報名，期望讓討論能切入更多的面向。 活動過程  在這次的活動中 John Yu 除了擔任主講者與引導者，其實在活動開始之前他也提供了不少的建議，像是：...

（本文於 2018-06-14 21:56:01 更新。） 在某次機緣之下，與尊敬的 Ruddy 老師針對「 DevOps 推薦書籍」有一些簡單的交流。那時整理了手上的筆記，將收集到的 DevOps 書單整理在本文之中。如果你也有推薦的 DevOps 書單，歡迎與我交流！（本文將持續更新，歡迎推薦 DevOps 好書。） （本文同步發表於 Medium） DevOps 不只涉及觀念，也與許多的工具相關，但因為技術工具書，例如：Ansible、Docker、K8S 這一類著重於工具操作與使用的書籍，通常隨著工具更新的緣故，書籍的壽命都比較短。同時並非每一種工具都適用於所有的團隊，因此這類書籍就不收錄在此書單中。 這份書單會以保存期限較為長久的觀念型書籍為主。 Effective DevOps - Building a Culture of Collaboration, Affinity, and Tooling at Scale 這是一本由技術人撰寫的非技術書籍，本書主要在談 DevOps 文化，圍繞在書名副標的那四個項目 Collaboration、Affinity、Tool、Scale，以文化與組織發展為主軸貫穿全書。另外書籍的前面幾章也針對 DevOps 及 DevOps 相關的關鍵字提供了基本簡介，某種程度可以當成一本 DevOps 入門書，可由此再延伸閱讀更多的書籍。（繁中、簡中） Continuous Integration: Improving Software Quality and Reducing Risk 關於持續整合（CI，Continuous Integration）的經典必讀書籍，缺點是目前沒中譯本。 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 關於持續交付（CD，Continuous Delivery）的經典必讀書籍，比較要注意的是因為英文版是 2010 年出版的書籍，因此書中範例提到的軟體會比較老牌一點。另外，在社群中也有前輩表示現今 Microservices、Serverless 等新觀念抬頭，這本書的部分內容應該可以配合這些觀念而有所更新。（繁中） The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 知名的 DevOps 小說，如果當工具書來讀會大失所望，按其他前輩的說法，此書就是要當成小說與實際案例來看，請細細品味書中的劇情及小說人物遇到的困境，並且對照自己的經歷而有所反思，同時嘗試換位思考如果你是小說內的主角你會怎麼面對問題，如此一來才能體會書中的醍醐味。本書也是讓玄妙的 DevOps「三步工作法」首次面世的書籍。（繁中、簡中） The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations 由目前世界知名的 DevOps 顧問 Gene Kim 與他的好朋友們延續《The Phoenix Project》而撰寫的另一本書。如果覺得看完《The Phoenix Project》之後，對於玄妙的三步工作法依然不得要領，那麼這本《DevOps Handbook》就是你的救星。這本書透過案例與說明幫助你一步步實踐「三步工作法」，這些案例不乏許多知名的公司，像是 Google、Netflix、Etsy⋯⋯。（簡中） The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece 另一本值得列為 DevOps 必讀書籍的輕薄好書。本書簡短、輕快且直擊紅心的點出軟體開發的核心關鍵—交付價值，這也正是藏在 DevOps 背後的重要關鍵。若希望讓你的團隊順利踏上 DevOps 之旅，那麼最好讓組織、團隊及個人皆能共同意識到「交付價值」的重要性。（簡中） Site Reliability Engineering - How Google Runs Production Systems 有些人是這麼評論的 “SRE is Google’s version of DevOps”，在《SRE》書中也自己寫到「SRE 是 DevOps 模型在 Google 的具體實踐」。另外在 Gartner 所推出的 Gartner DevOps Model 中，也可以看見 SRE 有被列入其中。這是一本兼具觀念與技術實務的書籍，內容包含很硬的技術實踐與很軟的團隊文化，對於 SRE 有興趣者非讀不可，另外若對你而言 DevOps 與 Cloud Architect 的關係密不可分，那這也是非讀不可的好書。 The DevOps 2....

今晚 DevOps Taiwan 舉辦了 Meetup #2 。感謝葉秉哲與 Erica Liu 兩位講師的鼎力相助，以及五倍紅寶石出礦坑贊助場地，讓本次 Meetup 能順利舉辦！ 本次活動報名人數 45，實際到場人數約 30，看來免費活動常見的通病依然再次發生。有限名額被占據，但未能到場參加活動，導致其他很想參予的社群朋友沒有名額。這樣的情況實在很可惜，因為今晚的活動真的很精彩，希望能讓更多人可以現場參予。 這次 Meetup 的主題是「思維引導、持續改善，引發團隊改變新契機」。 延續 iThome DevOps Summit 2016 的熱度，我們計畫邀請葉大再次分享在 Summit 中大獲好評的講題「從限制理論看 DevOps」，並期望能讓講題更有感，所以規劃加入小遊戲，透過實際體驗的方式，讓大家能更有所收穫。畢竟觀念很容易聽，但要做卻是不易，特別 DevOps 與團隊文化有關，而人並不是這麼容易被改變的。 主題一：「從限制理論看 DevOps」 同樣的題目「從限制理論看 DevOps」，但本次 Meetup 可是獨家擴充版！比起 iThome DevOps Summit 2016 講得更慢更多更詳細。講題由葉大從多場 Ansible Workshop 中收集到的 DevOps 痛點開始說起，將痛點歸納成 11 大項之後，接著該怎麼解決它們呢？ 一般的想法大概是各個擊破吧？但這樣做正確嗎？會不會是治標不治本？另外，這些問題似乎彼此牽連，好像並不是這麼容易各個擊破的，那該如何處理呢？於是切入本主題的核心重點「高德拉特的『限制理論』」。 葉大藉著一步一步的解釋他如何運用高德拉特的理論來推導前面 11 個痛點的因果關係，讓聽眾彷彿跟著走了一遭，相信有認真聽講的朋友，應該不時在心中點頭，並且腦袋也跟著一起運轉了一回。 當透過推導畫出 CRT 圖表之後，再拿它對照原本的 11 個痛點，恐怕大家都會希望自己的團隊中，也能經歷這樣的過程，將單一的問題轉化成有系統的 CRT 圖表，讓問題可以像串肉粽一樣的產生關聯，找出真正的肉粽頭，從源頭解決核心問題。 這場分享並未到此打住，接著再回到另一個重點「老闆主管都是豬頭嗎？」，我們應該正面一點，「老闆主管不一定是豬頭，他們只是遇到了無法解決的『衝突』。」 什麼樣的衝突？如果要持續的交付客戶滿意的軟體，到底團隊該將資源投入在「產品研發」還是「DevOps」上呢？在資源有限、資源搶奪的狀況下，主管當然很苦惱阿！所以主管不一定是豬頭，而是碰到了無法解決的衝突。 而偉大的高德拉特博士依然有解！面對衝突要找出其中的「錯誤假設」。難道投入研發就對「改善團隊體質 (DevOps)」沒有幫助嗎？反之難道投入 DevOps 就對「提供優質產品」沒有幫助嗎？這是值得思考的！ 這場分享個人覺得值得多次回味，對於沒有接觸過高德拉特及 TOC 的人來說，應該是一個很好的魚餌，能讓人稍微一窺這些理論工具並非只是空談，吸引你更深入的了解認識它，甚至學習運用它。 葉大已經將今晚的分享錄影釋出，也寫了一篇導讀，對此主題有興趣者，可以深入閱讀。 http://school.soft-arch.net/blog/157917/devops-a-toc-perspective 主題二：「持續改善：找出流程中的瓶頸與浪費」 這場分享我們邀請到泰迪軟體的 Erica 來帶大家用小遊戲的方式進行。...

延續前文，這一系列的文章是將我之前在 C.C. Agile #37 分享的簡報《DevOps: 建造開發維運的跨界之橋》轉換成文章的形式，一方面讓簡報內容能更完整地被分享，另一方面也讓我有地方可以補充一些後續又吸收到的新內容。 本文繼續來談談到底 “What is DevOps”，關於「什麼是 DevOps」目前我看到最多的標準答案是「這個問題目前沒有標準答案。」（2016/9/3 補充更多內容） 於是你就會看到有人開玩笑說「你問十個軟體、資訊領域的專家，什麼是 DevOps，那你會得到十個不一樣的答案。」（來自葉秉哲的演講「Docker 對傳統 DevOps 工具鏈的衝擊」） 而目前的情況也似乎就是如此，你可以在 wiki 上找到 DevOps 的條目，你可以在 Gartner 的報告中看到 DevOps 的相關趨勢，你也能找到各廠商宣稱自己的產品是 DevOps 必備的工具。  但若仔細比較它們對於 “What is DevOps ?” 的描述，你只會得到許多十分類似但卻有些不同的答案。於是又有另一個玩笑出現了「DevOps 是一種 92 共識，認真你就輸了」。  我個人最近在看 DevOps 的新聞與文章，發現了一個現象，早期談 DevOps 的文章，當談到什麼是 DevOps 時，都會直接給一個答案 DevOps 就是 ooxx ⋯⋯；但現在的文章則比較模糊一點，不再那麼斬釘截鐵，甚至有看到文章直接補一句「關於什麼是 DevOps，目前還有許多爭議⋯⋯各家都有自己的意見與詮釋⋯⋯ 」。 所以我才會開玩笑的說「什麼是 DevOps」，標準答案就是「這個問題目前沒有標準答案。」 但各家的定義依然值得我們參考，例如前面提到 Gartner，他們的定義即是 “Gartner defines DevOps as a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach....