开发不愿意了
一个后端服务通常有三个环境：测试环境，预发布环境，生产环境。
运维在给测试环境增加告警规则和告警路由时，开发人员反对。
这很容易理解，如果真把告警规则配置到测试环境，他们可能无时不刻地收到告警通知。
为什么会这样？因为：
很多开发将测试环境当开发环境，他们没有本地开发环境。测试环境不稳定，告警通知会非常的多；
开发人员的心理：测试环境挂了也无法所谓。
运维要强上
我觉得是要给测试环境加上的，理由如下：
这样可以让开发人员重视测试环境的可用性；
这样可以强迫开发人员在测试环境就考虑在生产环境可能出现的异常情况；
这样可以让开发人员不把测试环境当成开发环境。间接增加他们在本地写单元测试的动力（奢求）。
大前提
当然，以上理由也有一个前提，就是告警要实现服务级别的告警模式。
什么是服务级别的告警模式？假如存在一个平台alpha，它由svc-1，svc-2...svc-n组成。
笼统的告警通知模式：整个alpha平台只有一个On-Call值班表，只要是告警，就通知当前的On-Call，不论是基础设施问题的告警，还是业务逻辑问题的告警，一律通知这个On-Call，再由On-Call决定通知谁；
服务级别的告警模式：我们需要做到svc-1有一个On-Call值班表，svc-2也有一个值班表...svc-n也有。如此，当一个svc出现告警时，就只会通知到svc的on-call。
不难想象，笼统的告警通知模式只要做到告警自动路由到不同的业务的负责人，就是服务级别的告警通知模式了。
笼统的告警通知模式应用到测试环境，我们每天都需要有一个On-Call进行人工对告警进行分配的，这对于整个团队的效能是一种浪费。
所以，在没有实现服务级别的告警模式前，不建议在测试环境增加告警规则。
不存在没有缺点的解决方案
当然，为测试环境加上告警也可能会变成缺点：通知量太多了，开发人员对告警通知麻木。
这个问题可以通过以下方式来规避：
测试环境的告警通知要配置和生产环境一样的告警通知升级机制；即，如果开发长时间不处理告警，就将告警通知给他的上级；
测试环境只在工作时间进行告警通知。比如下班时间，告警触发规则虽然生效，但是告警通知只被记录下来，不发出通知。
问题
当告警通知可以被记录下来后，应该会有人想到加一个“告警通知处理速度”的KPI。我目前还没想通，加这个KPI的好处和坏处。就把这个问题留给各位读者了。
往期好文：
小基础设施团队的分工思路
另类的思路CMDB建设思路
SRE认知升级之可用性的本质
