大多数 DevOps 社区都在讨论工具的重要性不大。 争论的焦点是，文化必须首先改变，这可能会改变工具的使用方式。
我同意也不同意这个概念。 我认为工具和文化之间的关系比单向关系更具共生性和双向性。 我已经在多家公司的实际转型中发现了这一点。 我承认很难确定是工具改变了文化，还是文化改变了工具的使用方式。
违反原则
有些工具违反了现代开发和运营的核心原则。 我看到的主要违规行为是需要 GUI 交互的工具。 这通常会将操作员与价值管道分离，使其在认知上难以克服。 如果您基础设施中的一切都应该通过价值管道进行配置和部署，那么将某人从该流程中移除，就会固有地改变他们的观点和参与度。 手动修改还会将风险注入到系统中，从而产生不可预测性并破坏管道的价值。
我听说过这些工具很好，可以在新文化中发挥作用，而且我过去也尝试过。 屏幕抓取和表单操作工具已被用于尝试在某些我集成过的系统上实现自动化。 这非常脆弱，并非在所有系统上都有效。 它最终需要大量的人工干预。
来自一家大型供应商的另一个系统，该系统为基础设施提供集成的监控和票务解决方案，似乎将其 API 作为事后才考虑的事情来实现，这导致系统无法处理来自自动化系统的负载。 这需要不断的手动恢复，有时还需要手动关闭不应该创建或未正确关闭的错误票证的繁琐任务。
维护这些系统的个人经历了极大的挫败感，并且经常表达对整体 DevOps 转型缺乏信心。 在其中一个实例中，我们引入了一个用于监控和警报的现代工具，而相同的个人突然对整体 DevOps 转型产生了极大的信心。 我认为这是因为工具可以加强文化并在类似工具缺乏现代能力时改进文化，否则会阻碍积极性和参与度。
选择工具
在 NAIC（美国国家保险专员协会），我们采用了一种基于我们认为可以加强我们价值管道核心原则的功能来评估新工具和现有工具的做法。 我们目前在列表中有七个项目
- 提供 REST API 且功能齐全（拥有所有应用程序功能）
- 能够以不可变的方式进行配置（无需人工干预即可安装、配置和启动）
- 能够通过静态文件提供所有配置
- 开源代码
- 在可用时使用开放标准
- 作为软件即服务 (SaaS) 或托管服务提供（我们不运行任何东西）
- 可部署到公共云（基于许可和成本）
这是一个优先排序的列表。 每个项目都被评为绿色、黄色或红色，以表明每个陈述在多大程度上适用于特定技术。 这创建了一个可视化效果，可以清楚地了解不同候选者之间的比较情况。 然后，我们使用它来决定我们应该使用哪些工具。 我们不会仅根据这些标准做出决定，但它们确实提供了更清晰的画面，并帮助我们了解何时牺牲了原则。 透明度是我们文化中的核心原则，这个系统有助于加强我们决策过程中的透明度。
我们使用绿色、黄色和红色，因为通常在每个工具中都没有这些标准的清晰二进制表示。 例如，某些工具具有不完整的 API，这将导致应用黄色。 如果该工具使用 OpenAPI 等开放标准，并且没有其他适用的开放标准，那么它将在“在可用时使用开放标准”方面获得绿色评级。 但是，使用 OpenAPI 而不使用 OpenTracing 的跟踪系统将获得黄色评级。
这种类型的系统创建了对工具选择时重视事项的共识，并有助于避免在不知不觉中违反您价值管道的核心原则。 我们最近使用这种方法选择了 GitLab 作为我们的版本控制和持续集成系统，并且它在很多方面极大地改善了我们的文化。 我估计第一年有 50 个用户，而仅仅在最初几个月内，我们已经超过 120 个用户。
我们以前使用的工具不允许我们贡献自己的功能、透明地协作或完全自动化。 我们也受益于 GitLab 的文化对我们的影响。 它的 手册 和开放式沟通对我们的成长非常有价值。 工具以及制造工具的公司可以并且将会影响您公司的文化。 您愿意允许什么进入？
评论已关闭。