你应该给 DevOps“选择的自由”吗?

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...点击查看项目介绍 ;
  • 《从零手撸:前后端分离博客项目(全栈开发)》 2 期已完结,演示链接: http://116.62.199.48/ ;

截止目前, 星球 内专栏累计输出 63w+ 字,讲解图 2808+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,权限管理,Spring Cloud Alibaba 微服务等等,已有 2200+ 小伙伴加入学习 ,欢迎点击围观

为什么组织要转向 DevOps 工作模式?

在我看来,有一个主要驱动力:

将开发人员和运营人员(以及 - 如果可能的话 - 业务)聚集在一个团队中有助于团队专注于他们对公司特定业务职能的贡献。从团队只根据特定技术做事的意义上讲,不再需要专业化。 DevOps 团队现在将能够真正专注于业务价值。首先,这有助于公司变得更加敏捷和精益,同时不断消除瓶颈,使 他们的 业务部分尽可能顺利地运作。

话虽如此,团队有能力支持他们的业务链部分有多重要?他们是否应该在不同的团队之间都使用相同类型的工具,只是因为有某个架构师告诉他们这样?或者他们是否应该自由选择他们需要的技术/产品,以他们认为最好的方式支持他们的收购?

我发现了一些关于这个话题的有趣谈话:

选择的自由

首先是一篇关于“ 选择自由——DevOps 革新企业软件的三种方式 ”的帖子。它讨论了各种工具,但我想重点关注监控部分。最后声明如下: “更重要的是获得你需要的东西(定制的、相关的指标),而不是把它放在一个漂亮的包里” 。博文甚至更进一步询问我们为什么需要 APM 工具。在我看来,您可能仍然需要一个或另一个。但更重要的是团队能够做出自己的选择。

在幻灯片“ DevOps ”中,DevOps 被称为 “一种鼓励良好协作以更快、更可靠地构建质量更好的软件的文化转变或运动” 。它描述的最基本目标是消除浪费(精益)。通过自由选择最佳工具,DevOps 团队能够以最有效的方式消除浪费。这就是为什么选择 devops 工具的自由如此重要。

为什么要使用中心化工具?

如果我们进一步观察并具体询问为什么选择集中式工具(用于监控),我们会发现有两个主要原因:

1. 团队数量很少,比方说 2 到 3 个。在这些情况下,将知识集中在少量工具上是很有意义的。

2. 在较大的组织中,需要单一管理平台来涵盖所有业务流程、应用程序和基础设施。

在过去的几十年中,已经创建了许多监控工具,但没有一个真正为您提供单一管理平台。这些都无法真正深入了解所有业务流程、批处理流程、应用程序性能指标、日志条目等。

选择一个单一的解决方案来解决某些团队中的问题并没有给予选择的自由。我见过很多团队被迫使用特定工具只是因为它们对其他团队有好处。在那些团队中,那些工具不是最佳解决方案,因此他们制造了浪费,而不是通过自由选择自己的工具来减少浪费。

需要统一的工具

我刚刚阅读了另一篇关于“ 让 DevOps 和持续交付成为现实 ”的文章。最后(“统一工作 需要统一工具 ”)它陈述如下: 它来自各种功能,例如变更管理、版本控制、问题跟踪和监控,并且可供开发人员、运维人员、测试人员和其他人员使用,”。

Niek Bartholomeus 是安特卫普的一名独立软件架构师,他 最近帮助一家欧洲银行实现了更频繁的交付,他说: 他们。”


我们为什么要构建 StackState

这让我想到了我们构建 StackState 的主要原因之一。能够重用所有类型的监控、IT 管理和事件管理工具似乎是必要的,尤其是对于大公司而言。有很多好的工具,当然在不久的将来还会有更多。但是对整个堆栈有一个完整的看法只是另一个,可能更重要。爱因斯坦曾经说过:“没有任何问题可以从创造它的同一意识水平上得到解决。”因此,我们不相信会有一种所谓的元工具可以监控一切。所以我们认为这个元工具的概念应该被伞形工具的概念所取代。一个“应用程序”,它生成不同部门/DevOps 团队使用的所有不同工具的所有数据的统一视图。组织内部的控制往往会循环移动:从集中式命令/控制思维模式到分布式自治团队,然后再返回。 “ DevOps 回到未来 ”很好地突出了这一现象。

在这两种模型(集中式和分散式)中,StackState 都增加了价值:

我们相信这两种方法都能增加价值,但需要彼此相辅相成才能真正发挥作用。有些部分需要中心化,有些则不需要。

1. StackState 通过对不同类型的工具(如 APM、日志分析、批处理监控、IT 管理(供应、部署)和事件管理工具)创建统一概览来支持集中式方法。它就像一块玻璃。

2. 然而,玻璃比喻最能描述 StackState。团队可以自主选择自己的工具。 StackState 只是整合了它们。

我们真正专注于为您的整个 Stack 创建单一管理平台,同时允许通过协作进行分散管理。

我们的一些产品设计原则

  • 保留您现有的工具,深入整合并利用它们的优势: 通过这种方式,我们确实为团队提供了上述“选择自由”,同时创建了单一管理平台。
  • 启用协作: 同时避免集中治理:真正关注(DevOps)团队之间的协作,这些团队在大多数时候真正了解他们在 Stack 中的部分。
  • 一个观点胜过一千个字。 我们尝试尽可能多地可视化,而不是用长的(分页的)表格数据列表轰炸用户。它还应尽可能保持最新(接近实时),并在发生变化时进行更新。
  • 通过共同理解进行协作: 能够对整个 Stack 有一个共同的看法,因此每个人都有相同的内容。

请继续关注并通过 订阅我们的博客 关注我们,加入我们的 网络研讨会 或体验我们对 StackState 的 首次预览

相关文章