刘华：如何在复杂问题中找到最不坏的选项？

作为系统负责人，我的其中一个主要职责就是确保系统所使用的软硬件，包括OS、JDK、Oracle、MQ等软件或中间件的版本还有服务器的型号，是处于厂商维护期内的。

因此，每隔几年，我们都要对系统的底层运行环境进行升级。对于与底层环境、中间件、周边系统高度耦合、架构设计陈旧的遗留系统来说，每次这样的升级都是伤筋动骨，动作很大、风险极高。

自去年开始，我们就在为我们的核心系统的数据库进行升级，数据库版本要从原来的Oracle 11g升级到最新的19c，服务器硬件也要更换。原计划这个升级在今年上半年完成。

由于这是一套运行了十几年的遗留系统，也有前面提到的耦合和架构问题，这次升级不仅涉及到该系统本身，搭建在该系统上的周边系统也会被牵涉。其中一个报表系统就是直接从核心系统的数据库读取数据生成报表的。这次数据库升级，它也必然受到直接影响。

正当我们好不容易把Oracle 19c的测试数据库搭建起来，请求报表系统的团队开展测试时，我们遇到一个棘手问题。

报表团队说，报表引擎是第三方厂商的产品，我们在该引擎上进行报表开发。由于历史原因，这个引擎的版本很旧，早就过了维护期。从厂商官网上查询到，它只支持Oracle 11g。报表团队尝试联系厂商查询该版本是否支持Oracle 19c时，对方答复只能支持到12c。

这就成了我们这次升级的拦路虎。虽然我们可以把核心系统的数据库版本降级到Oracle 12c，但由于12c的维护期只能到后年8月份，这意味着我们明年又要做一次从12c到19c的升级。

而且，当前报表引擎的版本之所以在以前过了维护期也没有进行升级，是因为我们有另外一个项目正在用新的报表系统取代这个引擎。但这个项目今年才启动，我们有几千份报表需要在新系统上进行重新开发，这是一个起码要三年时间的大工程。如果新报表系统迁移不能在明年内完成，我们在明年升级19c时会面临同样的尴尬局面。

在这种情况下，我们不可能有两全其美的方案，只能寻找一个妥协方案。那么我们是怎么做出决策的呢？

01

—

首先，任何复杂问题都不会只有一个标准答案，也不会只有一个选项。我们首先要做的，就是尝试罗列能解决该问题的多个选项，每个选项一定有优劣，然后列举每个选项的好处和坏处。这里没有对错，只有取舍。

在我们的例子中，我们有以下选项：

选项一：继续原升级计划，核心系统和报表系统都运行在Oracle 19c上。对报表系统在19c上进行兼容性测试。

虽然厂商没有确认该版本支持19c，但很重要的原因是该版本太旧了，在它发布和维护的年代，Oracle 19c还没有面世，自然不会对19c进行过官方的兼容性测试，现在该版本已经过保，也不会应我们要求对19c进行额外的测试和确认。所以我们认为我们自己进行兼容性测试可以确认报表引擎能否在19c上运行。

好处：

• 延续原升级计划，一次性解决所有的数据库版本过保问题。

坏处/风险：

• 报表系统厂商没有确认支持Oracle 19c，是一个重要风险点；

• 即使引擎没有问题，一些报表使用的SQL函数在Oracle 19c上可能会有兼容性问题。

选项二：降级核心系统的数据库版本到Oracle 12c，核心系统和报表系统运行在12c上。

好处：

• 报表系统厂商确认支持Oracle 12c，比运行在19c的风险要低。

坏处/风险：

• 由于该报表引擎版本已经过保，运行在12c的风险与19c相若，因为如果出现任何问题，我们都无法得到厂商支持，只能自行解决。依然需要像19c那样开展兼容性测试；

• 由于Oracle 12c在后年也会过保，意味着下一年就要再次启动从12c到19c的升级。

选项三：核心系统运行在Oracle 19c上，为报表系统申请额外服务器运行在Oracle 11g上，两边进行数据同步。

好处：

• Oracle 11g是当前报表引擎已经在运行的版本，最可靠；

• 解耦了核心系统和报表系统对同一个数据库的读写，能大大提升两者的性能；

• 延续原升级计划，一次性解决核心系统的数据库过保问题。

坏处/风险：

• 需要验证不同Oracle版本间数据同步的可行性；

• Oracle 11g即将过保，而且执行这一选项意味着系统要在数据库版本过保的情况下继续运行，需要特批；

• 申请新的服务器从设计到上线起码需要额外6个月时间。

选项四：升级报表引擎到支持Oracle 19c并处于维护期的版本，核心系统和报表系统都运行在19c上。

好处：

• 延续原升级计划，一次性解决所有数据库版本过保问题；

• 彻底解决报表引擎版本过保、没有厂商支持的问题。

坏处/风险：

• 报表引擎升级需要大量额外时间、人力和成本；

• 在该报表系统即将被取代的当口，需要考量这个投入是否值得。

在提出这些选项后，我们也要考虑每个选项的坏处和风险是否有缓解方案，如果有些坏处和风险是根本无法接受的，则不需要考虑。

另外，我们应该指出一个推荐选项，并提供选择它的理由。我们不要仅仅向最终决策人抛出问题，最好能提供解决方案。

内部集体讨论

有了这些选项后，下一步就是展开内部讨论，进行补充，形成共识。

由于复杂问题没有标准答案，每一个选择都有风险和代价。作为职场人，害怕承担风险和责任是本能。而集体决策，就能分摊这些风险和责任，把大家“拖下水”，避免事后决策失误的时候个人被追责，从而避免因为个人不愿承担风险和责任而使事情停步不前。

而这种内部讨论，除了在团队内部进行外，最好也和其他同僚达成共识，组建一个决策联盟，一方面他们能从一个局外人的角度补充团队遗漏的论点和论据，另一方面当我们把决议提交给最终决策人时，他们也能帮个嘴。

上文提到的那些选项，其实就是经过内部讨论补充、丰富后的版本，而且我们一致认为第一个选项是我们的推荐选项。

得到最终决策人的认可

当内部达成共识后，最后一步就是提交给最终决策人做最后的拍板。这个最终决策人往往就是部门的一把手或你的老板。

这个时候，除了把问题、选项（含各选项优劣）、内部决议通过邮件或文档的形式结构化总结以外，建议专门给TA开一个会进行解释和讨论，而且最好把之前参与讨论的同僚们都拉上，他们会在关键时刻进行有益补充。

在我们的这个例子中，虽然我们内部推荐的是选项一，但和老板讨论后，他认为既然报表引擎厂商明确宣称不支持Oracle 19c，我们就不能承担这个风险。他更认可选项二，就是降级到Oracle 12c。他明白这个选项背后的成本。

我们也尊重这个选择，只要大家明白这个选择的代价。于是我们基于这个结果，拟定了接下来的行动计划：

1. 询问服务器团队降级所需要的手续、流程和时间；

2. 报表团队开展基于Oracle 12c的兼容性测试。

以上这三步，便是我们面对复杂问题进行决策的“三步曲”。

灵活变通

通过询问服务器团队，我们发现选项二的经济成本和时间成本远超原来的预期。

由于在我们公司的标准模式里，Oracle 12c和Oracle 19c的Linux版本是不一样的。按照公司流程，把现有的Oracle 19c服务器降级成12c意味着整个服务器的重构，最少需要8个星期。

也因为同样的原因，下一年我们要再把Oracle 12c升级到19c的时候，不能在同一套服务器上直接升级，需要重新采购新的服务器进行迁移，等于把这两年的工作全部要重新做一遍，人力成本和硬件成本高昂。

更要命的是，如果这个报表引擎不能在下一年内被替换掉，我们在下一年会面对同样的问题。而这可以说是大概率事件。

简单来说，选项二的代价过于高昂。

基于这种情况，我们要找新的出路。我们把选项三进行了一些调整。

由于我们现有的数据库服务器就是Oracle 11g，我们可以把这套旧服务器保留给报表系统专用，而新的数据库服务器继续完成Oracle 19c的升级，只供核心系统使用。新旧数据库之间通过数据同步工具（OGG）实现数据同步。当然，前提是OGG可以支持不同版本间的数据同步。

我们立马找DBA进行了实验，验证了OGG可以从Oracle 19c把数据同步到11g，也得到了Oracle官方确认这个方法是可行的。

这个选项的代价是，旧的数据库服务器和Oracle 11g在将来一段时间内都要在过保的情况下使用，按照我们公司的流程，需要拿到特批。另外，旧服务器的运行成本也是一笔额外的开销。

但作为现有报表系统被替代前的过渡方案，它是投入最小又能解决大部分问题的最不坏的选项。

现在，我们需要向老板重新呈现选项二和修改后的选项三的优劣，并让他接受和支持新的选项三。

在这里也可以看到，复杂问题的决策并不是一次性的，在这个过程中，灵活变通也非常重要，一旦决定的选择遇到障碍，就要及时重新决策，把前面提到的决策“三步曲”重新走一遍。