运维 | 敏捷和DevOps：是敌是友？(2)

DevOps不仅仅是自动化部署流水线。换句话说，DevOps方法要求“运维人员(Ops)能够像开发人员(Devs)那样思考，而开发人员(Devs)也要像运维人员(Ops)那样思考。” 以下是这一观点的进一步阐述以及可作为DevOps原则的三种方法：

• 第一种：系统思维 强调整个系统的性能，而不是特定的工作孤岛或部门的性能——这个系统可以大到涵盖整个业务部门，小到仅包括单个工作项。
• 第二种：扩大反馈循环 创建全流程的反馈循环。几乎所有过程改进计划的目的都是为了缩短并强化反馈循环，以确保可以不断进行必要的修正。
• 第三种：不断实践和学习的文化 塑造一种聚焦在这两件事上的文化：不断实践、勇于冒险并从失败中学习经验;要明白重复和实践是熟练掌握的先决条件。

持续交付侧重于第一种方法： 即实现从开发到运维的自动化流程。自动化在加快系统部署上的作用非常明显，但系统思维绝不止于自动化。

第二种方法的突出特点是实践， 即“开发人员也要随身携带传呼机”。虽然开发人员不一定真的要随身携带传呼机做到随叫随到，但他们也需要积极参与到运维工作中。这样能让开发人员了解到他们开发过程中所做选择带来的后续影响。例如，这样做能让开发人员将自己的日志消息存放到更好的位置让它们发挥更大的作用。开发人员不仅仅要了解运维工作，还要结合自己对系统的理解做一些故障排除的工作，这样可以更快地找到并实施解决方案。

第三种方法强调在整个系统中进行增量实验，而不仅仅是应用程序在流水线中移动的变化。 换句话说，看出自动化所需的时间并用日益强大的基础设施来不断改进它相对来说是比较容易的。而要清楚的知道角色或企业之间的交接如何导致延期是比较困难的。这意味着团队要“检查和调整”整个交付工作流，寻找可以提升人员协作效率的点。对于这个问题，持续交付要求团队养成不断适应和改进的习惯。如果团队从来不去思考如何变得更高效，并付诸行动去调整和改善，那么持续交付也无法持续发展和完善。团队要相信自己有能力解决自己的问题。

在scrum中，每次回顾会议都是一次改进实践和工具的机会。但如果团队没有抓住这些机会解决短期和长期的技术问题，他们就无异于坐等Product Owner将持续交付任务放到他们的backlog中，而事实上，Product Owner永远不会这么做。

DevOps是敏捷在软件开发团队之外的应用

Scrum主要遵循“欣然面对需求变化，哪怕变更出现在开发后期。敏捷过程正是利用变化来帮助客户取得竞争优势”这一敏捷原则。

而持续交付遵循的敏捷原则是：“我们的首要任务是通过尽早、持续地交付有价值的软件，来满足客户的需求”。

这意味着敏捷更强调输入和输出的变化，而不是每日站会和sprint规划会等仪式。事实上，《敏捷宣言》中还有另外10条原则。我们应该将它们视为一个整体，而不是从中选择某些原则。因为这些原则合起来代表的是敏捷和DevOps对变更的态度。

• DevOps旨在将敏捷关于变更的态度应用到新的领域：IT运维。

这些人一直在运行对于企业来说非常重要但同时又非常脆弱的系统。也正是因为它的重要性，所以也最迫切需要得以改进。因此，这里敏捷强调的变化并不是“为了改变而改变”。是为了让开发对其变更质量负责，同时提高整体交付商业价值。而这种对商业价值的关注是敏捷和DevOps的另一个共通点。

最后，敏捷和DevOps本身并不是业务指标。它们都是可以激励组织用更好的方法实现目标的企业文化。将敏捷和DevOps结合起来使用能取得更好的效果。而避免这两种文化发生冲突的诀窍就是要理解构成它们的更深层次的价值观和原则。武断而狭隘的定义会禁锢思维。相信看完本文，你已经知道敏捷不仅限于scrum，而DevOps也不仅限于持续交付。那么接下来，你就可以尝试强大的Agile + DevOps组合了。

【编辑推荐】

1. 2018年值得推荐的10个开源DevOps工具！
2. 把运维和开发放一起就是DevOps？还差得远！
3. DevOps对你意味着什么？
4. 运维DevOps体系解析与落地实践

（编辑：ASP站长网）