10.2.1 一个风控经理的烦恼
最近一个朋友请我吃饭，约了几次之后终于见面。点的菜还没上，就开始听他大倒苦水。
朋友在一个基金公司的风控部门担任风控经理，需要每天给各业务部门提供一些当天或近期金融市场的数据、报表和各风控指标（类似互联网公司的数据分析部门）。
为了减少工作量和成本，同时考虑到业务部门都是用的Excel，朋友做了一个Excel插件小工具分发到各业务部门，包括一些用复杂SQL实现的统计和处理逻辑。这样每天早上一上班，大家就不用找风控部门要数据了，可以直接通过这个插件自动从IT部门负责的公司数据库获取处理好的数据、报表和各风控指标。
这个工具确实解决了一些问题，也得到了各业务部门的认可，但由于时间比较紧张，性能优化方面没有考虑太多。随着业务拓展和小工具的不断分发，开始出现队列阻塞的问题：公司服务器出于数据安全考虑和历史原因，用的还是私有云，机房的服务器也比较老旧，同时还有其他定时任务（如备份、数据同步以及其他计算任务等）需要执行，这个工具的执行队列优先级不够，而且本来运行速度慢，所以早上大家一起用的时候队列就开始阻塞，排在队列后面的业务同事就开始抱怨风控部门。
在这个过程中，朋友也发现了一些可以优化的点：虽然各业务部门需求有差异，但许多核心计算统计逻辑是相同的，可以通过多表连接后提前生成几张中间表，这样可以把许多原本访问公司源数据库的请求转移到中间表来复用，从而减少对公司数据库的访问压力，同时通过提前的合并计算，减少大家手里插件的计算运行时间。
说到这里，我们点的鱼头豆腐煲上来了。我给他夹了几块豆腐，问他：“那你想过哪些解决方案？”
豆腐有点烫，他放下了筷子，说了几个优化方案。
1）第一个方案：给IT部门提需求，让他们负责在公司的服务器做一些中间表，把前面提到的常用结果存储下来，相当于缓存。但在IT部门推行的阻力比较大，他们宁愿少一事不愿多一事。
2）第二个方案：风控部门用自己部门的台式电脑做服务器。但是对于这个方案，风控部门的直属领导不认可，因为领导不想接服务器和数据库维护这摊子事儿，反而是希望抽出更多时间做风控模型相关的工作以体现风控部门的价值。
3）最后朋友觉得最靠谱也是最近在调研的方案：优化插件的逻辑，插件只负责从公司数据库获取原始数据，涉及的复杂计算逻辑通过Java实现（朋友学过Java语言），这样就不用IT部门审批，也不会给直属领导增加太多负担，最多就是自己辛苦一些。今天这顿饭就是想问我，这个方案技术上是否可行。
我夹了一碗鱼头边吃边跟他说：“你看，这件事情就跟这鱼头一样，表面看上去没什么刺，但要真吃起来还是得了解里面的结构。”
在大公司做事情，有时问题不一定都能用技术思路解决，这里推荐一个更有效的思路：从各方利益出发去思考问题和解决方案。
首先这个事情，从公司利益最大化出发，应该选择什么方案？对公司来说，在收益一样的情况下最好的方案是成本最低的方案，那么我们来看都有哪些成本。
·存储成本与计算成本：这是一组比较容易量化的成本，简单来说就是服务器硬盘和内存，现在的价格分别是500～1000元/TB和100～200元/GB，对基金公司来说就是毛毛雨了。
·开发成本与运维成本：这组成本有时在一个团队，有时是分离的。在需求一定的情况下，前者一般是一次性成本，后者包括服务器运维、数据库运维和系统运维等长期成本。
·分发成本与管理成本：如果把系统逻辑更多实现在客户端（如插件），那么这里相应会有一个分发成本，即将来系统更新或升级，可能需要通知每个用户也做对应的客户端升级。系统使用过程中也会产生沟通、培训等管理成本，管理成本往往是公司运营过程中最大的一块成本，也是最容易被忽略的成本。
上述成本从上到下是依次增加的，从公司的角度来说，会倾向于选择边际成本最低的方案，同时在可预期的情况下会倾向于一次性成本。所以你提的改进客户端的方案基本不可行，表面上看沟通的阻力最小，不需要经IT部门配合以及直属领导审批就能开发完成，但是从公司角度来看，隐含的管理成本可能超出想象。
·你用Java把所有逻辑写在客户端，公司同事用的时候要不要装Java环境？还是你打算花更多时间写一个基于Java的可执行客户端？
·有新同事入职了，要不要把安装和使用方法都培训一遍？
·培训和答疑多了，会不会需要专门招个人来干这个？
·安装、更新和使用这么复杂，本地同事还能手把手教，异地办公的同事咋办？
·如果你离职了，有没有其他人能接手这个工具的维护工作？
其次，不是所有对公司有利的项目都能被顺利推动。我们要看一看这里面的每个角色面临什么利益诉求，如表10-1所示。
表10-1 各角色利益诉求
基于上面的利益诉求分析，我最后给朋友推荐的方案如下。
·先看直接加硬盘内存能不能搞定，这是所有方案中成本最低的方案。
·如果不行，找领导出面与IT部门协调，要一个已有虚拟机的权限或申请购买一台新的机器，朋友自己负责部署和开发数据中间表，可以用最简单粗暴的Python+定时任务的形式。当然如果公司有成熟的Java开发和发布体系的话按规范开发和部署也可以。从公司角度来说，这样是边际成本最低的方案，同时对IT部门来说也是相对更容易接受的，阻力不会那么大。
·如果这件事情的价值在公司内被验证，各业务部门认可风控部门提供的这个服务，那么可以顺水推舟交接给IT部门。当然仅限服务器和数据库维护交接，代码和服务这块建议还是风控部门自己维护，即使是这样也比部门自己维护一个台式机服务器好多了，至少服务器稳定性、数据库备份这些都可以复用IT部门已有的解决方案，这样也可以预期有更多的时间去做风控模型。
说完我把最后一块鱼头吃完，期待地看着他，不知道他有没有接受我的方案。朋友看着钵里剩下的几块豆腐若有所思，我想他应该学到了很多。