什么是数据事故指挥官?

事故管理不只是软件工程师的工作. 随着…的兴起 数据平台 以及数据即产品的思维方式,建立更可靠的流程和工作流程来处理 数据质量 已经成为数据工程师最关心的问题. 

In a 以前的文章, we discussed how to set up automatic detection and alerting for bad data; now, guest author 格伦·威利斯 在数据事件指挥官这一新兴角色的帮助下,分享最好的数据团队如何处理破碎数据管道的分流和严重程度评估. 

现在是周一早上,你的手机一直响个不停. 

当你醒来时,你会发现你的首席执行官在说:“这份报告中的数字似乎又不对了。.” 

你和你的团队放下手头的工作,开始解决手头的问题. 然而,你们团队对这一事件的反应是一团糟. 组织中的其他团队成员正在重复努力, 你的首席营销官被蒙在蒙里,公司的其他部门也没有收到任何更新.

当这一切发生的时候, 财务部的约翰给你发短信,说他的电子表格有一个错误的表格, 和运营部的埃莉诺关于一个调查 有趣的 结果.

数据工程师应该做什么? 

如果这种情况听起来很熟悉,知道你不是一个人. 经常, 数据工程师不仅要承担修复数据问题的重任, 而是优先解决问题, 如何修复, 随着事件的发展,沟通状态. 对许多公司, 数据团队的职责通常是模糊的, 特别是当涉及到回答以下问题时: "谁在处理这一事件?”  

肯定的是, 数据可靠性sla 应该由整个团队来管理吗, 但当橡胶碰到路面时, 推荐一个正规滚球网站需要一个专门的角色来帮助发号施令,并确保这些sla在数据泄露时得到满足.

在软件工程中,这个角色通常定义为 事故指挥官, 其核心职责包括: 

  • 尽早且经常地将事件通知更广泛的数据团队和利益相关者.
  • 维护受影响的数据资产或异常的工作记录.
  • 为某一特定事件协调努力并分配责任.
  • 必要时分发运行手册和剧本.
  • 评估事件的严重程度和影响.

数据小组应每周或每天轮流指派事件指挥官, 或者特定功能团队拥有的特定数据集. 建立一个良好的, 可重复的事件管理实践(委派明确的事件指挥官)主要是一个文化过程, 但是,投资于自动化和保持数据健康的持续脉搏会让你在很大程度上实现这一目标. 剩下的是教育. 

以下是每个事故管理人员在对数据问题进行分类和评估时必须采取的四个关键步骤:  

1. 将通知路由到适当的团队成员

在一个分散的数据团队中, 团队成员分散在不同的业务单元,每个领域的数据团队成员负责为其涉众处理事件. 在这个结构, 数据团队成员通常向业务部门主管报告,有时也向CDO或数据主管报告. 图片由蒙特卡罗提供.


一个集中的数据团队直接向CDO或数据主管报告,同时对来自不同业务单位的数据的查询和事件进行处理.  除非另有说明,一些业务单位是他们的利益相关者. 图片由蒙特卡罗提供.

当响应数据事件时, 数据组织的结构方式将影响事件管理工作流程, 结果就是, 事件指挥官流程.

如果你是一个嵌入式数据团队的成员,那么委派事件响应(i.e.,营销数据和分析团队拥有所有的营销分析渠道). 如果你在一个中央数据团队工作, Fielding和路由这些事件警报到适当的所有者需要更多的远见和计划.

无论哪种方式, 推荐一个正规滚球网站建议您为数据团队的特定成员拥有和维护的数据管道建立专门的Slack通道, 邀请相关的利益相关者,让他们知道他们依赖的关键数据是否减少. 许多与推荐一个正规滚球网站合作的团队都已成立 PagerDuty 或Opsgenie的工作流程,以确保没有遗留的基地. 

作为一名数据事件指挥官, 正确地发送通知,并在错误蔓延到下游之前迅速地将其呈现给正确的人是非常重要的. 图片由蒙特卡罗提供.

2. 评估事件的严重性

获得上述通知可以让您和您的团队评估事件的严重性,并决定是否应该优先响应事件. 图片由蒙特卡罗提供.

一旦通知管道所有者数据有问题, 他们应该采取的第一步是评估事件的严重程度. 因为数据生态系统在不断演变, 在任何给定的时间,您的数据管道中都可以引入大量的更改. 虽然有些是无害的.e.例如,预期的模式变更),有些是致命的,对下游涉众造成影响(i.e.,临界表中的行数从10,000下降到1,000). 

一旦您的团队开始排除问题, 最佳实践是根据问题的状态对其进行标记, 是否固定, 预期, 调查, 不需要行动, 或假阳性. 标记问题可以帮助用户评估事件的严重程度,并在通过特定于受影响数据的渠道向相关涉众传达更新信息方面发挥关键作用,以便他们能够采取适当的行动. 

如果一个对您的公司并不重要的数据资产崩溃了怎么办? 事实上,如果该数据已被弃用了怎么办? 

即使是最优秀的数据团队,也会受到虚幻数据的困扰, 我都不知道有多少次我收到了数据问题的警告, 在所有的事件之后,解决方案都说了,也做了, 这对公司来说并不重要. So, 而不是处理高优先级的问题, 我花了几个小时甚至几天的时间处理那些坏掉的数据,结果却发现自己在浪费时间. 自2019年以来,推荐一个正规滚球网站没有使用过这张表.

就像在软件工程和DevOps中, 端到端沿袭映射关键数据依赖关系是数据事件指挥官工具包的一个关键组件. 图片由蒙特卡罗提供.

那么,如何确定哪些数据对您的组织最重要? 团队发现他们最关键的数据集的一种越来越常见的方法是利用工具,帮助他们可视化数据集的传承. 这使得他们能够在事件发生时看到所有的数据集是如何相关的, 并且能够追踪数据所有权,以提醒可能受到该问题影响的正确人员.

一旦你的团队能够弄清楚影响的严重性, 他们将更好地理解错误的优先级是什么. 如果是数据直接推动了财务洞察力, 或者甚至是你的产品表现得有多好, 这可能是一个超高优先级的问题,你的团队应该停止他们正在做的事情,尽快修复它. 如果不是,那就该向前看了.

3. 尽可能频繁地沟通状态更新

在响应数据事件时,为事件响应工作组的所有成员提供一个关于给定事件的中央状态页面将起到关键作用. 图片由蒙特卡罗提供.

在响应数据事件的热潮中,良好的沟通大有帮助, 这就是为什么推荐一个正规滚球网站已经讨论了数据团队应该如何以及为什么应该这样做 创建一个runbook 这一步一步地介绍了如何处理给定类型的事件. 遵循运行手册对于维护正确的职责线和减少重复工作是至关重要的.

一旦你知道了“谁做了什么”, 然后,您的团队可以开始更新状态页面,涉众可以在其中跟踪实时更新. 中央状态页面还允许团队成员查看其他人正在进行的工作以及这些事件的当前状态. 

在与客户的交谈中,我看到事故指挥代表团的处理方式有两种:

  1. 指派一名团队成员在给定的时间内随时待命处理任何事件: 在随叫随到时,该人员负责处理所有类型的数据事件. 有些团队会有专职人员负责他们团队管理的所有事件, 而其他公司则制定了每周轮换团队成员的时间表. 
  2. 负责覆盖某些桌子的团队成员: 这是推荐一个正规滚球网站看到的最常见的结构. 这个结构, 团队成员在进行日常活动的同时处理与他们所分配的表格或报告相关的所有事件. 表的分配通常是基于给定成员最密切使用的数据或管道进行的. 

要记住的一件重要的事情是,这里没有对错之分. 最终,这只是确保你承诺并坚持一个过程的问题. 

4. 定义和调整数据sla和sli,以防止未来的事故和停机 

而事件指挥官并不负责 设置sla在美国,他们通常要负责与他们会面. 

简单地说, 服务水平协议(sla)是许多公司用来定义和度量给定供应商的服务水平的方法, 产品, 或者内部团队会交付——如果他们未能交付,也会提供潜在的补救措施.

例如, 松弛的面向客户的SLA 99年承诺.每个财政季度99%的正常运行时间, 停机时间不超过10小时, 适用于Plus计划及以上的客户. 如果金额不足,受影响的客户将获得其账户上的服务信用,以备将来使用.

您的服务水平指标, 你的sla的定量测量, 将取决于您的具体用例, 但以下是一些用于量化事件响应和数据质量的指标:

  • 特定数据资产的数据事件数(N):尽管这可能超出你的控制, 假设您可能依赖于外部数据源, 它仍然是数据停机的重要驱动因素,通常值得衡量.
  • Time-to-detection(运输大亨): 当出现问题时,这个指标将量化您的团队收到警报的速度. 如果您没有适当的检测和警报方法, 这可以用几周甚至几个月的时间来衡量. 由错误数据造成的“无声错误”可能导致昂贵的决策, 对你的公司和你的客户都有影响.
  • 解决问题的时间(竞技场队伍): 当您的团队收到问题的警报时,这将度量您能够多快地解决该问题.

通过记录这些, 数据团队可以努力减少TTD和TTR, ,反过来, 建立更可靠的数据系统. 

为什么数据事件指挥官很重要

当涉及到对数据事件的响应时, 时间至关重要, 作为事件指挥官, 时间既是你的敌人,也是你最好的朋友.

在理想的情况下,公司希望数据问题能够尽快得到解决. 然而, 但情况并非总是如此,一些团队经常发现自己调查数据问题的频率超过了预期. 事实上,虽然数据团队投入了大量的时间编写和更新 自定义数据测试在美国,他们仍然会遇到管道破裂的情况. 

一个事件指挥官, 拥有正确的流程, 少量自动化, 和组织支持, 是否可以为您的数据管道的可靠性创造奇迹.

你的CEO以后会感谢你的.

有兴趣了解更多关于使用蒙特卡罗为您的数据管道建立一个健壮的事件管理流程的信息? 联系格伦,然后 推荐一个正规滚球网站团队的其他成员!