最近沒新梗，只好使用相同的開場白，繼 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 除了擔任主講者與引導者，其實在活動開始之前他也提供了不少的建議，像是：...

繼 Meetup #3 之後，很快的兩個月多的時間過去，DevOps Taiwan 在 2017/02/22 晚上舉辦了第四次的 Meetup。
感謝極客窩 (Geek Cave) 贊助場地，感謝安德魯前輩為本次 Meetup 準備的豐富內容，感謝志工群的幫忙。最後同樣也感謝社群朋友不畏風雨的熱情參與！
就以此文簡短紀錄一下本次活動的林林總總。 （封面背景圖片來源 https://unsplash.com/photos/-K6JMRMj4x4）
籌備 打從 Meetup #3 結束之後，時間約在 2016 年 12 月左右，志工們就默默在籌備 Meetup #4，首先苦惱的當然是「主題為何」。在與 DevOps 相關的眾多關鍵字中，這一次要選哪一個來當作主題呢？
很巧的就在此時，剛好注意到安德魯前輩已經撰寫了數篇關於「Microservies 微服務」的中文文章。於是抱持著一股既期待又怕受傷害的心情，直接的就向前輩發出邀約。結果意外的立即就獲得了前輩的正面回應，願意替社群分享主題。
有鑒於前幾次的 Meetup，志工們一直在思考與嘗試希望在活動舉辦上能有所變化，例如上次 Meetup #3 的 CM 大亂鬥，一次湊齊四種工具的講者，並且來了一場綜合座談，就是一個不錯的嘗試，那麼這一次我們又能試試什麼不一樣的做法呢？
不過很可惜的是，雖然有這樣的熱情，但在實務上這次籌備過程並沒激發出特別的想法，最後決定先維持一般做法，以講題分享為主。同時因為安德魯前輩表示可能無法準時到場，所以原訂希望能再湊一位講者，安排在主持人開場之後，先來一場約 15 ~ 20 分鐘與微服務有關的 Lightning Talk，但最終沒能找到合適的講者，故這個計畫也只能因此作罷。
最後活動前面的 20 分鐘到底該做什麼好呢？個人提議不如就設計一個簡單的暖場活動吧？有鑒於這一兩年參加社群活動的經驗，以及參與了不少次 Agile 社群的活動，深深覺得「社群」真正的價值是建立在「人與人的互動」之上，如果社群沒有了交流與互動，那實在是非常可惜的事情。於是前 20 分鐘就定調為「強迫互動的秘密暖場活動」，剩下就等活動日子來到了。
現在回想其實有許多需要檢討的地方，不過這些檢討與反省，就全部留在最後一個段落一起記錄了。
講題分享 這次很榮幸能邀請到 Andrew Wu 一宇數位技術長 & 技術發展顧問為我們分享「Microservies 微服務」 的經驗分享，從講者的個人經歷與部落格文章中可以很清楚地知道是一位在這個產業有著扎實經驗的前輩，同時也是一位對於社群與後輩抱有熱切的教育之心的前輩。
為什麼會特別提到「教育之心」這件事情呢？就以這次 Meetup 分享的內容來說，安德魯前輩特別將「一窩蜂驅動開發」的局部內容放在簡報之中，當然一方面是因為文章內有提到 Microservices，另一方面則是他深深認同文章的觀點，所以除了借用文章當梗呼應簡報內容，也更是為了推廣正確的「開發觀念」，不要成為「一窩蜂開發者」。...

籌備多時的 DevOps Taiwan Meetup #3 順利在 2016/11/23 夜間舉辦。感謝極客窩 (Geek Cave) 贊助場地，感謝四位講者黃俊宏、蔡宗城、Mose、Wayne Lin 為本次活動的付出，感謝志工群的幫忙。最後也感謝社群朋友對本次活動的熱情參與！
就以此文簡短紀錄一下本次活動的林林總總。
（封面背景圖片來源 https://unsplash.com/search/fight?photo=1iHpSdiZyFA）
籌備 其實原本 Meetup #2 的活動主題就是「配置管理工具大亂鬥」(CM Tools 大亂鬥) ，但因為 Meetup #2 一直遲遲未能順利籌辦，而當時正逢 DevOps Summit 2016 剛結束，葉秉哲 (葉大) 也有意再分享一次 TOC 的講題，於是在天時地利人和的情況下，就先以「思維引導、持續改善，引發團隊改變新契機」為題舉辦了 Meetup #2。
那到底什麼原因讓「CM Tools 大亂鬥」難以籌辦呢？
主要有兩個原因：
講者邀請 想要一次湊齊四種工具、四位講者實在是一件辛苦的事情，尤其是 Puppet 與 SaltStack 這兩個工具的講者。如果你去 Google 搜尋 Ansible 或 Chef，大概都能找到幾位己經浮出水面的講者。但是 Puppet 與 SaltStack 能找到的則相當有限。 如果不能用 Google 搜尋來找講者，就只好透過人脈來間接尋找了，於是在志工群動員了各自的人脈暗地詢問之後，最終我們才湊齊了四位講者。
而且講者還不是找到即可，還要與對方確認意願、約定日期時間，其中 SaltStack 的講者一度流標，因為時間上無法配合，最後是又再透過 Chef 的講者蔡宗城的人脈才順利邀約到 Wayne 來擔任講者。
規劃活動內容 CM Tools 大亂鬥，到底要怎麼鬥？這也讓志工們苦惱許久。 最後志工們討論出了一個很棒的想法，即是分為上下半場的活動。...
今晚 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 來帶大家用小遊戲的方式進行。...