在这篇博文的第2部分中，我们解释了SRE团队希望了解一个寻求SRE支持的服务的内容，以及在考虑将其接管之前，他们希望看到该服务有哪些改进。在第1部分中，我们研究了为什么SRE团队会或不会选择加入一个新的应用程序。现在，让我们看看一旦SRE同意使用寻呼机会发生什么。

入职准备

当开发人员处理行动项目时，SRE团队开始熟悉服务，积累服务知识，熟悉现有的监控工具、警报和危机程序。这可以通过几种方法来实现：

衡量成功

如果开发人员和SRE团队同意移交系统，他们还应该就衡量移交是否成功的标准（包括时间表）达成一致。这些标准可能包括（适当的数字）：

接手传呼机

理论上，SRE团队将在入学审查阶段确定这些问题的大部分，但实际上有许多问题只有在持续接触某项服务时才明显存在。

在中期（一到两个月），SRE应建立一份关于监测、资源消耗等方面的系统缺陷或优化领域清单。该清单的主要目的是减少SRE的"辛苦工作"（没有持久价值的手动、重复、战术性工作），其次是修复系统的各个方面，如资源消耗或积垢，这会影响系统性能。第三次变更可能包括更新文件，以便于系统支持的新SRE的入职。

从长期来看（三到六个月），SRE应满足上述收购成功的大部分或所有预先确定的衡量标准。Q： 太好了，那么现在我的开发者可以关掉他们的寻呼机了？

别那么快，我的朋友。尽管SRE团队在前几个月已经了解了很多关于服务的知识，但他们仍然不是专家；不可避免地会有涉及神秘服务行为的故障模式，在这些模式下，待命的SRE将不知道发生了什么故障，或者如何修复。没有什么可以替代有一个开发人员可用，我们通常要求开发人员保持他们的随叫随到轮换，以便SRE随叫随到可以页面他们，如果需要的话。我们预计这将是一个低页面率。

核心选项-交回寻呼机

一个SRE团队只能处理这么多服务，如果一个服务开始消耗不成比例的SRE时间，它就有可能排挤其他服务。在这种情况下，SRE团队应该主动告诉开发人员团队他们有问题，并且应该以中立的方式这样做，即数据密集：

在过去的一个月里，我们看到服务S1每周有100页，而在过去的几周里，稳定的速度是每周20-30页。尽管S1在SLO内部，但是页面控制着我们的运营工作，排挤了服务改进工作。您需要执行以下操作之一：

有时开发人员和SRE也会同意将寻呼机交还给开发人员是正确的做法，即使操作负载正常。例如，假设SREs正在支持一个服务，开发人员会想出一个新的、闪亮的、性能更高的版本。开发人员最初支持新版本，同时解决它的问题，并将越来越多的用户迁移到它。最终，新版本是使用最频繁的——此时SREs应该为新服务使用寻呼机，并将旧服务的寻呼机交还给开发人员。开发人员可以在方便的时候完成用户迁移并拒绝旧的服务。

将您的SRE和开发团队聚合在一起

现在，当开发人员团队设计新的应用程序或服务时，他们应该借此机会邀请SRE团队参加讨论。SRE团队可以很容易地发现设计中的可靠性问题，并建议开发人员如何使服务更易于操作，建立良好的监控，并从一开始就配置合理的推出策略。

同样，当SRE进行未来规划或设计新工具时，他们应该让开发人员参与讨论；开发人员可以提供建议向他们介绍未来的产品发布和项目，并就如何使工具更易于操作或更适合开发人员的需要提供反馈。

想象一下，SRE和开发人员团队之间有一堵砖墙；我们最初的服务接管计划是将服务抛到墙上，寄予希望。在这些博客文章中，我们向您展示了如何在墙上打一个洞，以便在服务通过时可以进行双向通信，然后将其扩展到一个门口，以便SREs可以进入开发人员的后院，反之亦然。最终，开发商和SRE应该完全拆除这堵墙，换成低矮的树篱和装饰性的花园拱门。SRE和开发人员应该能够看到彼此院子里发生的事情，并根据需要漫步到另一边。