今天其實沒什麼特別的目標，筆者想跟大家聊聊一些想法，並且將前面學到的東西做個總結。
畢竟學習的過程中，理論和實務是有差距的，筆者也想分享一些自己在公司實際應用 Ansible 的經驗。
如果有的話，歡迎在留言區分享各位遇到的問題和經驗，如果還沒有開始，也沒關係，也可以跟大家一起討論。
這 28 天下來，筆者發現最大的改變不是記住了多少指令或模組，而是思維方式的轉變。
遇到需要在多台機器上做同樣設定的時候，就是開很多個 terminal，一台一台 SSH 進去，複製貼上同樣的指令。
累死了不說，還經常會在某一台忘記執行某個步驟，然後就出問題了。
有時候同事會問：『你上次部署是怎麼做的？』筆者只能翻聊天記錄或是靠記憶，因為根本沒有標準流程這種東西。
現在遇到同樣的情況，第一個想法就是：『這個可以寫成 Playbook 嗎？』
不只是執行指令，連部署的邏輯、錯誤處理、回滾機制都會考慮進去。
雖然一開始寫 Playbook 會花比較多時間，但一旦寫好了，後面的維護和擴展就輕鬆很多。
而且現在同事問同樣問題的時候，筆者可以直接給他一個 git repository，所有的步驟和設定都在裡面，清清楚楚。
當筆者第一次導入 Ansible 取代舊有流程時，其實很多挑戰不來自於技術問題，而是來自於流程和文化的改變。
因為當我們在練習時，不需要考慮盈利，但是對於一間公司來說賺錢大於一切，所以每次在規劃新的流程時，都要考慮到風險和回滾機制。
一開始筆者也不知道從哪裡開始，就先列出了所有需要做的事情，例如：
雖然看起來很多，但筆者覺得解決每件事情前，完善的規劃是很重要的，且也是非常花時間的任務，但對筆者來說也是最具有挑戰性也最喜歡做的一件事，因為筆者可以透過抽絲剝繭將一個複雜的系統拆解成一個個小問題，然後逐一解決。
整個專案從規劃到完成花了幾個月，但實際的部署只需要跑一個指令：
ansible-playbook -i inventory/production site.yml -e env=production
大家可以看到我們花了大量時間，但在最終結果只剩下一個簡單的指令，這也就是為什麼筆者想要推崇 Infrastructure as Code 的原因，當我們的 Infra 都具備強韌的能力時，就可以很輕鬆的面對各種困難的業務場景。
筆者建議不要一開始就想要把整個公司的基礎架構都自動化，先自己開個小專案測試並且熟悉整個技術的特性再開始導入。
筆者非常建議一定要先看完官方文件再開始實作，雖然一開始會覺得很無聊，但後面遇到問題的時候就會發現，很多答案都在文件裡。
為什麼會這樣建議，因為筆者就是那個痛過的人 😅
現在筆者會在 README.md 裡面寫清楚：
雖然寫起來有點麻煩，但後面維護的時候會感謝當初的自己。
測試這塊：筆者的做法是先在 staging 環境跑過一遍，確認沒問題了才 deploy 到 production，雖然不是什麼高深的技術，但很有效。
備份這塊：筆者學到一個教訓，就是備份策略一定要實際測試過，之前有一次以為 database 有自動備份，結果真正需要 restore 的時候才發現備份檔案是壞的 😱
現在筆者會定期測試restore流程，確保備份是可用的。
剛開始寫 playbook 的時候，筆者總是假設一切都會順利執行，後來在 production 環境遇到一些奇怪的問題 (網路中斷、磁碟空間不足等等)，才發現錯誤處理的重要性。
現在筆者會在關鍵的 steps 加上適當的 error handling，至少不會讓系統卡在一個奇怪的狀態。
建議大家選一個自己熟悉的應用，從頭到尾用 Ansible 做一個完整的 deployment。不用太複雜，重點是把整個流程跑通。
為專案寫一個清楚的 README，讓三個月後的自己 (或其他人) 看得懂要怎麼使用。
如果各位的專案有資料庫或重要檔案，記得測試一下備份和還原的流程。
明天就是最後一天了！筆者想跟大家聊聊這30天的心得，還有一些對未來的想法。
iThome鐵人賽
看影片追技術