1.1. 当你发现数据出了故障，并且了解到它的初步影响时，下一步（有时甚至在根因分析之前）就是要解决这个问题，并且和利益相关方沟通，协商接下来该怎么做

1.2. 在事故解决后，无论是通过修改代码、数据或者运行环境中的哪种方式，数据团队都应该与受到影响的各方及时沟通，并在接下来的几天安排一场复盘

2.1. 复盘是指一场会议，这场会议要总结这次数据事件的关键信息、事件序列、相关各方人员、有关技术以及其他的重要事实，并用文档记录下来

2.2. 复盘不仅要谈论事件造成的影响和结果，更要把发生的事情都记载下来，这样才可以采取积极的措施来避免类似事故的再次发生

2.3. 对于每个事件来说，出错的是系统，而不是写代码的人

2.3.1. 好的系统应该能够容许人的失误

2.3.2. 系统的本职工作就是允许你犯错误

2.4. 数据管道应当可以容错，其中应该存在流程和框架来应对数据管道中那些“已知的未知”和“未知的未知”

2.5. 无论数据事件是哪种类型的或者是由哪种原因导致的，数据工程团队都应该在解决问题并进行根因分析后进行一场跨领域的全面复盘

2.6. 最佳实践

2.6.1. 将一切当作一次学习经历

2.6.1.1. 复盘分析必须不做任何指责才能有建设性

2.6.2. 利用这次机会，评估应对未来事件的能力

2.6.2.1. 执行脚本是详细描述如何执行一个共同的任务或流程的文本，被DevOps和IT团队广泛使用

2.6.3. 记录每一次复盘，并与更大范围内的数据团队分享

2.6.3.1. 对出了什么问题、系统是如何被影响的，以及问题的根本原因进行文档记录常常是不被重视的一项工作

2.6.3.2. 文档记录与事件管理中的其他步骤同样重要，因为它可以把数据工程师的个人经验总结下来并变成整个团队的经验

2.6.4. 修订SLA

2.6.4.1. SLA是许多公司用来界定供应商、产品或内部团队所提供的服务级别的一种方法，同时也规定了当服务不达标时的补救方案

2.6.4.2. 6个月前合理的SLA现在未必依然合理，你的团队需要率先了解到这些需要的改动，并且和下游客户进行沟通

2.7. 事后复盘对于数据团队和软件工程师团队来说都很重要

2.7.1. 随着我们在该领域不断进步，对数据宕机发生的方式和原因不断加深了解是我们持续改进系统和流程的弹性的唯一途径

3.1. 测试只能触及数据质量问题中“已知的未知”部分

3.1.1. 这个流程中“被动应对”的阶段

3.2. 预防则是“积极主动”的阶段

3.3. 建立事件管理的标准程序

3.3.1. 很多时候，数据工程师的职责不仅包括修复数据问题，还包括确定修复内容的优先级顺序，如何进行修复，以及随事件进展及时沟通情况

3.3.2. 数据团队应当轮流承担事件指挥官的职责，比如每周或者每天轮换，或者根据不同职能团队所负责的具体数据集来分配

3.3.3. 建立一个良好、可重复的事件管理机制（来明确指定事件指挥官）是一个文化建设的过程，但致力于自动化流程以及对数据健康的持续检查，可以让你受益深远

3.3.4. 不断学习并积累经验了

3.3.5. 关键步骤

3.3.5.1. 通知适当的团队成员

3.3.5.1.1. 团队成员分散在不同的业务部门中，而不同领域的数据团队成员则为利益相关方分门别类地处理数据事件

3.3.5.1.2. 中心化的数据团队直接向首席数据官或数据总监汇报，并且同时处理不同业务部门的数据查询和事件

3.3.5.2. 评估事件的严重性

3.3.5.2.1. 在数据管道的所有者得知数据出现问题后，第一步就是评估该事件的严重性

3.3.5.2.2. 当你的数据团队开始处理事件时，最好可以对事件的状态进行标记，比如是否已经修复、是否在计划内、是否在调查中、无须行动，或者是假阳性警报

3.3.5.2.3. 对状态进行标记可以帮助用户评估事件的严重性，并且可以在与该数据的利益相关方沟通进展的过程中发挥重要作用，这样可以帮助他们根据数据受损的情况采取适当的行动

3.3.5.2.4. 利用数据沿袭的可视化工具来理解数据是如何服务于业务需求的，从而找出最重要的数据集

3.3.5.2.5. 当你的数据团队能够分析出事件是否影响到了关键数据，那么它就能更好地了解数据宕机的严重程度

3.3.5.3. 尽可能频繁地通报事件状态的更新

3.3.5.3.1. 在响应数据事件的繁忙工作中，良好的沟通可以使你受益良多

3.3.5.3.2. 要采用对你团队的结构、资源和优先事项来说最合适的方案

3.3.5.3.2.1. 指定一名团队成员在某一时间段内值班，并负责处理其间发生的任何事件

3.3.5.3.2.1.1. 值班人员会负责处理所有类型的数据事件

3.3.5.3.2.1.2. 有些团队会指定一个人来全职负责该团队中所有事件的处理

3.3.5.3.2.1.3. 其他团队则会设立一个值班表，每周指定一名团队成员来值班

>   3.3.5.3.2.2. 团队成员各自负责某些数据表

3.3.5.3.2.2.1. 团队成员会在进行日常工作的同时，处理各自所负责的数据表或报告中出现的问题

3.3.5.3.2.2.2. 一名团队成员负责的数据表通常与他最熟悉的数据和管道相一致

3.3.5.4. 定义并与数据的SLO和SLI达成一致，以避免未来的数据事件和数据宕机

3.3.5.4.1. 事件指挥官并不负责制定SLO，但是他们通常负责满足这些SLO

3.3.5.4.2. SLO是很多公司常用的一种界定供应商、产品或内部团队所提供的服务级别的一种方法，同时也规定了当服务不达标时的补救方案

3.3.5.4.3. 作为对SLA的量化度量标准，SLI的制定取决于具体的用例，但也有一些常用的指标，用来量化分析事件响应与数据质量

3.3.5.4.3.1. 在某一数据资产中的数据事件的数量

3.3.5.4.3.2. 检测所需时间

3.3.5.4.3.2.1. 当事故发生时，该指标可以量化数据团队收到警报的速度

>   3.3.5.4.3.3. 解决所需时间

3.3.5.4.3.3.1. 在你的团队收到关于事故的警报后，该指标可以度量解决事故的速度

3.3.5.4.3.3.2. 努力减少TTD和TTR，从而构建更可靠的数据系统

3.4. 数据事件指挥官

3.4.1. 时间是应对数据事件的关键

3.4.1.1. 对于事件指挥官来说，时间既是敌人，也是朋友

3.4.1.2. 企业都希望数据事故可以尽快解决

3.4.2. 一名事件指挥官可以充分使用合理的流程、借助一些自动化措施、调动企业内部的合作，从而有效地为数据管道的可靠性提供保障

4.1. 确保事件管理能覆盖整个数据生命周期

4.1.1. 数据可观测性对于监控和保障数据仓库中的数据质量是至关重要的

4.2. 事件管理要包含噪声抑制

4.2.1. 对实现数据监控和异常检测来说，数据中的噪声是个大问题

4.2.2. 用信噪比来评价一个警报系统的可运行性，并努力把信噪比降到最低

4.3. 将数据资产和数据事件分组，智能化地路由警报

4.3.1. 数据可观测性是任何数据事件管理步骤（包括事故响应和升级）发生前必须进行的一步

4.3.2. “我的数据没有更新”与异常的趋势或指标是完全不同的问题

4.3.3. 如果数据问题随着时间的变化而存在，数据团队应当及时认识到这样的问题

4.3.4. 警报信息会被传递给商业智能团队，让其也能监控并根据需要采取行动