针对核心和非核心应用，以及强弱依赖关系，我们在设定 SLO 时的要求也是不同的，具体来说，可以采取下面 4 个原则。
第一，核心应用的 SLO 要更严格，非核心应用可以放宽。 这么做，就是为了确保 SRE 的精力能够更多地关注在核心业务上。
第二，强依赖之间的核心应用，SLO 要一致。 比如下单的 Buy 应用要依赖 Coupon 这个促销应用，我们要求下单成功率的 SLO 要 99.95%，如果 Coupon 只有 99.9%，那很显然，下单成功率是达不成目标的，所以我们就会要求 Coupon 的成功率 SLO 也要达到 99.95% 。
第三，弱依赖中，核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段。 这样做是为了避免由非核心应用的异常而导致核心应用 SLO 不达标。
第四，Error Budget 策略，核心应用的错误预算要共享，就是如果某个核心应用错误预算消耗完，SLO 没有达成，那整条链路，原则上是要全部暂停操作的，因为对于用户来说，他不会判断是因为哪个应用有问题，导致的体验或感受不好。所以，单个应用的错误预算消耗完，都要停止变更，等问题完全解决再恢复变更。当然，也可以根据实际情况适当宽松，如果某个核心应用自身预算充足，且变更不影响核心链路功能，也可以按照自己的节奏继续做变更。这一点，你可以根据业务情况自行判断。
梳理出系统的核心链路并设定好 SLO 后，需要一些手段来进行验证。这里有两种手段，一种是容量压测，另一种就是 Chaos Engineering，也就是混沌工程。
总之，生产系统的稳定性在任何时候，都是最高优先级要保证的，决不能因为演练导致系统异常或故障，这也是不被允许的。所以，一定要选择合适的时机，在有充分准备和预案的情况下实施各类验证工作。
此文章为4月Day25 学习笔记，内容来源于极客时间《SRE 实战手册》，推荐该课程。
