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

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

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

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

组织经常认为自上而下的模式（“使用这个！这样作！”）会让他们的团队创新的更快。优秀的团队领导会带来一个新的 CI/CD 工具，让每一个人都能工做余上。有能力的团队领导在引入新的 CI/CD 工具时，会确保每一个人都能掌握并运用它。而团队领导在不能彻底理解其价值或为何要这样作的状况下引入工具时，问题就出现了。甚至会出现一开始提出改变的人也忘了使用工具的初衷，指望获得的效益。使人遗憾的是，一旦初衷被遗忘，很容易形成工具的滥用，致使各方面的损失，以及负面价值。

咱们须要 DevOps！

我了解了许多确认 DevOps 是他们全部问题的解决方案的组织，只要他们可以快速启动并运行便可。

若是你如今处于这个位置上，问问本身“为何要在组织中使用 DevOps？咱们想让它为咱们带来什么价值”。

在这个点上，咱们讨论下，DevOps 是什么，而不是什么。

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

在个人经验中，这种普遍的支持对于软件团队来讲，尤为困难，由于它须要来自具备不一样技能和领域专长的人的配合。要作到这一点，既须要跨职能的团队结构，也须要深思熟虑的沟通技巧。好比，若是工做上须要与业务方面的人讨论数据库问题，那么他不只须要告知他正在处理的数据，并且要给出必要的问题背景，并将该人的注意力集中在他们应该关心的内容和缘由上。

是否应该引入新工具？答案或许是：可能。工具备时更像是一个快速修复而不是通用的解决方案。在个人经验中，在引入新的 DevOps 工具以前，记住这些注意事项会增长成功的机会。

开始转变以前：

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

2. 慢慢开始。不要妄想让这个组织在一晚上之间成为 DevOps 模型的团队。相反，从一个团队开始，看看处理方式的改变，是否更适用于你的组织。若是看到了积极的改进，就能够保持继续改进。

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

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

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

接下来呢？

若是你的组织正在考虑是否使用 DevOps，请先考虑下大家的交付速度和产品质量的问题。大家如今所遇到的真正问题是什么？了解这些问题的答案，有助于大家组织的每一个人来了解如今的痛点所在，从而帮助大家在最正确的地方来改变它们。

在以后的文章中，我会经过一些实战来帮助大家发现本身组织现现在的问题所在，帮你提升评估哪些工具或处理方法是解决这些问题的最优解的自信心。

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。