1. SLA 违约概述：从概念到实战
各位同学，咱们今天聊 SLA。说实话，这词儿在运维圈里都快被说烂了。但真正能把 SLA 违约根因快速定位做好的团队，我见过的不多。
我个人习惯，每次接手新项目，第一件事就是翻 SLA 合同。为什么？因为 SLA 不只是纸上的几个 9，它是你和业务方之间的「军令状」。一旦违约，轻则扣钱，重则丢客户。
什么是 SLA？
SLA，全称 Service Level Agreement，服务等级协议。说白了，就是你承诺给客户的服务标准。
举个例子：你承诺系统可用性 99.9%，那一年最多只能宕机 8.76 小时。超了，就是违约。
我遇到过一家电商公司，SLA 里写着「下单接口响应时间 P99 < 200ms」。结果双十一那天，P99 飙到 1.2 秒。虽然系统没挂，但按 SLA 条款，这已经是严重违约了。
核心要点：SLA 不是技术指标，是商业承诺。技术团队必须把 SLA 条款翻译成可监控、可量化的技术指标。
SLA 违约的常见类型
根据我的经验，SLA 违约大致分三类。咱们用表格对比一下：
| 违约类型 | 典型表现 | 根因方向 |
|---|---|---|
| 可用性违约 | 服务不可用、宕机、503 | 基础设施、代码缺陷、配置错误 |
| 性能违约 | 响应慢、吞吐低、超时 | 资源瓶颈、慢查询、锁竞争 |
| 容量违约 | 限流、降级、丢请求 | 容量规划不足、突增流量 |
你想想看，这三种违约的排查思路完全不同。可用性违约，第一反应是看监控告警和日志；性能违约，得先抓慢调用链；容量违约，得看流量和资源水位。
SLA 违约对业务的影响
这个我深有体会。之前负责一个金融支付项目，SLA 是 99.99%。有一次因为数据库主从延迟，导致对账接口超时，触发了违约条款。
结果呢？
- 直接罚款：按合同赔了当月服务费的 15%，几十万没了。
- 客户信任下降：业务方开始质疑我们的运维能力，后续合作差点黄了。
- 团队士气受挫：连续加班排查，最后发现是配置问题，大家都很憋屈。
避坑指南：我曾经见过一个团队，SLA 违约后只关注「系统恢复了没」，完全没留证据。结果客户追责时，拿不出任何监控数据证明「故障时长」。记住：SLA 违约的取证和恢复同样重要。
SLA 违约的典型场景
咱们来看几个真实场景。这些场景在后续课程中会反复出现。
- 大促流量冲击：双十一、秒杀活动，流量瞬间暴涨，系统扛不住。
- 依赖服务故障：你调用的第三方 API 挂了，导致你的服务也超时。
- 变更引发问题：上线新版本、改配置，不小心引入了 bug。
- 基础设施故障：机房断电、光缆被挖断、云厂商故障。
- 容量规划不足：业务增长快，但资源没跟上，高峰期直接打满。
嗯，这里要注意：很多团队只盯着「系统挂了」这种大故障，却忽略了「性能劣化」这种慢性违约。慢性违约更难排查，因为它不是瞬间发生的，而是慢慢累积的。
知识体系总览
为了让大家有个整体认知，我画了一张图。这张图涵盖了本章的核心知识点和它们之间的关系。
我的建议：刚开始做 SLA 运维的同学，别急着学那些花哨的排查技巧。先把 SLA 条款吃透，搞清楚哪些指标是红线，哪些是黄线。我曾经带过一个新人，他花了一周时间把所有 SLA 指标都配上了监控和告警，后来故障排查效率提升了一大截。
好了，这一章的内容就到这里。记住：SLA 违约不是技术问题，是管理问题。后面的课程，我们会深入每个场景，讲具体的根因定位方法。