系统出问题之后，操作日志审计能回答到什么程度

系统出了问题回头去翻日志——这个动作几乎是不用过脑子的。但日志究竟能回答什么、回答不了什么很多团队是在真出事的那一天才头一次认真想这个问题。这件事的边界值得先摆出来。日志是一份事实记录它记下了某个动作在某时某刻被某个账号触发过。它不解释动机也不判断对错。把日志当成万能的证据和把它当成可有可无的装饰是两种都容易吃亏的态度。下面按四层说哪类问题它定位得了、它能回答的四问、它答不上来的部分以及出问题时的查法和平时有什么不同。一、先分清问题类型再打开日志出问题之后需要先做的不是翻记录而是判断这是哪一类问题。分类不同日志的作用差别很大。配置类的问题日志的定位能力比较强。比如某个账号的权限被调整过、某个开关被切换、某次导出被触发、某个定时任务被改过执行时间——这些都会留下明确的动作记录。顺着时间点往回找通常能定位到是哪一步动的、由谁动的。数据类的问题就不一样了。某条记录的内容和昨天不同日志能说明它被修改过却说明不了这次修改是否符合业务规则。规则对不对要由了解业务的人来判断。日志提供事实判断落在人身上。这条分界如果一开始不清楚很容易把日志当成裁决工具用了几次之后发现它只能证明动作发生过——然后开始怀疑它没用。问题不在日志在预期设错了位置。二、它能回答的四问把日志的字段摊开能回答的问题大致是四个谁、什么时候、动了哪里、结果怎样。问题对应字段能答到的粒度谁发起账号到账号级含来源地址什么时候时间戳到秒级含时区动了什么目标记录与动作类型到动作级含变更前后值结果如何执行状态与失败原因到结果级失败项可定位原因这四问凑齐一条日志才算完整。缺任何一项它都会退化成一条孤立的时间戳——知道有事发生过判断不了这件事意味着什么。有一个细节值得单独说变更前后值这一列是很多日志里没有的。没有它只能知道某条记录被改过不知道改成了什么。对追溯来说这一列的缺失往往比时间戳不准更麻烦。三、它答不上来的部分把边界画出来比把能力说满更有用。答不上来的大致有三处。一是意图。同一条修改记录可能是误操作也可能是正常调整两者在日志里长得一模一样。只有当事人或者上下文能解释。二是业务正确性。动作合法、结果正确本来是两件事。日志能证明某次操作在权限范围内执行成功证明不了它符不符合当时业务上该有的做法。三是系统之外的环节。数据导出去之后存到了哪里、被谁看过、后续怎么流转日志的射程到导出发生的那一刻为止。这一段只能靠管理制度去补技术侧能做的是把导出的时间、范围、发起人固定下来。四、出问题时的查法和平时不一样平时看日志看的是覆盖面和连续性出问题的时候看日志看的是时间轴。两者的看法不同。一种用得比较多的做法是从结果倒着推先确定什么时候开始不对再往前一段一段缩小范围找到那个转折点。另一种是把同一时间窗里的动作排成一列看两个动作之间有没有异常的先后关系——比如某次配置调整紧跟着一次登录失败。还有一种情况要提前有心理准备日志里可能没有答案。记录断档、粒度不够、保留周期已过这几种都会让追溯停在半路。真到那一步能做的就是把结论记下来并且说清是哪里断的。五、把射程写进验收记录上面这些边界落到交付环节其实是一句话的事把这套操作日志审计的覆盖范围与保留周期写进验收记录。覆盖范围要说清哪些动作会被记、哪些不会被记保留周期要说清记录能回溯多久、到期怎么处理。这两项都是交付时能当面确认的事实不必等到出问题再来验证。鲲极鲲鹏的鲲在交付环节会把这两项写进验收清单。原因也很简单它的价值只在需要回头查的那一次显现平时看不出来而平时看不出来的东西容易被漏掉。配套的还有几处。在独立部署的环境里日志文件与业务库都在自己手上保留策略可以自己定代价是这部分责任也一起落到了使用方身上。数据导出权限管控要单独成项——能看见某批数据和能把它整批搬走本来是两回事合在一个开关里后者就顺手被前者默认带上了。手机号脱敏落在展示层也是能一行一行对过去的事实。团队权限管控里的角色调整、工单流转的状态变更也都落在同一套记录体系里。六、小结回到开头那个动作出问题之后回头翻日志这个习惯本身没有问题。真正需要提前想清楚的是它能回答到哪一步。日志能回答什么比它能记多少更有用。本文为自建环境下的运维技术分享不涉及产品选型建议。