问题描述
想了解DevOps团队人手不足的典型迹象和信号，以及如何解释和证明需要增加团队人员的请求。他们目前有两名DevOps专家组成一个团队，但需求和产品的数量和复杂性正在增长。他们正在考虑请求增加团队人员，但在解释和证明为什么这是一个好主意方面遇到了一些困难。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
如果你感觉团队人手不足，可能有以下四个主要原因：
1. 工作组织和计划不良
2. 做了其他人应该做的工作
3. 做了本不应该做的工作
4. 实际上人手不足
首先，从这三个方面进行审查。阅读《凤凰项目》一书，了解如何解决第一个问题。对于你帮助任何人完成的每个任务，问问自己这个任务是否应该被执行，是否应该由你来完成，或者是否应该让需要完成任务的人自己来完成。这将为你提供一些关于为什么你所做的所有工作都是必要的文档。
接下来，审查《凤凰项目》中提到的四种工作类型：
1. 业务项目 – 为组织中的其他团队做的工作
2. 内部项目 – 为了使你未来的工作更容易而做的工作
3. 定期维护 – 为保持正常运行而做的工作
4. 非计划中断 – 因为出现问题而做的工作
如果你的团队的工作是可持续的，你将在这四种工作上花费大致相同的时间。如果非计划工作开始接近你时间的50%，这表明你的团队肯定人手不足。
你应该能够雇佣足够的人手，以确保非计划工作占用你时间的25%左右，否则，一个人离开将使你的整个团队陷入困境，你可能永远无法恢复。过度配置人员和技术具有相同的原因和好处。
方案2
使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。
以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：
#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b
在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。
方案3
我实际上借鉴了SRE手册中的一种方法，我认为这非常相关。DevOps专业并不意味着随着组织的发展而水平扩展。相反，如果你发现事情没有完成，那就意味着你没有正确地赋予开发人员自助服务的能力。
评估你的流程，看看它们如何与常见的DevOps原则以及你是否遵循行业最佳实践相一致。
方案4
我假设这两个人的团队正在从一个项目转到另一个项目，并在那里建立DevOps的一些东西（创建CI/CD流水线，支持其他开发人员创建Dockerfile或其他技术）。换句话说，根据http://web.devopstopologies.com/的类型3、4、5或6。
在这种情况下，人手不足的迹象就是这两个人的工作负荷过大，太多的项目需要他们的服务，太多的工单，加班，压力和倦怠。这些因素应该足够让负责任的领导层增加更多的人手。我在这里没有看到DevOps特定的迹象，只是一个人手不足的功能。
改变的另一个迹象是，如果你仔细观察，如果你注意到你正在创建一个“DevOps孤岛”，所有的DevOps知识都集中在这两个人身上，其他人只是坐下来，因为这两个人“在做DevOps”。这不是DevOps的目的。如果是这种情况，考虑文化方面，并将他们修改为其他团队的更多传道者/教师/教练。
在这两种情况下，首先要清楚为什么首先要有DevOps的好处（一般的好东西）对于高层管理人员来说是明确的。如果你无法传达这个信息，那么通过将团队的工作减少到正常的开发/运维人员（正常情况下应该是这样）来减少你的工作量，从而为你的管理层提供一个完美的解释和证明…你的团队人手不足。
方案5
我认为DevSecOps是一种思维方式，而不是一个团队 – 如果你有一个Dev(Sec)Ops“团队”，那么你做错了…我试图理解将两个“DevOps工程师”放在一起并称之为“DevOps团队”的做法。
我们有开发团队、SCM、应用安全和系统工程师，他们都在为推动代码和配置/系统更改的快速部署/发布模型而协同工作 – 无论是在暂存还是生产环境中。
这与任何“DevOps”工程师无关。
方案6
我们过去在类似的情况下使用的方法是将团队的工作分为4个主要任务组，并将相当于2个全职员工的工作分配给这些任务组（尽量）完成。在我们的情况下，这与在主机环境中运行SCM帮助台有关，大约有300名开发人员向这两个全职员工寻求各种帮助/干预。这些任务组按照4个可能的优先级进行组织：
1. 优先级1和2的任务必须完成（不能有任何借口/谈判）
2. 优先级3的任务应该在“尽快”完成
3. 优先级4的任务应该在“如果有时间”的情况下完成
如果你使用上述方法，各种事情可能（肯定！）开始发生：
– 如果团队人手不足，可能大部分时间都会花在优先级1和2的任务上，而优先级3的任务可能需要一段时间才能完成…优先级4的任务可能会遭受饥饿（似乎永远没有时间完成这些任务）。
– 越来越多的时间可以“投资”于优先级4的任务，优先级1和2的任务所需的时间将减少，这样即使在可用的2个全职员工的预算中，也可以“投资”更多的时间。
– 你会惊讶地发现，经过一段时间后，优先级1和2的任务数量会减少。如果你对这些任务进行适当的报告，管理层会非常喜欢听到这个消息。在我们的情况下，这个数字从每月约300个减少到每月不到100个…
– 如果然而，这2个全职员工似乎从来没有（或几乎没有）时间完成优先级4的任务，那么你就有了一个完美的解释和证明…你的人手不足。
以上是一些DevOps团队人手不足的迹象和解决方案。根据你的具体情况，选择适合你团队的方案，并向管理层解释为什么增加团队人员是一个好主意。