DevOps 文字培训

应如何在组织中启动 DevOps？

你如何在组织中开启 DevOps 旅程，将决定这项计划能取得多大成功。因此，尽可能把握好第一次机会，这可能也是唯一的机会。

避免大规模变革，从小处着手

你已经知道，无法一下子打破现状，第一天就宣布整个组织进行 DevOps 转型。首先要找出那些一直在解决问题、努力实现尚未达成的目标的团队。这些团队清楚改进的必要性，也最愿意考虑改变工作方式。他们还愿意全心全意地为组织和客户服务。

尽快展示初步成果

你的任务是展示 DevOps 计划迅速取得的早期成果，向持怀疑和反对态度的人证明 DevOps 解决了哪些问题、创造了什么价值。随后再将这些改进逐步推广到组织中的其他领域。

德国一家领先的 ERP、CRM 和 SaaS 厂商大体上就是这样开启 DevOps 旅程的。他们的维护团队每年只交付一次，未发布的代码很快在不同的事件分支中累积。这使得合并代码以及推出经过充分测试的可靠维护版本变得极其困难。

他们先把维护开发团队与维护交付规划、质量保证和运维环境管理团队合并，再开始使用统一的任务和工单管理系统，简化协调和沟通工作。之后，他们开始每月发布，很快又改为每两周发布一次。

在维护团队采用新做法的第一年，解决的事件数量是前一年的 6 倍。同样重要的是，重新开启的事件及相关返工的比例从 39% 降至 4%。

凭借这些显著改进和可证实的改进指标，这项小规模 DevOps 计划在组织内获得大力支持和信任，并赢得高管支持，以便推广到其他产品和服务团队。

选择合适的全新产品和服务或现有产品和服务

开启 DevOps 计划时，还需考虑选择从零开始开发的产品和服务，还是基于现有系统开发的产品和服务。

从零开始开发的产品和服务对你的组织来说是全新的。为此，另行组建一支独立工作的团队对你最有利，尤其是在起步阶段。这种独立性让团队成员更有机会打破现状、跳出固有思路，也有望减少因原先职责造成的工作中断。为新团队设定切实的 IT 和业务绩效指标和成果，比如提高销售额、改善客户参与度或缩短交付时间。全新项目中的 DevOps 计划无需依赖遗留代码或依赖项，因此对你和团队而言，成功启动的风险较低。不过，成功给组织带来的影响也较小，因为这个全新项目无法证明 DevOps 能否解决组织的现有问题，也无法证明成功能否在其他领域复制。

你也可以用基于现有系统开发的产品和服务开启 DevOps 旅程。很多这类产品和服务已在生产系统中运行，为业务和客户提供支持。如果我们生活在同一个星球，那么你的现有软件应用很可能有相当多的技术债务，而且可靠的自动化测试不多。因此，从现有产品和服务着手可能更具挑战，但如果取得积极成果，回报会更大，对组织也更有说服力和影响力。

DevOps 同样适用于运行大量遗留系统的大型组织

许多人误以为 DevOps 不适用于基于现有系统开发的产品和服务，甚至认为它只适合初创公司。然而，一些最具示范意义的 DevOps 计划始于 IT 部门庞大而成熟的企业，这些企业有数不清的关键业务遗留系统和数千名员工。Amazon、Easy 和 Facebook 就是其中的几个例子。如前面 SaaS 厂商案例所述，你也可以在已有组织中，以现有产品和服务启动 DevOps。事实上，由于大多数此类产品和服务的实际表现与客户期望相差很大，它们往往最适合从 DevOps 转型中获益。给你一个启动现有项目 DevOps 计划的建议：先投入时间清偿或至少减少技术债务，再为现有产品功能和效益补齐缺失的自动化测试。否则，现有产品和服务永远无法让你在更短的周期内进行可靠的生产部署。

选择合适的记录型系统或交互型系统

首次实施 DevOps 时，你可以选择记录型系统，也可以选择交互型系统。记录型系统是用于管理组织内单一事实来源的集中式系统，尤其侧重管理客户、交易、安全和隐私等数据。交互型系统大多是分散式应用，帮助并鼓励客户与用户通过全渠道响应式门户，或通过手机、平板和桌面应用与你的组织互动。

选择记录型系统的好处是，你能展示 DevOps 团队有能力处理合规、安全和隐私等耗时且流程繁琐的任务。你和团队可以在产品和服务的整个开发与运维生命周期中，通过测试自动化和遥测取得科学、具体的证据。一个典型例子是，把分布在不同地理位置的数据从本地数据库服务器迁移到云端，同时确保单一事实来源仍符合有关法律、行业、地方和国际的规则与法规。

如果选择交互型系统，你就能展示如何利用快速交付周期可靠地加快创新。这是因为当今大多数带来商业成功、可见的创新都源于交互型系统。一个典型例子是，让电子商务门户的结账流程更加直观和简洁，从而将销售额提高 25%。做到这一点时，高管不仅会欣赏 DevOps，也会欣赏你。

成功实施 DevOps 转型的方法

在 DevOps 旅程开始时，别把时间浪费在争取保守团队上。找出最具创新精神、思想最开放、人脉最广且最有影响力，并相信 DevOps 方法和原则有必要的团队。从小处开始，先选择一到两个团队。用上述建议找出最适合的全新或现有产品和服务，以及合适的记录型或交互型系统作为起点。

首批成功案例出现后，加入计划的团队会成为你向整个组织推广 DevOps 的最大支持者。随后，把合作扩大到其他团队，增加成功案例。这些成功会为 DevOps 计划带来越来越多的口碑和信任。管理层看到可量化的好处后，也会给予你更多支持、资助和关注。

在最后阶段，找出有影响力的阻挠者和坚决的反对者（Curmudgeons）。或许可以用他们惯用的方法来应对他们，也就是提醒人们注意风险、唤起担忧。向他们说明，如果拒绝学习和使用 DevOps，他们的团队和产品会显得多么落后，并成为组织最后的薄弱环节。

总结

推动组织的 IT 转型绝非易事，DevOps 也一样。不过，从小处着手不会带来太大风险。同时请记住，无论是初任还是资深领导者，最重要的职责之一都是激励和动员团队为改善业务表现而行动，并为获得最大程度的职业满足感承担一些经过权衡的风险。