編按：本文為系列第二篇，第一篇〈什麽是DevOps？（一）從管理與商業思維角度切入〉。
看到標題，可能很多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學校也都將限制理論納入正式課程，一開始最主要是在製造業引起很大的回響，改變了很多生産流程。簡單來説，就像沙漏一樣，工廠的生産流程，每個機台的處理時間都不同，因此最慢的那個機台，就是整個生産流程的瓶頸點，也就是「限制因素」，它的產出速度決定了整個流程出貨的速度，所以要提高生産力，最重要是要改善瓶頸點的產能，否則在其他非瓶頸點的改善做再多也沒用。
掌握最新AI、半導體、數位趨勢！訂閱《數位時代》日報及社群活動訊息
這個概念除了工廠，在其他非製造產業也適用嗎？答案：是的。爲什麽呢？因爲一切都跟流程（Process） 有關。任何產業、任何公司，都是透過各式的流程來產生商業價值，不管是銷售流程、研發流程、製造流程、出貨流程、行政流程等，
除非所有工作都是由同一個人完成，否則只要分工就一定會有所謂的「流程」，而流程裡的「瓶頸點」，就決定了完成整個流程的速度，只有找到它、改善它，才有可能提高效率，產生更多價值。
但當舊的瓶頸改善了，整個流程裡可能又會產生新的瓶頸，所以必須反覆的去看整個系統，因此限制理論提倡的觀念，簡單可以分成五個步驟：
- 找出系統的瓶頸（限制因素，整體效能的上限）
- 決定如何利用瓶頸（充分利用瓶頸資源）
- 根據上面的決定，讓其他流程來配合瓶頸（一切以瓶頸為出發）
- 提高瓶頸的能力（整體效能提高）
- 回到步驟一，重新檢視新的瓶頸
限制理論雖然一開始是在製造業造成轟動，但不管是軟體業、服務業、醫療，甚至教育，都可以利用這 5 個步驟提高效率，有興趣的朋友可以去看高德拉特的四本書，分別應用在不同的情境：
《目標》（生産的應用）
《絕不是靠運氣》（銷售的應用）
《關鍵鏈》（專案管理的應用）
《仍然不足夠》（資訊科技的應用）
都是以小説形式書寫，所以看起來不會死板。
TOC在DevOps的應用
回到DevOps，一個軟體產品同樣是有流程的，從開發、測試、部署、上線、營運等，每一個步驟，都需要不同的人協力合作，也就一定會產生瓶頸點，而現在軟體的開發方式是講究敏捷精神，快速開發、快速回饋、快速修正、快速循環，但想要做到這步，前提要先知道，究竟整個流程的「瓶頸點」在哪裏，才有可能去改善它，否則永遠都快不起來。
假如瓶頸是在開發速度，那就要考慮開發手法或工具是否需要調整，或是增加資源，不管是對外招聘或培養内部人員多工；假如是部署速度跟不上，可以考慮是否使用雲端PaaS服務，尤其是新創公司在高速成長期，不可能什麽都自己來，等什麽都準備好，商機早就被別人搶走了，因此聚焦在核心競爭價值，將其他非關鍵的事情外包，才有可能實現快速成長；假如是系統營運不穩定，那就先找出整個系統是哪裡最脆弱，最容易出事情，優先處理這些瓶頸脆弱點，才能讓整體系統效能提高。
當整個IT部門的效率提升到某個程度後，其實會發現，限制整體效率提升的瓶頸，可能轉移到別的部門了，或許是行銷單位、業務單位、物流單位等，最後甚至是牽扯到整個公司的管理流程、公司政策等「組織政治」的問題，事情就不是那麽單純了，不但要處理「事」，也要處理「人」，這是實際執行上，最困難的地方。
DevOps的實際案例
剛好有個非常好的DevOps案例，完全突顯出開發、部署、營運的重要性；這幾年的11月11日，都是電商的大日子，而今年（2018）的這次大日，臺灣的電商們也卯住了勁，做了相當多的行銷推廣策略，結果證明相當成功，瀏覽人數大幅增加，但也因爲行銷太成功，PChome、MoMo的平臺都承受不了瞬間的壓力，而導致系統停止服務，游舒帆Gipi的這篇文章就討論了這件事（雙11準備不足，PChome和momo網站皆進入系統維護狀態），這個案例完全突顯出DevOps思維的重要性，在開發階段要是沒考慮到實際營運的需求，就算功能寫的再好，也會出現不得不停止服務的情形，就像Gipi文章講的，這其實是非常好的經驗，也是IT技術人員更可以向公司證明技術架構重要性的大好機會，不要抱著「我早就說過了」這種態度，每個人都是不經一事，不長一智，用商業思維的角度去跟公司報告IT技術在網路時代的重要性，我相信大部分的公司藉由這次的案例能更有體悟。
本文由李正霖授權轉載自其blog。
《數位時代》長期徵稿，針對時事科技議題，需要您的獨特觀點，歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw，文長至少800字，請附上個人100字內簡介，文章若採用將經編輯潤飾，如需改標會與您討論。
（觀點文章呈現多元意見，不代表《數位時代》的立場。）
