DevOps时代的IT人员规模确定-DevOps团队如何以及何时扩大规模？

#1 楼

恕我直言，直接将团队从DevOps转换中获得的收益直接应用于缩小团队规模不是一个好主意。充其量，您只会失去团队在将来进行任何此类改进的动力。但是您很可能会失去该团队中的大部分/所有人才。相反，

：


让团队欣赏他们艰难转型的好处。经过努力，以便他们将您的消息传播给您的其他团队，这些团队将必须经历（或已经在奋力进行）转型
，专注于更快地交付质量更高的产品/服务-与同一个团队一起-
在很多情况下，由于转型，您的业务将加快速度-很快您将更有可能需要雇用人员-恕我直言，最好是利用已经拥有的人员的经验而不是培训新员工
允许自愿减员为您工作并获得有效的缩减规模。

但是通常，DevOps转换的发生速度不够快，无法做出上述选择： ）

现在可以进行放大/缩小。

理想情况下，DevOps转换应具有出色的大大提高了软件开发和交付过程的可预测性。您应该能够非常精确地判断现有团队的能力：您当前的团队可以在一定时间内完成多少质量的软件/服务。

当您需要完成更多工作或者比当前团队的能力更好/更快地完成工作时，您需要扩大/扩展团队。确切的详细信息来自您用于日常活动的任何过程/方法，可能是一些敏捷变体（另请参见在采用DevOps之前，我的组织是否需要采用Agile Soft。Dev。？）

方法-显然很容易：雇用更多人来处理繁华的活动。如果您担心如何尽快将它们装上船并实际以预期的速度处理溢出的工作：请根据预测更早开始雇用。

现实可能会更加困难比起那个来说。扩展软件产品/服务或支持它的开发流程和工具不一定是直截了当的，即使对于拥有DevOps的组织而言。

我最喜欢的示例之一是在开发方面最弱的DevOps链接扩展性：持续集成。如果CI构建失败，就不会有任何交付/部署（在CD上下文中有点破坏“连续”术语）。

由于某个团队很乐意使用CI并获得了不错的结果，所以它不会意味着如果团队人数增加一倍，也会发生同样的情况。不，结果可能是毁灭性的-交付过程可能会停顿下来（在极端情况下）。我正在尝试在“传统CI系统的拥塞”中对此进行解释（免责声明：我是拥有引用页面并为该问题提供解决方案的公司的创始人）。

另一个示例可能是，例如，正在使用的版本控制系统（VCS）：随着存储在存储库中的软件的发展，其更改历史记录也在不断发展，从而推高了VCS系统的极限，有时甚至超出了可接受的性能水平。切换到更具扩展性的VCS系统或将代码库拆分为多个存储库可能是解决此问题的一种方法。

随着软件产品/服务的发展，不断发展的开发过程和支持它们的工具从根本上讲，这正是成熟的DevOps团队所做的事情。在团队的扩展/扩展策略中，也只需要考虑它们。

考虑到这一点，实际上可以减少为仅增加团队规模以覆盖执行上述策略所需的额外工作量。