2015 年 DevOps 状态:速度满足质量

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...点击查看项目介绍 ;
  • 《从零手撸:前后端分离博客项目(全栈开发)》 2 期已完结,演示链接: http://116.62.199.48/ ;

截止目前, 星球 内专栏累计输出 63w+ 字,讲解图 2808+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,权限管理,Spring Cloud Alibaba 微服务等等,已有 2200+ 小伙伴加入学习 ,欢迎点击围观

2015 年 DevOps 状态报告 (由 Puppet Labs Gene Kim 的 IT Revolution 合作发布)现已发布,这是该报告涵盖 DevOps 如何将 IT 性能与业务价值联系起来的第四个年头。该报告延续了前几年的趋势,将采用 DevOps 的高绩效公司的数据与尚未采用 DevOps 的低绩效公司的数据进行比较。今年,该报告强调了高绩效公司和低绩效公司之间的绩效差距如何显着扩大:DevOps 运动继续取得成果。以下是我们从报告中收集到的信息:

与 2014 年大致相同,高绩效公司的部署频率和速度仍然是低绩效公司的 30 倍和 200 倍,但他们现在从故障中恢复的速度快了 168 倍,实施变革的频率高了 60 倍。与 2014 年的 48 倍恢复速度和 3 倍的变革实施速度相比,这是一个巨大的增长。这里有一个非常重要的要点:高绩效公司在他们所做的事情上做得更好,因为他们做的更频繁。

改变作为一种竞争武器

简而言之,高绩效公司仍在快速行动,但他们越来越有能力更自信、更可靠地做出改变。这说明了 DevOps 的真正价值,即既能快速行动又 不会 破坏事物。能够可靠地实施变革的公司拥有强大的武器——他们可以更快地进行试验并最终在创新上超越竞争对手。试验和失败是相辅相成的,因此失败但迅速恢复并从经验中学习的能力是高绩效公司可以利用的竞争优势。这是一种武器,可以帮助他们找出与客户产生共鸣的内容,并在竞争对手采取行动之前实施解决方案。

敏捷性和质量的概念似乎是对立的,因此看到定量数据表明两者可以同时实现是令人鼓舞的。报告中的评论“故障更少,因为问题已在软件开发过程的早期得到解决”切实展示了 DevOps 的好处,并对其 改善制造的 根基表示认可。

在敏捷性服务中,质量很容易被忽视,尤其是在刚刚开始试验 DevOps 的低绩效组织中。看到质量“向左移动”——从整体上看待质量并将其纳入核心开发和部署流程——应该会鼓励更多规避风险的公司采用 DevOps。学习过程从弄清楚如何更频繁地进行更改开始,然后设法以较小的运营影响进行更改。这就是报告所指出的高绩效公司的趋势,而这种敏捷与质量的结合是创新的必要因素之一。

一分耕耘一分收获?

该报告还使用一种巧妙的方法来量化变革的能力和意愿,即所谓的部署痛苦。该报告要求公司思考“部署有多痛苦?”并建议这是一个很好的指标,表明您在采用 DevOps 方面做得如何。高绩效的 DevOps 团队并不害怕部署到生产环境——今年的统计数据表明他们这样做的频率更高,并且失败次数更少,恢复时间更快。

与部署相关的恐惧是很自然的。生产是所有验证发生的地方——基础设施的验证、架构的验证和部署的软件的验证。如果部署出现问题,动态将变为被动救火,这会极大地扰乱工作流程。但 DevOps 现状 报告强调了如何通过更小、更频繁的部署和衡量每次部署的影响来降低部署风险。 (注意:我们之前在博客中介绍过 衡量部署的重要性 ,因为我们同意衡量变更影响的重要性。)

DevOps 战胜倦怠!

作为一名正在康复的老派运维人员,很高兴看到该报告特别指出了与变革密切相关的倦怠问题。对于许多担任运营角色的人来说,与倦怠作斗争是一场无休止的战斗。长期以来,Ops 一直被认为是一份吃力不讨好的工作,担任这些角色的人已经习惯了很少得到表扬。他们通常只有在出现故障或“站点已关闭!”时才会收到高层管理人员的来信。

DevOps 运动通过更清楚地显示 IT 功能与业务价值之间的联系,帮助缓解了倦怠的威胁。这种可见性使人们对角色的重要性有了新的认识,当可用性和应用程序响应时间等指标成为业务的关键绩效指标时,这种认识得到了加强。

尽管如此,对于处于管理或领导职位的人来说,抽出时间主动感谢那些负责让你的飞机保持飞行的人,这并没有什么坏处。认可和同理心可以实现报告中避免倦怠的关键建议之一:建立支持性的组织文化。

当然,报告中还有更多内容,包括发现持续交付可以应用于任何正确架构的系统以及微服务架构日益重要的重要性。该报告还深入探讨了架构与开发人员生产力之间的联系,提供了多元化团队创造更好业务成果的证据。

要自己阅读报告, 请在此处免费下载 2015 年 DevOps 状态 报告

这篇文章最初出现在 Stevan Arychuk 的 New Relic 博客 上。

相关文章