近期做项目上云迁移的一些状况与感想

Posted 2023-04-18 NagaResst

总之一句话的感觉就是糟透了，全程一半以上都是在浪费时间。

先说背景，我工作的上一家公司主要是做 IT 技术服务的，虽然人的素质比较拉胯，但是流程还是挺成熟的流程，至少每个项目有大佬跟着把关告诉你怎么做，能学到的东西还是蛮多的。

跳槽之后这家公司，工作流程给人的感觉就是还在从作坊式的工作流程逐步向正规化进行模仿。但是项目除了代码和客户环境的设备列表，几乎没有什么文档留下给我们。且不说原型文件之类的东西，项目设计稿，部署手册，工作记录之类的一些东西完全没有建档，也有可能是建档了，但是不对我们开放（那不就等于没有）。

项目上云过程

近期给客户做项目上云迁移，现在这家公司的工作流程就是：客户要啥就给啥。客户要迁移方案，项目负责人找到研发部，最后让运维工程师去写，运维工程师两眼一抹黑，这项目咋部署的，啥功能，三方接口调用，业务部署完了怎么验证，完全不清楚，没有文档，也没有人说，问的时候开始挤牙膏。一开始只说了有个数据库的主备模式使用一个第三方软件，说到时候找客户要。

于是乎我开始部署，先登录人家原来的生产环境进行一顿摸黑式的勘察，各种功能的实现完全是凭经验去看当初是怎么做的。搞清楚了之后在云主机上重新部署环境，一开始部署的都很顺利，数据库主备的时候出了岔子，客户自己都不知道用什么方式进行主备，没定好方案。我只能装好数据库先放着。

等后来客户提供了热备的软件和安装手册，我一看，好家伙，这个软件需要额外的网卡和虚拟 IP（倒也可以预想得到）。好在客户的联系人也是有一些技术水平的，发安装手册时候他就已经在申请了。这一环节搞定之后，环境就都准备好了，客户那边也确定了业务停机的时间。第二天一早开始数据迁移。

数据迁移的过程就是简单的导出、压缩、上传、解压、导入。这些都很顺利，上午差不多 9 点左右开始，下午 2 点多其实项目就已经拉起来了。然后客户问了一句，SAP 和地磅怎么样。一句话把我问懵了，啥啥啥，SAP 是啥，地磅又是啥。我赶紧给负责人打电话，负责人说明了 SAP 和地磅的事情之后又问，怎么没先部署测试环境测试一下。

线上压根就没给测试环境啊，直接给了 4 个设备做生产环境的主机，前端一个，后端一个，数据库俩。

到这我就明白了，这公司的办事流程就是前期完全没准备，先搞个测试环境，摸黑探路，搞完了重新部署生产的，或者测试环境摇身一变升级成生产。

先不管那些，再搞环境肯定来不及，我赶紧跟他问清楚还有什么第三方的东西需要联调，好在就只有这两个。

接下来的过程就是漫长的一拖三了，微信群里最开始只有 6 个人，后来因为需要调通几个端口，涉及到第三方的业务，技术，云主机的技术工程师，逐渐拉成一个 13 人的微信群。到现在，时间过去了快两天，一顿瞎 B 测试，第三方接口回调推送数据的 4 层端口还是不通。

总结项目迁移过程的坑

1. 前期准备一定要充足，主要是项目迁移文档。
   不要觉得自己不会写就交给实施的人去写，实施过程反而是不重要的，要由最了解项目的人去写。
   项目迁移的最终目标就是在新的环境上对原有的业务解决方案重新实现，应用了什么中间件，什么技术都不是迁移文档的重点，重点是原有系统里有什么功能，与哪些第三方有互动，有什么注意事项，这些东西在迁移过程中怎么同步的由指向老环境转移到指向新环境，这样就可以确定都需要哪些人参与了。还有就是迁移完成之后需要进行哪些业务实现上的验证。这些东西在开始实施之前都需要确定好，而不是迁移完成之后一边测试一边写，顺便擦屁股。因为项目迁移本身就是需要保持原子性和一致性的将所有原有的业务解决方案在新的环境上重新实现。
   实现才是目标，而不是部署过程。

2. 迁移目标不明确。
   迁移开始之前，客户自己都对项目迁移没有什么概念，只是以为重新部署，对部署之后的结果没有什么打算。很多都是现场拍板，比如想要 HTTPS 访问，都是部署完成之后才提。

3. 故障点解决的中间环节不透明。
   最后测试出来接口回调不了是网络的 4 层协议不通，怀疑防火墙策略没有放行。但是找云厂商的支持，能得到的回复就是已经开通，实测结果就是不通。解决故障的结果就是一句话，通或者不通，到底是否给解决了，网络是否通常，毫无说服力。而且，效率奇差！！

迁移上云|开局一张图，技能靠爬坑

迁移上云|开局一张图，技能靠爬坑

个人经历过两家公司从0到1上云，迁移和直接上云，记录一些爬”坑“趣事

上云流程+云端网络、应用结构

迁移上云流程+结构图

流程 结构

为啥上云

当然每个公司面对的问题不同，我只能从自身经历的两家公司和自身的一些认知来说，欢迎同学补充。

假设你们是自建机房（IDC就不讨论了），你想想中你们的机房是这样的

但是也有可能是这样式的

有点夸张哈，但是实际自己机房什么样，谁进谁知道

进入正题

机房图片只是调皮一下，真实上云的话考虑无非几点，上云是否可以解决你的关键性问题，

• 成本？成本是否会降下来，成本增加是否解决了其他痛点？。。。

• 安全？中毒还找不到根源？服务器安全策略？被 DDOS 了是不是束手无策？。。。

• 运维？技能靠重启？没两天人员又离职了？漏洞补丁很头疼？。。。

• 性能？搞活动预估、压测不到位机器撑不住？带宽打满了？横向纵向毫无扩展能力？。。。

那么各位同学，你们上云是解决什么问题？或者就是紧跟潮流一开始就在云上？

为什么上云？上云的”坑“有哪些？博客园的上云之路最具参考价值 。 回忆链接

避坑部分

首先要明确你们当前的网络结构，也就是你们在云端满足当前业务场景的网络结构。到了云端一切皆是服务，没有硬件这个概念了。但是常说的网络拓扑还是要有的

• 入：一个请求过来是怎么一层层到达你的服务器的，遇到故障也要一层层排查过来
• 出：一般是请求对外资源，不需要管理的话，简单怼上一个公网ip就开搞了

上云要有一个预估的流程，切记上来直接购买服务资源，这里不是的我们自己花了几百块买的1核1G还是3年的那种哈。具体执行过程中需要按流程梳理时间截点，不明确的话一拖再拖很耗费精力

“坑”之原来如此

• 商务经理——上云对接云厂商一般都有个专属商务经理，年轻的我曾以为这肯定是云官方的，实际有可能不知哪里找的第三方。如果你的消费能力很强，比如几十万以上，请直接官方联系，大客户 。这个时候可能会是官方商务人员与你对接。你想云端用户怎么也几百万吧？小客户呢，就是第三方外包来服务了。如果你是用的“玎*”与你的客服经理联系。那他们的区别是。一个有官方认证，一个没有只是挂了一个title。

• 工单——问题来了需要协调，你肯定又以为是云端的专家直接给你服务的。图样图森破，实则有的时候工单来来回回几次，你嗅到了业余的滋味 ，你祭出你的大杀器，老子要投诉你啊。这时候他要给你转后台了，让你耐心等待。这时换了一个工号来解决你的问题。通常他真能解决你的问题。不要问，问就是经历过了。曾经面试一个运维，他说他干的就是云厂商的客服，解决客户工单问题。解决不了的，会一层一层向上转。所以你第一层替你排查问题的就是这些外包人员如果你是大客户情况紧急请及时联系你的商务经理——（催）协调

• 域名、备案、主体——这几个都是提交资料类型的，剩下的就是等，折腾几次也是有的。其中备案主体一个云账号只能绑定一个主体，这个在社区反馈里10个有8个说坑。

• 欢迎各位同学补充，原来如此系列未完待续。。。

“坑”之自己挖自己跳自己爬

当然还有一些就是自己的锅了

• 搞清楚计算单位——搞清监控中流量、宽带的单位，比如：KB/s和Kbps 可是截然不同的两个概念。压测和监控千万不要搞混，预算不是低了就是高了，监控阈值设置不合理。

• 产品服务计费方式——搞清楚，什么按次的、按量的、组合资源包的、不能算入资源包的，不然你就是今天申请钱，明天申请钱。这都是小事，更大的比如服务停止了，预期资源永久删除的，哭都没地方哈。申请资源用完要收回，只要是你占用资源都会收费。

• 总之好好看产品文档 ——可以避免大多数问题。产品使用限制啊？如果线上产品服务不兼容要提前规避，避免浪费时间。邮件端口、还有他们自己人都说有点坑的云盾啊，自己压测前申请加好白名单。