生产环境全链路压测建设历程之五 针对稳定性矛盾， 从目标、流程、组织体系发力

上一篇提到，淘宝网针对稳定性的矛盾，从技术上进行各种发力。



今天的内容，主要是从目标、组织体系、流程来展开讲。

目标与标准：

在管理学里面，描述具体目标需要具备SMART这5大元素：

1.目标必须是具体的（Specific）

2.目标必须是可以衡量的（Measurable）

3.目标必须是可以达到的（Attainable）

4.目标必须和其他目标具在相关性（Relevant）

5.目标必须具在明确的截止期限（Time-based）



当年淘宝网在设定稳定性目标的时候，其实一个最具体的目标是，单笔订单交易要在xxx毫秒内处理完成，一年365天除发版本时间外，订单交易系统要持续平稳运行。



为什么要这么来定目标？ 这里给大家同步一个数据，在2013年的时候，支付宝曾经公布果一个统计数据：银行网上支付15%不成功。    



支付不成功，结果是糟糕的用户体验。直白点说，电商平台就是要让用户享受购物的乐趣，如果购买一个商品，还需要等个10秒，用户等得不耐烦，就少了一笔交易。



围绕订单交易系统要持续平稳运行这一具体目标，根据订单交易异常持续时间长度，来设定P1、P2、P3、P4故障。

设定了故障标准后，会有一些惩罚措施，比如一年下来吃了几个P1故障，年底基本上妥妥的KPI 3.25。。



组织体系



组织体系，其实就是成立稳定性小组，把相关角色的职责明确，避免扯皮



稳定小组的角色构成:

研发角色：业务系统研发负责人，

应用保障/PE：定位是生产系统的负责人

DBA：提供高可用、高性能的数据库方案

技术支持小组：内部和外部沟通的重要桥梁，相当于信使。

配置管理/SCM ：识别和管理集团研发过程中的软件资产

过程改进/SPI ：优化组织运作体系，提供过程改进服务





流程



在处理故障的过程中，也围绕故障发现、故障处理、故障Review三个阶段来进行组织



故障发现阶段：

1）建立信息反馈通道，有一个小组叫做业务支持小组，作为一个工作台来统一收集如下内容:如客服电话的内容、内部小二群的聊天内容、外部舆情，当然还少不了的是监控报警的内容

2）业务支持小组根据收集的信息，结合一个核心的指标：实时订单交易量指标的正常与否，来判断这是否为一个故障

3）在通报信息的时候，结合实时订单交易量的正常与否，把相关信息同步到一个叫 消防小分队 的旺旺群里面

4）和订单相关的业务应用、DBA运维工程师、业务研发工程师团队，都在这个 消防小分队 的群里面。大家都会看各自负责的事项来看是否有异常告警

5）如果明确这是一个影响到订单交易量的异常，业务支持小组则会判断这是一个故障，录入到故障系统里面



故障处理阶段：

1）录入故障后，故障系统会自动发送通告到相关人员

2）业务支持小组主要负责跟踪故障处理进度，并把进展同步给客服、公关部门

3） 研发、运维、值班长等相关角色主要是围绕快速消除故障这一目标来进行问题定位、确认问题影响范围、以及确定解决方案



故障review阶段：

1)业务支持小组，作为组织方，负责组织相关人员准备开会

2）故障review会议，主要的内容为判断责任方，涉及人员自行举证说清楚自己有否责任。一个故障的责任，会有全部责任、主要责任、次要责任之分，这和处理交通事故是一模一样的。

3） 故障review会，最后的环节是形成待办（后续Action），业务支持小组会把相关的action录成任务

4） 业务支持小组在故障管理系统里面，补充完成故障报告，以及跟踪后续action的进展