[DevOps]鳳凰計畫

Reading time ~1 minute

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 制度在公司很重要!好的員工一位難求~

我流紀錄

分成七個部分說明

不論什麼公司,維運一但失敗,業務就會失敗

  1. 在書中,CEO 認為維運部門只要讓服務乖乖不出錯就好,不需要改善與優化。這觀念嚴重阻礙了主角想做的改革,CEO 常常沒等主角解釋完,就用自己的想法直接評論事情。這樣的主管在我身邊聽到不少,有的擅自猜測員工接下來要說的話,然後直接歪樓;或是不懂裝懂,被員工靠氣勢糊弄等等…其實只要管理者保持虛心受教、事後仔細查證、避免偏見的態度去處理事情,這類問題也是能被解決的。
  2. 公司業務和 IT 之間的關係圖很重要,每個 IT 員工都要知道自己的工作和公司業務之間的關係,這樣不只激發向心力,在算績效時也比較多東西能說嘴。很多較大的公司,員工每季都要寫公司目標、個人目標,和自己在上一季對公司目標的貢獻,提醒每個人做的事情有沒有時時刻刻符合公司利益。
  3. 不管是什麼公司,其實都能稱作 IT 公司,因為沒有成功的 IT 就沒有成功的業務。只有強大的 IT,才能快速交付產品,並調整公司本身以應付市場環境的變化。舉例,像世界第一大藥廠輝瑞的產品,雖然不是最強的,但他的執行團隊就像訓練有素的軍人般執行上頭的銷售策略,能以最快最有效率的方式將藥品銷售到全世界,賺到最多利潤!輝瑞經常代理其他公司的藥品,靠該藥品賺取大把利潤後,再將該藥品的公司併購,壯大自己!

使用大家習慣的東西做任務追蹤

  1. 在主角改革前,開發部主管已經花了大筆錢建立了任務追蹤系統,嘗試要每個員工用該系統做紀錄,但大家不習慣每件事都要填一堆繁瑣的表格,最後這項政策也就無聲無息了。主角很聰明的把大家找來,要他們用最熟悉的便利貼做紀錄,在每天開會時交上便利貼,慢慢大家才習慣這種工作模式。我認為這也是 Scrum 課程喜歡從便利貼開始的原因,因為老外習慣用便利貼,一個便利貼就是一個任務,照著 TODO –> DOING –> DONE 的流程去追蹤每份工作。這裡重點在於用大家熟悉的工具去引入新的工作模式,像假設公司大多數人是習慣用 Email 的,最好做一個系統,當員工發 Email 給 IT 部門時,系統就自動產生對應的 Ticket 排到工作列中。

Dev 和 Ops 不應該在對立面,是相同目標的存在,應該共同合作與體諒

  1. 開發者應該要認知到,工作不是交出程式碼就結束了,應該要包含整個網站的部署,如何和維運部門一同合作,達成該網站上線後的維運需求,也是一門重要的課題!
  2. 整個產品 (ex. 網站) 的生命週期,都是開發者應該在乎的,對維運流程做優化, CP 值也很高!
  3. 維運部門和開發部門應該共同討論出合作的 Guideline
  4. 監控策略、Log 都是能創新、能一起討論的。不要覺得麻煩、懶得耗時間溝通,這是用別的角度切入產品的好機會!
  5. 以前是『程式碼即是應用』,有了 docker 後,變成『整個 Linux kernal 以上的環境 + 程式碼』即是應用,開發者要更有自覺,產出 docker image 且部署完工作才完成!
  6. 維運部門的工作應該是是開發或優化自助式的部屬介面,讓開發者能更方便的用 config 的方式來規劃如何去部署應用程式,而不只是值班監控或幫忙重啟…

避免約束點,約束點是整個部門的改善重點

約束點分兩種,一種是人,一種是工作站。

關於工作站的約束點,PMP 有提過類似的概念,critical path 經過的點就是約束點,只要有一個點 delay 就會影響整個專案進度。

這裡把重點放在『人』這個約束點,這個人涉入許多工作任務,只要沒有他,工作任務就很難完成 (done)。如果很多任務的進度很大的程度上,都依賴於這個人的做事效率,那這個人就是約束點,而且當這人涉入的工作越多,他的工作效率只會越來越差,就像是 queue 塞住無法疏通。

這現象的解決方法,就是將他的知識文件化,藉此把他的工作分擔下去!在鳳凰計畫裡,主角組成『踩坑小組』去採坑,把遇到的問題和解決方式一點一滴用文件累積起來。

約束點還有一個缺點,就是會慢慢把產品的架構變成自己的形狀,沒有人清楚他改了什麼,最後變成只有他懂內部架構在幹嘛。約束點一離開,整個公司就跟垮了差不多,這會是公司的大危機!很多台灣公司約束點的現象非常嚴重,Code Review 能有效避免這個問題,且 Code Review 不能只是做個形式,Reviewer 要知道每份改動的目的是什麼、解決什麼問題、是否是最有效的解法等等。

綜觀全局,善用各部門資源在對的時間做對的事情

在應付 SOX-404 外部稽核時,其實約翰應該善用會計部門的審查小組直接對公司的敏感資料做把關,讓 IT 能在當時 Focus 在更重要的事,而不是像初期為了快速解決 IT 控制問題而上機器偷改程式碼,導致機器重新部署時錯誤連連,給主角帶來一堆隱藏性的炸彈!

布侖特告密,論下屬溝通的重要性

在系統發生意外時,主角組織應變小組去解決問題,無法解決才去拜託約束點:布倫特,這目的是為了讓 IT 部門慢慢脫離約束點的掌控,但我覺得本書的主角沒有好好跟布侖特說明他的用意,導致布侖特對於自己好像被架空感到不安,就越級上報 CEO,CEO 就以為主角亂搞而指責主角的改革計劃。下屬是否有向心力,對整個計畫是否能更有效的進行,有很大的影響,就算邊摸著石頭邊過河,也要讓下面執行的人知道目前上面的策略,降低其他變因而造成失敗的機率。

不管什麼鉅細彌遺的計畫,都比不上日常的回饋改善

執行多年的鳳凰計畫沒有結果,一直是 Work In Progress,多年過去後,當時的評估也可能因為過時,上線後仍然以失敗收場。主角對直面客戶的部門主管們,做了一系列訪談,發現他花了整本書 2/3 頁數所努力的鳳凰計畫,其實是個過時、注定會失敗的垃圾專案,但全公司的未來依然賭在這個註定失敗的專案,讓他感到十分恐惶。

主角透過訪談收集需求,歸納出其中 IT 部門能幫忙的地方 (IT 造成的業務風險/IT 加強業務理解客戶需求的精確度…),在新功能上線後,要求業務收集使用者反饋,並快速回饋給 IT 部門,這才是最棒的鳳凰計畫!也就是第二工作法!

而要達到即時反饋必須要有自動化的 CI/CD 才行,如果人工一定 2 ~ 3 週跑不掉,不能像多個採用 CI / CD 的公司 (Amazon / Facebook…) 那樣每日部署 10 幾次。所以不是 DevOps 一定要有 CI / CD,而是如果沒有 CI / CD 就做不到 DevOps,我把 DevOps 的精髓在於新的管理思維!

結尾

好書改變老闆思維,改變公司文化,大家發大財 w

[影片推薦]瀏覽器中Javascript的運作機制

介紹瀏覽器渲染步驟中Javascript的部分,包含Event loop的說明 Continue reading