关于遗留系统怎么办？

前段时间经常聊到Legacy System（遗留系统）的一些话题，特别是在IT信息化比较早的行业中，如运营商和金融行业。

运行的系统已经有多年，十多年甚至二、三十年的历史，无论软件架构、硬件架构，还是数据架构，都是使用的很早期的商用解决方案，而且这些架构之间又有很强的耦合性。

比如，我们经常听到大机、小机，DB2，Sybase、Weblogic、WebSphere等等，在开源盛行的互联网行业基本不会用到这样的解决方案，估计在很多人耳中这些都已经是陈旧的历史名词了。

遗留系统，最大的问题：年代久远，人员更迭频繁，对当前的维护人员来说，就是一个黑盒，只知道它外在的能力是什么，但是内部运行逻辑已经没有几个人能讲清楚了。

特别是，当一个技术团队，要面临多个，甚至更多的遗留系统时，情况会更为复杂。

因为这些系统在早期可能是不同的厂商研发的，这时面临的一个问题就是，各种标准都不统一，系统版本、软件版本、部署方式、参数配置、接口设计等等等等。

所以，没有标准，就不会有规模化，更谈不上先进的DevOps、持续交付、SRE等等，这个恰恰是很多传统行业效率和稳定提升的最大的痛点。

当时，我们讨论下来，有几个结论：

1、保守态度，不轻易改变，老的系统，面对的场景没有发生太大变化，原来什么模式就是什么模式，不要为了改变而改变，比如运营商的CT系统，银行的核心交易系统，核心关键，关乎国计民生。

同时，业务特性的原因，本身不会有很频繁很大的变更，这种时候，现有手段，慢一点、稳妥一点，哪怕流程繁琐一点都没问题。

如果改，就可会带来极大的风险，也不会带来太大收益，不改，也能维护下去，孰优孰劣，自然就清楚了。

现在运维有一种提法，叫做双态运维，就是针对系统特点，分为稳态和敏态，不同场景采用不同的模式。

2、重构过渡，如果业务场景变化了，要求系统必须能跟上节奏，这种情况下，建议通过重构，且逐步迁移的方式过渡。

也就是，根据新的场景，设计适应的技术架构，能够满足效率、稳定和成本的要求，然后老系统上的业务和流量逐步迁移过去。

如果是直接在承载业务运行的老系统上改，成本和风险会非常高，实际情况下是不可行的。

3、从现在开始，重视标准统一，前面提到传统行业的软件体系，大多是多厂商建设，标准不统一。

但不管是做DevOps，还是SRE，甚至最基础的自动化，标准都是前提中的前提。

所以，如果当前正在规划新的技术体系，或者有针对某些遗留系统重构的机会，从一开始规划好各种标准体系，就非常重要，建设前没有标准，事后再去统一标准，基本就没有机会了。



互联网的技术体系，从最早期的单体架构，没有标准，到系统拆分的服务化演进，形成统一标准，再到基于统一标准的运维自动化、持续交付以及稳定性建设，最终形成大中台的体系，也是遵从着这样一个过程和规律走下来。

只不过，互联网公司在早期没有太大的业务和技术的包袱，所以可以小步（甚至大步）快跑，大胆试错，快速迭代，整个过程的进展会更快一些，但是规律是一样的。

不过当规模到了一定体量，所面对的问题，跟传统行业也是一样的，就是，也一样会有遗留系统。

既不可能随意放弃（还在承载业务），也不可能说重构就重构，成本和代价是必须要考虑的。

比如，互联网巨头Google也一样会面对类似的问题。以下是Google SRE第二本书中关于遗留系统的内容，有些共鸣，这两天刚看到，这里一并分享下。

Google专门提遗留系统，主要原因也是早期还没统一标准，到了后期部分系统也没改造，所以就没法融入Google强大的自动化体系中。

仍然要靠大量的人力维护，这也是SRE日常要花大量精力去做的繁琐的事情，被Google归为Toil事项。

4大原则，跟我们之前自己总结的有几点相似，但是Google有些更具体的实践。具体怎么做，就直接看原文吧：

The journey away from a legacy system usually follows this path:

Avoidance（规避）: There are many reasons to not tackle this problem head on: you may not have the resources to replace this system. You judge the cost and risk to your business as not worth the cost of a replacement. There may not be any substan‐ tially better solutions commercially available. Avoidance is effectively choosing to accept technical debt and to move away from SRE principles and toward sys‐ tem administration.

Encapsulation/augmentation（封装/加强）: You can bring SREs on board to build a shell of abstracted APIs, automation, configuration management, monitoring, and test‐ ing around these legacy systems that will offload work from SAs. The legacy sys‐ tem remains brittle to change, but now you can at least reliably identify misbehavior and roll back when appropriate. This tactic is still avoidance, but is a bit like refinancing high-interest technical debt into low-interest technical debt. It’s usually a stopgap measure to prepare for an incremental replacement.

Replacement/refactoring(替换/重构): Replacing a legacy system can require a vast amount of determination, patience, communication, and documentation. It’s best under‐ taken incrementally. One approach is to define a common interface that sits in front of and abstracts a legacy system. This strategy helps you slowly and safely migrate users to alternatives using release engineering techniques like canarying or blue-green deployments. Often, the “specification” of a legacy system is really defined only by its historical usage, so it’s helpful to build production-sized data sets of historical expected inputs and outputs to build confidence that new sys‐ tems aren’t diverging from expected behavior (or are diverging in an expected way).

Retirement/custodial ownership(退休/托管所有权): Eventually the majority of customers or func‐ tionality is migrated to one or more alternatives. To align business incentives, stragglers who haven’t migrated can assume custodial ownership of remnants of the legacy system.

—————END—————