2019年08月09日，上海受台风利奇马的影响，晚间狂风大雨。
临下班，合作渠道WB在微信群里报告线上生产事故问题：赶快扒日志看记录，日志显示一切正常，看不出bug在哪里，WB声称并未接收到我方CI的回调请求。晚七点多，肚子已经饿了，给WB说，看日志CI没啥问题，先撤了。
在出公司大楼经过一个拐角的时候，隐隐感觉这情形代码里的配置项会不会有问题，心里很是忐忑，冒雨又折回。重新打开电脑，再捋一遍代码的时候，bug像一道匕首直刺心头：卧槽，这个路径竟然还是测试环境 的路径！项目组是公司敏捷开发团队，每周五都会有生产版本发布，赶快给负责版本控制的同事打招呼，等一下，搭个顺风车。
在确定了配置路径有问题之后：亟待明确的是服务间调用是走内网还是走外网，要不要NG转发，走不走esb，是不是要申请通信权限。简单描述一下WB的该次请求：WB请求CI的NG--------》NG转发到CI的Mule服务----------》Mule服务调用Gateway----------》Gateway转发至应用微服务Application ---------》Application服务响应之后执行异步回调Mule服务---------》Mule服务请求WB接口地址 。中间涉及的防火墙和权限就暂且忽略，目前的问题点是：Application服务响应之后执行异步回调Mule服务，这个Mule服务内部接口地址规范是什么，会负责系统维护的同事一番确认后，决定走内网Mulef5，这个时间点负责维护配置中心的同事已经下班了，当务之急硬编码的方法先上了。
九点多回到家，觉得有必要复盘一下为什么会遗留这种bug，2018年11月份进入CI公司的敏捷开发团队。刚入司时对敏捷开发基本不了解，后来才发现这是一种近乎流水线的开发模式。作为开发可以说是一个不停机的多线程，从一个合作业务开发要介入需求沟通、网络申请、防火墙权限申请、配置维护、数据维护、多环境测试联调、线上支持。每天被各种合作群微信轰炸，有时候盯着开发文档和需求分析文档去盘问需求的正确性 ，有时候也不得不去应答一些需求和业务上的问题，开发思路很容易中断。对于单个的合作渠道追求对接速度快，省略了各种文档和单元测试，缺少代码的复核和管理。快速迭代，线上支持，这种公司层面的情况是短期没办法改善的，在这种工作模式下，应该梳理出标准的工作流程模式，严格按照流程模式在上线之前去复核，才能避免易忽视的小问题。
以WB案例来说：
阶段一：谈合作阶段
前期CI分公司业务人员与WB达成合作意向，确定合作产品方向。
阶段二：谈需求阶段
CI需求人员介入，通过沟通和场景分析，参考WB合作接口文档，分析CI接口映射关系、业务字段关联，草拟一份需求分析文档供开发测试用。
阶段三：方案确定阶段
此阶段开发人员已经开始开发，开发对需求分析文档中的一些问题会和WB方开发和CI方需求及业务人员确认，此阶段开发人员主要解决加密解密、加签验签，测试环境申请。CI业务人员明确WB合作方案和WB合作机构信息，CI业务人员同步方案和机构信息至测试系统。
阶段四：开发者开发阶段
此阶段大致分三板块：第一，Mule开发；第二，应用开发；第三，配置项维护。
阶段五：测试联调阶段
此阶段开发负责环境双方网络权限，Ng转发路径，Api访问权限的开通，相关数据维护。测试人员介入进行本地测试，本地测试通过，WB方介入联调。
阶段六：生产环境准备阶段
测试环境和生产环境在网络权限和防火墙控制有很大差别，主要是权限和参数维护。应按流程梳理各个环节权限是否开通，各参数和WB提供生产参数是否有出入。确认无误，进行上线。
原文地址：https://www.cnblogs.com/slowcity/p/11330012.html