DevOps团队人员不足的迹象是什么？

#1 楼

您会感到团队人员不足的四个主要原因：


组织和工作计划不佳
做别人应该做的工作
根本不应该做的事
实际上人手不足

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

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



业务项目-您为组织中其他团队所做的事情

内部项目-为使将来的工作变得更轻松而进行的工作

计划的维护-您所做的保持亮起状态

计划外中断-由于出现问题而要做什么

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

您应该能够聘用约一个人的临时工，以保留您25％的时间，否则，一个人离开会使您的整个团队陷入混乱，您可能永远无法康复。人员和技术的过度配置具有相同的原因和好处。

#2 楼

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

答案：
一旦您发现自己没有得到解决，推迟或推迟许多任务，尤其是维护，我认为这是一个很好的指标（根据我的经验）。此外，DevOps团队越稀薄，越有新的项目和开发团队，您将需要更多的人。

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

#3 楼

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

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

#4 楼

我假设这个由两个人组成的团队从一个项目开始到另一个项目，并在那里建立DevOps东西（创建CI / CD管道，支持其他开发人员创建Dockerfile或您使用的任何技术）。换句话说，按照http://web.devopstopologies.com/键入3、4、5或6。在这种情况下，这两个人的工作量不足的迹象就是工作量过多；太多项目要求提供服务；门票太多；随着时间的推移;压力，倦怠。这些因素应该足以成为负责任的领导者增加能力的理由。我看不到DevOps专用标志，这只是人员配备不足。

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

在这两种情况下，为什么要在第一个团队中使用DevOps的更深层次原因地方是一件好事（一般的好东西）应该由高层管理人员明确。如果您无法传达此信息，则可以将其转移到常规的Dev / Ops上以缩减您团队的工作量（无论如何，应该如此）。

#5 楼

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

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

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

#6 楼

任务分组

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


必须完成优先级1和2的任务（不能做任何借口/谈判）
要完成优先级3的任务“在时间允许的情况下”。
要在“时间允许的情况下”完成优先级4的任务。

请继续阅读有关这4个组中每个任务类型的更多详细信息。 ..

任务说明

优先级1-操作帮助台


由易于访问且随时可用的专家。
在工作时间内通过电话，电子邮件或票务系统。
符合预定义的SLA。
基于ITIL的所有帮助台呼叫注册，并定期报告所有呼叫。
应用紧急定制（工作关键问题。

优先级2-值班服务



24小时/天，7天/周随时待命。
预定义的SLA。
报告所有值班值班电话。
管理升级ded。

优先级3-例行维护


管理。
应用程序寄宿。
内务管理。
性能增强。
空间管理。
资源消耗的调整。
针对自定义项的建议增强功能，可减少服务台呼叫和/或值班干预的数量。

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


创建和维护用户文档。对新自定义项进行质量检查。
开发并实施增强功能请求。
参与DRP测试。

评估

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


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