方案设计阶段

问题：

  • 方案落地需要多个模块同时更新，强耦合，更新不好操作；
  • 方案实现前后不兼容，未考虑可持续性，更新失败风险高，无法回滚；

原因：

方案设计不合理

教训：

多个应用服务需要一起更新，无限期延后上线进度，并且无限放大上线风险，基本上处于不敢甚至根本无法上线的状态！
进而导致重新对业务进行分析，对功能模块更新进行解耦，重新制定上线步骤，并独立分阶段上线，整体开销巨大！！！

改进：

  • 设计必须考虑前后向兼容
  • 各个模块保证独立性

开发自测阶段

问题：

  • 带病上线，导致上线时间被拉长，甚至延后
  • 等到上线进行测试，出现问题回退，导致版本更新延后

原因：

  • 没有充分的自测，意识缺失；
  • 没有良好的测试方案的构造，意识薄弱；

教训：

  • 一方面因为是项目交接信息缺失或有误，导致开发自测有遗漏点；另一方面，对已知的需要测试的模块，因为没有很好的测试方法，也处于保守等待线上验证，但是线上又不敢操作的两难境地。

改进：

  • 开发需要胆大心细，如履薄冰时，也不能畏首畏尾，最好是重新设计测试方法，将风险降低甚至规避。
  • 务必对修改的功能点进行明确的测试，并给出明确的验证方法；
  • 上线之前必须自行构造相应的测试方法，而不是等到上线之后验证；
  • 自测越早越好，为可能的bugfix以及额外的风险预留时间；

提测阶段

问题：

没有系统的开发、测试、线上的环境隔离；

原因：

当前测试的环境不完善；

教训：

测试过程中，遇到的一些问题，排查方法没有进行很好的整理（如外部域名访问不通），导致线上重复踩坑，而redis的数据查询，相应的key之前测试也构造过，线上排查又重复去翻代码进行拼接，重复劳动；

改进：

  • 中间的所有操作尽量进行记录，并及时整理，为后面的工作做好铺垫，并方便后续的复盘！
  • 梳理并规范各个环境以及相关测试账号；
  • 明确QA执行发布操作；

发布阶段

问题：

  • 分支使用不规范，未发布的代码合入到了dev分支，导致当前需要上线的代码无法正常合并；
  • 发布平台老旧，发布任务命名不规范，导致误操作发布了其他项目；
  • 发布人员对整理发布内容熟悉程度不够，导致临时发现其他问题；
  • 线上运行版本有额外人工修改的配置，导致走发布任务后将配置回退；

原因：

  • 分支管理规范未落实；
  • 发布人员的发布任务不规范；
  • 线上发布不规范；

教训：

  • 归档数据迁移时，因为迁移代码没有很好的验证方式，最后延后到了发布阶段进行操作，此时实际是边调试迁移脚本，边执行发布，大大拖延的发布时间；
  • 管理后台也因为在代码合并过程中进行merge等操作，浪费了较多的时间；

改进：

  • 验证功能通过后，方可进行上线流程。
  • 明确git分支的使用规则，只有验证过，且当天需要发布的代码才合入到dev；
  • 发布人员需要进一步梳理发布任务以及自身职责的发布模块；
  • 线上发布要严格收口到发布人员以及发布平台，严禁人工操作！

项目跟踪

问题：

对项目的整体进度及风险掌控不足，导致一而再，再而三的延期；

原因：

  • 因为是新人，对项目整体熟悉程度不足；
  • 自身项目风险意识还是有所欠缺；

教训：

  • 从第一次上线时间11.27，到目前12.18杭州侧完成上线，延期了近3周，主要还是开发对风险感知不足；
  • 实际上线时，缺少一个完整的上线流程节点时间表；

改进：

  • 做好总结，加强开发的业务能力；
  • 后续交由QA进行整体发布进度掌控；
  • 加强自身的项目owner意识，尽快熟悉业务，做到对风险和进度提前感知；
  • 发生项目有延期风险，需要及时告知到相关人员，或者寻求外部帮助；
  • 加强项目的进度管控意识，尽量事前规划，而不是事后的Delay；

项目交接

问题：

  • 描述不准确
  • 信息缺失

原因：

  • 时间仓促
  • 原负责人意识不足

教训：

  • 原有负责人在离职前两天还在写代码；
  • 交接文档失真，交接代码存在缺陷，配置错误或者遗漏；
  • 原负责人离职之前，接手人没有走过完整的开发、上线、运维流程；

改进：

  • 控制交接时间，给交接人1-2周时间进行交接项确认和补充
  • 交接项Check，需要接手人进行着项确认，否则视为接手人工作不到位