任务调度产品经理如何备战618?

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

编辑导读:618作为一年中最重要的两个促销活动之一,会涉及到各个部门各个系统。而作为一名任务调度产品经理,要如何开展工作,为618保驾护航?本文作者对此进行了分析,与你分享。

任务调度产品经理如何备战618?

618是电商的大日子,各路人马各显神通。作为中台系统的小伙伴儿们,在“见不得人的中后台”各种忙活。我们揭开它的神秘面纱,探究这群“地下”工作者们,是如何为618保驾护航的,如何让那千万台冷冰冰的服务器协作起来、支撑PB级的数据运转,保障百亿级订单,千亿级别的GMV的达成……

故事,从大数据平台的核心环节“调度平台”说起,任务调度是大数据平台离线计算的重量级产品,它既承载了各类数据库与数据集市间的同步工作,还承载了各类的离线数据计算工作。主要的应用场景是数据的管理、搬运、计算、存储。

任务调度产品经理如何备战618?

目前任务调度支持多种任务类型,包括:普通任务、数据计算(py/sh/zip)、数据入库任务、数据出库任务、数据拉链任务、数据同步(JDW到Jmart)。

  • 数据计算(py/sh/zip):调度可以支持python、shell、jar等多种脚本类型,提供强大的计算能力可定时功能支持数据的分析运算。
  • 入库任务:目前任务调度支持从MySQL、HBase、ElasticSearch、Oracle、mongodb、SQLServer、log、phoenix多种数据源抽取数据到数据仓库的bdm层。
  • 出库任务:支持从Hive推送到包括MySQL、jss、HBase、Oracle、jinggo、postgresql、ElasticSearch、jimdb、phoenix等多种数据库。
  • 数据拉链任务:支持将bdm层的流水表,加工成fdm层的拉链表。
  • 数据同步(JDW到Jmart):支持将数据从数据仓库,同步到数据集市。

通过任务调度系统,可以方便快捷的管理定时任务,支持任务间建立依赖关系,任务的快速补数和重跑,以及强大的监控功能,提供良好的作业管理服务。

任务调度以强大的技术能力保障618的各种任务、那么作为调度的产品经理如何保障618呢?

一、事前:制定大促保障策略&宣贯、执行资源倾斜

准备工作一:制定任务等级划分规范、分等级保障机制和管控规范

将任务等级划分为:0级、1级、2级、3级。0级:公司核心业务,数据面向对象为外部客户或内部VP、一级部门领导及以上。一旦发生不可用会直接影响外部客户合作项目,可能造成P0-P2级事故发生。

  • 1级:数据面向对象为二级部门领导,一旦发生不可用会影响跨一级部门或以上合作项目,可能造成一般事故(P3级)的发生。
  • 2级:数据面向对象为三级部门领导,一旦发生不可用会影响二级部门内部项目。
  • 3级:数据面向对象为三级部门内部,一旦发生不可用会影响三级部门内部项目或个人报表数据。调度平台会根据设置的等级进行资源的分配

  准备工作二:制定调度任务和质量检测的降级策略

制定任务调度的降级策略:

  1. L0、L1提供专属监控,保障任务及时收到告警通知。
  2. 大促期间资源紧张时平台会对L2、L3采取任务延时抽取策略和任务一键推迟策略
  3. 必要时刻为L0、L1任务开启绿色通道保障任务正常运行。
  4. L0、L1任务节点资源优先分配。
  5. 针对任务关键属性的修改以及任务禁用等高风险操作,平台针对不同级别有不同的管控策略。

制定数据质量的降级策略:

  • 质量规则执行时长达到30分钟,会给质量分区负责人、关联调度告警人发送提醒,确认是否做干预;
  • 质量规则执行时长达到60分钟,系统自动终止质量检测,关联调度任务正常执行,本次质量检测失效,并给质量分区负责人、关联调度告警人、质量管理员发送通知。

准备工作三:制定调度任务的封板管理措施(新建、拷贝,禁用、重跑等)

在大促备战期间如果有用户进行任务的创建及拷贝,由于新任务的安全性得不到保证,会存在诸如性能低、资源占用高等风险,影响系统稳定性等问题,针对上述问题产品制定了如下管控措施:禁止新建和拷贝任务,需二级部门负责人审批。

对于新建任务项需要逐一检查,包括:

  1. 关注任务周期为小时、分钟;
  2. 评估任务对系统的影响;
  3. 检查出库任务SQL的where条件;
  4. 建议用户配置任务监控及超时时间。

对于拷贝的任务建议转为新建任务,按照新建任务进行检验。如果没有转换要确认一下几项:

  1. 确认原任务的近一周执行情况,如运行异常,沟通具体原因;
  2. 确认新任务与原任务的逻辑差别,包括SQL、参数等;
  3. 确认所属应用、负责人、集市、队列、账号与申请单填写的信息一致;
  4. 任务描述包含“通过流程申请拷贝,申请单ID及原任务ID”;
  5. 运行规则配置属性检验:周期类型、运行时间与申请单一致。超时时间必填,需沟通确认。最大并发实例数选择为10以内。
  6. 与用户确认节点编号;
  7. cgroup配置与用户核实,避免资源不够被kill或执行慢;出库任务,建议对于内存在推荐值上上浮1G;
  8. 任务监控,推荐配置。对于启用任务、修改任务运行规则、修改抽数sql、模型变更、修改任务属性等操作,均有可能对系统的稳定性造成影响,需要二级负责人进行审批,停止接口的申请、任务调度3.5升级,其他任务非大促相关接入申请不再审批。对于数据质量服务异常导致无法校验数据是否符合要求时,对服务进行降级。

准备工作四:保障策略宣贯

按天发送调度任务等级划分策略宣贯邮件。2.用户视频培训,主要针对离线平台、常用场景、监控告警配置、调优策略、大促保障五个方面为用户做介绍。保证用户在大促期间充分了解调度保障策略。

准备工作五:资源倾斜,保障重点业务

产品经理推进用户去评估任务的等级,并进行变更,对L0、L1的任务必须要配置告警和质量;对于核心业务, 数据质量检测时长超过5分钟,需配置超时策略,避免影响SLA;对于管控和保障大促稳定性的措施,产品经理对产品功能做相应的设计、跟进落地上线。做好大促保障的每一环。

二、事中:启用保障策略

1)严格执行封版管控措施

虽然在5月25号任务调度平台会进行封版的管控,但期间仍有特殊场景或业务进行任务的新建和修改,此时需要二级部门负责人进行审批。比如,在大促期间一个部门要批量禁用所有任务,此时产品经理就要考虑几个问题:

  1. 是禁用一次还是大促期间多次启用禁用?
  2. 是否所有任务都归属于这个部门?
  3. 禁用所有任务都价值?
  4. 会产生哪些不利的影响?
  5. 操作完成所需的时间?
  6. 任务的生效时间和失效时间。

这些都是产品经理需要在研发之前把控的信息。这些信息需要业务方提供,由产品经理来衡量是否可以提供封版期间禁用任务的白名单权限。一般这种批量禁用任务的情况都是业务方为了保证高级别任务的稳定。所以产品应该做好把控,做到灵活应对,即不影响业务稳定,又快速解决业务面临的问题。

2)优先保障高级别任务平稳运行

同一队列中运行的多种级别任务会争抢资源,如果在线上核心数据出现问题需快速恢复、大促活动产生极大数据量等应急场景下,需优先保障高级别任务平稳运行。这时需要启动一键推迟功能,下面介绍一下一键推迟功能:

  1. 点击“推迟”,导入需推迟的任务id,填写推迟时长及自动恢复时间;
  2. 发起审批流程,审批通过后,这些任务推迟成功,系统发邮件给当前任务及下一层任务的负责人;
  3. 在推迟后,还未恢复前,可”继续推迟“,点击继续推迟,也要发起审批,审批通过后,继续推迟任务成功,系统发邮件给当前任务及下一层任务的负责人;
  4. 到达自动恢复时间后,推迟的任务自动恢复到原始的计划执行时间,5.如果还未到达自动恢复时间时,也可以点击”恢复“,任务提前恢复到原始的计划执行时间。

3)值班保障

针对任务调度的保障策略和大促期间的紧急事项如果用户有疑问,提供交流群群答疑并且每日安排固定的值班人员进行答疑。对于用户的咨询做到及时回复,让用户充分了解任务调度的保障策略

在618期间,产品经理会在11点就开始坚守在电脑前,目不转睛的各自盯住显示器,一旦某台机器、某个业务、某条链路出现一点点的波动,他们都能第一时间看到,流量上涨、积压、抖动,出现问题及时跟进,推动解决,及时报备问题。

三、事后:复盘、总结

因为调度平台上跑着很多离线任务,所以到6月19号的凌晨才会解除平台的封版,大促结束之后要对出现的问题进行复盘、总结、归档。

  1. 明确备战的节奏:首先明确公司整体的备战节奏,跟随大节奏进行压测、故障预演、灾备演练;
  2. 建立良好的沟通机制:提前与业务进行沟通,收集业务需求和业务等级有无变更情况。做到及时响应灵活应变。
  3. 提前预估业务峰值情况:搜集每年大促业务的峰值情况,进行数据对比,做回归分析,预测业务今年的情况,可以做到合理利用资源。
  4. 制定更完善的管控策略:从用户的应用场景出发,预想到每个场景会遇到的问题及风险,比如创建任务、拷贝任务、任务启用、实例重跑、修改任务运行规则等。

对于电商来说618意义非凡,虽然作为偏底层的产品经理,离618业务较远,但是也在用行动保障大促平滑稳定。

 

本文由 @斗罗魂灵 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!

随意打赏

提交建议
微信扫一扫,分享给好友吧。