记上线三小时失败经历

今天是 5.21 日。很美好的日子。但是发生了一些让人沮丧的事情。

1. 项目范围蔓延---范围爬行

上午大数据一位相关方，提出了新的变动，讨论了新的实现方案。所幸改动不大。但是这个功能也是改动了多处逻辑，下午四点左右完工。

上午和部门老大讨论了一下，之前遗留的存量数据的同步的问题。最终的方案还是回到了一开始想的临时过渡方案。但是针对这个问题而言，做错了几个方面：

1. 没有及时把问题抛出到管理层。
2. 在周老师已经提醒了两次的情况下，我还是没有积极主动的找领导沟通，只是简单的和两位领导分别沟通了一次。导致后面开会的时候，老大明显的对结果不满意，因为没有最终的解决方案落地
3. 当自己拿不定主意的时候，不能空洞的找领导说问题。需要把问题、想到的解决方案、不同的结果和影响考虑好之后进行沟通。毕竟大家的时间都是宝贵的。
4. 解决方案定下之后，需要积极主动推进，通知所有相关方。

2. 下午的时候开始写上午的变动功能，但是没有从整体把控

功能需要整体把控，否则将导致反复修改，占用了不少时间。

3. 评审新人代码时，没有足够的耐心

对于新人的过多错误代码和逻辑没有做好心理准备，容忍度不够。更不应该的是放弃评审，任期发展

4. 下午和产品UI沟通了另外一个需求的相关事宜，最终结果新提出的变更可行性不够。

5.管理好相关方参与计划

1.下午6点钟之前的时候准备上线新一版的项目优化，但是由于没有提前做好相关方的工作。双方项目组成员再次花费了差不多两个小时的时间才最终交付代码。

2. 代码交付之后由于依赖的项目的 jar 包上传有问题，二十分钟左右的时间又消失了。

7.问题的定位，不熟悉的领域及时寻找专家

最终解决完所有的问题之后，准备上线交付时，发现项目发布不了了。寻找问题过程中，一头雾水，向运维部门成员寻求帮助。但是时间比较晚，都下班了。问题的定位上又花费了差不多半个小时的时间。最终其他项目组成员遇到同样的问题将其反馈至部门群，初步定位到是 docker 环境的问题。至此，准备下班，不再纠结。定位问题时，主要是发现构建的 jar ，没有上传到 Jenkins 上，由于一直对 maven 的原理不是太清晰，在查看 maven 构建的一些输出时，有了误解。

总结：对于今天发生的事情，当然自己是要负全责的。

改进方案如下：

1. 做好沟通管理，相关方计划
2. 不能决定的问题及时上抛。问题已经自己的见解和解决方案同步给出。
3. 带新人需要时间和耐心。代码同样需要认真评审，不然一堆 bug 坑死你。
4. 对于问题的定位需要精准，不纠结。及时抛出问题。
5. 对自己不熟悉的领域，如CICD。一定要请教专人。当然自己也要涉猎学习。

最终还是要感谢自己的父母不辞辛劳。在今晚差不多九点的时候给我发了一个红包，当时刚下班吃饭。父母真的是这个世界上最爱我们的人了，他们为我们付出了那么多，我们又反馈了些什么呢？晚上和妈妈通电话，她告诉我说明天他们会很忙，同时我每天也很忙，怕我记不得明天是自己的生日。当时真的是快泪奔了。可怜天下父母心，愿岁月温柔以待。

记上线三小时失败经历

原文：https://www.cnblogs.com/hui-run/p/10902904.html