1 可观测性要回答什么
读者可以先想象这样 1 个服务：顾客在手机上提交订单，请求经过入口、订单 API 和数据库，成功后返回订单号。服务部署在云上，API 有 2 个副本，使用工作负载身份访问数据，网络规则限制访问路径。某天值班人员收到“下单变慢”的反馈。此时，控制台显示实例仍在运行、数据库仍可连接、部署也显示完成。这些状态都正确，却没有回答顾客为什么等了很久。
可观测性关注的是：根据系统输出的证据，理解它在特定时间、特定条件下发生了什么。入门时可以把目标压缩为 4 个问题：用户受到什么影响；影响从什么时候开始；涉及哪些请求与组件；哪些证据支持当前解释。它并不承诺自动给出根因，而是让团队有条件提出假设、缩小范围，并在采取动作后判断服务是否恢复。
监控通常从已知问题出发，例如预先配置“错误比例超过阈值”。可观测性还需要支持告警没有预先描述的问题，例如“只有新版本、某条路径、部分请求出现延迟”。两者并不冲突：监控帮助发现异常，可观测性提供进一步追问的材料。收集很多数据也不等于具备这种能力；如果无法把数据对齐到服务、版本与时间窗口，值班人员仍然只能猜测。
图中应区分业务请求路径与观测数据路径。请求经过入口、API 和数据库；这些组件把运行信号送到观测平台。平台查询失败不一定意味着下单失败，下单失败也可能恰好发生在数据没有送达时。因此，需要同时观察服务和采集链路：最近的数据是什么时间产生的，哪些组件没有上报，查询结果是否来自完整窗口。
云的资源层次会影响定位方式。某个副本异常、某个可用区网络受阻、数据库连接紧张，可能产生相似的用户症状。只看整个服务的平均值容易掩盖局部问题，只看某台机器又容易忽略整体影响。适合入门的做法是先保留服务级视图，再允许按环境、版本和区域等有限维度下钻，而不是为每个临时实例建立互不相连的看板。
“可观测”也有边界。没有记录的历史细节通常无法事后补回；有记录也不代表已经证明因果关系。某次部署与延迟上升同时发生，只能使部署成为优先检查对象。若回滚后恢复，还应结合版本差异、依赖耗时与流量变化继续核对。我们需要的是能修正判断的证据，而不是为最初的猜想寻找支持。
本课围绕订单 API 建立这套基本能力：从用户结果选信号，把告警连接到可查询的材料，再用时间线组织排查。深入的追踪协议、存储引擎与统计模型留到后续学习；当前先做到让另 1 位值班人员接手时，可以沿着同样的路径复核结论。
2 指标、日志与追踪的职责
指标把连续发生的事件汇总为可计算的数值，适合回答“有多少、变化多快、整体怎样”。订单 API 的请求计数、失败计数、耗时分布和连接池使用量都属于指标。它们适合持续查看趋势，也适合触发告警。查询时必须明确单位与口径：请求总量是累计计数还是某个窗口内的次数，耗时单位是毫秒还是秒，失败是否包含调用方主动取消。
日志记录某个时间发生的事件及其上下文，适合回答“当时具体遇到了什么”。例如 1 条数据库超时日志可以包含服务名、版本、路由模板、错误类别、请求关联标识，以及已经等待的时间。应优先使用结构化字段，避免把全部信息藏在自由文本里。日志不必逐行描述代码执行过程，重点是记录业务边界、异常和关键状态变化。
追踪把 1 次请求在多个组件中的活动连接起来，适合回答“时间花在哪里、调用跨过了哪些边界”。完整追踪由若干跨度组成，跨度描述 1 段有起止时间的工作，并通过父子关系连接。订单入口、订单处理、数据库调用可以分别形成跨度。关联上下文需要随调用传递；每个服务都独立生成自己的标识，无法自然拼成同 1 条链。
这 3 类信号不应各自孤立。指标显示某个版本的慢请求增多后，可以查看该时间段的代表性追踪，再依据追踪标识检索相关日志。为了实现这种跳转，至少应统一服务名、环境、版本和时间表达。时间通常保存为带时区的统一格式，界面再按需要转换；持续时间尽量使用组件自身的计时结果，避免直接拿不同机器的墙上时钟相减。
字段放在哪里也有区别。把订单号、用户标识或追踪标识作为指标标签，会让取值组合迅速膨胀，这称为高基数问题。适合指标的标签应当有受控数量，例如环境、服务和少量错误类别。订单号若确有排查用途，应受访问控制地留在日志中；优先使用不含个人信息的内部关联标识，也不应记录令牌、密码或完整支付资料。
指标适合观察总体，却通常不能还原某个请求；日志有细节，却可能缺少调用关系；追踪能展示路径，却可能只覆盖被保留的请求。不能因为追踪页面没有显示错误，就断言服务没有错误。正确的问题是：这些数据来自哪些请求、覆盖哪些组件、是否存在丢失或延迟。信号之间能够互相印证，才有助于减少误判。
部署事件同样值得关联。记录版本何时开始发布、何时完成、何时回滚，通常比在事故后凭记忆寻找变更更可靠。这里不需要收集全部控制台操作，只需先把影响服务行为的重要变更放在同 1 条时间线上。这样，当流量、错误和版本同时变化时，团队能够明确接下来需要验证哪种解释。
3 黄金信号、SLO 与告警边界
面向在线服务，可以先用 4 类黄金信号建立视图：延迟、流量、错误和饱和度。延迟反映请求等待多久；流量说明系统正在承担多少工作；错误描述未达到约定结果的请求；饱和度关注资源或队列接近容量边界的程度。它们相互补充：低流量可能使错误比例剧烈波动，队列增长可能先于超时，CPU 使用率偏低也不能排除等待外部依赖。
延迟不宜只看平均值。假设多数请求很快，少量请求等待很久，平均值仍可能显得正常。P95 表示在观察集合中约 95% 的请求耗时不超过这个值，但它不是最慢请求，也不直接表示每个用户的体验。应同时查看请求量、错误和耗时分布；不同副本的 P95 不能简单取平均来充当服务整体的 P95。
服务等级指标 SLI 是对用户结果的测量方式，服务等级目标 SLO 则为该指标规定目标与统计周期。例如：“订单提交接口在滚动 30 天内，99.9% 的有效请求成功完成。”这句话仍需配套定义：哪些路径算订单提交、哪些结果算成功、重复请求如何处理、在哪个边界测量。没有清晰分母的百分比，无法稳定指导告警与复盘。
有效请求不能为了让数据好看而随意排除。顾客提交了格式不合法的字段，可以依据事先定义归入调用输入问题；如果服务发布错误导致正常输入被拒绝，就仍应反映在服务质量中。若“成功”只看 HTTP 状态，却没有核对订单是否持久保存，目标可能与用户体验脱节。初期可以采用清晰、可实现的口径，并注明尚未覆盖的业务结果。
99.9% 的成功目标允许最多 0.1% 的有效请求未成功，这部分允许空间常称为错误预算。若统计周期内有 100000 次有效请求，对应的数量上限是 100 次；这是解释目标的例子，并非任何服务都应采用的标准。错误预算帮助讨论可靠性与发布节奏，但不能把严重的数据错误当作可以随意消耗的额度，也不能把请求比例直接换算成停机分钟。
告警需要连接动作。用户失败率持续上升、快速侵蚀目标时，适合呼叫值班人员；磁盘缓慢增长但仍有充分处理时间，可能更适合作为待办；单次可恢复重试通常只需记录。持续窗口能过滤短暂抖动，但也会延后发现，应依据业务可承受的影响选择。低流量服务还应结合失败次数或合成探测，避免少量请求造成比例告警反复跳变。
每条告警至少说明影响、范围、窗口、负责人和首个检查入口。没有数据也不能自动解释为正常：采集停止、查询失败和真实零流量应分别表达。告警边界不是阈值表，而是“出现什么证据时，由谁在多长时间内做什么”的运营约定。复杂的多窗口预算告警可以后续再学，先把口径、责任与动作写清楚。
4 动手：从一次告警回溯到证据链
下面使用教学环境中的订单 API 做 1 次受控练习。准备 1 个可以回退的测试版本，让少量测试请求在数据库调用前等待额外时间；不要在真实顾客流量中随意制造故障。练习前记录正常流量下的请求量、错误比例和耗时范围，并确认测试日志不包含真实订单资料。若没有运行环境，也可按相同字段整理提供的模拟事件，练习查询顺序。
假设 10:05 收到告警：最近 5 分钟，订单提交接口的 P95 超过 800 毫秒，并且窗口内有效请求达到预定下限。先记下告警实际统计的时间段、数据更新时间与测量入口。通知到达时间不等于故障开始时间，图上的当前点也可能仍在补齐。把查询范围扩展到 09:50—10:15，有助于比较变化前后，而不是只盯着触发瞬间。
第 1 步确认影响：入口侧是否也变慢，错误是否增加，受影响的是所有请求还是部分路径。第 2 步切分范围：比较版本、区域和副本，注意每组请求量是否足够。第 3 步核对事件：10:00 是否发生部署，流量是否同时上升。第 4 步抽取代表请求：查找慢请求追踪，并关联日志。第 5 步验证假设：观察跨度、连接池等待和依赖耗时，而不是直接把时间线上的最近变更定为根因。
例如，新版本的入口耗时明显升高，数据库服务器处理耗时却保持稳定。追踪显示订单 API 内部有较长空白，结构化日志又记录“调用前等待 600 毫秒”。这些证据共同支持等待发生在 API 内部。数据库 CPU 正常只是辅助信息，单凭它无法排除连接等待、网络延迟或慢查询；同样，某条慢追踪也不代表全部请求都具有相同模式。
随后在测试环境撤回延迟注入，继续发送相同类型、相近数量的请求，观察后续完整窗口。不要在曲线刚下降时立即宣告恢复，因为滚动窗口仍包含此前的慢请求。应同时确认入口体验恢复、错误没有转移到其他路径、观测数据持续到达。如果仅减少了采集量，图表可能变好看，却没有改善服务。
最后写出简短证据链：“10:00 测试版本发布；10:01 起新版本延迟上升；慢请求在 API 内部出现等待；10:08 撤回注入；后续完整窗口恢复基线。”每项附上可重查的筛选条件，而不是只保存没有时间范围的截图。把已经验证的事实、仍待验证的解释与采取的动作分开，接班人员才能继续判断。
练习成功的标准不只是告警响过。还应能从告警进入相关看板，从看板找到代表请求，并根据日志与变更记录解释等待位置。如果某个跳转失败，就记录缺失字段或覆盖边界，作为补齐观测能力的任务。只在演练时能靠熟悉代码的人猜出答案，说明这条排查路径仍不够可靠。
5 采样、成本与覆盖取舍
观测数据本身也消耗资源：应用生成数据需要计算与缓冲，传输占用网络，平台写入、索引、保存和查询都可能计费。成本不能只看保存了多少字节，还要看字段数量、指标序列数、查询频率与保留时间。目标是用可承受的代价保留足够证据，而不是默认所有事件永远保存，也不是为了降费一次关闭全部日志。
采样是按规则选择部分事件。假设订单 API 平均每秒处理 200 次请求，每条完整追踪平均占用 8 KB，统一用十进制单位估算，每天生成约 138.24 GB。若按 10% 保留，每天约为 13.824 GB；保存 7 天约为 96.768 GB。这只是原始数据量估算，未包含索引、复制、压缩、波峰或计费规则，不能直接充当真实账单。
通过滑块调整追踪保留比例，可以看到体积近似随比例变化，但排查价值不会始终等比例增长。若按独立随机方式保留 10% 的请求，只有 1 次的罕见错误被保留的概率也只有 10%。没有查到该错误的追踪，很可能是未被选中。增加采样率能够提高遇见证据的机会，却无法修复某个服务从未创建跨度的问题。
指标通常覆盖全部请求的汇总，追踪则可能保留部分请求。若采样策略偏向保留错误或慢请求，保留下来的集合就不再代表总体，不能直接用其中的错误比例代替服务错误率。对于入门系统，可以先用稳定的请求指标判断总体，再利用追踪解释典型路径。按结果选择追踪涉及更多实现约束，当前只需理解：保留策略会改变能看到的证据。
日志也需要分层。持续运行时保留必要事件与结构化错误，短期排查时按服务、版本或时间范围增加细节，并设置到期恢复。临时开启详细级别后无人关闭，是常见成本来源，也会增加敏感信息暴露面。日志重复记录整份请求体往往价值有限，使用错误类别、关联标识与必要的状态字段通常更容易查询。
覆盖应先看关键路径，再看数量。入口、订单处理与数据库之间若缺少任意关键边界，保存更多现有跨度也可能仍无法定位等待。可以列出关键组件，分别标明是否产生指标、是否传播追踪上下文、是否能关联日志、数据多久可查。用几条已知测试请求验证这张表，比单看每日写入体积更能说明覆盖情况。
采集链路发生拥塞时，还要预先决定怎样保护业务。通常应限制缓冲与重试，避免把上传观测数据变成订单请求的必经阻塞点；同时保留丢弃数量、队列积压和发送失败等指标。数据被丢弃后应标示观测缺口，不能悄悄把不完整的曲线当成正常下降。保留周期则根据事故发现时间、复盘需求与访问约束约定，并定期复查。
6 常见坑：告警风暴淹没真故障
假设数据库访问变慢，入口、订单 API、后台任务同时出现超时，2 个副本又各自发出资源告警。值班人员在几分钟内收到大量通知，但用户面对的可能是同 1 次服务故障。每条规则单独看都有道理，组合起来却占满注意力。告警风暴的危险并不只是吵闹，而是让最需要处理的用户影响被重复消息覆盖。
先区分“检测事件”与“呼叫动作”。平台可以保存每条异常记录，但不必为每个副本、每次重试都单独呼叫。对相同服务、相同影响和相近时间的告警进行分组，能够把多条技术症状合成可处理的事件。分组键应稳定且数量受控；如果把随机请求标识放进去，几乎每次异常都会变成新的通知组。
去重处理重复发送，分组把相关事件放到同 1 个处理视图，抑制则在明确条件下暂缓部分通知。这些动作不能混为“全部静音”。例如已经确认数据库依赖异常时，可以减少同一依赖导致的副本重复通知，但仍保留事件记录和新的用户影响变化。若其他路径同时独立故障，过宽的抑制规则可能把它一起藏起来。
反复触发与恢复也是常见噪声。某个数值在阈值附近波动，告警就不断切换状态。可以要求持续若干时间才触发，并为恢复设置稳定观察窗口；也可以让触发与恢复使用不同阈值。具体值要依据服务特性和响应需求选择，不能为了减少通知把等待时间拉得过长。发布期间的维护静默必须限定对象、负责人和结束时间，并保留用户体验监测。
只看资源百分比容易制造缺少动作的告警。CPU 达到 80% 可能是正常利用，连接池使用量接近上限则可能意味着请求即将排队。应结合用户症状、持续时间和容量趋势判断紧急程度。对于自动恢复且不影响目标的瞬间波动，可以记录并汇总；对于快速扩大的失败，即使资源指标看起来平稳，也需要及时处理。
每次故障后，应回看实际通知：哪条最早指出用户影响，哪条帮助缩小范围，哪条只是重复。删除无用规则不代表放弃监测，而是让呼叫渠道保留明确行动价值。修改规则后需要用历史窗口或受控演练检查效果，避免只在平静期感觉安静。交接资料中也应注明静默状态，防止下一班误以为没有异常。
另 1 个陷阱是由观测平台自身制造风暴：采集延迟使大量服务同时出现“无数据”，恢复后补报又触发过期异常。应检查数据时间、到达时间与采集健康状态，让无数据问题有自己的处置路径。若平台不可用，团队仍应保留最低限度的外部探测和应急入口，避免把能否打开看板当作判断服务状态的唯一依据。
7 案例：缺失追踪跨度导致误判
某次订单 API 发布后，入口 P95 从 250 毫秒升至 1200 毫秒。现有追踪只有入口跨度和数据库查询跨度，数据库查询通常在 40 毫秒内完成。值班人员看到数据库跨度后方有大段空白，又发现数据库连接数有所增加，于是推测“数据库变慢但追踪没有测准”，准备扩容数据库。这个推断把缺少证据的位置，直接归给了最熟悉的依赖。
先把事实与解释拆开。事实是入口耗时升高、数据库查询跨度较短、根跨度仍持续到较晚才结束。解释可能包括连接获取等待、API 内部计算、未记录的远程调用或数据不完整。数据库连接数增加与延迟同时出现，只说明存在关联。追踪里的空白不是“没有执行”，也不是“数据库占用时间”，而是当前图中没有可解释的子跨度。
排查人员接着核对新旧版本的调用路径。新版本在查询库存后增加了优惠校验，需要调用另 1 个内部服务；这段调用没有创建客户端跨度，也未将追踪上下文传给下游。下游虽然有日志，但无法通过原追踪标识找到。为了定位当前问题，团队先用受控测试请求的关联标识与时间窗口比对两侧日志，并检查新增依赖的请求耗时。
证据显示，优惠校验通常等待约 900 毫秒，新版本的等待主要发生在这段路径上。团队在测试环境为该调用补充跨度，并传播上下文，新的追踪中出现清楚的客户端与服务端关系。这里还要核对客户端耗时包含了什么：它可能包含连接、网络与等待；服务端跨度则只反映下游接收后的工作。两者不同，并不自动表示采集错误。
在修复实现前，团队依据业务约定回退本次发布，随后检查完整观察窗口，确认延迟恢复且订单结果正确。若业务允许降级，也必须明确优惠处理规则，不能由值班人员临时决定省略业务校验。本案例的重点是先定位等待边界，再选择已授权、可验证的恢复动作；给数据库加资源既未得到证据支持，也可能延误恢复。
补齐跨度之后，还需验证它在所有副本与目标版本中生效，并用已知请求确认上下文可以贯穿调用链。若只是把采样率从 10% 提高到 100%，原来没有产生的跨度仍然不会出现。若跨度有时存在、有时缺失，则应进一步区分版本覆盖、采样决策、传输丢失与异步边界等原因，而不是笼统地说“追踪不可靠”。
复盘结论应同时包含故障原因与观测缺口。故障原因是新增依赖等待超出预期；观测缺口是关键调用未被记录，导致最初归因偏离。后续动作可以是把关键出站调用的覆盖检查加入发布验收，并补充依赖耗时指标。这样，即使下一次追踪未抽中某个请求，也仍有总体信号提示是哪段路径开始变化。
8 把可观测性目标写进运营方案
运营方案首先定义服务边界和使用者关心的结果。对于订单 API，应写清入口、持久保存与后续通知是否属于同 1 个目标。若下单返回后还要异步发送通知，就不能用同步接口成功率代替通知及时性；可以把它们分别测量。初期不必给每条内部函数设目标，优先覆盖关键用户路径，并说明当前尚未观测的环节。
其次建立指标字典。每个关键指标记录名称、单位、分子分母、数据来源、聚合窗口、标签范围与负责人。例如成功率应说明由入口还是应用统计，延迟应说明是否包含失败请求。只有这些定义一致，发布前后、不同区域之间的比较才有意义。若口径改变，需要在图表和事件记录中标出，避免把测量方式的改变解释为业务改善。
再把目标连接到响应。写明谁接收紧急通知、无人响应时怎样升级、首个检查链接指向哪里，以及哪些恢复动作已经获得授权。运行手册应从确认用户影响开始，再检查范围、近期变更与依赖证据。不要只列“检查日志”这样的宽泛指令，而要给出服务、时间窗口和必要字段，使新接班人员可以实际操作。
观测覆盖也应进入发布验收。新增远程调用时，确认它能传播上下文并输出合理的耗时指标；新版本发布后，确认服务名与版本标签没有漂移；扩展到新区域时，确认采集权限与网络出口能够工作。验收不要求每次重建整个平台，而是围绕本次变更触及的边界，发送已知请求并检查证据是否到达。
数据治理同样属于运营工作。约定哪些字段禁止采集、谁可以查生产日志、谁可以修改告警、谁可以导出数据，以及不同类型数据保留多久。对排查使用的临时权限设置期限，并记录访问行为。追踪与日志常包含内部路径和业务关联信息，即使不含密码，也不能默认所有团队成员都可无限制检索。
方案还需要可衡量的维护节奏。可以定期回看告警是否有动作价值、关键路径是否存在盲区、数据写入量是否异常，以及事故后多久才发现证据已过期。选择适合团队的周期，并为每项改进指定负责人和完成条件。比如“补齐优惠调用跨度，并用测试请求证明可关联日志”比“加强可观测性建设”更容易验收。
最后写清失效边界：观测平台不可用时去哪里确认服务，采集拥塞时业务是否会被拖慢，关键数据丢失时如何标记结论的不确定性。指标、日志、追踪和变更记录组成的是可以持续维护的证据系统。方案是否有效，要看陌生接班人员能否用它回答影响、范围、假设与恢复情况，而不只看是否附了漂亮看板。
9 从可观测性走向云安全进阶（C42）
有了可查询的运行证据，团队能够更快发现异常，但异常并不自动等于攻击。订单失败率升高，可能来自发布问题、依赖故障、调用方输入变化，也可能来自恶意请求。可观测性帮助确认发生了什么和影响到哪里；安全分析还需要结合身份、权限、操作意图与资源暴露面。不能仅凭某条性能曲线就给事件定性。
以身份为例，运行日志可以说明 API 在何时访问数据库，身份审计记录则用于回答谁或哪个工作负载发起了操作、使用什么权限、结果如何。两者可能记录不同边界：应用报告访问失败，审计记录可能说明权限被拒绝；应用完全没有收到请求，控制面也可能已经发生网络策略变更。把这些时间线关联起来，才能避免只在应用内部寻找原因。
日志记录“有 1 次操作”并不能证明该操作被授权。安全判断需要事先定义的身份与权限规则；反过来，没有日志也不能证明没有发生操作，可能是未开启、未覆盖或已丢失。进入 C42 时，应继续追问审计覆盖哪些资源、记录由谁管理、保留与完整性如何保证。本课先建立这些问题，不展开复杂取证与攻击检测算法。
观测平台本身也是需要保护的云服务。采集器通常需要向指定位置写入数据，查询人员需要读取一定范围，告警管理员则需要修改规则。把这些能力全部授予同 1 个广泛身份，会放大误操作与滥用的影响。权限应按实际职责收窄，生产与测试环境分开，密钥或令牌不应出现在日志正文中，凭据变更也应有可审计记录。
网络边界也会影响证据。应用到采集端的连接被阻断时，首先出现的可能是观测缺口；若团队把无数据误认为无异常，就会失去发现问题的机会。应为采集链路保留健康信号，并明确哪些组件通过何种允许的路径发送数据。不要因为希望采集顺畅，就把数据接收端或管理接口开放给任意来源。
对于业务数据，需要遵循必要性原则。排查支付失败通常不需要完整支付资料，定位用户请求通常可以使用内部关联标识。确实需要访问敏感字段时，也应有明确用途、受控权限和合适的保存期限。数据越集中，检索越方便，对访问控制和操作审计的要求也越高；这是一项设计约束，而不是事故后才补上的管理手续。
因此，走向云安全进阶的自然连接是：先让系统行为可解释，再让身份、权限、网络和数据保护规则可以被验证。C42 将沿着这些边界讨论防护与运营。读者带过去的不是“装好工具就安全”的结论，而是 1 套具体追问：谁能做什么、异常如何被发现、证据是否完整、恢复动作是否受控。这些问题与本课的证据链可以共用时间线，但各自的判断标准仍需明确。
放进方案里
在运营方案中，为订单 API 写下可验收的观测约定。服务边界从下单入口到订单持久保存，异步通知另设指标；负责人维护有效请求、成功结果与延迟的定义。初始 SLO 采用滚动 30 天有效请求成功率 99.9%，具体目标由业务确认。入口按环境、版本和区域输出受控标签的请求量、错误与耗时分布，并同步记录重要部署事件。
关键路径覆盖入口、订单处理、数据库及新增远程依赖。发布验收发送已知测试请求，确认跨度关系完整、日志能够按关联标识检索、时间与版本可以对齐。指标用于判断总体，采样追踪用于解释路径；未抽中请求与未产生跨度分别记录。追踪按 10% 的初始比例估算容量，错误保留策略另行说明；日志禁止写入凭据和完整支付资料，保留期限依据复盘需求与访问约束确定。
紧急告警围绕用户影响设置持续窗口与低流量保护，通知中提供负责人、影响范围及查询入口。相同故障症状分组处理，静默必须注明对象与到期时间。值班人员先确认影响，再查版本和依赖；回退操作按既定授权执行，恢复后观察完整窗口。事件记录保留事实、假设、动作与验证结果，并为未解决的证据缺口指定负责人。
采集端应限制缓冲与重试，并上报积压、丢弃和发送失败；无数据进入独立处置流程。观测平台不可用时，通过独立探测与应急入口确认服务状态。每月复查告警有效性、关键路径覆盖、数据量和查询权限，发现缺口后安排有验收条件的改进。方案完成的标准是接班人员能复现查询、说明用户影响，并判断恢复是否成立。
10 小结：下一步云安全进阶（C42）
可观测性把用户影响、运行信号和处置动作连接起来。指标帮助看总体，日志保存事件细节，追踪解释调用路径；SLO 明确目标，告警把需要行动的变化交给负责人。采样、缺失跨度和采集故障都会限制证据，结论必须说明这些边界。
离开本课前，试着口头回答 3 个问题：没有追踪能否证明没有错误；入口变慢而数据库跨度很短时，还需哪些证据；告警恢复后为什么仍要观察完整窗口。下一课进入云安全进阶（C42），继续用身份、权限、网络与审计证据验证服务边界。