DevOps团队人员不足的典型信号是什么？您如何证明/解释增加团队成员的要求？

我很想让这个问题笼统，但是这里有一些附加信息：

目前，我们有2个DevOps专家作为一个团队一起工作，但是需求，产品数量和复杂性都在增长。我们正在考虑要求增加一个新的团队，但是在解释和证明为什么这是一个好主意方面有些困难。

您可能会觉得团队人手不足的主要原因有四个：

1. 组织和工作计划不佳
2. 做别人应该做的工作
3. 做根本不应该做的工作
4. 实际人手不足

首先回顾一下前三点。阅读Phoenix项目，了解如何进行第一个操作。问问自己完成任务的所有任务，是否应该完全完成，是否应该由您自己来完成，或者是否应该让任何需要完成任务的人自己完成。这将为您提供一些文档，说明为什么需要进行所有工作。

接下来，回顾Phoenix项目中提到的四种工作类型：

1. 业务项目 -您为组织中其他团队所做的工作
2. 内部项目 -您所做的使将来工作更轻松的工作
3. 定期维护 -您要做什么才能保持照明状态
4. 计划外中断 -由于出现问题而要执行的操作

如果团队的工作是可持续的，那么您将在这四个时间上花费大致相同的时间。如果计划外的工作开始占用您近50％的时间，则表明您的人员不足。

您应该能够聘用一个人，在计划外工作之前占到25％的时间，否则一个人离开会使您的整个团队陷入混乱，您可能永远也无法康复。人员和技术的过度配置具有相同的原因和好处。

背景： 除了为当前的基础架构和开发人员提供支持之外，我们还作为DevOps团队进行每月计划，以期在帮助sprint和已启动的新项目的开发团队的基础上完成我们想要完成的工作。但是，在这个月中，我们经常注意到需要完成和改进的其他事情，然后将其添加到待办事项中。我们还负责并协助我们进行其他超出范围的事情，但如果可以的话，我们会协助业务：)

答：一旦您注意到您没有绕过或推迟很多任务，特别是维护，我认为这是一个很好的指标（根据我的经验）。此外，DevOps团队越稀疏，出现的新项目和开发团队越多，您将需要的人越多。

它非常容易被日常完成任务困住，但是我认为它非常重要（甚至每月一次）以退后一步并对此进行评估。

实际上，我从SRE手册中摘录了其中的一页，我认为这很相关。DevOps专业并不意味着与组织横向发展。相反，如果您发现事情还没有完成，那就表明您没有适当地授权开发人员进行自助服务。

评估您的流程，看看它们如何与公认的DevOps原则保持一致，以及您遵循行业最佳实践的程度如何。

我假设这两个团队要从一个项目到另一个项目，并在那里建立DevOps东西（创建CI / CD管道，支持其他开发人员创建Dockerfile或您使用的任何技术）。换句话说，按照http://web.devopstopologies.com/输入3、4、5或6 。

在这种情况下，短缺的迹象就是这两个人的工作量过多。太多项目要求提供服务；门票太多；随着时间的推移; 压力，倦怠。这些因素应该足以成为负责任的领导者增加能力的理由。我看不到DevOps的特定标志，这只是人员不足的功能。

改变现状的另一个迹象是，如果您认真观察并发现自己正在创建“ DevOps筒仓”，其中所有DevOps专有技术都集中在这两个家伙/女孩中，而其他所有人只是向后倾斜，因为这两个是“做DevOps”。这不是DevOps的重点。在这种情况下，请考虑文化方面，并将其修改为其他团队的福音传教士/老师/教练。

在这两种情况下，为何首先拥有DevOps是一件好事的更深层次原因（一般而言，Good Stuff）对于高层管理人员来说应该很清楚。如果您无法传达该信息，则通过将其转移到常规Dev / Ops上来缩小您团队的工作规模（无论如何，应该如此）。

我给人的印象是DevSecOps是一种心态，而不是团队-如果您有一个Dev（Sec）Ops“团队”，那么您做错了...我想把我的头放在两个“ DevOps Engineers”上并称他们为“ DevOps团队”。

我们拥有开发团队，SCM，应用程序安全和系统工程师，他们齐心协力，为快速部署/发布模型而工作，以将代码和配置/系统更改推进到给定的端点-登台或生产

这样与任何“ devOps”工程师都没有关系。

任务分组

我们过去在类似情况下使用的一种方法是将一个团队的工作组织为4个主要任务组，并分配2 FTE（全时等效）的等值来（尝试）完成这些任务。在我们的案例中，这与在大型机环境中运行SCM服务台有关，大约有300位开发人员向这2个FTE寻求各种帮助/干预。任务组按4个可能的优先级进行组织：

• 优先级1和2的任务必须完成（不能找借口/无法进行谈判）
• 优先级3的任务应“ 在时间允许的情况下” 尽快完成。
• 优先级4个任务是要完成“ 如果时间允许”。

请继续阅读以获取有关这4组中的每组任务的种类的更多详细信息...

任务说明

优先级1-操作服务台

• 由易于访问且始终可用的专家组成。
• 在工作时间内通过电话，电子邮件或票务系统。
• 符合预定义的SLA。
• 基于ITIL的所有帮助台呼叫注册，并定期报告所有呼叫。
• 对紧急问题应用紧急自定义（解决方法）。

优先级2-值班服务

• 每天24小时提供服务，每周7天提供通话服务。
• 符合预定义的SLA。
• 报告所有值班值班。
• 在需要时进行管理升级。

优先级3-例行维护

• 管理。
• 申请登机。
• 家政。
• 性能增强。
• 空间管理。
• 调整资源消耗。
• 建议增强自定义设置，以减少服务台呼叫和/或值班干预的数量。

优先级4-修复和增强功能

• 创建和维护用户文档。
• 新定制的质量检查测试。
• 制定和实施增强请求。
• 参加DRP测试。

评价

如果您使用上述方法，则可能会发生各种事情：

• 如果团队人手不足，可能大部分时间会去处理优先级1和2的任务，而获得优先级3的任务可能要花一些时间...而优先级4的任务可能会饿死（似乎从来没有时间执行）这些任务）。
• 有更多（可用）时间用于“ 投资 ”优先级4的任务，优先级1和2任务所需的时间将减少，因此（“ 2个FTE可用预算”中的更多时间可以“投资”） ”中的优先4个任务。
• 您会惊讶地看到一段时间后，优先级1和2的任务数量将减少。而且，如果您对这些任务进行了充分的报告，则管理层很乐意听到这一点。在我们的案例中，这个数字从每月300左右下降到每月100以下...
• 但是，如果这2个FTE似乎从来没有（或几乎没有时间）执行优先4个任务，那么您就可以为您的管理层提供完美的解释和证明...您的人手不足。