昨天项目发布stg环境，折腾到晚上12点还没有搞完，所以今天上午还要接着加紧时间进行处理。
为什么从昨天白天开始准备，到晚上还没有搞完呢？这个问题很值得反思复盘一下，所以在这里先提前做个简单的梳理。现在在我看来主要有以下几个方面的问题和解决方案：
1.缺少发布流程的说明文档：作为第一次发布，幸好是听了一下其他同事的介绍，要不然完全是两眼一抹黑，但在没有规范详细说明文档的情况下，还是踩了不少坑。
解决方案：首次的操作流程和内部问题解决方案要及时进行文档输出，做好内部文档建设和沉淀，至少要想着减少内部重复犯错的概率和成本。
2.缺少对流程问题的提前梳理和预判：公司虽然有客服，但运维、db、网络的支持人员都是通过线上联系，而且是客服随机分配，在首次不了解实际情况的时候，又不方便提前互动沟通。完全不像是面对面沟通模式，可以和对应负责的运维，提前进行问题沟通和确认。
解决方案：在和支持人员沟通不畅的情况下，首次踩坑获取犯错在所难免，所以项目组内部依然还是要加强文档建设，以便更好对后加入的成员有一个问题的概览和预判。
3.和发布支持人员沟通成本高：支持人员响应非常慢，一个简单的问题原本两分钟就可以解决的，愣是要等上近一个小时才有反馈，而且还需要不断地加急消息。之所以会有这么迟的响应，其实完全也可以理解，因为听说公司只有几十号运维，而却要服务上千位开发人员，这个强度明显支持不过来。
解决方案：（1）运维人员做好常见问题的梳理和说明，另外，也可以同时说明发布流程；（2）增加支持人员的人手，扩大支持人员的团队规模；（3）关于发布相关的需要在先找客服联系的同时，公司也可以加强机器人的分类问题管理，同时做好培训工作，这个我看在我入职的时候，db和运维方面一定有意识地开始在做了。
4.责任心低，个人参与度小：我们的项目属于新建项目，在前期申请mysql、mq资源的时候，我参与度比较低，而且在有同事提出离职的情况下，我也没有主动将他之前参与申请的内容，及时确认是否申请到位，具体的申请信息又是如何的，这些我都没有主动询问。而由于同事暂时不在公司，导致进展被阻碍，耽搁不少时间。
解决方案：加强责任意识，多多主动参与，可以不去具体做，但一定要做到心里有底有谱。但现在在不熟悉的情况下，完全是两眼摸黑。这种情况下，自己参与度还很低，实属不应该，非常值得反思。
5.自身对发布方面的知识缺少学习：对发布的大致流程虽然在别人提示的情况下，会知道。但自己心里并没有一个清晰的流程，所以有些资源的申请，完全是在遇到问题之后，在运维的指导下，进行操作的。这点也浪费了不少时间。
解决方案：在公司力量技术薄弱的方面，自己都要主动地加强学习，做好个人担当，主动弥补不足。如此才能真正起到锻炼自己的作用。
