总之一句话的感觉就是糟透了，全程一半以上都是在浪费时间。
先说背景，我工作的上一家公司主要是做 IT 技术服务的，虽然人的素质比较拉胯，但是流程还是挺成熟的流程，至少每个项目有大佬跟着把关告诉你怎么做，能学到的东西还是蛮多的。
跳槽之后这家公司，工作流程给人的感觉就是还在从作坊式的工作流程逐步向正规化进行模仿。但是项目除了代码和客户环境的设备列表，几乎没有什么文档留下给我们。且不说原型文件之类的东西，项目设计稿，部署手册，工作记录之类的一些东西完全没有建档，也有可能是建档了，但是不对我们开放（那不就等于没有）。
项目上云过程
近期给客户做项目上云迁移，现在这家公司的工作流程就是：客户要啥就给啥。客户要迁移方案，项目负责人找到研发部，最后让运维工程师去写，运维工程师两眼一抹黑，这项目咋部署的，啥功能，三方接口调用，业务部署完了怎么验证，完全不清楚，没有文档，也没有人说，问的时候开始挤牙膏。一开始只说了有个数据库的主备模式使用一个第三方软件，说到时候找客户要。
于是乎我开始部署，先登录人家原来的生产环境进行一顿摸黑式的勘察，各种功能的实现完全是凭经验去看当初是怎么做的。搞清楚了之后在云主机上重新部署环境，一开始部署的都很顺利，数据库主备的时候出了岔子，客户自己都不知道用什么方式进行主备，没定好方案。我只能装好数据库先放着。
等后来客户提供了热备的软件和安装手册，我一看，好家伙，这个软件需要额外的网卡和虚拟 IP（倒也可以预想得到）。好在客户的联系人也是有一些技术水平的，发安装手册时候他就已经在申请了。这一环节搞定之后，环境就都准备好了，客户那边也确定了业务停机的时间。第二天一早开始数据迁移。
数据迁移的过程就是简单的导出、压缩、上传、解压、导入。这些都很顺利，上午差不多 9 点左右开始，下午 2 点多其实项目就已经拉起来了。然后客户问了一句，SAP 和地磅怎么样。一句话把我问懵了，啥啥啥，SAP 是啥，地磅又是啥。我赶紧给负责人打电话，负责人说明了 SAP 和地磅的事情之后又问，怎么没先部署测试环境测试一下。
线上压根就没给测试环境啊，直接给了 4 个设备做生产环境的主机，前端一个，后端一个，数据库俩。
到这我就明白了，这公司的办事流程就是前期完全没准备，先搞个测试环境，摸黑探路，搞完了重新部署生产的，或者测试环境摇身一变升级成生产。
先不管那些，再搞环境肯定来不及，我赶紧跟他问清楚还有什么第三方的东西需要联调，好在就只有这两个。
接下来的过程就是漫长的一拖三了，微信群里最开始只有 6 个人，后来因为需要调通几个端口，涉及到第三方的业务，技术，云主机的技术工程师，逐渐拉成一个 13 人的微信群。到现在，时间过去了快两天，一顿瞎 B 测试，第三方接口回调推送数据的 4 层端口还是不通。
总结项目迁移过程的坑
-
前期准备一定要充足，主要是项目迁移文档。
不要觉得自己不会写就交给实施的人去写，实施过程反而是不重要的，要由最了解项目的人去写。
项目迁移的最终目标就是在新的环境上对原有的业务解决方案重新实现，应用了什么中间件，什么技术都不是迁移文档的重点，重点是原有系统里有什么功能，与哪些第三方有互动，有什么注意事项，这些东西在迁移过程中怎么同步的由指向老环境转移到指向新环境，这样就可以确定都需要哪些人参与了。还有就是迁移完成之后需要进行哪些业务实现上的验证。这些东西在开始实施之前都需要确定好，而不是迁移完成之后一边测试一边写，顺便擦屁股。因为项目迁移本身就是需要保持原子性和一致性的将所有原有的业务解决方案在新的环境上重新实现。
实现才是目标，而不是部署过程。 -
迁移目标不明确。
迁移开始之前，客户自己都对项目迁移没有什么概念，只是以为重新部署，对部署之后的结果没有什么打算。很多都是现场拍板，比如想要 HTTPS 访问，都是部署完成之后才提。 -
故障点解决的中间环节不透明。
最后测试出来接口回调不了是网络的 4 层协议不通，怀疑防火墙策略没有放行。但是找云厂商的支持，能得到的回复就是已经开通，实测结果就是不通。解决故障的结果就是一句话，通或者不通，到底是否给解决了，网络是否通常，毫无说服力。而且，效率奇差！！