[译]开始尝试DevOps：最适合你的是什么样的工具？

原文地址&＃xff1a;Moving to DevOps: what tools do you really need?
原文作者&＃xff1a;June Jung
译文出自&＃xff1a;掘金翻译计划
本文永久链接&＃xff1a;github.com/xitu/gold-m…
译者&＃xff1a;Starrier
校对者&＃xff1a;suhanyujie

DevOps 是一系列问题的最新解决方案&＃xff0c;每一个问题的解决方案都有许多数字化工具库&＃xff1a;CI/CD 系统&＃xff0c;测试框架&＃xff0c;监控工具和安全审计工具等。哪些工具才是你所需要的&＃xff1f;哪些可以解决你的组织所遇到的问题&＃xff0c;痛点&＃xff1f;在帮助各种规模的团队时&＃xff0c;我经常听到的两个问题是“我们需要拥有什么样的组织结构&＃xff1f;我们应该使用哪些工具&＃xff1f;”

这两个都不算是问题&＃xff0c;但单独问时&＃xff0c;它们都没有抓住重点来问。在你直接回答这些问题的时候&＃xff0c;你应该先评估你的组织需要解决的问题&＃xff0c;然后再考虑解决方案。

组织常常认为自上而下的模式&＃xff08;“使用这个&＃xff01;这样做&＃xff01;”&＃xff09;会让他们的团队创新的更快。优秀的团队领导会带来一个新的 CI/CD 工具&＃xff0c;让每个人都能工作余上。有能力的团队领导在引入新的 CI/CD 工具时&＃xff0c;会确保每个人都能掌握并运用它。而团队领导在不能完全理解其价值或为什么要这样做的情况下引入工具时&＃xff0c;问题就出现了。甚至会出现一开始提出改变的人也忘了使用工具的初衷&＃xff0c;期望得到的效益。令人遗憾的是&＃xff0c;一旦初衷被遗忘&＃xff0c;很容易造成工具的滥用&＃xff0c;导致各方面的损失&＃xff0c;以及负面价值。

我们需要 DevOps&＃xff01;

我了解了许多确认 DevOps 是他们所有问题的解决方案的组织&＃xff0c;只要他们能够快速启动并运行即可。

如果你现在处于这个位置上&＃xff0c;问问自己“为什么要在组织中使用 DevOps&＃xff1f;我们想让它为我们带来什么价值”。

在这个点上&＃xff0c;我们讨论下&＃xff0c;DevOps 是什么&＃xff0c;而不是什么。

DevOps 是开发团队和运维团队之间的具体协作方案。本质上&＃xff0c;它表明你已经在文化上将开发实践应用到你的基础架构中&＃xff0c;并将实践应用到你的开发周期中。这在实践中是什么效果呢&＃xff1f;这可能意味着将基础设置作为代码来维护&＃xff0c;或通过构建可重用的组件来创建不可变的基础结构&＃xff0c;以便你可以随意删除或启用它们&＃xff0c;从而提供版本控制和更改的历史记录。这也意味着让所有的产品贡献者更关注他们工作的最终结果 —— 它们是如何运作的&＃xff1f;用户如何与它们进行交互。让人们关心质量意味着关心其商业价值和可用性。当构建产品的每个人最后都关心质量的两个方面&＃xff0c;部署后会发生什么以及最终暴露给用户时发生什么&＃xff0c;这才是真正使用 DevOps 的目的。

在我的经验中&＃xff0c;这种广泛的支持对于软件团队来说&＃xff0c;尤其困难&＃xff0c;因为它需要来自具有不同技能和领域专长的人的配合。要做到这一点&＃xff0c;既需要跨职能的团队结构&＃xff0c;也需要深思熟虑的沟通技巧。比如&＃xff0c;如果工作上需要与业务方面的人讨论数据库问题&＃xff0c;那么他不仅需要告知他正在处理的数据&＃xff0c;而且要给出必要的问题背景&＃xff0c;并将该人的注意力集中在他们应该关心的内容和原因上。

是否应该引入新工具&＃xff1f;答案或许是&＃xff1a;可能。工具有时更像是一个快速修复而不是通用的解决方案。在我的经验中&＃xff0c;在引入新的 DevOps 工具之前&＃xff0c;记住这些注意事项会增加成功的机会。

开始转变之前&＃xff1a;

1. 确保所有人意见一致。关于你试图通过这种改变来达到目的的想法&＃xff0c;每个人在这个问题都应该达成一致&＃xff0c;并在痛点上有所共鸣。

2. 慢慢开始。不要妄想让这个组织在一夜之间成为 DevOps 模型的团队。相反&＃xff0c;从一个团队开始&＃xff0c;看看处理方式的改变&＃xff0c;是否更适用于你的组织。如果看到了积极的改进&＃xff0c;就可以保持继续改进。

3. 明白你所要做的工作。要明白&＃xff0c;DevOps 可能并不是解决你的组织问题的正确方案。有些公司在没有 DevOps 的情况下都取得了成功&＃xff0c;考虑到他们的文化和产品&＃xff0c;这些可能并不适用于他们。我个人觉得瀑布工作流会更适用于那些成功的组织。比如&＃xff0c;如果机密性是公司产品策略的一个重要部分&＃xff0c;那么以增量方式交付来获得反馈对你来说&＃xff0c;就会行不通&＃xff0c;因为直到发布前&＃xff0c;你都需要将所有产品的详细信息都封锁&＃xff0c;直至一个大型的发布。在这种情况下&＃xff0c;构建 DevOps 文化会异常艰难。

4. 保证衡量。在你开始任何改进计划之前&＃xff0c;请获取你当前状态的指标&＃xff08;即&＃xff0c;开发周期的时长&＃xff09;。在邀请 SRE 进入开发团队之前&＃xff0c;请先这样做。一段时间后&＃xff0c;就可以看到它是否有效。在你做出改变的前后进行衡量&＃xff0c;看看是否有所改变。比如&＃xff0c;在众多敏捷转型时&＃xff0c;很多公司采用了 standups&＃xff0c;却没有真正理解原因&＃xff0c;也没有衡量它是否对他们的团队产生了积极的影响。这可能导致浪费的时间比节省的时间还要多。

5. 并不是所有事情都适合自动化。至少不是一次性地向全自动化进行转变。DevOps 的一个误解是&＃xff0c;所有的基础设施和配置管理都必须自动化完成。这些被称作“基础设施即代码”。但有些东西的手动操作效果会更好。自动化并不是解决所有问题的方法。考虑一下&＃xff0c;你将运行这个自动化脚本多少次&＃xff0c;以及你需要多少时间来实现自动化。你会频繁使用自动化还是只是偶尔使用&＃xff1f;有时&＃xff0c;你必须用手动的方式&＃xff0c;甚至找出什么是最好的自动化解决方案。仍然渴望自动化么&＃xff1f;让应用程序 Docker 化&＃xff0c;是一种优秀的自动化解决方案&＃xff0c;因为你努力付出的结果可以被重复使用。自动化预生产环境是实现自动化的另一种好方法。再举例说明&＃xff0c;你是否尝试过防火墙自动化设置&＃xff1f;考虑到目前许多防火墙软件缺乏 API 支持&＃xff0c;这样的尝试可能并不值得。尽管对于灾备来说&＃xff0c;这样有意义&＃xff0c;但实际上来说&＃xff0c;你从中所获取的价值&＃xff0c;可能远不如你所付出的努力。