早从 8 年前,就已经有企业开始引入 DevOps 了,到 2018 年,DevOps 已经相当普及。然而,很多新兴的创业公司和大型企业仍然不敢引入 DevOps。
这一现象是由创业者及企业高管的思维方式导致的。他们常常认为:“如果现有的工作方式没有问题,就没有必要改善现状。”正是由于这种思维方式,这些企业仍然在采用传统的工作方式。例如他们使用公司内部服务器运行关键任务,并将开发、运营和质量保障设为各自分离的部门。
对于创业公司来说,采用传统的工作方式意味着他们更看重服务的复用性和用户的体验,从而忽略了新功能的实现。这种做法的优点在于它能规避风险,保证产品性能的稳定,同时能最大限度的减少服务中断可能性。
引入 DevOps 之后:效果很好,但仍有改善空间
据 Puppet 最新的一份 2017 年关于 DevOps 调查报告结果所示,DevOps 软件交付方法能够应付所有的挑战,并提供多个优点。
以下是该报告中一些有趣的调查结果:
引入DevOps 文化的公司代码部署频率提升46 倍,这意味着每一批代码只需要几个小时就可以交付给生产环境,而不用像以前一样需要数周。
遵循DevOps 的IaC, CI 和CD 原则可确保将代码交付的时间缩短440 倍,这样,代码的构建,测试及部署在一小时内就可以完成。正是这样的速度创造了上面所说的代码部署能力。
许多企业担心过于频繁的部署代码可能会导致测试不足,从而留下严重的隐患。如果在上线后,这些隐患引起服务器停机,就会严重影响用户体验。恰恰相反,DevOps 拥有深入代码的自动测试流和稳固的版本基础架构,能够防范风险。就算发生了任何故障,引入DevOps 之后,TTR(恢复时间)提高了96 倍,更不用说它已经将风险发生的机率减少了5 倍(据Puppet 的报告,相较于引入前提交代码时平均35% 的失败率,DevOps 将它降低到了7% 左右)。
当公司上下都全力配合DevOps 实现的时候,它带来好处的速度将会提高2 倍。超过65% 的受访者表示,DevOps 的引入帮助他们实现了所有的工作目标。然而,约有一半的受访者表示,如果没有一个积极的、有魅力的领导会导致DevOps 引入失败。
现已有近27% 的企业正在进行或者已经实现了DevOps。同时也有41% 的受访者表示他们将会把实现DevOps 列为公司未来几年的优先任务。
DevOps 的大部分服务都是自动化的,这一特点简化了大量的常规任务,为创造性的工作腾出了资源。例如,自动化的代码交付可以节省以下资源:
使用 Codeception 这类自动化测试工具能够节约大概 27% 的测试资源和时间。
使用 GCP 和 Kubernetes 自动化部署流能够节约至少 30% 的代码部署资源和时间。
避免了不必要的瓶颈和管理开销,能够省去超过 27% 的审批和工作流程。
使用 Kubernetes 容器管理工具,Terraform 配置协调平台,Ansible, Salt, Chef 或者 Puppet,能够节约大概 33% 的配置管理的资源和时间。
工具很实用,但 DevOps 文化是最重要的
正如领先的协作软件供应商 Atlassian 在其 DevOps 采用报告中指出,有 41% 的 IT 企业熟悉 DevOps 服务,而另外的 59% 仍然不知道这种服务的优势。因此,这 41% 的企业在行业竞争中具有相当大的优势。
对 Atlassian 的调查做出回应的 IT 专家中,90% 的人都已经体验过 DevOps 带来的好处。尽管如此,他们中有 70% 的人表示,逐步增加的责任反而会导致压力爆棚。
为什么会有这样的反应?因为在一家公司里多部门协作,同时教会开发和运营部门的人员使用所有的工具,这并不是一个高效创造 DevOps 工作流程的方式。前面的报告中提出了下列几个重要的问题:
80% 的受访者表示,在一个新成立的 DevOps 团队中,知识的共享和交叉学习实践的机会很有限。他们只能通过静态文档,而不能通过团队间的直接沟通或者 wiki 来分享一些知识。另外只有 17% 的受访者表示他们能够获取所需的一切信息,同时也能及时得到团队的配合。
虽然每个拥有 DevOps 文化的企业都部署了监控和记录工具,但是仅有 64% 的受访者表示他们有主动监控和智能警报系统。这意味着只有三分之二的企业能够迅速的压制并从根本上解决问题,而不用处理由于服务器问题导致的用户差体验。
你们应该知道,这时候用大炮打蚊子这种做法是非常值得的。
几乎所有的受访者都表示他们的公司已经实现了自动化测试,或者正在实施自动化交付流。尽管如此,近 42% 的受访者表示,在将代码交付到生产环境之后,他们仍然需要手动修改小错误。这意味着 CI/CD 实践尚未成熟,新提交的代码并没有经过真实生产环境严格的,负载的测试。
灾害管理仍未完善。有近 50% 的受访者承认他们的方法,流程和反应会根据不同类型的事件而定。这就是说,有一半的 DevOps 的开发人员没有遵循明确的指导,仍然依靠手动来解决问题,并等待上级的指示。
关于 AWS 和 Azure DevOps 相关统计的简要总结
2017 年,Sumo Logic 公司发表了一份关于云事件现状的年终报告。
该报告结合了超过1500 个用户的回复。其中有64% 的用户使用AWS,3.8% 使用Azure,其余则是其他云服务提供商(CSP)或者多云策略用户。以下是这份报告的主要内容:
80% 的 AWS 用户使用 Linux 操作系统。Azure 的 Linux 操作系统用户数量由 2016 年的 4% 增加到 2017 年的 12%。
AWS Lambda 的应用率增长了近 200%(从 2016 年的 12% 到 2017 年的 23%)。
2017 年,已经有 24% 的 AWS 用户使用 Docker (2016 年为 18%)。
现在NoSQL 数据库比传统的关系型数据库管理系统(RDBMS)更受欢迎。事实上,Redis, MongoDB 和Cassandra(28.3%) 的使用率刚刚超过了MySQL,PostgreSQL 和RedShift(27.3%)。这两个组合占据了AWS 用户使用的所有数据库类型的55.6%,而Oracle 和Microsoft SQL 则明显落后。
NGINX 和 Apache 作为领先的 Web 服务器,已经将 IIS 甩在身后。
安全性是云转换的首要原因,但近 50% 的 AWS 用户表示从未使用过内置的 AWS CloudTrail 服务,用于监控 AWS VPC 流量的 VPC Flow Logs 工具也很少被使用,只有 14.1% 的受访者确认使用过这些工具。
关于 DevOps 采用现状的总结
上述报告中的统计数据清楚地表明,引入 DevOps 的公司能够看到他们的软件交付操作有了明显的改进,并且能够实现他们的既定业务目标。然而,传统的文化很难打破,除非能够实现真正的合作和知识分享,这也是 DevOps 目前面临的一大挑战。
当然,解决这些问题只是时间的问题,这就要求即使是那些目前尚未开始向 DevOps 转型的公司,仍然能够取得成功,并在业内其他市场参与者中获得竞争优势。还是建议他们能够真心实意地接受 DevOps 文化,高效地分配资源,建立更好的,更有效率的自动化工作流。
感谢张婵对本文的审校。
评论