政务云上可用性是硬指标、日志留存与审计是红线。以市级政务云项目为例，讲清日志冷热分层与留存合规、操作审计四要素检索、三级告警与值班路由、灾备与演练的落地做法。
政务云上的系统有个共同特点：可用性是硬指标，日志留存和审计是红线。可观测平台在这里不是锦上添花，而是要同时满足"出了问题能快速定位"和"审计抽查拿得出东西"两个要求。这篇讲我们在一个市级政务云项目里的落地方式。
等保 2.0 要求日志留存不少于 6 个月，涉及重要数据的系统还可能要求更长。落地的第一步是算清楚量：一个日均调用百万级的政务系统，按 500 字节/条算，一天约 500 MB，六个月就是 90 GB 左右，加压缩和副本后翻倍。
我们对日志分了冷热两层。近 30 天存热存储，检索要快；30 天以上转冷存储（对象存储或归档盘），只保不常查。合规要求的"留存"不等于"秒查"，把冷数据挪到便宜的地方，成本能降一半以上，同时留存的完整性和防篡改校验一起做掉。冷数据按文件块算哈希留档，审计抽查时能证明"这批日志从写入到现在没被改过"。
政务场景最怕的不是故障，是"事后说不清"。所以审计重点放在两类操作上：一是系统管理员和运维人员的操作记录（登录、改配置、删数据），二是业务数据的关键变更。
做法是让平台把操作日志和业务日志分开采集、分开存储、分开授权。审计日志默认只追加、不可删除，给审计角色只读权限。抽查时能按"人 + 时间 + 动作 + 对象"四要素检索，几分钟出报告，而不是翻半天。每次测评、等保复查前，我们提前按四要素导出相关记录，评审当天直接交材料，不再临时翻库。
政务云的告警容易做成两个极端：要么告警风暴，值班的人麻木；要么阈值定太松，出了问题没人知道。我们用的办法是分三级：核心业务接口的可用性和时延用严格阈值，基础设施用聚合告警加静默窗口，非关键指标只记录不打扰。
值班上，把告警按影响面路由：影响公众服务的一分钟进政务 App 和企业微信群，内部系统的走邮件和短信。每周出一份告警周报，统计误报率、平均响应时间，倒逼告警规则持续收敛。跨部门协作也提前定好：哪个接口归哪个委办局、出了事第一责任人是谁，写进值班手册，而不是事发后再找人。
政务云对可用性要求高，光有监控不够。我们把关键系统做了双中心部署，可观测平台本身也随业务一起切流，主中心挂了能在一段可接受时间内切到备中心，RPO 和 RTO 都提前压测过。
每个月做一次故障演练：从告警触发、定位、到切换和恢复，完整走一遍并记录耗时。演练不是为了表演，而是验证"告警到定位"这条链路真的通，顺便把值班手册里过时的联系方式改掉。
政务云的可观测，本质是"责任可追溯、状态可感知"。把这两件事做实，比堆一堆炫技的功能有用得多。