克服浮躁_推动采用并克服变革阻力

推动DevOps转型可能具有挑战性，但这是一项有意义的工作。 要取得成功，您需要专注于DevOps的业务驱动力，并通过评估现有的最佳实践并选择最佳的试点项目来证明成功，从而找到正确的重点。 最终，您希望了解整个软件和系统的生命周期。 在本系列的第8部分中，您将学习如何开始在公司中驱动DevOps。

在我作为DevOps传播者的工作中，我开始感到我的同事们相信DevOps是解决任何IT相关挑战的最重要因素。 它们没有错，DevOps之所以如此有效的原因变得越来越明显。 但是DevOps也威胁着现状，许多其他公司的同事经常向我寻求帮助，以说服其组织采用DevOps最佳实践。

整个行业的IT经理都热烈拥护DevOps原则和实践。 即便如此，对于什么是DevOps以及如何最有效地实施DevOps最佳实践仍然存在困惑。 许多努力失败了，因为现有的利益相关者不适应变化。 他们还认为DevOps失去了对其所使用的功能和组的控制。 我已经看到运营团队与DevOps进行了反击，感觉它威胁到了他们的生存-直到他们意识到DevOps可以给他们带来多少个人利益。 您需要做的第一件事是了解DevOps的目标以及如何衡量其成功。

目标和衡量成功

DevOps致力于改善组织更新其应用程序的方式，这使他们能够更频繁地部署代码并提高系统的可靠性。 成功进行DevOps转换的最常见方法是完全自动化的部署管道，该管道可以交付支持业务目标所需的应用程序更改（包括紧急错误修复）。 DevOps还通过提供确定性的方法来验证已部署正确的代码，并确保没有由于人为错误或恶意意图而进行的未经授权的更改，从而大大增强了系统安全性。 要真正了解DevOps的价值，您需要考虑使这种方法引人注目的业务驱动因素。

我们生活在充满挑战和动态的商业环境中。 公司必须不断提供满足并超出其苛刻和精通技术的客户群的期望的复杂功能。 DevOps通过快速可靠地交付业务功能来增强敏捷性，从而提供竞争优势。 具有成熟的DevOps功能的公司可以更好地应对业务压力，并享受更加可靠和安全的系统基础架构。 尽管如此，许多公司仍难以理解DevOps的全部含义，而错误的信息是成功采用DevOps的主要障碍。 如果您希望克服变化的阻力并成功采用DevOps，则需要确保传达有关DevOps的全部内容以及它如何帮助实现业务成功。

什么是DevOps？

DevOps是一组松散定义的原则和实践，可帮助包括开发和运营在内的团队更有效地沟通和协作。 有效的DevOps方法是创建一个高性能的跨职能团队，将开发和运营技术专业人员的专业知识相结合。 来自不同群体的聪明人团结起来，可以提供协同作用和高效的工作团队，他们可以以积极的态度应对几乎所有挑战。 根据定义，DevOps意味着您既代表开发又代表运营。 开发专注于使用最新技术开发新功能。 运营部门负责确保可靠的系统。 将这两个重要的观点放在一起，您将获得惊人的结果。 但是DevOps不仅与Dev and Ops有关。 DevOps还应包括来自其他孤岛的利益相关者，例如：

• 产品管理
• 质量检查
• 测验
• 信息安全

绝对有必要包括所有正确的利益相关者，以清晰，准确的方式传达DevOps信息也是如此。 技术专业人员经常以模糊和混乱的方式使用DevOps流行语。

误传

存在有关DevOps的错误信息。 即使是某些试图推进自己的议程的人，例如联邦法律或行业最佳实践通常要求使用DevOps绕过操作和IT控制的人员，也会被误导。 许多大型银行在实施DevOps方面做得很出色，但这并不意味着各个开发人员都可以绕过联邦法规的职责分工而将其代码推向生产环境。 部署良好的DevOps可以增强您证明符合法规要求和通用IT审核控制的能力，例如2002年《萨班斯-奥克斯利法案》第404条的要求。

开发清晰的信息很重要，同时选择正确的项目来展示DevOps最佳实践的价值和优势。 确定如何实施DevOps的最佳方法是从评估当前的最佳实践开始。

进行DevOps评估并克服阻力

当我与任何技术小组合作实施流程改进计划时，我首先要问哪些方法运作良好，哪些方面可以改进。 与实际工作最接近的人通常处于最佳位置，以洞悉不应更改的现有实践（至少在一开始时）以及应该优先考虑的痛点。 我会见了各种各样的利益相关者，从开发经理到测试人员，我要求他们解释进展顺利以及可以改进的地方。 DevOps评估提供了宝贵的见解，可以准确地了解任何组织需要改进哪些实践。 关键是要接受团队内部的过程改进建议，而不是局外人的想法。 为了克服对变革的抵制，请在组织内找到合适的举措作为起点，并且已经有了一些支持的利益相关者。 进行评估时，我将现有实践与行业标准（例如ISO / IEEE）和框架（ITIL v3，ISACA COBIT）进行比较，以帮助确定流程改进计划。

通过进行IBM DevOps自我评估并阅读“ 使用DevOps实现ITIL ”，将自己沉浸在DevOps中 。

企业采用率要求您制定策略来扩展整个企业的DevOps最佳实践。 我通常通过制定通用标准来做到这一点，以帮助每个小组了解需要开展的工作。 理想情况下，您可以创建和利用自己的过程成熟度框架，其中包含与您的组织相关且重要的标准。 首先，确保团队通过高性能的跨职能团队进行有效的沟通和协作。 然后，我回顾了他们的配置管理最佳实践。 我还确保我查看了他们的自动化应用程序测试。 我从他们可以轻松实现的小事情开始，我专注于在过程的早期展示成功。

我总是选择一个中小型项目，以提供最大的成功机会。 在团队看到情况可以改善之后，他们变得更加自信，并准备应对任何挑战。 如果您选择的项目难以实施或花费太长时间，则可能会导致团队失去成功的风险。 例如，我可能认为团队对版本控制系统的选择较弱，但是修复用于部署的脚本将显示出更快的结果。 选择正确的试点项目对您的长期成功至关重要。 在计划DevOps计划时，您还需要全面了解。

通过阅读“ 使用DevOps驱动应用程序生命周期管理 ”，了解DevOps生命周期 。

DevOps不仅涉及开发和运营。 在规划DevOps计划时，请考虑整个应用程序生命周期，并让所有利益相关者参与。 我经常发现产品经理为我提供了崭新的观点，可以帮助我专注于最重要的目标。 有时，最好的主意来自您的服务台或其他支持部门。 实施DevOps意味着您正在促进组织中不同孤岛之间的更好沟通，并帮助他们更有效地沟通和协作。

对我而言，可靠性通常是头等大事。

可靠性

创建可靠的系统需要DevOps革命中不断涌现的实践和原则。 阅读有关“ 使用DevOps开发可靠的软件 ”的更多信息。

DevOps计划通常始于尝试解决不现实的目标，例如单个按钮部署或什至是不必要的目标（例如连续部署）。 我的首要任务是确保部署完全可靠，即使部署没有完全自动化到只需要一个按钮操作而无需操作员干预的程度。 这意味着第一步是可以接受的，即使有人必须运行一些脚本并单击Enter几次—可靠性是最重要的目标。 我遇到了在部署过程中因问题而辞职的人。 这些人通常认为我们必须在星期五晚上进行所有部署，以便如果出现问题，我们可以在整个周末内解决该问题（当然，假设您的系统可能在周末关闭）。 我要做的第一件事是将部署分成较小的部分，并将它们安排在一周中的一两天内。 这涉及到一种文化变革，向所有利益相关者展示了完全可靠的部署不仅是可能的，而且是必不可少的。 我总是提醒人们，生命支持系统和核电厂都具有必须更新的复杂软件，显然，目标必须是完全可靠的部署。 部署完全可靠之后，您可以逐步升级到连续交付和连续部署。

安全

保持系统安全有助于防止系统故障并确保不间断的服务。 阅读“ 使用DevOps确保强大有效的安全性 ”以获取有关DevOps和安全性的信息。

下一个考虑因素是使用DevOps帮助确保安全的部署。 这是DevOps与您的数据安全人员合作的地方，并且可以产生显着的结果。 我的工作是确保可以验证是否已部署所有正确的文件，并通过人为错误或恶意意图检测任何未经授权的更改。

接下来的考虑是确保您的质量保证和测试功能能够与DevOps自动化部署的快速步伐保持同步。 质量保证和测试DevOps没有强大而全面的自动化测试就无法生存，这不仅应包括单元和功能回归测试，还应包括更完整的API和服务虚拟化测试。 如果您的自动化测试跟不上任何DevOps转换所带来的快速部署的步伐，则DevOps转换将面临失败的风险。

阅读“ 使用DevOps驱动质量检查和测试” 。

云中的DevOps

几乎不可能想象没有DevOps最佳实践就尝试管理基于云的基础架构。 通过将基础架构作为代码获得的DevOps做法，云将受益匪浅，并提供了可观的，可证明的结果。

DevOps提供了一组功能强大的原则和实践，可帮助解决基于云的计算固有的挑战。 阅读“ 云端DevOps ”以了解更多信息。

结论

DevOps提供了一套强大的原则和实践，可帮助改善沟通和协作。 推动DevOps的采用并克服对变革的抵制要求您了解哪些计划将为您的组织证明价值，并帮助您建立支持，以在整个企业范围内扩展您的DevOps最佳实践。

---

翻译自: https://www.ibm.com/developerworks/library/d-drive-devops-adoption/index.html