故障管理规范

基本原则

• 故障永远是表面现象，背后技术和管理上的问题才是根因
• 组织责任+个人责任分别担责
• 就事论事、承担责任、不断改进
• 定义具体的标准和行动

过程质量保障

• 质量意识

  • 敬畏线上问题
  • 制定线上操作高压线，所有人要有高压线意识

• 方案评审：

  • 每个项目启动前必须完成方案评审环节，通过才可以启动开发（架构、异常、安全）
  • 针对主业务流程重新评审流程方案（方案+SQL检查）
    1. 定范围：收集需要评审的主流业务（web、app：首页、搜索页、频道页、详情页等）
    2. 评审方式：流程评审、代码评审、sql评审
    3. 评审输出：方案优化、代码/sql优化，清理无效的代码，替换低频低效代码。

• 有效的代码review：

  • 形成问题代码模式清单
    1.数据量增长后，原来的sql语句不适合，导致的慢sql（已经存在，或者将来可能会存在）
    2.可能会因为主从不同步导致的错误代码块
    3.注释掉感觉以后可能会用到的代码（不需要留着，除非明确将来重新会用到）
    4.引入的类当前类没有使用，或者声明的变量当前类没使用（删除）
  • 每周五选择一部分代码全员review(附带代码介绍)
    1.每周五指定下周五需要review的功能代码（每次两个小时之内），内例如：整个注册流程，整个商城购买流程
    2.每个小组自行review指定功能代码，每次至少找出两个以上问题
    3.找出的问题记录在git上(谁先发现的问题，谁负责提)，需要写清楚问题，并且改进建议（组内一致），作为下周的周需求上线（review过程不关注是谁写的代码，目的主要是提高我们的代码质量）
  • 每季度评审代码review之星

• 测试用例评审：

  • 输出每个业务的基础用例
    • 采用testlink用例管理工具，分三个组输出用例：内容生产组用例、内容消费组用例、服务类组用例
    • 各组需要梳理、补全当前测试的、即将测试的、缺少的用例
    • 各组补充完成基础业务用例后检查，可分次、分批组织同行评审
  • 测试方案评审（测试重点、测试范围、测试策略）
    • 测试用例设计前，用xmind整理测试方案、记录测试重点、测试范围、测试策略
    • 测试重点：1.关键流程 2.关键数据 3.关键功能点或界面 4.大部分用户比较关心的地方 5.如果产生异常影响面较大的地方 6.历史曾经出现过问题的地方
    • 测试范围：1.保证当前需求下基础用例的覆盖 2.各端的覆盖（app/H5/web） 3.兼容性覆盖(历史数据兼容、浏览器兼容、app历史版本、app升级兼容) 4.易用性（方便、简单）、可靠性（性能、安全）5.UI检查
    • 测试策略：1.对不同项目（重大项目、中小项目、周需求）选择不同的用例设计策略 2.按项目紧急程度、业务功能的先后、用例的优先级、用例执行难度，设计高效的执行策略
    • 完成方案后，用xmind工具组织方案评审

• 可靠性专项用例：公共异常用例、性能用例、接口自动化
  * 公共异常用例：1.testlink 各业务组建立专门管理 2.梳理公共业务 3.整理批量异常用例
  * 性能用例：1.testlink 各业务组建立专门管理 2.新开发的项目测试方案进行性能测试评估 3.梳理系统中能产生性能瓶颈的业务并设计用例
  * 接口自动化：Yapi平台，软件开发主干栏目中，在每个系统下，将接口设计对应补充为接口测试用例

• 线上环境操作规范：数据库操作规范、生产环境变更规范、生产问题定位规范

  • 数据库操作规范

    • 1:备份整个数据库，数据库表
    • 2:执行的SQL语句,脚本，数据库表结构修改、创建索引等、必须在预发布环境测试执行过，没有问题，才能在生产环境执 行。
    • 3:对于大批量的插入操作，必须分批执行，避免造成mysql数据库的主从同步延迟。
    • 4:生产执行SQL，必须2个人同时在（开发和操作数据库的管理人员）
    • 5:程序连接数据库帐号，遵循权限最小原则
    • 6:禁止为程序使用的帐号赋予super权限
    • 7:其它部门，需要批量导出、导入数据、查询数据，需提git，黄智指派到开发，然后在执行数据库操作。

  • 生产环境变更规范

  • 1:网站架构调整

    • 1.1:用Enterprise Architect工具，把架构变更的图用工具画出来，然后讨论架构的合理性
    • 1.2:内网预发布环境测试验收（部署观察1到2周左右），没有问题，才能部署到生产环境。

  • 2:生产数据库变更

    • 2.1:数据库执行的脚本，必须在预发布环境执行通过，才可以在线上，生产环境执行。

  • 3:配置文件变更

    • 3.1:变更配置文件之前需要先备份配置文件（nginx，mysql,redis,zookeeper）。
    • 3.2:配置文件修改后，必须在预发布环境测试通过，才可以在线上，生产环境执行配置变更。

  • 生产问题定位规范

    • 1:看数据库的负载情况（主，从数据库负载），负载很高，导出执行的SQL分析和慢SQL语句（给开发分析）。
    • 2:登录阿里云的控制台，看SLB的负载和流量，观察流量是否异常（对比之前一周的流量）。
    • 3:登录服务器，看应用的负载，找出负载高的进程，在分析线程，那个方法类，导致内存溢出。

故障监控

• 主机监控

  • 1:CPU使用率
  • 2:CPU负载
  • 3:内存使用率
  • 4:磁盘使用率
  • 5:磁盘读写
  • 6:网络公网带宽流入和流出
  • 7:进程总数
  • 8:TCP连接数
  • 9:inode使用率
  • 10:端口监控

• 页面监控

  • 1:网站首页
  • 2:H5页面
  • 3:App页面
  • 4:网站资讯页面
  • 5:网站搜索页面
  • 6:网站元件供应
  • 7:ON搜索结果页面
  • 8:网站资料页面
  • 9:网站技术难题页面
  • 10:网站搜索页面-中文

• 业务监控

  • 1:使用阿里云的日志服务，自定义规则功能，监控业务数据

• 数据库监控

  • 1:mysql主从同步状态
  • 2:mysql主从延迟
  • 3:数据库表的数据监控
  • 4:数据库慢日志
  • 5:连接总数

故障应急

• 最短时间解决问题（建立应急操作手册）
  • 建立稳定的代码回滚机制
  1. 通过DevOps_发布系统回滚上一个版本的代码
  2. 通过服务器备份的代码来回滚
  • 检查流量负载
  • 检查数据库负载
  • 待完善
• 应急小组（什么级别问题，什么级别人员全力参与）
• 信息通报（通报范围、通报流程）

故障复盘

• 故障报告
• 复盘会议
• 故障定级
  • P1：网站、APP无法服务2小时一上；APP上线后大面积不可用
  • P2: 网站、APP无法服务2小时以内、部分模块无法服务2小时以上
  • P3: 后台模块无法服务，大量用户投诉;网站部分模块无法服务，影响大量用户（影响），考虑评估影响范围
  • P4: 部分模块无法服务，影响少量用户
  • P5: 部分模块不稳定，影响少量用户
• 故障定责（组织责任、个人责任）
  • 个人责任：不规范的操作、确定的代码bug、直接发生产、明显的漏测，P3以上故障季度绩效降一等
  • 组织责任：架构问题、18年前的业务流程
• 改进行动