上线之后：监控告警、热修复、回滚决策与事故复盘
上线不是终点而是起点。这一课讲上线后要监控什么、告警怎么设，出事故时如何按「止血—定位—修复—复盘」有序响应，覆盖服务器故障、第三方异常、崩溃飙升、商店被拒等典型场景，并给出上线第一周观察清单
- 建立上线后的核心指标、崩溃收集与告警体系
- 掌握事故响应四步法：止血、定位、修复、复盘
- 能对服务器故障、第三方异常、崩溃飙升、热修复/强制更新做决策
- 会写事故复盘并把教训沉淀回清单，避免重复踩坑
真正考验功力的是上线之后
发布完成不等于工作结束：真实用户的机型、网络、操作路径远比测试复杂，问题一定会来。差距在于成熟团队有监控第一时间发现、有预案不慌、有复盘让同样的问题不再犯。这一课讲上线后的运维与应急，让你从「出了事才知道」变成「用户还没大面积感知就已处理」。
上线后要监控什么
四层监控，缺一不可
① 客户端：崩溃率/ANR(卡死)、启动耗时、页面性能、各机型系统分布
② 服务端：进程存活、CPU/内存/磁盘、QPS、错误率(4xx/5xx)、响应时间
③ 依赖：数据库连接与慢查询、第三方(大模型/支付/TTS)成功率与延迟
④ 业务：核心漏斗(注册→学习→完成)、付费转化、留存等北极星指标
告警：设阈值+对比基线(比昨天/上版本同时段)，异常主动推送给你，
而不是等用户投诉才知道；配一个外部「黑盒探针」定时探测线上可用性告警不是越多越好：阈值过敏感会天天误报、最后你对告警麻木。原则是告警只发给「需要人立刻处理」的事，配基线对比（比平时显著异常才报），并分级（P0 全站不可用立即电话级、P2 局部问题工作时间处理）。日常趋势用看板看、异常才告警。
事故响应四步法
线上出事时最忌讳在慌乱中直接改代码试。固定四步：
① 止血(优先恢复服务，而非先找根因)
- 能回滚立刻回滚到上一稳定版 / 关特性开关 / 限流降级
- 第三方挂了就熔断、走兜底，先让用户能用
② 定位(在止血的同时/之后查根因)
- 看监控与告警时间线、错误日志、最近变更(十有八九和刚发布有关)
- 沿请求链路逐层排查(CDN→网关→后端→DB→第三方，见 Stage16-m1)
③ 修复(最小改动修复，验证后再谨慎上线，避免引入第二个问题)
④ 复盘(写 Postmortem：时间线、影响、根因、处置、改进项与负责人)
复盘对事不对人，目标是让系统和流程下次能挡住同类问题热修复、强制更新与商店被拒
呼应 Stage15-m8：混合应用的网页层问题可用 OTA 热更新快速修复（不碰原生、不改核心功能性质），原生层问题必须发新版；当旧版本存在严重问题时，通过版本接口对低版本强制更新。如果新版本被商店拒绝，别慌：按驳回邮件的具体条款定位、修复后重新提交，若是误判走申诉并附证据，申诉期间可先用热更新/服务端策略缓解线上影响。
一份好的事故复盘长什么样（选学）
Postmortem 通常包含：事故摘要与影响范围（多少用户、多久）、精确时间线（发现—告警—止血—恢复）、根因（技术根因 + 为什么监控/流程没提前挡住）、处置过程、做得好与不好的地方、行动项（带负责人和截止时间，例如「给磁盘加 85% 告警」「发布清单增加某项」）。最有价值的是行动项真正闭环，并回补到监控告警和上线清单里——这样每次事故都让系统更健壮，而不是道个歉就翻篇。
上线第一周观察清单
新版本/新产品上线第一周是高风险期，建议加密观察：每天固定看几次崩溃率、错误率、核心漏斗与付费数据；重点看新用户首日路径有没有卡点；收集并归类用户反馈与差评；观察服务器资源趋势会不会随用户增长触顶；确认备份真的在跑、并做一次恢复演练；记录所有小问题排期修复。平稳度过第一周、指标符合预期，再进入常规运维节奏。
新手只盯功能能不能跑（均值），老手还盯它会不会突然不行（方差）：监控、告警、灰度、回滚、复盘，本质都是在压低「出故障的概率」和「故障的影响与时长」。你不需要追求零故障——那不现实——而是追求故障可快速发现、快速止血、不再复发。把这套闭环跑顺，一个人也能维护出让用户觉得「一直很稳」的产品，这正是专业工程师和业余爱好者的分水岭。
线上突发故障时，最优先的动作应该是？
本节小结
上线后四层监控：客户端(崩溃/ANR/启动性能/机型分布)、服务端(进程/CPU内存磁盘/QPS/错误率/延迟)、依赖(数据库慢查询/第三方成功率)、业务(核心漏斗/付费/留存)，告警设阈值+基线对比分级、少而准，加外部黑盒探针。事故四步法：止血优先(回滚/关特性开关/限流熔断降级,先恢复)定位(时间线/最近变更/沿CDN→网关→后端→DB→第三方链路)最小修复验证再上复盘Postmortem(时间线/影响/根因/处置/行动项,对事不对人并闭环回补清单)。典型止血：崩溃飙升回滚或关开关、磁盘满限流清理扩容、第三方故障熔断兜底、严重bug用OTA热修或强更(原生问题必须发版)，商店被拒按条款修复或附证据申诉。上线第一周加密观察崩溃/漏斗/付费/资源/备份恢复演练/反馈归类。稳定性=既管均值也管方差，目标是快速发现、快速止血、不再复发。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
国内各应用商店通常要求独立渠道包或渠道标识，用于分别提审、升级提示和来源统计。正确做法是所有渠道共用同一份代码，只在构建时注入不同渠道号，用构建脚本一次出齐，并逐一回验每个包的签名、版本号和渠道标识；手工改包最容易导致某个商店常年停在旧版、用户一直收不到更新。