当优化小组进入会议室的时候，被眼前的场景吓了一跳。整个会议室做的满满当当的，甚至连后排的座位上都坐了人。笔者做优化差不多十年了，还第一次遇到这样的业务调研。一般情况下，业务部门往往不是特别重视业务调研，认为这是走过场，业务部门反馈的问题往往不会得到很好的解决。不过这次不同，业务部门像当年欢迎解放军进城一样欢迎我们，确实让我们受宠若惊。不过随着会议的进行，大家的心情也变得沉重起来。会上业务部门提出了十三大类，上百个问题。总结起来包罗万象，有些是系统性能方面的问题，有些是业务逻辑方面的问题，甚至有些很可能是操作方面的问题。看样子业务部门为这次优化做了十分全面的准备。
会后，我们梳理了会上提出的问题，进行了筛选，选出比较严重的二十多个和性能关系比较大的问题，准备随后几天对这些问题进行确认和分析。从这些问题看，其中有十多个问题是和业务相关的，不过这些问题里也反馈出一些系统存在的问题。比如科目汇总表经常在半夜2点的时候死掉，这个问题在后续与运维人员调研和开发商调研时都没有人提及，根据这个线索，后期优化项目组发现了一个十分重大额隐患。
在会上业务部门提出的问题中有十多个问题是和系统性能直接相关的问题，比如每到月底系统会特别的慢，比平时几乎慢了一倍；凭证创建、传递、生成和查询的速度都特别慢，慢到无法忍受，月底时创建一个凭证要5分多钟；实时汇总基本上在3分钟以上，哪怕汇总的数据很少，而工具汇总经常就白屏了。
这回业务调研可以说是收获满满，这样高质量的业务调研为优化项目组提供了十分有价值的资料，可以帮助优化工作向着正确的放心前进。而大多数的优化工作并不关注业务部门的需求，经常是通过黑盒方式，不管三七二十一，从数据库系统、操作系统、硬件上面一通采集，然后针对性的做一些调整，然后找到一些缺少索引和统计信息不准确导致执行计划错误的的SQL优化一下，拿出来的成绩单也还算可以了。整体性能提升30%，部分模块甚至提升上百倍。这种优化虽然也能起到一定的作用，但是实际上并不是业务部门所需要的优化。基于准确的业务部门的优化需求的，是一种白盒结合黑盒的方法，这种方法重点在于解决业务部门使用系统上的问题，能够真正的帮助业务部门解决性能问题，而不是只是获得一些纸面上的提升。实际上最早做优化的时候，我们也是这么做的，做完后，指标上特别漂亮，不过有时候业务部门并不认可。
为了进一步理解昨天业务部门提出的问题，第二天，优化项目组的技术人员到财务部进行现场调研。技术人员和财务部的相关接口人针对昨天整理出来的清单进行一一确认。记录下每个问题对应的应用模块的业务逻辑，并对每个问题模块进行实际操作，记录下响应的情况以及响应时间等数据。从现场调研的情况来看，系统的状态比昨天会上听到的更加糟糕。很多模块点击后要数分钟甚至几十分钟才能显示结果，甚至有很多模块有时候都直接出现网页超时，无法获得结果。
业务调研的结果让我们彻底放弃了来现场前摸底分析会制定的优化计划，准备采取白盒优化为主的方案来完成这个项目。优化项目组分为两个小组，一个小组采用白盒的方法针对用户提出的二十多个优化需求进行点对点分析；另外一个小组采用黑盒优化的方法从系统层进行分析，对一些通用性的问题进行分析，提出优化方案。白盒优化需要更多的分析系统与应用，不了解应用就无法完成本次优化任务了。于是我们决定第一阶段的研发调研力度要加强。因为两个试点省份使用的财务系统是同一个开发商开发的同一个版本。不过这两个试点省的系统是开发商的两个不同的团队在维护，而且在一些模块上存在个性化定制。因此我们还是决定两个试点现场分别进行开发商调研，主要调研本地开发与维护团队，暂时不和总公司的开发组交流。同时两个现场的调研情况每天进行一次汇总沟通，从中找出共性的问题。
可能有些读者会有所疑问，这套系统是统一开发的，为什么还要这么麻烦在两个现场对本地维护的开发队伍沟通，而不直接和这套系统的开发团队沟通。实际上，财务系统的整体业务架构比较统一，所以一般都会统一进行开发，而各省的个性化业务都会有所不同，所以会在本地保留一个小的开发队伍。主线版本的开发队伍不直接面对客户，他们往往不太了解在各个用户现场所遇到的问题，这些问题往往是有现场开发运维队伍负责解决。所以现场开发运维团队对系统存在的问题的了解更为深刻，对他们的调研会更加顺利。另外一方面，统一版本的开发队伍往往面对来自各个用户现场的需求，因此他们不可能对每个个性化需求都有所响应或者快速响应，必须按照他们的一个较为长期的开发计划进行研发工作，因此他们本身比较排斥一些对他们产品问题的讨论。我们很难从和他们的交流中获得我们所需要的信息。
