什么是DevOps？（二）从工厂生产流程看IT作业流程-面包板社区

看到标题，可能很多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） 有关。任何产业、任何公司，都是透过各式的流程来产生商业价值，不管是销售流程、研发流程、製造流程、出货流程、行政流程等，

除非所有工作都是由同一个人完成，否则只要分工就一定会有所谓的「流程」，而流程裡的「瓶颈点」，就决定了完成整个流程的速度，只有找到它、改善它，才有可能提高效率，产生更多价值。

但当旧的瓶颈改善了，整个流程裡可能又会产生新的瓶颈，所以必须反覆的去看整个系统，因此限制理论提倡的观念，简单可以分成五个步骤：

找出系统的瓶颈（限制因素，整体效能的上限）
决定如何利用瓶颈（充分利用瓶颈资源）
根据上面的决定，让其他流程来配合瓶颈（一切以瓶颈为出发）
提高瓶颈的能力（整体效能提高）
回到步骤一，重新检视新的瓶颈

限制理论虽然一开始是在製造业造成轰动，但不管是软体业、服务业、医疗，甚至教育，都可以利用这 5 个步骤提高效率，有兴趣的朋友可以去看高德拉特的四本书，分别应用在不同的情境：

《目标》（生産的应用）
《绝不是靠运气》（销售的应用）
《关键链》（专案管理的应用）
《仍然不足够》（资讯科技的应用）

都是以小説形式书写，所以看起来不会死板。

TOC在DevOps的应用

回到DevOps，一个软体产品同样是有流程的，从开发、测试、部署、上线、营运等，每一个步骤，都需要不同的人协力合作，也就一定会产生瓶颈点，而现在软体的开发方式是讲究敏捷精神，快速开发、快速回馈、快速修正、快速循环，但想要做到这步，前提要先知道，究竟整个流程的「瓶颈点」在哪里，才有可能去改善它，否则永远都快不起来。

假如瓶颈是在开发速度，那就要考虑开发手法或工具是否需要调整，或是增加资源，不管是对外招聘或培养内部人员多工；假如是部署速度跟不上，可以考虑是否使用云端PaaS服务，尤其是新创公司在高速成长期，不可能什么都自己来，等什么都准备好，商机早就被别人抢走了，因此聚焦在核心竞争价值，将其他非关键的事情外包，才有可能实现快速成长；假如是系统营运不稳定，那就先找出整个系统是哪裡最脆弱，最容易出事情，优先处理这些瓶颈脆弱点，才能让整体系统效能提高。

当整个IT部门的效率提升到某个程度后，其实会发现，限制整体效率提升的瓶颈，可能转移到别的部门了，或许是行销单位、业务单位、物流单位等，最后甚至是牵扯到整个公司的管理流程、公司政策等「组织政治」的问题，事情就不是那么单纯了，不但要处理「事」，也要处理「人」，这是实际执行上，最困难的地方。

DevOps的实际案例

刚好有个非常好的DevOps案例，完全突显出开发、部署、营运的重要性；这几年的11月11日，都是电商的大日子，而今年（2018）的这次大日，台湾的电商们也卯住了劲，做了相当多的行销推广策略，结果证明相当成功，浏览人数大幅增加，但也因爲行销太成功，PChome、MoMo的平台都承受不了瞬间的压力，而导致系统停止服务，游舒帆Gipi的这篇文章就讨论了这件事（双11准备不足，PChome和momo网站皆进入系统维护状态），这个案例完全突显出DevOps思维的重要性，在开发阶段要是没考虑到实际营运的需求，就算功能写的再好，也会出现不得不停止服务的情形，就像Gipi文章讲的，这其实是非常好的经验，也是IT技术人员更可以向公司证明技术架构重要性的大好机会，不要抱著「我早就说过了」这种态度，每个人都是不经一事，不长一智，用商业思维的角度去跟公司报告IT技术在网路时代的重要性，我相信大部分的公司藉由这次的案例能更有体悟。