看到標題，可能很多IT技術人會跳腳地說，寫程式是需要靈感的，是一種藝術，怎麽可以跟制式化的工廠流水線相比呢！“寫程式”這個行爲確實是藝術沒錯，同一個需求，每個人寫出來的程式都會不一樣，效能也會不一樣，不過生産線每個製程其實也需要技術，否則熟練的工匠不會那麽珍貴；但最重要的是，如果將視野拉大到整個IT的作業流程與工廠生産流程，其實是有很多相同點的，這篇文章就來談這個，而這最核心的概念就是限制理論“TOC, Theory of Constraints”。
鳳凰專案，DevOps的實際應用小説
這幾年在談DevOps的圈子，有本書非常有名，叫做“鳳凰專案 (The Phoenix Project)”，内容以小説體的型式，描述IT部門如何讓一家製造公司從谷底翻身，裏面就包含了DevOps的概念與實際應用，強力推薦所有IT人都去看這本書，會發現網路時代的IT概念跟十幾年前怎麽差那麽多！最主要的原因如我系列文章第一篇講的，因爲網路技術突破了空間的限制，使得很多做法都重新調整了。而鳳凰專案這本書，最核心的精神，就是限制理論 (TOC)，作者也在書最後面提到，他們花了近十年的時間在研究TOC，最後才寫出這本書，而鳳凰專案裏的許多内容，也是向限制理論作者所寫的第一本書“目標”致敬，同樣用小説體，情節安排也很類似。
淺談限制理論 (TOC, Theory of Constraints)
那究竟限制理論在講什麽？這個理論是由以色列的“物理學家”(你沒看錯，物理學家)，Eliyahu M. Goldratt (臺灣翻 高德拉特)，在1984年藉由”目標“這本小説提出，在管理學界造成非常大的震撼，到現在超過30年了，世界各國仍然持續再版，許多MBA學校也都將限制理論納入正式課程，一開始最主要是在製造業引起很大的回響，改變了很多生産流程。簡單來説，就像沙漏一樣，工廠的生産流程，每個機台的處理時間都不同，因此最慢的那個機台，就是整個生産流程的瓶頸點，也就是限制因素，它的產出速度決定了整個流程出貨的速度，所以要提高生産力，最重要是要改善瓶頸點的產能，否則在其他非瓶頸點的改善做再多也沒用。
這個概念除了工廠，在其他非製造產業也適用嗎？答案：是的。爲什麽呢？因爲一切都跟流程 (Process)有關。任何產業、任何公司，都是透過各式的流程來產生商業價值，不管是銷售流程、研發流程、製造流程、出貨流程、行政流程…等，除非所有工作都是由同一個人完成，否則只要分工就一定會有所謂的流程，而流程裏的瓶頸點，就決定了完成整個流程的速度，只有找到它、改善它，才有可能提高效率，產生更多價值，但當舊的瓶頸改善了，整個流程裏可能又會產生新的瓶頸，所以必須反復的去看整個系統，因此限制理論提倡的觀念，簡單可以分成五個步驟：
- 找出系統的瓶頸 (限制因素，整體效能的上限)
- 決定如何利用瓶頸 (充分利用瓶頸資源)
- 根據上面的決定，讓其他流程來配合瓶頸 (一切以瓶頸為出發)
- 提高瓶頸的能力 (整體效能提高)
- 回到步驟一，重新檢視新的瓶頸
限制理論雖然一開始是在製造業造成轟動，但不管是軟體業、服務業、醫療甚至教育，都可以利用這五個步驟提高效率，有興趣的朋友可以去看高德拉特的四本書，分別應用在不同的情境，“目標” (生産的應用)、“絕不是靠運氣” (銷售的應用)、“關鍵鏈” (專案管理的應用)、“仍然不足夠” (資訊科技的應用)，都是以小説形式書寫，所以看起來不會死板。
TOC在DevOps的應用
回到DevOps，一個軟體產品同樣是有流程的，從開發、測試、部署、上線、營運…等，每一個步驟，都需要不同的人協力合作，也就一定會產生瓶頸點，而現在軟體的開發方式是講究敏捷精神，快速開發、快速回饋、快速修正、快速循環，但想要做到這步，前提要先知道，究竟整個流程的瓶頸點在哪裏，才有可能去改善它，否則永遠都快不起來。
假如瓶頸是在開發速度，那就要考慮開發手法或工具是否需要調整，或是增加資源，不管是對外招聘或培養内部人員多工；假如是部署速度跟不上，可以考慮是否使用雲端PaaS服務，尤其是新創公司在高速成長期，不可能什麽都自己來，等什麽都準備好，商機早就被別人搶走了，因此聚焦在核心競爭價值，將其它非關鍵的事情外包，才有可能實現快速成長；假如是系統營運不穩定，那就先找出整個系統是哪裏最脆弱，最容易出事情，優先處理這些瓶頸脆弱點，才能讓整體系統效能提高。
當整個IT部門的效率提升到某個程度後，其實會發現，限制整體效率提升的瓶頸，可能轉移到別的部門了，或許是行銷單位、業務單位、物流單位…等，最後甚至是牽扯到整個公司的管理流程、公司政策…等“組織政治”的問題，事情就不是那麽單純了，不但要處理“事”，也要處理“人”，這是實際執行上，最困難的地方。
DevOps的實際案例
這幾天剛好有個非常好的DevOps案例，完全突顯出開發、部署、營運的重要性；這幾年的11月11日，都是電商的大日子，而2018年的這次大日，臺灣的電商們也卯住了勁，做了相當多的行銷推廣策略，結果證明相當成功，瀏覽人數大幅增加，但也因爲行銷太成功，PChome、MoMo的平臺都承受不了瞬間的壓力，而導致系統停止服務，游舒帆Gipi的這篇文章就討論了這件事 (雙 11 準備不足，PChome 和 momo 網站皆進入系統維護狀態)，這個案例完全突顯出DevOps思維的重要性，在開發階段要是沒考慮到實際營運的需求，就算功能寫的再好，也會出現不得不停止服務的情形，就像Gipi文章講的，這其實是非常好的經驗，也是IT技術人員更可以向公司證明技術架構重要性的大好機會，不要抱著“我早就說過了”這種態度，每個人都是不經一事，不長一智，用商業思維的角度去跟公司報告IT技術在網路時代的重要性，我相信大部分的公司藉由這次的案例能更有體悟。
延伸閲讀：
相關閲讀：
Benson的跨域商業人生 