1.1. 为关键的数据管道制定一个事件管理计划

1.2. 使用异常检测作为大规模事件检测方案的一部分

1.3. 在事件发生时，进行全面的根因分析与影响分析

1.4. 通过测试、持续集成/持续部署、数据可观测性与更多的数据来积极主动地应对数据质量问题

1.5. 暂停数据管道、找到问题根源都只是恢复数据可靠性并继续信任数据的冰山一角

2.1. 无论是单独的数据管道系统，还是大型的数据系统，此类“数据宕机”问题的解决方案都已经存在

2.2. DevOps生命周期

2.2.1. 计划

2.2.1.1. 研发团队与产品和商业团队协作，从而了解软件的目标与SLA

2.2.2. 编码

2.2.2.1. 编写软件的代码

2.2.3. 构建

2.2.3.1. 将软件发布到一个测试环境中

2.2.4. 测试

2.2.4.1. 对软件进行测试

2.2.5. 发布

2.2.5.1. 将软件发布为产品

2.2.6. 部署

2.2.6.1. 将软件与现有应用程序共同集成和部署

2.2.7. 运维

2.2.7.1. 运行该软件，并根据需要进行调整

2.2.8. 监控

2.2.8.1. 监控软件的运行状况，并对问题发出警报

2.2.9. 不断循环往复的

2.3. DevOps生命周期的循环反馈流程

2.3.1. 帮助团队可靠地实现大规模交付与业务目标相一致的功能

2.3.2. 我们往往倾向于被动地处理数据质量问题，因此在数据分析方面还没有以有意义且可扩展的方式来推动应用这套反馈流程

2.4. 有效的事件管理是在软件故障发生时减少混乱、尽快恢复正常业务运行的关键

2.4.1. 如果你没有提前计划好应对潜在事件的措施，那么在面对复杂的真实问题时，套路化的事件解决方案可能根本不管用

2.5. 事件管理就是要对可能出现在日常工程流程中的问题进行鉴别、溯源、解决、分析和预防

3.1. 当数据系统越来越多地采用分布式架构，且企业摄取的数据规模越来越庞大时，出现错误（和事件）的概率也必然增加

3.2. 数据可靠性生命周期

3.2.1. 通过将数据可靠性生命周期应用于数据管道，数据工程师团队可以把检测、解决甚至提前预防数据质量问题的步骤更加无缝地衔接起来，从而确保数据质量问题不会影响到业务运营

3.3. 关键步骤

3.3.1. 事件检测

3.3.2. 响应

3.3.3. 根因分析

3.3.4. 解决

3.3.5. （不做指责的）复盘

4.1. 将事件检测和数据工程与分析的工作流程结合起来，从而确保当故障发生时，数据的拥有者与终端用户都能通过合适的沟通渠道得到通知

4.2. 在数据进入生产环境之前就进行测试

4.3. 当数据管道被损坏或者数据仪表板崩溃时，你首先要做的就是进行事件检测

4.4. 事件可以通过数据监控与警报被检测到，这一过程可以手动实现，也可以通过设定阈值来自动实现

4.5. 事件检测也可以作为异常检测或者数据可观测性解决方案的一部分，并根据历史数据模式和定制化规则定期自动触发

4.6. 事件检测的一个重要部分就是异常检测

4.6.1. 高质量的异常检测系统应当能够借助算法的微调来提高信噪比并降低假阳性率，并且在精确率和召回率之间达到平衡

4.7. 数据团队总是倾向于认为仅凭异常检测就足以“解决”事件管理方面的问题

4.7.1. 事件管理问题从来不会被真正“解决”

4.7.2. 仅仅依靠异常检测是一个单点故障

4.7.3. 事件检测应当是一个多层面的过程，不仅包含检测事件，还包括对事件的响应、解决和预防，并且要不断迭代和重复这些步骤

4.8. 异常检测是一种工具，而不是灵丹妙药

4.8.1. 一个希望实现自动化运营的数据团队，假如仅依赖异常检测，而不借助测试、版本管理、可观测性、沿袭等其他的技术工具，那么等待着团队的最好情况就是层出不穷的问题，而最差情况则是挫败感和漫长的数据宕机恢复时间

4.8.2. 不要仅仅依靠异常检测本身来解决数据质量问题，因为“检测到”有一个故障，并不意味着故障就能被立刻“解决”

4.8.3. 仅凭异常检测无法真正构建出可信任、可依靠、透明度高的数据系统，从而满足洞察力驱动型企业的需求

4.9. 当异常检测被端到端（例如跨数据仓库、数据湖、ETL和商业智能工具）实现，而并非仅仅在数据平台的其中一两层实现时，它对业务来说是极具价值的

5.1. 良好的事件响应机制的核心在于有效沟通，好在响应机制的大部分工作可以通过PagerDuty或者Slack等交流工具提前准备并自动完成

5.2. 据团队应当提前为标准的数据事件响应流程编写执行脚本(runbook)和自动化运营手册(playbook)

5.2.1. 执行脚本为你提供了关于如何使用不同服务及其遇到的常见问题的说明

5.2.1.1. 要把故障发生时的角色提前分配好

5.2.2. 自动化运营手册则会提供处理事件的分步流程

5.3. 除了“事件响应人”外，通常还会有一名“事件指挥官”来负责分配工作、整合信息，而事件响应人和其他利益相关方则会一起解决问题

5.4. 在具体的业务情况中，元数据可以作为一种强大的工具来有效判断哪些团队会受到某一数据宕机事件的影响

6.1. 根因分析(Root Cause Aanlysis，RCA)

6.2. 数据事件可能悄无声息地出现在整个数据管道中，并影响数十甚至上百张数据表

6.3. 低数据质量的一个常见原因是新鲜度问题

6.3.1. 数据的版本异常老旧

6.3.2. 背后的原因多种多样

6.3.2.1. 某个程序的作业卡在了计算队列里

6.3.2.2. 计算系统超时

6.3.2.3. 某个合作伙伴没有及时上传数据

6.3.2.4. 软件错误

6.3.2.5. 意外的日程安排变更导致你的程序作业从有向无环图(D A G)里被移除

6.4. 大多数数据问题的根源

6.4.1. 进入程序作业、数据管道或系统的数据发生某种意外的变更

6.4.2. 转换数据的逻辑（ETL、SQL、Spark作业等）发生了变更

6.4.3. 某种事务型故障

6.4.3.1. 计算超时错误

6.4.3.2. 授权问题

6.4.3.3. 数据基础设施故障

6.4.3.4. 日程变更

6.4.4. 快速诊断故障原因需要的不仅仅是合适的工具，更需要对这三类问题为什么以及是如何发生的有全局认知

6.5. 事件的发生往往不是由于单一因素，反而经常是多种因素的共同作用

6.5.1. 要把这些多因素综合的故障当作可贵的学习机会，用于流程优化和技术微调

6.5.2. 在软件（和数据）系统变得越来越复杂的今天，精确诊断某次故障或事件的单一确切原因或根源正变得越发艰

6.5.3. 系统崩溃的原因很少是唯一的

6.6. Amazon的五步法框架

6.6.1. 发现问题

6.6.2. 思考这个问题为什么会发生，并记录其原因

6.6.3. 判别该原因是不是问题的根源

6.6.3.1. 该原因能否被预防？

6.6.3.2. 该原因能否在其发生前提前被检测出来？

6.6.3.3. 如果该原因是人为失误，那么为什么会发生这样的情况？

6.6.4. 继续重复这些步骤，把上面的“原因”迭代成“问题”

6.6.5. 当你确信已经找到问题的根源时，就可以停止了

6.7. 随着数据工程师努力减少手动作业量，他们研发出很多智能流程、测试方法、数据新鲜度检查方法以及其他解决方案用以诊断数据事件，避免它们传播到下游

6.8. 对数据管道进行根因分析的五个步骤

6.8.1. 查看数据沿袭

6.8.1.1. 追溯到系统中出现问题的最上游节点，而那里就是故障最开始发生的地方，你也要去那里寻找答案

6.8.1.2. 最上游节点的数据仪表板就可以提供所有的答案，帮你迅速诊断出问题的根源

6.8.1.3. 要确保参与数据事件解决的所有人（数据工程师、数据分析师、分析工程师、数据科学家等）都能获取最新版本的数据沿袭

6.8.1.4. 数据沿袭应当包含商业智能报告、机器学习模型、反向ETL池等数据产品

6.8.1.5. 自动化字段级别的沿袭常常是数据工程团队的高回报投资选项，因为它能帮助我们简单快速地了解哪些数据资源是损坏的，以及这些损坏的部分是如何影响下游的数据产品和数据仪表板的

6.8.2. 查看代码

6.8.3. 查看数据

6.8.3.1. 查看有异常字段的数据表中的其他字段或许能为你判断数据异常的根源提供线索，这种方法一般比较有用

6.8.3.2. 要确保所有参与解决数据故障的人员都能方便地对数据进行切割和分块，这样才能便捷地分析数据事故与不同的数据段、时间段以及其他数据分段的相关性

6.8.4. 查看运行环境

6.8.4.1. 许多数据事故的直接诱因是运行ETL/ELT数据转换工作的运行环境

6.8.4.2. dbt是处理这些程序运行问题的一个有效的开源工具

6.8.5. 借助你同伴的帮助

6.8.5.1. 你的团队伙伴可以提供有价值的知识或见解，帮你诊断数据中的问题

6.8.5.2. 要确保所有参与解决数据故障的人员都能获取关于数据所有权和使用情况的元数据，这样他们就能知道出了问题可以去向谁提问

6.8.5.3. 保留一份数据事件的历史记录，并记载相关的文档，这也很有帮助

6.8.6. 可以把根因分析从令人焦虑的深夜紧急电话转变成在整个组织中规模化可持续的通用标准流程

6.9. 根因分析在（接近）实时地解决甚至预防数据质量问题上是一个强有力的工具，但是要记得，数据管道的崩溃常常不是某个单一问题导致的