在剛開始接觸組態管理工具（Configure Management Tool，或常見譯為配置管理工具）的時候，應該都會經歷過一段日子，就是擔心自己寫的自動化腳本會不會有問題，特別是當腳本要使用在 Production 環境時，總是會再三的確認，深怕自己一個不小心，不但沒省事，反而把 Production 環境搞壞了。
本文簡單地談談在 Ansible 中有哪些小技巧可以幫助你降低這些憂慮，放膽執行您的 playbook。
（本文同步發表於 Medium）
 （Photo by John Schnobrich on Unsplash）
在實際執行 playbook 之前的三個基本 Options 先從 ansible-playbook 指令內建的 Options 開始說起，有三個 Options 是最基本的檢查，分別是：
--syntax-check --list-tasks --list-hosts –syntax-check 首先是 --syntax-check，它可以用來幫你檢查 playbook 有沒有格式或語法錯誤，不過其實我們不用手動執行它，因為當你執行 ansible-playbook 時，就已預設會先進行語法檢查了。 所以在 --help 中也是這麼說明的。
--syntax-check perform a syntax check on the playbook, but do not execute it （謎之音：那你還浪費篇幅介紹它。）
對於現代的開發者而言，「語法檢查」通常會跟工程師使用的編輯器、IDE 綁在一起，讓語法檢查能夠自動完成，以 ATOM 為例就有 pacakage - linter-ansible-syntax 可以幫助我們在撰寫 playbook 時即能完成語法檢查。
–list-tasks 第二個 Option 是 --list-tasks，它可以幫你列出在即將要執行的 playbook 中有哪一些 tasks 會被執行。建議在執行重要的 playbook 之前可以先跑一次 --list-tasks，複閱是否會執行的皆是你所預期的 tasks。...
在休養生息的倒數日，找來電影《薩利機長：哈德遜奇蹟》一起度過。雖然不是好萊塢動作爽片，但劇中包含感人、激勵人心的劇情，以及關於心理健康、創傷的演出，還有最重要的面對危機事故的正確態度。這些內容反而令人想要再次細細回味這部電影。
（有部分劇透，請慎入）
（本文同步發表於 Medium ）
 （Photo by Smit Patel on Unsplash）
劇情主軸為全美航空的一架班機剛起飛沒多久即遭遇鳥擊，因而導致失去動力，在此狀況之下，薩利機長判斷必須水面迫降於哈德遜河上，成功迫降的機長被眾人視為是英雄角色，但負責事故調查的「國家運輸安全委員會」，則質疑機長的這項決定，認為這可能是錯誤的決策，並且在事故當時亦可能有人為疏失。而最終電影的高潮即是在最後的聽證會上，薩利機長反敗為勝證明自己的判斷是正確的。
「若你想要找出其中的人為疏失，那麼你便不能將人性從中抽離。」 （憑印象記憶的劇中台詞）
在空難之後的事故調查，透過黑盒子及收集到的數據進行電腦模擬及真人駕駛測試。最初呈現在聽證會上的真人駕駛測試顯示在當時的情況下，機長擁有足夠的時間能夠安全返航，無需進行高風險的水上迫降。但薩利機長卻在聽證會中一針見血的點出這些模擬測試所欠缺的關鍵因素——人性。
從來沒有機長受過訓練，學習過「如何在低空遭遇鳥擊且動力全失時該如何因應。」，但負責擔任真人駕駛測試的駕駛員在聽證會之前，卻早已被清楚告知情景，並已練習過該情境 17 次，因此才能臨危不亂的做出完美的因應動作，將飛機返航降落於跑道上。這正是模擬測試與真實情境的最大差異，在有限時間、高度壓力的情境中，當事人是否依然能夠迅速、理智地做出正確的決策與判斷。
雖然這是一部關於航空業飛機事故的電影，但其中關於事故處理的態度卻值得借鏡。事實上也確實是如此，航空領域因為關係到人的性命，一架飛機若發生事故，很可能影響到超過百人的生命安危，因此為了避免發生意外及減少人為疏失，在航空領域中已經年累積出許多的方法、原則，而這些經驗也經常被借鏡至其他領域，例如劇中遭遇事故之後機長與副機長的互動即是其一，在事故當下，飛機操控權轉回由機長主控，同時副機長負責開始實施標準應急動作，而副機長即將進行的所有操作皆會口述，並由機長再次覆述或確認，這樣的互動其實在醫療領域中也經常能見到。
而劇中最令人敬佩的是薩利機長在事故當下所保持的沈穩、不慌亂、冷靜、理智的態度。這正是任何人都該學習的地方，因為唯有如此，才能正確、迅速的分析現況，在可行方案中找出最大的生機。
如將場景換成 IT、軟體業，試想在公司新產品的上線時刻，伺服器卻立即出現異狀，導致使用者的不良回饋開始大量湧入，身為工程師的我們該如何因應此種狀況？我們也有辦法保持冷靜嗎？恐怕這並不是一件容易的事情，能夠令人保持冷靜的因素，除了個人擁有的個性、性格的特質之外，還有另一項關鍵因素——「經驗」。
經驗可以分為兩個層面，一個即是如薩利機長一樣，駕駛飛機的年資已超過 40 年，充分累積該領域足夠的經驗及敏感度。另一個是特別針對事故所進行的案例分析與事故演練。事故分析、災難還原演練，每個人都知道這些是重要的動作，但有多少人能夠確實的實施？而在電影中即有一段劇情是薩利機長表示自己會定期閱讀其他班機的事故報告作為學習。
而在 Google 的《SRE》這本書中我們也能看見，原來 Google 的 SRE 們被要求、也被給予足夠的時間完成事故分析報告，並且報告必須由資深者及跨部門、跨領域者協助複閱以求完整。除此之外也會定期以模擬劇的方式，將經典的事故報告拿出來作為情境演練。
這些動作都有助於我們累積經驗。甚至更進一步，我們應該要擁抱事故，將其視為是正常任務的一環，因為事故隨時都有可能發生。這也正是現在逐漸被人提及的概念「Chaos Engineering」。
除了前述的內容之外，在這部電影中還有其他值得討論的內容，例如：
如何區分你在事故當下的判斷是來自深厚經驗的累積，或僅是毫無根據的直覺？ 如何建立因應事故的標準程序，同時接納其他的可行備案？ 專業人士應該擁有之不獨自邀功、不咎責（對事不對人）、當責（accountability）的態度。 你的團隊是建立於一兩位英雄角色，或你建造的是一組能互信、互助、值得信賴的團隊。 機器（Monitoring）可能會出錯、人也可能誤判，如何避免？ 航空、醫療領域還有哪些優良的實踐是值得我們借鏡的？ 您也有觀賞這部電影嗎？也歡迎與我分享您從電影當中獲得了哪些想法。
感謝台灣微軟的 R 姐邀請，上週五晚上有幸能參加微軟 MVP 的活動。活動安排的行程前半部為「講者分享」，而後半段則為「分組討論」，在四個分組主題之中，其中一組的討論主題即為「DevOps」。 （本文同步發表於 Medium ）
在當晚的分組討論中，眾多 MVP 及與會者針對 DevOps 及 Scrum 交流了許多經驗，很有趣的是在「DevOps」這一組，首個被提出討論的問題依然是「What is DevOps？」
到底什麼是 DevOps？這真是一個難以回答的問題，特別是當你看見越來越多的資料及聽見不同專家的見解之後，個人越是深深覺得 DevOps 這個字難以用幾個字簡單的說明。
DevOps 是一場 IT 及軟體界的轉型運動、DevOps 是一種文化、DevOps 是一種精神、DevOps 是一種方法論、DevOps 是一大堆串聯在一起的技術解決方案、DevOps 是商人用來⋯⋯
在活動結束、返家的路途之中，自己再一次地咀嚼於活動中交流及獲得的各種經驗，並且反思如果下次再遇到「What is DevOps？」，到底應該要談些什麼？於是心中浮現了以下幾個問題。
組織內外是否有溝通層面的問題？ 組織內外有穀倉效應的問題嗎？ 目前團隊的生產力如何？ 目前從開發直到維運整個流程的順暢度如何？ 組織是否擁抱「持續改善」的文化？ 組織是否擁抱「不咎責」的文化？ 組織是否擁抱「學習型組織」？ 成員是否具備「當責」的心態？ 同時也想起在 Agile Tour HsinChu 2017 活動當天，一早遇見 Titansoft 的老闆 Yves 時的情景。在當時與 Yves 的閒聊中，對於 DevOps 自己似乎說過這樣的一句話——「我覺得 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 除了擔任主講者與引導者，其實在活動開始之前他也提供了不少的建議，像是：...