项目

一般

简介

Actions

问题平台使用规范

问题处理流程

【1】运维过程中发现问题或者用户提出问题或者需求

  • 发现系统问题时
    • 根据自己的理解和经验尝试分析和解决问题
    • 寻求其他现场同事、翟旭耀进行问题分析和处理,一定尝试自行解决
  • 用户提出新的需求或者优化建议时
    • 考虑是否系统已经实现相关功能或者有其他解决方案
    • 咨询翟旭耀或者研发,是否已有类似的问题对应的解决方案
  • 以上问题都未得到解决,进入下一环节,将问题录入到问题平台

【2】提交问题到问题平台,创建新的问题

  • 无法自行处理或者需要研发协助的问题、需求等都需要走问题平台
  • 项目
    • 问题所在项目
  • 跟踪
    • BUG:系统问题(功能性问题,数据问题等)
    • 优化:系统原有功能点优化等
    • 待办:新需求,新功能开发等
  • 主题
    • 一句话简单概括问题核心内容或问题概述
  • 描述
    • 如果是BUG,对问题表象、问题原因;操作步骤,如何重现;尝试处理方式,结果等 相关信息进行详细说明
    • 如果是优化,对优化原因,优化后要达到的效果等进行详细说明
    • 如果是待办,对新需求功能进行详细阐述,需求提出背景及使用场景等进行详细说明
    • 这里强调, 描述必须足够详细,原则上不允许将word作为问题描述
  • 状态
    • 此环节状态为:新建(待分配)
  • 优先级
    • 立即处理:重大bug,影响客户使用,产生错误数据,客户要求必须马上处理等此类情况时,优先级为立即处理,一般24小时内处理完或者当天下班前必须处理完成的问题
    • 紧急:需要在2-3天内必须处理完成的问题或需求
    • 高:需要在1周内必须处理完成的问题或需求
    • 中:需要在2周内必须处理完成的问题或需求
    • 低:暂无时间要求的问题或需求
  • 指派给
    • 当前环节问题统一指派给翟旭耀
  • 父亲任
    • 默认一般不进行选择
    • 如果一个较复杂的问题时,可以进行拆分,将大问题拆分成小问题,总的问题为父问题,在该问题下可以添加相应子问题
  • 开始日期
    • 默认当前日期
    • 如果当前问题不着急处理时,也可以将开始日期推迟,一般是提前录入问题时才会将开始日期推迟
  • 计划完成日期
    • 问题提出人员根据问题优先级明确一个该问题处理完结的时间点
    • 注意: 计划完成日期与优先级的时间标准保持一致
  • 附件
    • 问题截图、日志文件等信息可以作为附件

【3】翟旭耀对问题进行过滤、检查和指派

  • 问题核对,检查是否满足规范
    • 问题描述,必须足够清晰准确,需要研发协助处理
    • 问题优先级,按照实际情况标记优先级
    • 计划完成日期,必须和优先级对应,且与优先级对应时间标准一致
    • 指派问题
      • 前端问题,指派给王凤
      • 采集问题,指派给高磊
      • 后端问题,指派给赵鹏军
  • 核对不通过,不满足以上要求时
    • 将该问题打回给提交人员,提交人员重新修改后进行上报

【4】研发处理问题

  • 前端问题,由王凤统一进行分配和指派,将问题指派给处理人,指派时确认优先级和计划完成日期是否和预期一致
  • 具体问题处理人员接到问题后任务后
    • 查看问题描述,了解问题及需求具体情况
    • 明确优先级,计划完成时间会否和预期一致
    • 更新“预期时间”,也就是处理问题预计总耗时,一个工作日按照7小时计算
  • 研发人员处理完成后
    • 编写 问题处理说明 wiki,并与问题进行绑定
    • 回复问题处理结果,包含问题处理说明链接
    • 更新问题状态为:“包已上传或处理完等待验证”
    • 更新指派人为:问题提出人员或现场更新人员
  • 注意: 需要更新包,配置文件,数据库表结构、数据发生变化等,研发必须提供的问题处理说明

【5】现场更新部署

  • 需要更新包,配置文件,数据库表结构、数据发生变化等,都要根据研发提供的问题处理说明进行部署升级
  • 现场更新人员必须先将问题处理说明全部阅读完成后再开始进行部署升级操作
  • 部署升级操作一般不要在上班期间进行
  • 部署升级前务必做好 包、配置文件、数据库等方面的备份
  • 问题更新时存在问题或者疑问,直接联系问题处理人员,也就是问题处理说明负责人

【6】问题提交人员对问题进行验证并关闭

  • 现场人员更新完成后必须立即进行验证操作
    • 复杂问题,研发在问题处理说明中包含问题验证说明,按照该验证流程验证
    • 简单问题自行验证
    • 注意:这里一定要考虑全面,尽可能的验证相关的功能点,保证问题被全面验证,不存在遗漏点
  • 验证不通过时
    • 首先与问题处理人员联系,协调处理
    • 联系完能立即处理掉的,直接处理,处理完成后再次验证
      • 验证通过
        • 修改状态:验证通过并关闭
        • 必要时回复处理结论
    • 联系完无法立即处理的,必须再次进行更新和调整的
      • 情况一:
        • 修改状态:已指派人员处理
        • 修改指派人:问题处理人员
      • 情况二:(需要重新分配人员时)
        • 修改状态:验证不通过打回二次分配
        • 修改指派人:王凤
        • 后续由王凤再次分配给研发人员处理

流程图

赵鹏军 更新于 超过 4 年 之前 · 19 修订