读数据质量管理：数据可靠性与数据质量问题办理之道12应对与缓解 ...

1. 办理

1.1. 当你发现数据出了故障，并且相识到它的初步影响时，下一步（有时甚至在根因分析之前）就是要办理这个问题，并且和长处相关方沟通，协商接下来该怎么做
1.2. 在变乱办理后，无论是通过修改代码、数据或者运行环境中的哪种方式，数据团队都应该与受到影响的各方实时沟通，并在接下来的几天安排一场复盘
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. 变乱应对与缓解策略

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. 通知适当的团队成员
  

1. >  3.3.5.1.1. 团队成员分散在不同的业务部门中，而不同领域的数据团队成员则为利益相关方分门别类地处理数据事件
3. >  3.3.5.1.2. 中心化的数据团队直接向首席数据官或数据总监汇报，并且同时处理不同业务部门的数据查询和事件

复制代码

• 3.3.5.2. 评估变乱的严峻性
  

1. >  3.3.5.2.1. 在数据管道的所有者得知数据出现问题后，第一步就是评估该事件的严重性
3. >  3.3.5.2.2. 当你的数据团队开始处理事件时，最好可以对事件的状态进行标记，比如是否已经修复、是否在计划内、是否在调查中、无须行动，或者是假阳性警报
5. >  3.3.5.2.3. 对状态进行标记可以帮助用户评估事件的严重性，并且可以在与该数据的利益相关方沟通进展的过程中发挥重要作用，这样可以帮助他们根据数据受损的情况采取适当的行动
7. >  3.3.5.2.4. 利用数据沿袭的可视化工具来理解数据是如何服务于业务需求的，从而找出最重要的数据集
9. >  3.3.5.2.5. 当你的数据团队能够分析出事件是否影响到了关键数据，那么它就能更好地了解数据宕机的严重程度

复制代码

• 3.3.5.3. 尽大概频繁地通报变乱状态的更新
  

1. >  3.3.5.3.1. 在响应数据事件的繁忙工作中，良好的沟通可以使你受益良多
3. >  3.3.5.3.2. 要采用对你团队的结构、资源和优先事项来说最合适的方案
5.   >   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. 其他团队则会设立一个值班表，每周指定一名团队成员来值班

1.   >   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达成划一，以避免未来的数据变乱和数据宕机
  

1. >  3.3.5.4.1. 事件指挥官并不负责制定SLO，但是他们通常负责满足这些SLO
3. >  3.3.5.4.2. SLO是很多公司常用的一种界定供应商、产品或内部团队所提供的服务级别的一种方法，同时也规定了当服务不达标时的补救方案
5. >  3.3.5.4.3. 作为对SLA的量化度量标准，SLI的制定取决于具体的用例，但也有一些常用的指标，用来量化分析事件响应与数据质量
7.   >   3.3.5.4.3.1. 在某一数据资产中的数据事件的数量
9.   >   3.3.5.4.3.2. 检测所需时间

复制代码

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

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. 使用DevOps的最佳实践来规模化数据变乱管理

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. 警报信息会被传递给商业智能团队，让其也能监控并根据需要采取行动
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。