超级管理员
楼主
内部系统的运维不需要上来就搞一套可观测性平台。把基础巡检做扎实，能挡掉大部分事故。
一、每日看
- 服务可用性：核心接口逐个探活，不要只看服务器是否在线。进程在但接口 500 是最常见的漏报。
- 磁盘空间：低于 20% 就要处理。数据库盘尤其要盯，写满之后恢复很麻烦。
- 错误日志：按错误类型聚合看数量，不要逐条读。突然出现的新类型错误优先看。
- 备份结果：确认昨天/今天的备份任务成功。备份任务失败但没人发现，是最危险的状态。
二、每周看 5. 慢查询：数据库慢日志 top 20。持续变慢的查询通常是数据量增长导致的索引失效。 6. 资源趋势：CPU、内存、连接池的趋势曲线。看趋势而不是瞬时值，能提前发现容量问题。 7. 证书有效期：内网系统的证书也别忘了。过期导致的故障往往在半夜爆发。 8. 账号权限：离职人员的账号、长期未登录的账号、权限异常高的账号。
三、每月做 9. 恢复演练：从备份恢复一次到测试环境，确认能恢复、数据完整。没验证过的备份等于没有备份。 10. 依赖清单更新：系统依赖的第三方服务、库、证书，哪些即将过期或停止支持。
几个容易忽略的点
- 时间同步。多服务器环境下时钟漂移会导致日志难以关联、定时任务错乱、证书校验失败。统一 NTP。
- 日志轮转。日志不轮转会把磁盘写满；轮转策略太激进会丢掉排查需要的历史。按重要性和量级分别设置。
- 连接池泄漏。表现为运行一段时间后连接耗尽，重启恢复。监控连接池使用率的趋势比监控瞬时值有效。
- 定时任务的执行情况。定时任务失败了通常没人知道，因为没人等它的结果。要给任务加结果通知。
告警设计的原则
- 告警要可行动。收到告警就知道该做什么，否则就是噪音。
- 分级。短信/电话只给需要立刻处理的，其余走群消息或邮件。
- 设置恢复通知。很多团队只在故障时告警，恢复后没有通知，导致不确定要不要继续处理。
- 定期清理无效告警。长期没人处理的告警等于没有，要么修要么删。
文档比工具重要 把每个系统的负责人、部署位置、依赖关系、常见故障的处理步骤写下来。这份文档在半夜出故障时的价值，超过任何监控工具。工具会告诉你哪里坏了，文档告诉你怎么修。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。