通用工具_高效协作共识与红线

规则制定时充分讨论，规则制定后必须严格、持续执行

个人要求篇

红线：

事不过二：
- 同样问题不犯第二次
- 所有评审和问题讨论，不超过2次
- 部门内信息披露、规则同步，不超过2次
高标准高要求：

数据资产各成员务必维护个人、项目、团队口碑，要求做事可靠、可依赖、有效率，并积极扩大团队的影响力。

主人翁意识：

认真负责是工作的底线，对交付结果负责，对自己负责的项目负责。积极主动是“Owner意识”更高一级的要求：主动出击、主动解决、主动承担。PS：主动找团队负责人沟通项目进展、问题、规范、风险；主动找别人沟通，了解更多更细节的信息。

保持敬畏

对组内规范与约定的敬畏、对用户体验和线上服务的敬畏。

认知迭代
- 善于、勤于提问并定义问题
- 敢于试错
- 持续思考

协作沟通篇

红线：

信息握手机制：
- 事事有回应，被@覆盖到的同学要显式回应，比如点击确认；
- 事项进展主动反馈，不等问，不跨周；
- 协议握手确认（系统之间上下游沟通的参数或code需要明确含义）；
- 团队信息传递需避免指令不行，军情不查，延误战机。指令不行就是系统或团队之间传递信息效率低没有回执，比如通知了切流后因为怕麻烦并没有明确收到对方确认就进行操作，或者是一个通知不说行也不说不行，没有反馈；军情不查指的是可能线上已经出现问题，具体研发同学在那里排查，不进行信息同步与报备，导致别人能帮助的也帮不上，具体什么进展了也不清楚；延误战机指的是系统恢复没有后手，无法最快速度止血，导致线上问题无法第一时间得到恢复；
唯一出入口机制
- 统一口径：如指标服务平台的xxx能力，维度服务支持xxxx等，避免流量数仓他们xxxxx，指标服务他们xxxx，给人一种结论单点，不全面不稳定的印象；对于数据资产，用户对资产的疑问可以通过引导用户提相关主题工单方式解决，避免以不清楚不知道应付用户；
- 不要接私活：口头、零散需求需统一落地且可追溯，不要私下接活；
- 统一拉齐：对接外部团队时，如果涉及团队内部的协作，由对接人负责拉齐具体负责人，避免给外部踢皮球的感觉，对外是整体出口；
会议提效

原则：有目的，聚焦问题不发散，会后总结结论和待办（时间、人物、效果），不要做聊天式开会，会议能线下则线下（主体参会人可线下优先线下）

1）主动的会

提前准备好会议内容，不能空对空纯说；能提前确认和解决的就提前确认和解决；

2）被动的会

被拉的时候主动提出需要“我”在会上做什么，什么时间需要，前置信息是什么，确认自己真的在会里面被需要并且解决问题再参加，否则请拉会方明确这些信息，避免把大家时间浪费在无效沟

通里面，同时如果沟通两次无法达成一致就快速上升，避免无效拉扯；

3）备注：方案讨论时候各自带着自己相对想通了的观点开会，不要临时现聊；而且会议的发起人需要作为讨论逻辑条线的串联者（禁止跳出逻辑条线去讨论，这样可能导致会议时间不可控，会议长期无结论，信息gap填不上等问题），按照既定顺序去讨论方案，既会议提效，又最快拿到要解问题的结论结果；会后要用文字【公开】结论与待办（明确艾特到人），该文字要逻辑清晰描述准确（结果上看可以让与此事有关而没有参与讨论的同学一目了然）；上面这几步，缺一步都会有问题（或早或晚，困难守恒，不会因为绕过而不存在，越早消除成本越低）

外部协作
- 依赖外部：如果是一个链条式的操作如做一个事儿需要A，但是A依赖B，B依赖C（依赖关系可能跨部门），一定要一层层对清楚依赖关系（需要【谁】在【什么时间之前】把【什么事项】做到【什么程度】），对清楚后形成checklist，上述的【谁】（要能做主的人）明确盖戳确认，才能执行。
- 被外部依赖：如果有说xxxx对我们形成“依赖”，要敏感度提升；如果判断这个“依赖”有风险，就不要让这个说是依赖，达不成一致可以上升
- 依赖结论：避免直接抛出“理应我们内部解决的问题”，而是通过明确现状、提供选择、解释原因等方式，将问题转化为确定性信息，体现专业性和解决问题的能力
- - 反例：xxx多难，xxxxx没人之类的，xxx复杂之类的
  - 正例：“前面有8个排期，分别列表xxx，如果优先级不变则第九个预计xxxx哪天看是否业务可接受；或者补充前8个优先级不能调整的原因xxxxx”
原则：态度友好，面向事实，但务必坚守原则，原则问题学会拒绝；
沟通：讨论前各抒己见，确认后坚决执行；防止沟通GAP，细节确认清楚再做保证；确认不清楚的未知风险，需提前预知并上抛；

代码质量篇

公共关注：

设计：使用设计模式，践行设计原则；
重构：持续重构，避免相似功能的另起炉灶；
代码reveiew: 代码改动需要找两个人进行code review，如果改动较大，建议线下约会评审；

服务关注：

MySQL：重点关注ER关系、主键、索引、字段类型；
代码管控：所有线上代码都要基于coding库管理；
单测：单测覆盖率基线60%，增量行覆盖率基线70%，越高越好；
代码：本地安装EOS插件，保持代码洁癖（整洁、易懂、高效）；

系统稳定篇

红线：

上线操作：

上线需具备上线MR、技术方案、reviewer、上线操作checklist、快恢复说明；

系统鲁棒逻辑

服务端问题引入分为三类：变更（也就是上线，70%事故都上线引起，变更包括但不限于配置修改、代码修改、任务调整、数据调整、运维调整等）、过载（c端这种容易过载，但数据服务相比c端流量虽小但是在线计算压力比较大集群混用所以一样可能过载）、强依赖故障（如第三方db和api又可以递归的归结为强依赖变更、强依赖过载，又如同步处理流程中的节点故障，非刚需节点要考虑异步处理），所以链路推演就是依赖变更确认的前提，需详细推演核心链路整个流程，不可点状思考；上线需要做到相关上线人员随时可回滚，包括但不限于代码、DB等，回滚又分为单点回滚和链路回滚；系统按照Fail Fast原则（如超时时间设定，让失败尽快返回不要无效等待直到雪崩）与影响最小化原则（如一批指标中一个失败，则只能影响这一个而不能影响一批）设计容错性；问题追根溯源，遇到一个case要解决一类case，找到根因，确保同类问题不再次发生；

系统稳定性职责意识

按照“谁的系统谁保护”的原则，我如果开放服务允许别人调用，则不允许存在某些请求能够调挂我的系统的情况出现，如果有明确的【允许】或【不允许】的规则，则需要尽早进行参数合法性校验，不允许继续往后流转。

方案可推敲

任何技术方案或者代码动手前，必须知道合理性，随时准备着如果出问题，被拉出来复盘时，我们的方案是当时情况下的最优解；

精简配置：降低用户理解和操作成本，提升用户体验。即使用辅助驾驶代替手动驾驶，同时也要提供给用户可随时转为手动驾驶的能力；
依赖：梳理系统上下游的依赖关系，任何一个被依赖的点变更后都能触达所有依赖方；
日志：配置合理的日志等级、日志清理策略、同步异步配置；
指标服务平台：了解指标服务平台的全部功能，有问题（数据标准、流程、功能）或者概念的困惑请及时群里提出（新上功能可通过公告、指标服务答疑群、部门群内发的上线内容等了解）；
应用健康度：基线97%；
实时/离线任务健康分：实时95分，离线99分；

监控报警篇

红线：

报警处理流程
- 报警需及时跟进，值班同学第一时间贴报警截图到群里，快速判定影响范围和原因，告知在处理以及同步处理进度；
- 严重问题第一时间拉相关方群语音一起解决，并同步到负责人进行报备评估；
各项目监控报警配置需全面，基础设施与业务异常都要监控并报警；重点进行坏点监控，趋势监控。
- 工程&服务监控项：MDC，UMP，JIMDB，JMQ，JED/MySQL，ES，JVM，JSF限流，全域看板等。
- 数据监控项：BUFFALO（任务稳定性：任务失败、SLA延迟、运行时长大于平均运行时长，数据质量：空值、主键重复、波动等）、JDQ/JMQ（消费积压、生产掉0等）、JRC（任务重启、CP超时等常规监控）、HBase、ClickHouse（主备集群、核心指标监控等）、Doris、JIMDB、UMP（IO交互务必加）、SRE（监控面板加入新任务）
避免报警淹没与狼来了；监控好与坏的衡量标准就是告警覆盖率、告警处理率、告警召回率（告警在故障场景的覆盖率）、故障恢复时长MTTR（越低越好）
监控报警做好值班与 backup；

线上风险篇

红线：

风险报备原则

识别问题，评估影响，不要发群里@一下就结束了，要确保收到信息的人在处理了。

PS：报备流程如下：

严格遵守值班同步机制（参考值班表）

对大家的要求：

1）早上7点关注下二级部门产品走查群，有和我们负责主题相关的问题一定要第一时间和产品联

系确认，无论是否是我们的问题，只要是在排查或者处理中就要在群里同步当前处理状态，目的

主要有两个：a.让负责人或者其他同学知道这个事情有人跟进 b.负责人或者其他相关同学看到能识别到这个事情的重要或者紧急程度，会给你提供相关的资源支持，让问题解决的更快，降低影响和风险。

根据反馈人数和页面判断影响范围，如果影响比较大先报备再恢复和排查同步进行，如果影响可控就先排查确认是问题后再报备。报备范围先C3内部报备，如果比较紧急或者重要，一定要打电话。

【注意】一定不要出现你在处理这个问题，但是负责人不知道你在处理这个问题，而是从别人的报备里才知道这个事情，从而失去快速止血判断的时机。

2）需要找谁排查？内部拉人一定拉全（可能问题不是自己的bug，但要识别出和谁相关的都需要周知下），首先自查是否有上线，先恢复再定位，各环节同步排查（防止排查到最后是自己问题，但是延误了恢复最佳时机），定位和修复问题，问题报备的人分开，但要明确好谁修复，谁报备。

3）问题同步的方式和内容，注意代表整个部门的形象，给外部的印象一定是专业、客观、有逻

辑的，而不是很随意的发一个同步，如果拿不准结论，先回复在排查中，一定要找架构师或负责人确认结论后再做可靠的同步。

4）问题原因要一跟到底，探查问题发生的根本原因；例如spark任务广播失败，文件fetch failed等都是表像，要同平台深究发生的原因，以及长短期上的解决方案；如果需要长期落地，可以通过信鸽进行提需跟踪；

\5) 如果是我们部门问题且产品或者业务需要报备，那么由我们来报备问题

显示回复机制

群里被@的消息一定要显示回复。

交接棒

线上的问题如果识别到是我们依赖的其他链路节点的问题，要及时的拉相关同学确认这个问题在

看，而不是@完就完事了，一定要把棒准确交接给正确的人，描述清楚问题以及需要别人做什么，第一优先级一定是先恢复线上再分析原因。

上线

任何线上操作都要可回滚

1）单点回滚

2）链路回滚

报警接收人

需要确保值班人都能收到对应的报警。

报备模版

【问题描述】问题具体发生或发现时间+问题简洁描述。

【问题影响】影响时长、影响范围、资金损失、订单损失、客诉量、业务影响、社会舆论影响等。

【发现方式】系统监控/人工/用户反馈

【发生时间】

【发现时间】

【恢复时间】

【问题原因】如原因尚未定位，需写清楚排查进展，或“原因排查中”，待问题定位后，及时更新

进展。

【问题进展】目前问题状态，并说明目前是否已止损。

【跟进人】协助问题解决及处理的团队，跟进团队不一定等同于责任团队，具体责任团队以复盘

结论为准。

线上问题都需要记录到泰山白虎；
故障预判为S0～S3，或涉及资损（订单或成本损失等，不论金额大小），或客服热点舆情达到蓝色预警，或IT工单量超过10单且无具体改进时间，或工单量超过50单，则必须报备至“9999-零售技术风险应急沟通群”，其他场景，不做强制要求；
线上问题第一：先恢复，再查原因；发现问题需尽快评估影响范围，及时回滚；
问题上抛：搞不定要及时上抛与寻求帮助，不要自己陷入；
自查：线上问题可能与负责的系统或数据有关时，主动并及时排查；
总结：及时反思与复盘，线上问题通用化的定位及修复方案可总结分享，避免重复踩坑；

日常工作篇

红线：

判断我们应不应该做、要怎么做的标准

判断我们应不应该去做的很简单的依据其实就是：【我们自己做的干不干净、清不清晰；用户用的爽不爽；行业内怎么做的】；用这三个视角去做判定，如果用这三个依据去判定，觉得不合理了，立刻就需要提

出来，避免形成债务，困难是守恒的，越到后面，相同的困难点解决起来的复杂度就会高很多；

请假

非突发情况提前至少3天沟通并提交工单，明确事由，事情不掉地，确认backup（backup需完全替代请假人，参与会议，修复问题等，backup需及时与请假人充分沟通请假期间所做的判断和事情的最新变更等）；

日常：
- 回家带电脑：值班同学回家路上要带着电脑，其他同学保证家里有电脑能连vpn，如遇线上问题能及时处理；
- 周进展：每周五周会前更新周进展文档；请假也需要写“周进展”；
- 行云工时：每周六中午前完成每周的工时填报；
- 京me手机端每日一题：每日完成，不要每天都选一样的结果；
研发：
- 技术方案：所有改动需要产出技术方案并评审，并落地沉淀到joyspace；
- 上线：上线准备；与用户功能相关的上线，需要提前进行demo；数据资产上线需要填写上线报备信息，写明上线内容、影响范围及GOC三项（可灰度、可监控、可回滚）措施。
- CR：大改动CR需拉评审会；
- 优先级：任务需按四象限法则（重要且紧急、重要不紧急、紧急不重要、不重要不紧急）划分优先级并执行；
- 排期：排期需细化，有理有据，不怕被挑战；
拔高：
- 技术分享：营造良好的技术氛围，提升团队战斗力；
- 积极对外发声：只有面对不同发声和挑战，才能把产品、方案打磨的更加完善，沉淀专利与行业分享；
- 敢于挑战：从“成本”、“效率”、“体验”判断需求是否合理、别扭，不合理的点要提出挑战；
技巧：

4.1 能力建设思维框架

能力分析二维表

能力的定义

能力指的是【脱离case】，能够【面向能力使用者】表达清楚：什么角色在什么场景可以如何操作就可以得到什么效果，且目标用户在页面上会【自然地操作】（操作者脑子里已知xx信息，有一个目的，则可以下一步自然进行下去）（另：该系统的owner有义务描述清楚在整体大图中此处的能力处于什么位置，前序后序的能力点是什么逻辑连接起来的）。

能力优先级评估

“加法”的事情我们可以做的慢一些（核心在于预期控制），但是保命类的系统安全性问题（包括三板斧，问题定位时间，潜在风险）是需要高优先级快速搞定的三个亮点都很容易被一个线上问题冲掉。

4.2 “答疑&咨询”类工作规则

所有答疑如果是线上问题第一时间处理；如果是文档有描述的可以给用户看文档（同时注意沟通话术，比如当前紧急问题处理，用户可以通过文档来解决），如果文档有描述不清楚的我们优化文档；理论上不能同一个问题用聊天的形式回答两遍。不要用手的勤快补充脑袋的懒惰。

4.3 问题上升

上升决策前：

全面评估、准备充分、内部沟通、敢于上升：问题及分歧是什么，都有哪些方案，涉及几方，各方的论点是什么，决策点是什么，谁来决策，我们的主张和建议是什么，预估谁能赢；

上升决策中：

清晰沟通、提出建议、聆听反馈、达成共识、展示专业性、合理性大于成本、站高一层看问题；

上升决策后：

记录好决策结论，待办及跟进人、时间节点，采用群信息、邮件、周报等形式进行留痕；

4.4 上线报备、审批

使用以受众为核心的表达，让信息高效传递。谁要关注、背景、收益、影响、审批依据。