日常问题： 上线确认 - Ryan.Miao

作为开发，手头没事的时候，担心自己没参与大项目，年终没产出。而真正需求到来的时候，却是狂风暴雨一般，密集且时间紧迫。在紧锣密鼓996之后，终于迎来了上线。 但这一天不太顺利。

xxx正式上线。上线前，方案强调要开发把所有配置都给到他，他要确认下。当时觉得有问题，开发的配置干嘛要给到他们。

开始正式验证数据的时候，第一个接口就404了。于是所有人都突然黑人问号了。客户心情瞬间不信任了。问这边啥情况。这边说需要调查。出问题模块的小组正在开会。又说不是变更时间段，要晚上9点后才可以做变更。客户当场不干了。于是老板们都加入了会议。

网络代理配置

压力之下，问题还需要一步步定位。半小时后确认是香港代理节点没配置转发。原方案设计是北美访问香港，香港代理到深圳。深圳这边倒是都配置好了。结果忘记香港代理配置了。

很快问题修复。流程可以继续验证了。但客户的信任出现了裂痕，他认为我们的系统不敢完全相信。之所以要各种配置方案，测试方案，就是前期合作中也多次出现过问题。所以客户在要求提供各种开发相关的资料，以此来证明我们做好了。这才明白为啥业务方会要我们开发设计的细节配置了。

后续还有更多流程，更多配置。于是大家自己也不敢保证没问题了。又开始拉着checklist检查清单挨着对。网络也挨着ping telnet。台风天，还是搞到很晚。

内部网络联通

回家后，同事接到电话要求第二天8点前到公司，因为有个功能是早上8点的。提前做好准备。然后他也想再确认下配置有没有问题。于是发现该服务sftp请求的地址网络不通。又是黑人问号脸。好像是没有开墙？于是，大晚上打值班的运维电话让帮忙开通网络。

数据安全和记录痕迹

第二天，他很早到公司。8点了，查看具体情况， 截图实际验证结果。

结果，说内容不对。

客户也发现问题了。

现在也不知道文件是谁放上去的。

最后确定是测试环境的文件。没查出个结果。

负责文件的小组说，早就是让xxx客户改密码了，他们没改。问客户，客户说他们没放文件。而我们这边也都说没。也没办法调查，因为机器环境在客户那里。

还好之前有设计异常方案，通过其他渠道修改了文件配置。至于文件究竟是谁放的，我们只能猜测是客户自己的人搞的。但他们否认，我们也无法举证。只能继续验证了。

设计方案和实际场景

中午去肯德基吃饭。吃到一半，打电话过来。xxx报错了。于是赶紧排队等电梯回去查看。测试根据报错，确认是创建人字段超长了(还好把错误一路传到了前端)。看下配置，数据库表中创建人字段长度是10位？哦，当时可能按工号设计的，结果用户是外国人，拿手机号当做用户名了。

打电话给运维，改。

改的时候也有点曲折，客户现场等，问需要多久，开发回方案说5分钟，方案回客户10分钟。结果6分钟的时候，开发还没改好脚本。着急的时候越容易出错，他自己在写sql。我旁边看着，想，如果是我，我会用工具修改生成sql后，复制。

在客户催了2遍后，改完了。然后流程回滚，重新验证。(还好，之前设计的方案支持错误中断回滚，否则只能运维改数据了)

到这里，还没验证完，但是，陆陆续续出现不少问题了。

1. 敬畏生产，清单多次验证是需要的
2. 数据安全和历史痕迹是需要的，除了防止出错，更多的是可以找到谁来背锅
3. 设计方案除了需要评审，需要有经得住考验的、可以拿来即用的方案库，而不是每次又重新来。人力毕竟容易出错，复制就不会。

最后，上线方案要设计验证方案。总不能拿客户当测试。破裂的信任，要想修好，需要付出更多的努力。