为团队全力以赴：技术主管的随叫随到开发人员角色指南
这篇博文的目的
这篇博文的目的
这篇博文全面探讨了我认为如何成为一名高效的团队值班开发人员。值班开发人员可以成为每个团队中一个极具价值且影响深远的角色，与其他敏捷团队角色相辅相成。我将分享我的观点，说明为什么值班开发人员可以而且应该做的不仅仅是接听呼叫。
这篇博文也是一封写给团队共同拥有代码特性和微服务的“情书”。如果值班开发人员没有对其负责维护的代码拥有所有权，他们的工作效率将大打折扣。
这篇博文简要介绍了我们可以从角色扮演游戏中学到什么。
《龙与地下城玩家手册》第五版中的“标志性队伍”。
介绍
对于开发人员来说，随时待命意味着什么？我先引用Atlassian 事件管理中的定义：
随叫随到是指指定特定人员在特定时间待命，以便在发生紧急服务问题时做出响应，即使他们并非正式值班人员。
通常，“紧急服务问题”指的是影响最终用户的高严重性事件。当网络运营中心或站点可靠性工程师呼叫值班开发人员时，很可能就是紧急服务问题。
然而，我们经常会遇到一些非紧急但比下一个迭代周期更紧迫的问题。因此，我们可以增加值班开发人员的职责范围，让他们在迭代周期内处理任何突发情况，从而保护其他开发团队成员。
我相信，通过在其他重要的敏捷团队角色（例如产品负责人、Scrum Master）之外，增设“随叫随到开发人员”这一角色，我们可以解决许多组织架构上的问题。这个角色能够有效地提升组织的知识管理和事件响应速度，使其更好地适应规模化发展。更重要的是，这个角色让技术负责人无需再承担单枪匹马的重任。
为团队而摆烂——一个比喻
乔安娜，扎卡鲁姆的十字军战士，出自《风暴英雄》。暴雪娱乐。
什么是坦克？
在角色扮演游戏（RPG）中，团队中的“坦克”角色旨在承受团队的伤害，其次，确保他们能够吸引敌人的注意力。
这和做一名随叫随到的开发人员有什么关系？
在撰写这篇文章的过程中，我越来越意识到，值班开发人员就像团队的坦克。其他开发人员则是输出，他们努力完成冲刺目标。用这个比喻来说，值班开发人员需要：
- 能够减轻自身（以及我们的业务）因代价高昂的中断而造成的损失。
- “吸引注意力”——吸引他人的注意力，以免分散其他人的注意力。
当敌方火力集中在你的坦克身上时，你的输出职业就能集中火力攻击队伍的主要目标，最大化他们的每秒伤害输出（DPS）。通过平衡不同职业在副本战斗中的职责，整个团队就能取得辉煌的胜利！
这一点也适用于你的敏捷团队。🌈
“损害”缓解——确保值班开发人员获得支持
来自《守望先锋》的莱因哈特和卢西奥。暴雪娱乐。
在制定值班轮换制度之前，如何确保开发人员获得处理高危问题所需的必要支持？值班压力很大，而且高危事件的平均修复时间 (MTTR) 过长有时会给公司造成巨大损失。
换句话说，我们如何才能避免坦克被一大群怪物瞬间碾压？开发者版本的板甲是什么样的？
我建议在组建值班轮换团队时应具备一些先决条件。这些先决条件旨在支持您的值班人员发展工作，并尽可能简化这一过程：
- 您的技术主管已带领开发团队熟悉了您团队负责的功能和/或微服务。
- 理想情况下，这些功能和微服务都有完善的文档。
- 你们有处理高危问题的操作手册（即操作指南）。
- 你们已经建立了一套轮岗期间的知识转移系统。
- 轮值值班人数不宜过多（或过少）。理想规模约为 5 名开发人员。如果轮值人数过多，开发人员就无法充分参与值班工作，也就无法积累经验、提升技能，从而无法缩短平均修复时间 (MTTR) 指标。
- 同时，个人待命时间不应超过总时间的 25%，否则有倦怠的风险。
- 你创造了一个心理安全的环境。
- 至少，你应该通过不追究责任的事后分析，为值班人员提供心理安全感。你还应该培养一种教学相长的学习文化。
- 团队的工程经理 (EM) 和产品负责人 (PO) 都明白，半夜接到请求是重大问题，不应该频繁发生。如果值班开发人员需要在非工作时间响应请求，则必须给予其相应的补偿。
入职培训、运行手册和轮班记录
第一种风险缓解措施是让技术负责人或领域专家 (SME) 对其他开发团队成员进行代码组件或所负责微服务的培训。要明确领域专家并非所有事件的主要响应人。今后，该人员将在值班开发人员需要时提供支持。
这可以强制中小企业编写文档，供其他人参考。
下一种缓解措施是制定生产操作手册。
运行手册是一种专门针对生产环境中可能出现的各种问题而设计的文档。
编写操作手册听起来很难——如何编写处理你还不知道的问题的分步说明呢？
以我的经验来看，大多数团队其实已经这么做了！我们会编写文档，概述团队对各项功能的风险评估和缓解方案。我们会针对可能导致生产环境问题的代码编写工单注释。我们有发布日监控流程。如果仪表盘上出现异常情况，我们也大致知道该怎么做。
把这些内容整理成一份操作手册，供值班开发人员参考！
很多时候，只需为你的功能添加一个文档页面，说明“如果发生 x 事件，请关闭此功能开关”即可。而有时，你则需要考虑监控生产环境错误日志或特定的Grafana仪表盘。
写下来。
记下班次笔记
最后，务必确保轮班人员及时更新交班记录。我目前的团队会记录所有生产事故记录。我们有一个模板，用于记录以下内容：
- 事件描述
- 解决
- 根本原因
- 要点和后续步骤
- 事件时间线
在之前负责多个微服务的团队中，我们的值班记录包括有关运维职责和维护测试环境的条目。
轮换次数要少（但不要太少！）
为了让开发人员增强信心并提高值班技能，我们需要定期进行值班演练！就像其他任何事情一样，我们需要练习值班才能胜任。
莫莉·斯特鲁夫在她的博文《让值班不再糟糕》中，探讨了值班制度弊端的特征以及如何改进。在描述弊端时，她写道：
最终，团队规模庞大，以至于每 3-4 个月才轮值一次。这看似理想，实则不然。[…] 频繁的轮值意味着值班频率过低，开发人员无法积累足够的经验和实践，从而无法有效地处理值班问题。[…] 虽然听起来有些矛盾，但增加值班频率其实是有益的，因为开发人员已经逐渐适应了值班，并能够找到最适合自己的值班策略。
Molly的经历与我在大型企业的工作经历非常相似。相比于应对整个组织的轮换安排，我更自信、更自在地回复自己团队的呼叫。
总之，为了支持轮值制度，请将开发人员的数量控制在 5 人左右，这样既能让大家获得经验，又不会让大家过度劳累。
但谁是治愈者？！
安度因·乌瑞恩，出自《魔兽世界：争霸艾泽拉斯》。暴雪娱乐。
我不知道。可能是电磁场。
为团队拉开进攻
在角色扮演游戏中，仇恨机制是敌人用来决定攻击优先顺序的一种手段。吸引仇恨最多的玩家会成为敌人的优先攻击目标。这被称为“拉仇恨”。
洛汗的盾女伊欧玟为希优顿吸引仇恨。
在开发团队中，通常情况下，技术负责人是优先级最高的被干扰者。但技术负责人不应该总是团队的“坦克”。原因有二：
- 这会导致较低的巴士系数。
- 它阻碍了整个开发团队的成长。
为了解决这个问题，技术负责人需要将部分职责下放给值班开发人员，并允许他/她代表团队处理突发事件。这意味着值班开发人员应主要负责从迭代工作中切换任务并处理各种突发情况。这些职责可能包括：
- 回复所有事件页面。
- 发布日监控。
- 协助团队的产品负责人和工程经理对收到的缺陷进行分类。
- 审查任何非所有者对团队拥有的代码组件所做的更改。
- 帮助产品负责人和工程经理回答利益相关者关于自有功能的问题。
应对利益相关者的干扰
有时候，利益相关者（客服经理、产品负责人、其他开发人员）会用一些棘手的技术问题打断敏捷团队的工作。如果你所在的团队负责维护其他开发人员使用的任何框架或工具，你很可能会遇到很多这样的问题。（即便你已经尽力为下游用户编写了所有文档！😢）
我的职业生涯大部分时间都在负责支持其他开发团队的团队中度过。经过反复试验，我发现处理这类干扰最有效的方法是明确指定专人负责解答。而且，这个人不应该总是同一个人。
我建议使用值班开发人员，因为他们已经因为代价高昂的上下文切换而被打断了。
开发团队的其他成员可以专注于冲刺目标，而利益相关者也能得到及时有效的答复。
在集体责任模式下，谁应该花时间回应问题并不总是很明确，更不用说进行任何研究或分析了。有时是技术负责人包揽所有回答，导致响应率低下。有时还会出现旁观者效应，任何人都可能承担回答问题的责任，也可能无人负责。
利益相关者正在等待一个采用集体责任模式的团队给出答复。
你的团队需要负责解决利益相关者的障碍，同时又不损害团队自身的需求。值班开发人员可以帮你完成这项工作，这样开发团队的其他成员就可以专注于主要目标——你的迭代目标。
最大化DPS——确保团队其他成员高效完成冲刺目标
《魔兽世界》中的奥妮克希亚巢穴。暴雪娱乐。
在最后一部分，我想谈谈坦克如何通过一些细微的方式支持团队，让其他队友更好地完成击杀巨龙的任务。（巨龙是你们的冲刺目标）。
好吧……我用坦克来打比方说不太恰当。
但这里有一部分内容是关于随叫随到的开发人员角色如何让其他所有人成为更好、更高效的开发人员，从而更好地完成冲刺目标。
随时待命鼓励开发人员打造更好的产品。
轮值制度让我们在非值班时间也能成为更优秀的开发者。通过直接处理生产事故和缺陷分类，轮值中的每个人都能深入了解代码如何影响生产环境和客户。这让我们在日常工作中，无论是改进现有产品还是构建新产品，都能做得更好。
开发人员应该追踪他们的工作成果——通过直接了解客户遇到的问题，他们可以在日常工作中做出更好、更明智的决策。这样做，我们可以获得关于代码非功能性方面的反馈——所有与面向客户的功能无关的元素——并找到改进代码可管理性、可操作性等方面的方法。——《DevOps手册》，第233页
随叫随到的开发人员可以解决阻碍开发团队的问题。
理想情况下，不应该要求值班开发人员参与迭代开发工作。他们已经需要频繁切换工作内容，因此任何有助于达成迭代目标的工作都算是锦上添花。
我认为，更合理地利用值班开发人员的“空闲”时间，是让他们致力于改善值班体验。这包括自动化手动流程、改进警报系统、编写开发工具等等——任何能够减轻值班人员运营负担的事情都值得去做。
自从我在 Charity Majors 的博客文章“值班不应该让人厌烦：经理指南”中看到这个想法后，我就一直很喜欢它。
工程师值班时，不负责日常项目工作——绝对如此。这段时间神圣不可侵犯，专门用于维修设备、制作工具以及设置防护栏以保护人员安全。如果没有发生火灾，工程师可以利用这段时间解决任何让他们感到烦恼的问题。给予他们充分的自主权，并鼓励他们跟随好奇心，无论探索到什么方向，这都将是一次特别的体验。
这样如何才能最大限度地发挥你的冲刺产出潜力？值班开发人员通过改进我们的环境和工具来提高每个人的产出。🛠
结论
感谢您阅读我这篇略显技术性的文章，内容是关于如何为您的团队创建一个高效的轮班开发人员角色。也非常感谢之前撰写过相关主题文章的各位。
后记
我不是坦克玩家。我更喜欢远程输出和治疗，但有时候你也需要扮演团队需要的角色。😏
参考
- https://www.geeknative.com/48262/art-inside-dd-5e-players-handbook/
- https://www.atlassian.com/incident-management/on-call
- https://en.wikipedia.org/wiki/Tank_(video_games )
- https://www.icy-veins.com/wow/tanking-guide
- https://www.dungeonsolvers.com/2019/05/10/i-fight-for-my-friends-how-to-be-a-tank-in-dd-5e/
- https://dotesports.com/overwatch/news/reinhardt-camera-control-patch-17485
- https://sre.google/sre-book/being-on-call/
- https://www.atlassian.com/incident-management/postmortem/blameless
- https://www.atlassian.com/incident-management/on-call/improving-on-call
- https://dev.to/molly/making-on-call-not-suck-490
- https://en.wikipedia.org/wiki/Hate_(video_games)
- https://en.wikipedia.org/wiki/Bus_factor
- https://en.wikipedia.org/wiki/Bystander_effect
- https://medium.com/opsgenie/why-every-team-in-your-organization-should-embrace-on-call-1b43b31f6d8a
- Gene Kim、Patrick Debois、Jez Humble、John Willis。《DevOps 手册：如何在技术组织中创建世界一流的敏捷性、可靠性和安全性》。
- https://charity.wtf/2020/10/03/on-call-shouldnt-suck-a-guide-for-managers/