建立运营团队的所有权

最新推荐文章于 2024-09-21 17:56:48 发布

danpob13624

最新推荐文章于 2024-09-21 17:56:48 发布

阅读量139

点赞数

最近，我一直在进行一些讨论，因此想出一些有关该主题的文章。成为Ops团队的成员有时可能会充满挑战。这项工作可能是高压的，常常感觉就像您花了所有时间来灭火，刮，牛等。在Ops中遇到的困难之一是，通常很难在事物上打分，使用技能来给人留下深刻的印象。

很难留下印记的原因不是因为缺少工作，而是因为工作变化频繁，以至于很难影响项目的长期结果。在遵循敏捷方法的运营团队中，这通常甚至更加困难，因为工作被分解为较小的故事，并且这些故事可能由多个人共同完成。即使在这些团队中，也有在某些领域具有技能的人，而且经常有不止一个人对特定主题充满热情。根据我的经验，对某个主题充满热情的人更有可能做得很好，因此我们应该了解如何利用它。

角色和责任矩阵

展示给我的一个成功工具是角色和责任矩阵。这样做的目的是在基础架构中建立组件的一些基本所有权，以便个人可以专注于他们的工作。这通常在团队中自然发生，但是这样做可以正式实现一些重要目标：

允许没有经验但有兴趣的个人举手并处理新事物。
使团队可以就谁负责哪些基础架构达成共识。这不是唯一的所有权，而是更多关于建立专业知识和减少对决策的争执。
作为经理，可以帮助您确定在特定问题上与谁合作的人。

矩阵非常简单，对于每个组件（您可以根据需要对其进行分区），您都定义了两个角色，即“ P1？和“ P2”。这些是该组件的主要和次要接触点。但是，这不仅仅是拥有主要和次要的：

P1：此人是当前的“非专家”，即受训者。该组件的所有升级都应首先交给他们。如果他们不知道答案，则有责任与P2合作并解决问题。在这个过程中，他们学习。
P2：此人是当前的专家，培训师。他们了解自己是P2，并且需要与P1一起解决需要帮助的问题。

我还观察到这种设置，其中只有一个P1，他们是专家，因为没有足够的人为该组件提供P1 / P2（或者不是优先级）。 P1成为专家的另一个原因是，如果系统正在经历大量更改，并且您希望有人对所做的更改保持严格的控制。

这是一个示例矩阵的样子

对此，每个人都是一个组件的P1和其他组件的P2。在一个完美的世界中，它的工作原理是这样的，但这个世界并不完美。尽自己所能-尝试设置类似的东西。

通常在每季度或每6个月的一次会议期间建立此机制。您遍历功能区域列表，并征募志愿者。这通常以很少的比赛结束而告终，但是在担心谁是P1或P2的情况下，您应该试着理解为什么每个人都在其中扮演重要角色，他们想要实现的目标以及考虑他们还想在哪些领域完成工作。通常，在讨论他们对该组件的愿景以及他们正在从事的其他工作之后，他们将变得更加不言自明，谁是最好的P1并可以达成协议。

定义跨职能领域

上面的矩阵运作良好，但人们的第一个问题通常是“如何进行监控，如果我拥有的话，这意味着我必须为所有人进行所有工作吗？”。在大多数情况下，答案是“否”。有些功能区域非常清晰，并且大部分都是自包含的，但是有些功能区域跨越了所有其他区域。与其他事物相交的示例包括监视，网络，配置管理，有时还涉及存储之类的事物，具体取决于您的体系结构。

对于您的专业领域是他人依赖的领域，需要对这些任务拥有共同的所有权。我通常以“监视”为例以这种方式查看它：

P1负责该系统的总体体系结构和基础架构，培训，文档和升级。他们负责使其他团队成员有效使用该系统，并对团队进行任何重大更改以供审核和达成共识。
其他组件的P1所有者负责将其系统与监视程序集成，编写任何监视器，并为该系统建立有意义的度量标准和阈值。
两位P1所有者共同努力，以确保以一致的方式完成任何监视/指标，这与团队所同意的架构一致。

通过这种方式，您不必花一整天时间为一百万个不同的组件编写监视器，从而避免使监视所有者感到头疼，但他们对监视基础结构的整体成功拥有所有权。拥有其他组件的个人正在决定如何在监视系统的最佳实践的约束内，如何最好地监视自己的系统；如果他们想以不同的方式开辟新天地，可以与监视所有者合作。

在运营之外工作

操作（我认为）最重要的作用之一就是与开发尽可能紧密地合作。这变得越来越明显，越来越多的团队开始使用它来命名，例如DevOps。有些Ops员工比其他人更擅长于此，有些人会出去寻找与之合作的开发人员，而另一些人则需要鼓励。

在Ops中为个人定义明确的角色是强制这种协作的好方法。通过指派一名Ops人员参加即将到来的开发项目并围绕该角色设定明确的期望，您可以帮助促进他们的参与并授权他们开始与其他团队合作。开发团队成为职能部门，他们像其他任何组件一样获得了P1和P2。

如果可以的话，我通常会提倡较小的Dev组织，那就是每个Dev团队要整合一个Ops人员。这意味着Ops人员参加站起来，参加计划会议，并且熟悉Dev团队正在处理的所有工作。如果需要与Ops相关的工作（或始终需要进行沟通），则由分配的Ops团队成员负责该角色。他们不一定要负责所有工作，但要负责确保沟通和确保工作完成。

另一种方法是将Ops团队成员分配给各个项目。随着项目的兴起，团队成员开始参加这些会议，并开始参与任何站立讨论并围绕该项目开展工作。我不太喜欢这种方法，因为它大部分时间都依赖于开发团队伸出援手，并说“好吧，我们现在准备为Ops人员做准备”，而且这种情况通常发生得很晚。将Ops成员放在团队中的位置可以给您更早的警告，并且可以更早地确定最终结果。

跟踪与沟通工作

既然每个人都在自己的项目上工作，那么就会出现一种交流的方式，这种交流的频率越来越低，而沟通的程度也越来越低。为避免这种情况需要付出一些努力，但实际上并不那么困难。重要的一点是，每个团队成员都在谈论他们每天在站立时所做的工作，并在计划会议期间明确他们的优先事项。如何实现此目标取决于您，但我会提出一些想法。

看板可以很好地用作正在进行中的可视化工具。从Ops的角度来看，我认为这就是看板角色开始和结束的地方。运营本身就是一个由中断驱动的团队，尽管许多组织都通过大量实践摆脱了这种模式-如果您当时处于这种状态，则可能不需要我的帮助来跟踪和交流工作。我看到看板工作非常好的地方是在计划过程中优先考虑工作（abc必须先出现在xyz上，然后移动卡），并以视觉方式显示您的工作，正在做的工作以及接下来将要做的工作。

每日站立非常有用。运维团队的事情每天都在变化，每天早上花10分钟让所有人与正在发生的事情保持同步是一个巨大的帮助。识别障碍并谈论如何清除障碍是其中很大的一部分。当每个人都在谈论事情时，说“我被阻止等待xyz”是今天解决该问题的机会。

使用诸如Google Docs之类的共享文档系统来记录投标书也是一项巨大的进步。我可以写一些提案，而不是征求反馈，人们可以将其添加到文档中–他们可以发表评论等。我们聚在一起进行30至60分钟的会议，以审核文档和反馈，我们在最后的建议上开枪。如果仍然有未解决的问题，我们回去回答。关键是很多工作都是异步完成的，而不是要求每个人都将自己最好的，最分散注意力的想法带到会议中。

轮换角色

最后，所有这些都在改变。多年以来，没有人希望一直停留在同一角色上—运营部门的人员希望学习新事物，他们希望有机会采取需要改进的事情并留下自己的印记。在每个基础架构中，都有一些很酷的项目，也有一些la脚的项目。系统的某些部分也很麻烦维护，没有人愿意这样做。旋转这些很重要。

根据我的经验，定期检查优先事项是有效的。您首先需要对进行中的工作进行审查，以便人们知道要解决他们今天不在工作的领域时所签署的协议。然后您按功能区域擦拭石板清理并进入功能区域，询问谁想参与其中。

此过程的窍门是试图让正在执行项目的人员保持这一职责，同时让其他人了解系统。这是真正可以利用P1 / P2角色的地方。如果您要重新建立网络，并且确实需要同一个人来维持他在该项目中的势头-他将成为P2，继续进行这项工作。您分配一个新的P1（如果有新朋友要参加），让他们处理日常的中断。两位成员共同努力，新成员将学习，而旧成员将完成项目。

如果功能区域尚无任何工作，而您真的想在此进行一些新的改进，请找到一个热衷于进行此更改的人并将其设置为P1。寻找一个可以帮助他们启用并让他们继续前进的P2。

包起来

所有权是任何工作的重要组成部分，在运营部门，这是让我回头的光。向团队中的每个成员赋予这种能力很重要，希望这能给您一些有关如何做到这一点的想法。

参考：在Operation Bootstrap博客上，由我们的JCG合作伙伴 Aaron Nichols 建立了Ops团队的所有权。