DevOps如何驱动企业价值流交付？

在数字化转型的今天，一个企业的IT能力决定了它未来的成败。正如DevOps倡导者Christopher Little所说：“每个公司都是科技公司，无论他们认为自己处在哪个行业，银行也只是拥有银行执照的IT公司而已。”

业务的加速创新让当代技术领导者们面临着安全漏洞频发、交付周期不断缩短、技术大规模转型的挑战，如何才能打造一个持续的、可预测的、稳定安全的业务价值流交付体系？

这个问题从根本上来说是软件交付中稳定与快速的矛盾，很多企业为此建立了多套IT体系，用以区隔"做得正确"和“做得快速”两种系统，并被冠以“双模IT”或“前台、中台、后台”等概念。

DevOps致力于从根本上解决这个矛盾，在对高绩效企业的调查（Puppet Labs DevOps）中证明，良好实践DevOps的组织能够兼顾高水平的生产力和可靠性。

  ·关注价值流动效率·  

在精益生产理念中一系列的改善及加速价值流动的理念和原则，DevOps中都可以找到一一的对应。

• 强调与关注整体目标

• 防止缺陷向下游传递

追求数量会造成浪费，而追求质量会产生价值。——大野耐一

缺陷一旦带入到下游，修复的成本和工作量会指数级的增加。在有缺陷的上游基础上开展新的研发活动，不但会引起自身的质量问题，还会导致技术债务的积累。

在精益生产的发源地丰田公司，使用著名的"安灯绳"制度来防止缺陷向下游的传递。在丰田制造工厂里，每个工作中心都是一条绳索，每个工人和经理都受过培训，他们会在出现问题时拉下安灯绳，在安灯绳被拉动时，团队领导就能第一时间得知并立即着手解决问题。如果问题不能在指定的时间（如55秒）内解决，就会停掉整个生产线，调动整个企业一起协作，直到成功地找出解决问题的对策。

在DevOps中，通常有两种方式来实践防止缺陷传递：

一是为下游设计发现问题的方法——为运维设计功能，如尽快崩溃、日志记录、异常上报等，让下游发现的问题可以尽快的反馈到上游。

二是建立快速发现、全体分析、快速解决的机制——当发现问题的时候应该全员参与讨论分析，主动停止任何新功能的开发直到问题的解决。

• 小团队小规模高频次

  ·数据度量与持续改进·  

• DevOps数据度量的目标

数据度量在软件生产中非常普遍，传统的CMMI或者ISO相关体系中都有大量的数据度量指标来验证最终的成果。DevOps作为一种精益研发的生产实践，非常强调快速迭代和快速改进，所以会在数据度量上有以下几个目标：

l 让工作可视化：建立跨越整个价值流（从需求到运维）的可视化看板，帮助团队从全局跟踪和管理

l 对比和改善：可以建立参考坐标系，让人通过横向与纵向的对比评估当前所处的水平，与他人团队或者竞品的差距，并帮助人关注需要改善的方向。

l 衡量创新的价值：检验创新活动能否最终转化为实际价值的标尺

• 度量与改进中的原则

在数据度量和改进的过程中，经常会有一些错误的方式导致团队过分追求片面或者局部的指标改进，甚至浪费精力去做一些毫无价值的工作，不但没有给全局改进带来任何收益，反而造成了新的浪费，因此以下的几点可以作为我们开展度量和改进的原则：

l 度量只能作为绩效或者评级的参考，应尽量避免直接相关：将某个局部指标（缺陷密度等）作为绩效考核往往会让团队忽视了全局改进，陷入局部改进的陷阱。

l 度量指标体系自身需要不断的迭代演化才确保有效性：跟软件一样，度量本身也需要持续迭代。

l 数据积累越多越久越有用：样本太少会导致偏差的概率增加，在度量上我们需要耐心。

l 深入研究卓越的团队或者个体：有时候最值得学习的人就在我们身边，我们需要一种机制来发现和复制组织内部的成功。

l 尽量通过自动化减少度量的成本：别让度量成为团队的负担

  ·DevOps理念如何落实·  

众所周知，DevOps是个开放的体系，其理论体系也正处于在实践中不断发展的阶段。

在整个DevOps最佳实践中实际包括了敏捷研发和过程管理。企业级DevOps和规模化的敏捷实践十分不易，团队从几十人到上千人再到上万人，规模不等，其最终的目标也不一，所以实践企业级DevOps时往往因组织规模而异、因组织目标而异、因组织文化而异以及因人而异。

这需要从组织架构设计、开发团队的划分、开发与整体持续集成过程的协同等不同层面去落实该技术体系，这里介绍几点企业级DevOps的实践目标。

小团队：亚马逊推崇控制内部团队的规模大小，一个团队规模应该2个披萨就可以吃饱（约6~10人）。这种架构可以使团队充分的自治，在架构上与其他团队的工作解耦。在统一的自助式平台（AWS）上，各个团队独立，高效的处理自己的工作，快速频繁的交付业务价值，不需要等待其他的团队大量迟来的功能或是因为他人的错误进行紧急的返工。

小规模：将单个大规模的研发交付目标切分成多个小规模的持续交付，可以显著的加速高质量价值流的交付。小规模使得团队目标更加清晰，更容易从上线之后的反馈中总结下一次的改进事项，即使发生问题，其影响范围也更小，更容易被修复或者隔离。

高频次：为了实现小规模的交付，我们必须提高交付的频次、质量、降低单次交付的成本。利用自动化的测试、集成、安全扫描等工具，可以有效减少开发人员向测试团队或者QA/安全部门沟通申请的时间。

工作可视化：端到端的精益看板，可以清晰的展示出用户的价值如何在流动，当前有哪些步骤会有拥堵的风险，减少哪些环节可以有效的提升整体效率，每个人是如何在自己的工作中为团队整体的目标做出贡献，把个人，团队以及最终的用户反馈建立起有效的连接。

自动化：基于自助式的平台可以实现环境搭建的自动化，以便精准、重复地搭建指定版本的环境。这些自动化的过程可以有效的减少沟通成本/等待时间，让研发团队可以将精力和时间用于提升产品的交付质量。