众所周知，改造遗留系统并不容易。如果系统没有很好的架构和编码，在此基础上做功能升级往往比重新构建一个系统更费时费力。我的团队最近承接了这样一个平台升级改造项目。平台七八年被四五家供应商不断修改，可维护性极差。在升级改造的同时，我们“有幸”直接承担了系统的各项线上运维工作，真正体会到了身陷“软件泥潭”的感觉。1.那些难忘的经历。在立项之初，我们就知道系统原团队在合约到期后会立即退出，所以我们很快进行了交接，在系统升级之前就开始了运维工作。以下是我们的一些经验片段，可以让您一窥该系统的强大功能。1）“定时炸弹”系统中有这样一个功能，可以定时修改首页某个区域的内容。有一次，运营商通过后台上传要修改的内容后，发现上传错误，但系统并没有提供删除和更新上传内容的功能。幸运的是，时间是可以修改的，所以运营商巧妙地将时间设置为一年后生效，从而避免了系统主页被更改为错误信息。一年后，我们团队接手，首页被莫名修改。原本设置定时任务的人已经走了，留下我们的研发和运维人员苦苦排查问题直到深夜。2）“说谎”的流水线在交接运维工作时被告知客户需要经常做各种活动，而且每个活动都需要修改代码并重新上线。团队一度庆幸，虽然系统老了，但还是可以通过Jenkins上线。但接手后，我们发现自己“幼稚”了。该系统由4个子系统和大约20个单独部署的服务组成，使用不同的语言和框架。第一次使用流水线上线的时候，我们以为点一下按钮就搞定了，结果发现最后只有少量的服务部署提示成功。更何况，这些提示的部署成功实际上可能已经失败了。有些提示失败，但实际上部署成功。当我们联系原运维团队时，被告知由于年久失修，这些管线有的可以使用，有的不能使用。为了不影响第二天的正常使用，我们的研发和运维人员一直上线到天亮。3)尴尬的日志和难解的评论。系统经常会出现一些小错误，虽然不是致命的，但会被客户的业务部门投诉。比如线索模块，负责处理线索数据并发送到下游。每周总会无缘无故丢失几条数据，于是我们开始排查。首先是检查日志。当我们找到处理线索的日志时，吓了一跳，只见满屏的日志上显示着大写的“END”。没有时间信息，也没有相关的处理信息，但是每一条数据都处理成功。打印“END”，找不到任何有用的信息。我们看代码的时候，意料之中的名字没有传达出意思，好在有注释。不过注释都是乱码，自然帮不了我们，还是修改代码吧。修改后，我惊奇地发现，有的评论变成了中文可读的，而有的则变成了另一种乱码。不管我怎么改，只有一部分评论正常了，其他的还是乱码。没想到，前几波研发团队写的注释，用的代码都不一样。二、成因的初步探讨那么这个系统是如何发展到下面这种情况的呢？从我们近期的观察来看，以下几点可能值得注意：1）缺乏长远规划，各种“债”不断堆积企业的复杂性，使得交付团队处境艰难，面临频繁、紧急的业务需求，交付团队往往依赖技术人员强行响应，导致各种临时方案的堆积，各种“债”的堆积，使得系统越来越难以维护。还有一个现象就是因为系统的各种依赖太过复杂，每一个新的供应商基本上都不愿意去修改或者优化之前的代码，只是增加了功能而已。导致系统管理后台出现多个同名模块，功能完全不同，完全分不清到底用的是哪个。久而久之，系统的操作越来越难，换个运营商肯定不行。2）运维功能不足。由于闭环系统功能不足，开发阶段后只有运维人员支持，很多迫切的需求都是靠运维人员改数据库实现的。当通过换库响应需求，临时修改代码成为家常便饭时，整个系统变得更加脆弱。三、应对策略与建议最好的策略自然是不要过早承接遗留系统的运维工作，至少要等到升级改造工作进行到一定阶段后，再承接。新系统上线。但现实往往是骨感的。如果必须立即交接，建议至少做到以下几点：1）延长交接周期，交接期间做足功课，交接清单更详细，交接期间做好日程安排，确保双方团队充分沟通，从业务和技术层面进行详细的讲解。交接清单参考示例见文末附录。如果项目使用了一些看板或者相关的需求开发管理工具，也要注意交接。对于交接单中的文件，很可能对方严重缺乏，所以一方面要让对方尽量补齐相关文件，另一方面也要就清单中的各个主题进行交接沟通会，尽可能多地获取知识，交接过程中注意做好总结。2）保证开发者的可调试环境能够正常运行非常重要。交接阶段虽然拿到了大量的文档，但是文档的内容和现在的代码是否一致，如何快速排查和修复紧迫的bug？这些最终都需要可运行和可调试的代码来给出答案。以这个项目为例，在交接期间，只有TechLead和一个运维同事与原团队进行了所有的技术和运维交接工作。面对多种语言、多种框架实现的各种代码，有点力不从心。幸运的是，果断的要求对方协助在我们研发的机器上运行调试了各种代码。交接后，我们马上赶上了双十一活动的开展。结果在凌晨的抢购时间，商品购买页面的购买按钮还是灰色的，无法点击。于是现场调试发现了系统处理时间的bug并及时修复。业务没有受到太大影响。3）完善监控和日志功能，变被动为主动。这一点不需要过多解释。通过监控的完善和日志的完善，团队可以及早发现系统中的各种问题，出现异常时可以追溯原因，不致于无所适从。4）与前任球队保持良好的关系。虽然这不是技术措施，但有时非常有效。毕竟，前任团队已经通过努力熟悉了这个系统的本质。当遇到一些紧急问题时，他们的一个建议可能会节省一天的故障排除时间。4.结语虽然这样的“软件泥潭”让团队的行动非常艰难，但是我们在处理和解决各种企业级问题上积累了经验，我想团队中的每个人都会从中有所收获。在系统运维工作顺利进行后，团队终于开启了遗留系统改造之旅。附录1：交接清单示例（设计与开发）类别内容项目管理项目议程会议记录系统图项目要素业务功能清单业务流程图需求变更记录操作说明/用户手册常见问题清单界面设计UE设计稿高保真画面设计稿需求变更表系统设计系统架构设计图部署架构图DB关联图（ER图）及DB详细设计系统集成关系图对接系统清单及对接系统接口清单源码开发制作操作说明测试系统测试用例及系统测试报告性能测试用例及性能测试报告用户测试用例用户测试签名附录2：交接单示例（运维相关）类别内容在线相关在线判断表在线操作记录上线版本说明ription临时对应系统基础设施硬件资源列表软件资源列表服务器/系统账号权限系统工具-付费/免费软件运维系统运维工作列表近六个月运维工作响应过程运维系统故障对应过程SLA（服务水平协议）DEVOPS（开发运维一体化）CI/CD工具和使用监控工具备份管理代码库和分支管理数据库相关配置和策略
