乌卡时代敏捷和 DevOps 成功秘籍

如今，我们正处于一个颠覆性变革丛生的乌卡时代（VUCA），我们周遭的世界正变得越发难以理解。乌卡时代的特征包括：

动互联网、人工智能、云计算等技术加速了乌卡化的进程，资讯和知识的泛滥，人们深度思考的时间越来越少，越来越碎片化。用户对业务快速交付的诉求越来越强烈，企业的压力也是与日俱增，从而催生了对敏捷与 DevOps 的诉求。

提到敏捷与 DevOps ，这个必须提到另外一个话题“反脆弱”。第一听到这个对比是 2014 年 ScrumGathering 上的 Ken Rubin 的一个演讲，见下图。

在看什么是“反脆弱”之前，我们先来看看它的对立面：脆弱

脆弱的东西就像花瓶，就像酒杯，你得非常小心的存放，不然很容易就打碎了，在遇到外界冲击的时候，更多地是损失、被伤害，而不能从中获益；而反脆弱的东西，则正好相反，它欢迎变化，欢迎你去制造混乱，因为他能从混乱重受益，这就像是免疫系统一样，免疫系统面对每一次病毒的袭击，都会在战胜病毒的同时，获得一份抗体，从而增强自身的抵抗力！同理，我们应该更换一个思路，我们的目标不应该仅仅是消除不确定性、风险、变化，而应该培养起这样一种能力，能够在受到外界冲击的时候快速复原，也就是具备“强韧性”，同时从外在的冲击中获益，具备“反脆弱”能力。

脆弱( Fragile ) - 从混乱中受害；强韧( Robust )  - 从混乱中复原；反脆弱( Anti-Fragile ) - 从混乱中受益。无论是组织还是个人，在面对混乱时、面对外部的变化时，都应该具备的强韧与反脆弱能力。这种能力可以通过“敏捷与 DevOps ”来构建。

既然有了敏捷，为啥还要 DevOps 呢？

我们可以看一下这张图。

一般而言，开发与运维有着不同的文化；开发部门的驱动力通常是“频繁交付新特性”，而运维部门则更关注 IT 服务的可靠性和 IT 成本投入的效率，降低风险。两者目标的不匹配，在开发与运维部门之间造成了鸿沟，从而减慢了 IT 交付业务价值的速度。运维从维稳出发，自然希望生产系统部署上线次数越少越好，而上线频度降低，对开发人员是一个负激励：反正我发布的版本也不会上线，反正我再积极也不能实时的体现出来，团队积极性和人员士气都会受到打击。

与此同时，业务部门则希望业务需求尽快的推向市场，而维稳的要求导致价值交付用户的速度被延缓，价值无法迅速得到反馈验证。

DevOps 的由来

Flickr 公司的约翰.阿尔斯帕瓦和保罗.哈蒙德在 2009 年 Velocity 技术大会关于开发速率的一场演讲，“一天十次部署”，是 2009 年前后兴起的 DevOps 运动的一部分，提倡开发和 IT 运维通力协作，在完成高频率部署的同时，提高生产环境的可靠性、稳定性、灵敏性和安全性。 2009 年一天十次部署就算很快了，但现在只能算平均水平，2012 年亚马逊公司宣布，他们平均每天能开展 23000 个部署。

这里提到了 Netflix 这家公司，就不得不提到这家公司的“猴子军团与 Game Day ”

Netflix 在 AWS 上建立了一个叫做 Chaos Monkey 的系统，这些猴子会在工作日期间随机杀死一些服务，制造混乱，来测试 production 下的稳定性。Chaos Monkey 是一种服务，用于将系统分组，并随机终止属于某个分组中的系统中的一部分；Chaos Monkey 运行在一定的受控时间段和时间间隔内（不会无故运行在周末和假日中，并且仅在上班时间内运行）；在大多数情况下，我们的应用设计要保证当某个 peer 下线时仍能继续工作，但是在那些特殊的场景下，我们需要确保有人在值守，以便解决问题，并从问题中进行经验学习；基于这个想法，Chaos Monkey 仅会在工作时间内被使用，以保证工程师能发现警告信息，并作出适当的回应；每当这些猴子开始骚扰，一开始，相关的工程师们不得不放下手头的工作，手忙脚乱地寻求应对之策。随着系统的不断完善，猴子们的攻击能力和攻击范围也在不断提升，反而让整个 Netflix 的服务稳定性、自愈能力以及抗击打能力不断上升。

.ChaosMonkey ，可以随机关闭生产环境中的实例，确保网站系统能够经受故障的考验，同时不会影响客户的正常使用。

.LatencyMonkey ，在 RESTful 服务的调用中引入人为的延时来模拟服务降级，测量上游服务是否会做出恰当响应。通过引入长时间延时，还可以模拟节点甚至整个服务不可用。

.ConformityMonkey ，查找不符合最佳实践的实例，并将其关闭。例如，如果某个实例不在自动伸缩组里，那么就该将其关闭，让服务所有者能重新让其正常启动。

.DoctorMonkey ，查找不健康实例的工具，除了运行在每个实例上的健康检查，还会监控外部健康信号，一旦发现不健康实例就会将其移出服务组。

.JanitorMonkey ，查找不再需要的资源，将其回收，这能在一定程度上降低云资源的浪费。

.SecurityMonkey ，这是 ConformityMonkey 的一个扩展，检查系统的安全漏洞，同时也会保证 SSL 和 DRM 证书仍然有效。

.10-18Monkey ，进行本地化及国际化的配置检查，确保不同地区、使用不同语言和字符集的用户能正常使用 Netflix 。

.ChaosGorilla ，ChaosMonkey 的升级版，可以模拟整个 Amazon Availability Zone 故障，以此验证在不影响用户，且无需人工干预的情况下，能够自动进行可用区的重新平衡。

备注：本文猴子军团引用了姚冬老师的文章“ Netflix 与 AWS 之间不得不说的混乱猴子军团”。

敏捷与 DevOps 如何落地？

不得不提到 DevOps 工作三步法原则：

.第一步是流动原则。保证你所有的工作从左到右可以顺畅的流动，形成一个稳定的工作流。

.第二步要保证持续反馈，在流动过程中实现从右到左稳定快速而丰富的反馈信息流，给你的上游工作者带来更多质量的反馈。

.最后一条原则是，在整个过程中，进行持续学习。坚持不断的优化和改进。

第一步，我们的很多敏捷实践都是可以排上用场，譬如敏捷迭代规划，敏捷需求管理，看板可视化、持续构建、持续集成、持续测试、持续部署等等。

这里不得不提到 Jez Humbler 大牛的一个“绞杀者模式”

绞杀者模式，源于 Martin Fowler 在澳洲旅行时，由当地藤类绞杀植物得到的启示，“它们的种子落在无花果树的顶部，然后藤蔓逐渐沿树干向下生长，最后在土壤中生根。多年以后，藤蔓形成奇妙和美丽的形状，但同时绞杀其宿主树。”

上图即典型的绞杀类植物，我们能看到什么？生命力！

对于架构也是如此，对于紧耦合的架构，可以在其基础上，进行安全的演进式的解耦，从而减少架构的熵。

系统解耦，拆分方法需要根据遗留系统的状态，通常分为绞杀者与修缮者两种模式。

绞杀者模式指在遗留系统外围，将新功能用新的方式构建为新的服务。随着时间的推移，新的服务逐渐“绞杀”老的一流系统。对于那些老旧庞大难以更改的遗留系统，推荐采用绞杀者模式。绞杀者模式用API封装已有功能，并按照新架构实现新的功能，仅在必要时调用旧系统。能够在不影响调用者的情况下变更服务实现，降低了系统的耦合度。

修缮者模式就如修房或修路一样，将老旧待修缮的部分进行隔离，用新的方式对其进行单独修复。修复的同时，需保证与其他部分仍能协同功能。 

这部分引用姚东老师的《【从熵增定律出发，谈谈演进式架构与技术债务】》

第二步，就是建立起各种快速的 PDCA 反馈环，这点在 DevOps 里面有一个专用术语：遥测技术，用来监控各个阶段课程出现的问题，及时提供反馈。这块其实可以多看看丰田精益生产的“安灯拉绳”。

第三步其实比较难，这其实涉及到一个企业文化的建设。

这个话题在北京站的 DevOpsDays 上，Jez Humbler 在闭门交流上，有了一个很好的阐述。

“先改变人的行为，再去改变人的想法，这样才能建立起你期望的文化！”

再延伸一步的畅想，我们该如何驱动敏捷与 DevOps 的快速落地呢？

让我们看看戴悟奥普斯( DevOps )公司是如何从 2-3 月才发布一次演进到平均每天发布 100 多次的吧！

这里面其实最核心的还是目标设定与绩效管理！

“在戴悟奥普斯，他们将发工资的节奏跟产品上线进行了绑定，每上线一次，就发一次工资！！不上线的，就不发工资！”

奖金的额度跟每次上线的需求数量挂钩。

“为了保证质量，每发生一次线上事故，根据严重程度，就扣回对应额度的奖金！这里实际挂钩的是  Fail Rate !，同时还考虑了 MTR ，也是平均恢复时间。"

为了保证上线的内容就是客户所需要的，他们会度量外向型的度量指标：譬如客户上钩指数、客户上瘾指数、客户尖叫指数等。

乌卡时代，敏捷和 DevOps 的成功其实没有捷径，没有所谓秘籍，关键还是需要脚踏实地的落地各种实践，需要建立起信任、试错、以客户为中心的文化，需要有针对性的 KPI 设定，加油吧，同学们！

王立杰老师：《敏捷无敌》作者，《敏捷开发一千零一夜》主编，江湖人称“无敌哥”，京东首席敏捷创新教练，北大光华/新华都商学院 MBA 《创业机会分析与识别》特邀讲师，多年产品研发管理与敏捷实施经验，专注于精益创业与产品创新、精益/敏捷组织转型、研发效率提升。2014 TiD 大会十大最受欢迎讲师，曾经在 51CTO、ScrumGathering 、敏捷之旅等大会做过多次演讲，是中国 DevOpsDays 组织者，EXIN DevOps Professional 认证讲师。