你不应该对无法控制的事情负责
内容提要
在服务水平研讨会上，强调不应对无法控制的事情负责，因为指标聚合了多个变量，其中不全在控制范围内。责怪前端团队销售电子商务网站上的商品数量是不公平和不现实的，开发人员无法控制市场需求或生产能力。同样，GraphQL团队也无法完全控制延迟，因为GraphQL可能使用由不同团队拥有的后端。解决问题需要明确各团队的责任和影响力。
延伸解读
指标聚合多变量，责任分配需谨慎
文章指出，指标通常聚合了多个变量，并非所有变量都在团队控制范围内。例如，前端团队无法控制市场需求或生产能力，GraphQL团队无法完全控制延迟，因为延迟可能涉及其他团队拥有的后端服务。因此，将无法控制的指标强加为团队责任是不公平且不现实的。这提醒我们，在设定团队目标时，必须区分可控与不可控因素，避免错误归因。
延迟预算分配：基于测量与协商
文章以移动、后端和数据库架构为例，说明用户面对的延迟是多个团队控制变量的总和。分配延迟预算时，需先测量各团队当前的平均延迟，再根据改进方向协商分配。例如，若总预算500ms，网络延迟131ms不可控，剩余369ms由移动和后端分配。分配方案可以偏向一方或均摊，但需考虑合理性和团队实际能力，最终通过透明沟通让团队自行决定。
重新思考团队边界，消除不合理依赖
当团队无法控制影响其指标的所有变量时，可能需要重新考虑团队边界。文章举例，若后端团队依赖另一个团队的服务，而该服务仅此一个消费者，则可通过转移所有权、创建新服务或合并功能来消除依赖。这有助于让团队控制自己负责的变量，实现责任与控制权匹配。但需注意，转移所有权可能面临技术栈不适配的风险，创建新服务则可能耗时且不稳定。
Q&A
为什么不应该让团队对无法控制的事情负责？
因为指标通常聚合了多个变量，并非所有变量都在团队的控制范围内。让团队对无法控制的事情负责是不公平且不现实的。
在移动应用延迟问题中，哪些因素会影响延迟？
延迟是多个变量的总和，包括移动应用团队处理用户交互、API调用、解析响应和更新UI的时间；后端团队接收API调用、验证、查询数据库、应用业务逻辑和发送响应的时间；网络连接质量；用户设备硬件；以及后端可能依赖的其他服务（如认证、数据服务）和云服务。
如何合理分配延迟预算给不同团队？
首先测量各团队当前的平均延迟，然后根据改进方向和当前表现分配预算。可以保持一方不变让另一方优化，或按比例分配优化目标。最终应与团队沟通，透明地传达预算并让团队决定如何划分。
如果后端团队依赖其他团队的服务，可以采取哪些措施？
可以转移服务所有权给后端团队、创建新服务替代旧服务、或将功能合并到现有后端中。这些方法旨在消除依赖，使团队对影响其指标的变量有完全控制权。
为什么移动团队在延迟问题上容易受到过多指责？
因为用户面对的延迟是多个团队控制的变量总和，但人们往往只看到移动团队负责的用户界面部分，忽略了网络、后端、数据库等其他因素。如果不考虑这些细节，移动团队就会承担不应有的责任。
如何确保责任与控制权相匹配？
团队应对各自负责的变量有控制权。如果存在依赖，应重新考虑团队边界，通过转移所有权、创建新服务或合并功能来消除依赖。同时，要控制自己负责的事务，并对自己负责的事情采取控制措施。
