目前我們團隊的正巧有兩位後端工程師在優化部署程式碼的步驟，一位使用 ansible（就稱他為Ａ工程師），另一位使用 script（這位稱為Ｓ工程師），我剛突然很認真在想，是什麼原因讓兩位工程師開始對部屬進行優化。（這邊補充說明一下，會需要回想原因是因為這並不是上級交派的工作，而是兩位工程師自發性的優化。）

Ａ工程師之所以開始使用 ansible 去嘗試部署，是因為專案測試需求，所以測試用的機器從原本的 5 台，到目前差不多要到 30 台，當數量成長時，自動化的需求就出現了，哈哈哈！碰巧Ａ工程師對於 ansible 已經躍躍欲試很久了，就開始使用 ansible 來建置自動化部屬。

Ｓ工程師使用 script 優化部署流程的原因是我們要把現行在 AWS 上的機器，轉成使用 AWS 內建提供的 Linux 版本，會比我們現在選用的 Linux 版本來的省錢一點，加上陸續有需要加上團隊成員的權限，於是某天Ｂ工程師突然跟我說：『我提了一個 review ，裡面是部署 AWS 時會用到的 script 優化，腳本我分成不同服務，之後哪台機器需要什麼服務，就跑相關腳本就好。』

兩位工程師在優化的過程中有個小小的插曲，Ａ工程師其實一直想要說服Ｓ工程師直接改用 ansible 來做自動化部署，但Ｓ工程師的想法是他還沒有使用過 ansible ，也還不知道可能會有什麼坑要踩，所以不想要馬上就使用他不熟悉新技術，針對這個小插曲，我的想法是「無論使用哪門技術，只要能夠對我們團隊有幫助那就都是好事」。

該如何讓團隊開始 DevOps ？我想創造需求可能會是個滿有效的方式，比起一直在工程師旁邊碎碎念，還不如讓工程師直接面對麻煩的問題，進而自己找尋解決方案。最重要的，我想應該是建立一個讓大家都願意去嘗試，去改善不怕犯錯的環境，假設小插曲發生時，我就直接選邊站，這樣我想某一位的工程師應該會有點受傷吧！

還有另一個需要建立的是大家對於分工的看法，目前我們團隊總共有 17 位工程師，雖然目前大家自己比較專精的部分不盡相同，會知道哪位對前端比較熟，哪位對後端比較熟，誰比較會部署，但我們並沒有把組織劃分，也沒有去規定只有誰才能做哪類型的工作，還是回歸一句「只要能對團隊好的，都是直得被鼓勵的」。

目前的做法比較像是在開發團隊中，不去做細的職能分工，但如果把範圍跨大到其他部門，那就更能夠往 DevOps 靠近了。