我与我当时的一位经理同事讨论过确保计划项目的移动，即使唯一可用的团队成员没有专业知识来承担它。简单的答案是让该团队成员在有经验的人的帮助下达到一个起点，通过一种非繁重的结对工作模式，刚好足以给他们动力。任务可能无法按时完成，但至少他们让它动起来了。
在实践中，这总是说起来容易做起来难，因为我们总是陷入这样的心态：“如果专家会做，它会更快”或“我只接受我拥有的这个非优先项目”专业知识，而不是搞砸那个非常关键的问题。” 这种有点孤立的心态在遗留系统中尤为普遍，增加了已经具有挑战性的 DevOps 采用的障碍。
在尝试采用 DevOps 实践时，大多数失败的发生是由于团队对变革的抵制，因为领导者过度简化了问题。这就是为什么在 DevOps 评估的早期阶段，领导者和遗留团队之间的对话对于亲自传达愿景和目标、解决不确定性以及制定谈判和协议是必要的。这种方法有助于在人们中建立信心和接受度，因为 DevOps 最终是一种文化转变。还值得注意的是，如果创建一个 DevOps 团队/人员对某些人来说是有问题的，因为瓶颈刚刚转移到另一个实体。
“分担责任的态度是 DevOps 文化的一个方面，它鼓励更紧密的协作。如果将系统移交给另一个团队来照顾，开发团队很容易对系统的运维不感兴趣。如果一个开发团队在系统的整个生命周期内共同承担维护系统的责任，他们能够分担操作人员的痛苦，从而找到简化部署和维护的方法（例如，通过自动化部署和改进日志记录）。”
——马丁·福勒
以下是在考虑采用 DevOps 时需要解决和考虑的一些问题：
完整的架构和技术审计
从 DevOps 的角度来看，包含所有受支持系统（文档声明和客户端部署）、SCM 分支/发布策略以及端到端交付和部署架构文档的列表非常重要。在已有数十年历史的遗留系统中，小型自动化流程和工具很可能已经存在，也应该被考虑在内。进行此审核将帮助每个人了解系统和底层流程，这是实现 DevOps 核心原则之一的第一步，即流程/系统思维。
根据自动化和 DevOps 工具集评估您的系统
记下基准和基线数据，以帮助为您的路线图定义切合实际的目标。对于指标，不要过度复杂化并选择可以转化为所有人都能理解的商业价值术语的正确类型是持续改进的关键（例如：部署速度、故障率、交付频率和错误重现率）。
接口协议
当团队进行探索性工作时，无论是自动化还是尝试新工具，建立关于如何在整个交付过程中发送数据的标准将促进并行开发并有助于可追溯性。最重要的是，只要最终输出符合与管道下一阶段兼容的标准格式，这些数据接口将保护其自主权，实施由他们自行决定。鉴于此，这些接口协议的一部分必须包括反检查机制。
但是，无论 DevOps 计划是否会推进，对于维护遗留系统的组织来说，已经开始投资于以下方面总是有益的：
- 标准和最佳实践。如前所述，一旦决定将这些过程自动化，就可以更轻松地定义交付过程之间的接口。
- 单元测试覆盖率以及针对工具和操作中的代码的强调。在过去使用遗留系统时，很多部署延迟都是由发布交付系统失败引起的。这种失败是由于忽视了针对交付系统本身的适当开发实践。
- 满足系统自动化需求的专用工具的自动化和开发。
- 技术债务偿还。
- 探索云和容器化解决方案的可能性。
由于根深蒂固的实践和与之相关的态度，将 DevOps 应用于遗留系统的过程带来了独特的挑战。与任何适应过程类似，通过实施展示有形进展的渐进调整而不是严格遵守自上而下的方法，更容易取得成功。当个人认为进步是由他们自己提升自己或为整体改善做出贡献的意愿驱动时，他们的内在动力自然会增强。可能无法实现完全 100% 的 DevOps，但至少会有推动它发展的动力。
热门跟贴