好書分享 #1: 鳳凰計畫
DevOps 最佳佈道書一枚！ 身為工程師，除了了解自己的領域外，建議能多方涉略維運、行銷、設計等相關領域。這樣除了幫助溝通，也能以不同角度去觀察事物，並建立正確的做事方法。
劇情簡單安利
Bill 是無極限零件公司的一名 IT 經理，有天忽然被 CEO 抓來負責這個可能讓公司起死回生的計畫：鳳凰計畫。
在本書的第一章節，Bill 帶讀者經歷了每個傳統公司的 IT 部門都會遇到的困境，像是員工不遵守制度、關鍵工作集中於一位員工、tasks 雜亂無章難以追蹤等等…在 Bill 接近崩潰之時，一位來自董事會的成員，用工廠生產線作為比喻，引導 Bill 將 DevOps 的原則逐漸導入他的 IT 團隊，讓團隊漸入佳境。其中讓我印象最深刻的，是 SOX-404 外部稽核會議裡，公司用下游人工審查 cover 掉 IT 控制問題，本書在這裏帶入了『第一工作法』，告訴我們要時刻注意自己的任務是否和公司的大目標一致！這樣才不會花費大量時間在對公司沒有幫助的事情上。
第二章節，高層不理解 Bill，不但沒有支持 Bill 的改革計劃，還拼命施加壓力給 Bill，導致 Bill 憤而離職。而離職這個動作讓高層開始反思，整個公司從高處墜落再從谷底浴火重生，印證『大破才能大興』這個諺語。第一章比爾帶讀者領悟了『四種工作類型』和『第一工作法』，第二章他們用約翰的逆襲帶入『第二工作法』，藉由到處訪問各部門的主管收集需求、開發新功能，再建立能正確把使用者體驗傳達回開發端的回饋機制。之後為了加速這樣的循環迭代，他們更搭配了自動化，發展出『持續整合』和『持續交付』。公司每個部門的大主管，性格都非常鮮明有趣，他們的轉變很值得一看！
第三章是收尾，基本上就是品嚐勝利的果實，裡面也帶到很多厲害的 DevOps 公司 (Google/Facebook/Amazon/NetFlix…) 常見的開發日常，和第三工作法『培養勇於受挑戰的文化』。好的制度也必須搭配觀念正確的人，才能發揮這個制度最大的優點，所以教育訓練和 mentor 制度在公司很重要！
我流心得
這裡列出七個我映像深刻的部分說明
不論什麼公司，維運一但失敗，業務就會失敗
- 在書中，CEO 認為維運部門只要讓系統乖乖不出錯就好，不需要改善或優化。這觀念嚴重阻礙了主角想做的改革，CEO 常常沒等主角解釋完，就用自己的想法直接評論事情。這樣的主管在我身邊聽到不少，有的擅自猜測員工接下來要說的話，然後直接歪樓；或是不懂裝懂，被員工靠氣勢糊弄等等…其實只要管理者保持虛心受教、事後仔細查證、避免偏見的態度去處理事情，這類問題也是能被解決的。
- 公司業務和 IT 之間的互相了解很重要，每個 IT 員工都要知道自己的工作和公司業務之間的關係，這樣不只激發向心力，IT人員在實作時也能針對業務提出的需求，做技術相關的建議。很多較大的公司，員工每季都要寫公司目標、個人目標，和自己在上一季對公司目標的貢獻，提醒每個人做的事情有沒有時時刻刻符合公司利益。
- 不管是什麼公司，其實都能稱作 IT 公司，因為沒有成功的 IT 就沒有成功的業務。只有強大的 IT，才能快速交付產品，並調整公司本身以應付市場環境的變化。舉例，像世界第一大藥廠輝瑞的產品，雖然不是最強的，但他的執行團隊就像訓練有素的軍人般執行上頭的銷售策略，能以最快最有效率的方式將藥品銷售到全世界，賺到最多利潤！以執行力著稱的輝瑞經常代理其他公司的藥品，靠該藥品賺取大把利潤後，再將該藥品的公司併購，壯大自己！
使用員工習慣的東西做任務追蹤
在主角改革前，開發部主管已經花了大筆錢買了外面的任務追蹤系統，嘗試要每個員工用該系統做紀錄，但大家不習慣每件事都要填一堆繁瑣的表單，最後這項政策也就無聲無息了。
主角很聰明的把大家找來，要他們用他們熟悉的便利貼做紀錄，在每天開會時交上便利貼，成功讓大家慢慢習慣這種工作模式。我認為這也是 Scrum 課程喜歡從便利貼開始的原因，因為老外習慣用便利貼，一個便利貼就代表一個 task，照著 TODO –> DOING –> DONE 流程去追蹤每份任務。
這邊重點在於，用大家熟悉的工具，去引入新的工作模式，假使公司大多數人是習慣用 Email 的，最好員工發 Email 給 IT 部門時，系統就會自動產生對應的 Ticket 排到工作列中。
Dev 和 Ops 不應該在對立面，是相同目標的存在！應該共同合作與體諒！
- Developer 應該要認知到，工作不是交出程式碼就結束了，應該要包含整個網站的配置部署。如何和維運部門一同合作，達成該網站上線後的維運需求，也是一門重要的課題！
- 整個產品 (ex. 網站) 的生命週期，都是 Developer 應該在乎的，所以優化維運流程也應該要有開發人員的參與。
- 維運部門和開發部門應該共同討論出合作的 Guideline
- 監控策略、Log 收集形式都是能夠創新、被一起討論的。身為 Developer 不要覺得麻煩、懶得耗時間溝通，這是用別的角度切入產品的好機會！
- 以前是『程式碼即是應用』，有了 docker 後，變成『整個 Linux kernal 以上的環境 + 程式碼』即是應用，開發者要更有自覺，產出 docker image 且部署完，工作才算完成！
- 維運部門的工作應該是是開發或優化自助式的部屬介面，讓開發者能更方便的用 config 的方式來規劃如何去部署應用程式，而不只是值班監控或幫忙重啟…
避免約束點，約束點是整個部門的改善重點
約束點分兩種，一種是人，一種是工作站。
關於工作站的約束點，PMP 有提過類似的概念，critical path 經過的點就是約束點，只要有一個點 delay 就會影響整個專案進度。
這本書把約束點的重點放在『人』，這個人涉入許多工作任務，只要沒有他，工作任務就很難完成 (done)。如果很多任務的進度，很大的程度上，都得依賴這個人的做事效率，那這個人就是約束點。而且當這人涉入的工作越多，他的工作效率只會越來越差，就像是 queue 塞住無法疏通。
這現象的解決方法，就是將他的知識文件化，藉此把他的工作分擔下去！在鳳凰計畫裡，主角組成『踩坑小組』去採坑，把遇到的問題和解決方式一點一滴用文件累積起來。
約束點還有一個缺點，就是會慢慢把產品的架構變成自己的形狀，因為他會埋很多自己才懂的 work around 在裡面，沒有人清楚他改了什麼，最後變成只有他才懂內部架構在幹嘛。這樣會造成約束點一離職，整個公司就跟垮了差不多，是公司的大危機！很多台灣公司約束點的現象非常嚴重，Code Review 能有效避免這個問題，讓每個 team member 知道互相對程式做了什麼修改。這裡的 Code Review 不能只是做個形式，Reviewer 要知道每份改動的目的是什麼、解決什麼問題、是否是最有效的解法等等，所以 Task 在估算點數時，也要包含到 Code review 的時間。
綜觀全局，善用各部門資源在對的時間做對的事情
在應付 SOX-404 外部稽核時，其實約翰應該善用會計部門的審查小組直接對公司的敏感資料做人工把關，讓 IT 能 Focus 在更重要的事，而不是像初期為了快速解決 IT 控制問題而上機器偷改程式碼，導致機器重新部署時錯誤連連，給主角帶來一堆隱藏性的炸彈！
布侖特告密，論下屬溝通的重要性
在系統發生意外時，主角組織應變小組去解決問題，無法解決才去拜託約束點：布倫特。
這目的是為了讓 IT 部門慢慢脫離約束點的掌控，但我覺得本書的主角沒有好好跟布侖特說明他的用意，導致布侖特對於自己似乎被架空而感到不安，就越級上報 CEO，導致 CEO 誤會主角亂搞，而指責主角的改革計劃。
下屬是否有向心力，對整個計畫是否能更有效的進行，有很大的影響。就算邊摸著石頭邊過河，也要讓下面執行的人知道目前上面的正在嘗試一些改變，降低因為其他變因而造成改革失敗的機率。
不管什麼鉅細彌遺的計畫，都比不上日常的回饋改善
執行多年的鳳凰計畫沒有結果，一直是 Work In Progress，多年過去後，當時的評估也可能因為過時，上線後仍然以失敗收場。主角對直面客戶的部門主管們，做了一系列的訪談，發現他花了整本書 2/3 頁數所努力的鳳凰計畫，其實是個過時、注定會失敗的垃圾專案，但全公司的未來依然賭在這個註定失敗的專案，讓他感到十分恐惶。
主角透過訪談收集需求，歸納出其中 IT 部門能幫上忙的地方，像是降低 IT 造成的業務風險、加強業務紀錄客戶回饋的精確度等…在新功能上線後，要求業務收集使用者反饋，並快速回饋給 IT 部門，建立好的循環，這才是公司要的鳳凰計畫！也就是第二工作法！
要達到真正的即時反饋，必須要做到自動化的 CI/CD 才行，如果人工，2 ~ 3 週一定跑不掉。採用 CI / CD 的公司 (Amazon / Facebook…) 甚至能每日部署到 10 幾次。所以不是 DevOps 一定要有 CI / CD，而是如果沒有 CI / CD 就做不到 DevOps，DevOps 的精髓其實在於這個新的管理思維！
結尾
好書改變老闆思維，改變公司文化，大家發大財 w
