（本文同步發表於 Medium）
我個人的 devops 旅程大約起始於 2013 的年中，當時我正陷於傳統產業之 IT 與 MIS 的救火工作之中，就在那時我收到了來自好友聖佑捎來的一段訊息，「你有聽說過 DevOps 嗎？」正是這一句有如直銷的話語，引領我正式進入 devops 的世界中。而在接下來的日子裡，大量的知識與資訊向我席捲而來，到底什麼是 devops？是特定的技術？團隊協作方式？組織轉型？文化？面對大量令人眼花撩亂的資訊，實在是令人難以招架，現在回想起來，我與本書其中一則推薦序有著相同的想法，若是當時的我也能夠擁有這本書那該有多好。
這並不是一本寫給技術宅的技術手冊，它更像是一本心理學字典、參考書、故事集或者是《哈佛商業評論》雜誌。本書就像是一份指南，能夠指引向來只重視技術知識的 IT 人，繼續探索更多不同領域的知識與資源。一間企業能夠順利的運作絕不是只靠「dev」或「ops」即可，企業若期望提升其生存能力，組織內的每個部門皆有其重要性，希望本書的中譯本可以幫助更多人以更廣義的角度來看待 devops，讓優良的企業文化能深植在全體組織之中。
在未來 devops 一詞會不會消失？我個人不敢斷言，但可以肯定的是隨著這波 devops 風潮，只會有越來越多的人們知道，原來世界上擁有更優良的工作方法、團隊協作方式以及各種可以提升組織效能的工具。而「開放」和「持續改善」恐怕也將會是未來組織、團隊及個人都必須擁抱的一種優良文化。
在我個人的 devops 旅程中，一再接受到來自社群的諸多幫助，「取之於社群，回饋於社群」，主動請纓擔任本書譯者是我個人在心中為「回饋社群」所立下的一項里程碑，期盼本書能為社群提供更多的參考資料，讓更多人能夠因此受益。讀者若對於 devops 相關主題有興趣，可以加入世界各地的 devops 社群，也歡迎加入 DevOps Taiwan 社群，同時也鼓勵你嘗試籌組屬於自己城市的在地社群，讓社群能夠遍地開花，建立更多的人際連結、互動與交流。另外我個人比照原書作者為英文版設立 https://effectivedevops.net/ 的做法，也設立了 https://effectivedevops.tw，期盼也能為社群提供更多有助於互動交流的空間。
這本由技術人寫出來的非技術書籍，實在是令人感佩兩位作者的學識豐富，但對於擔任譯者的我而言，則是一段艱難的歷程，能夠順利完成本書的翻譯，著實要感謝許多人的幫助，感謝出版社編輯的耐心、感謝多位社群前輩的建議及鼓勵、感謝幾位心理學領域的朋友所提供的諮詢。
最後感謝我那可愛又逗趣的妻子，雖然妳一再表示妳是氣質美女，但在我的心目中，妳就是為人生旅途增添風趣的最佳伴侶，還有我的寶貝女兒，妳的可愛笑容是這段艱難日子中最棒的心靈療癒，謝謝妳們，妳們是我持續向前邁進的重要助力。
——陳正瑋
寫在翻譯書籍順利出版之後 感謝來自社群針對《Effective DevOps 中文版》的支持與鼓勵，但還請容我再次向大家致歉，對於這本書延誤到如今才順利出版，實在是感到非常不好意思，謝謝大家的包容與忍耐。
同時也再次說明，譯者並非作者，因此無論各位是買一本或買十本，基本上都不會影響我個人的收入，不過還是鼓勵大家多多買書、看書，因為出版業真的需要更多人的支持，不然出版品的品質恐怕只會逐年下滑。我一直很認同過去求學時期聽見的一句話「一個國家的國力與翻譯力息息相關」，雖然現在是網路 + 人人都會英文的時代，想要取得第一手的資訊與知識已經不像過去的時代那麼困難，但我還是依然認為知識能否更快速的普及與傳遞，和該知識是否能被快速、正確地被翻譯為當地語言是有關聯性的。因此，還是要再次呼籲，希望大家能多多支持出版業，不論是買書、看書、推廣好書、擔任譯者或作者，這些都是值得鼓勵的方式。
另外，https://effectivedevops.tw 網站也已經順利上線，將會貢獻給 DevOps Taiwan 社群使用，將會用來匯整各種值得收藏的 DevOps 相關好文或參考資料。雖然網站目前還只是一個陽春的 MVP 版本，但相信未來的日子我們會將其改善得越來越好，如果您也有收藏任何與 DevOps 有關的優質文章，也歡迎讓我們知道，謝謝。
提供 DevOps 經典好文與參考資料 最後，要再提一次，縱然在書籍出版過程中，譯稿已經過多雙眼睛的校對與覆閱，但相信本書依然可能會有錯譯及翻譯不佳之處，如果有任何的建議，還請各位務必回報讓我們知道，我們會盡快將大家回報的錯誤，整理為「書籍勘誤對照表」並於網路公佈，在此就先感謝大家的指教了。 回報《Effective DevOps 中文版》勘誤 相關連結 《Effective DevOps 中文版》 DevOps Taiwan 社群 https://effectivedevops....
如同程式需要測試，Ansible Playbook 或 Roles 其實也是某種 Code，因此最好也能為其撰寫適當的測試。本文就讓我們向 Ansible 圈內的大神 geerlingguy 求教，學習 geerlingguy 大神測試 Roles 的方式。
（本文同步發表於 Medium）
本文的內容也正是我在 DevOps Taiwan Meetup #13 - Ansible User 小聚所分享的閃電秀，當時的簡報在此：
「跟著 geerlingguy 大神一起測試 Ansible Roles」 建立你的 Roles 並透過 Travis CI 測試 要學習 geerlingguy 大神的測試方式之前，當然請先準備好你的 Roles，將其推上 GitHub。關於 Roles、Ansible Galaxy 及 GitHub 三者的關係，這邊就不再重複說明了，請直接參閱凍仁翔的文章「怎麼在 Ansible Galaxy 分享 Roles？」（上、下）。
推上 GitHub 之後，接著要將 Repository 與 Travis CI 建立串連，這部分也同樣可以參閱凍仁翔的文章「怎麼用 Travis CI 測試 Roles？」。
接下來就讓我們一窺 geerlingguy 大神是如何測試的。
geerlingguy 大神的測試妙招 Ansible 的使用者們應該或多或少都曾使用或參考過 geerlingguy 大神所撰寫的 Roles，如此大量高品質的 Roles，全部都有通過 Travis CI 測試，到底是如何做到的？關鍵在於 geerlingguy 充分利用了 Travis CI 的特性，並且撰寫一支專門協助測試的 shell script。...
（本文內容已過期，請參閱最新的 ansible-container 官方文件。）
自從上次（2016年）試用 ansible-container 遭遇慘痛的踩雷經驗之後，如今 ansible-container 的版本號已進入 0.9.2，據說文件及穩定度皆已有所改善，因此決定趁著放假撥一點空檔再次試用它，希望這次的試用過程不會像上次一樣地慘痛。
（本文同步發表於 Medium）

以乾淨的 Ubuntu 16.04 環境試用 根據官方文件，ansible-container 的 Prerequisites 為
Python 2.7 or Python 3.5 pip setuptools 20.0.0+ 因此決定直接以乾淨的 ubuntu 16.04 環境挑戰，避免遇到 python 版本或相依套件的問題。首先透過 Vagrant 建立乾淨的 ubuntu 16.04，並在 VM 內安裝 Docker。接著以下面指令安裝 pip。 apt-get update
apt-get install python-pip
pip install --upgrade pip 接著按官方文件安裝 ansible-container。
pip install ansible-container[docker] （[] 內除了可以填 docker 之外，也可填寫另外兩種 engines，分別是 k8s 及 openshift。） 順利安裝後即可執行 ansible-container -h，查看 help。
試用 ansible-container 開始簡易地試用 ansible-container...
延續小技巧（1），本文繼續分享兩個與 Ansible playbook 有關的小技巧，希望大家都能安安心心地執行自己所的撰寫 playbook。
（本文同步發表於 Medium）
 （Photo by John Schnobrich on Unsplash）
在 playbook 內適當的設立檢查點與中斷點 在小技巧（1）中，主要提及的都是執行指令 ansible-playbook 時可以添加的 options，而在本文則分享兩個常用的 modules。
善用 debug 檢查 相信有在使用 Ansible 的使用者們都知道，在撰寫 playbook 過程中，經常有一些 Modules 是我們會重複使用的，其中一個即是 debug。
在 playbook 當中，有時為了讓各個 tasks 能夠順利串連，我們會將部分 tasks 的結果透過 register 註冊為新的 variables，提供後續的 tasks 能以此進行邏輯判斷。
而為了確認這些 variables 取得的值或結果是否合乎自己的預期，一般在撰寫 playbook 的過程中，便會直接透過 debug 將其印出，方便自己能夠直接進行除錯與檢查。
# 舉例：
command: whoami
register: check_user
debug: msg="{{ check_user }}" debug 非常單純，即是幫你將 msg 中的資訊印出，因此非常適合適時地安插在 playbook 當中作為檢查點，讓你可以在執行 playbook 之後快速檢查執行成果是否都如你預期。...
在剛開始接觸組態管理工具（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 這個字可能會漸漸消失，真正會留下的是其他這些相關的重要觀念與實踐方法⋯⋯」