经过6周拼搏，快速开发工具终于按期完工，并在“1号工程”大规模的开发阶段投入了使用。这个工具经受住了实践考验，对提高开发效率和产品质量发挥了很大的作用。听到同事们对工具赞赏有加，小M和团队成员们觉得所有付出已经得到了加倍的回报。
渐渐地“1号工程”的产品成型了。为了测试产品性能项目组专门进行了一次压力测试，也就是用程序模拟很多人同时使用系统的情况，看看系统最多能够承受多少人使用。
一般情况下随着压力的提高系统只会越来越慢直到瘫痪。但是这次压力测试的时候出现了一个奇怪问题：系统会出现交互信息错位的情况。例如，前台提交了A交易的数据，后台返回的却是B交易结果；前台提交C交易数据，后台却返回了刚刚A交易的结果，完全是所答非所问。
最麻烦的是这个问题总是偶尔发生。做过开发的人都知道，能“稳定”出现的错误不可怕，因为容易抓住，所以排查起来简单。最怕的就是这种若隐若现的问题，因为很难抓到，所以无法跟踪，当然也就很难排查了。
大家都意识到了问题的严重性，项目组立刻召开紧急会议讨论对策。会上首先由压力测试小组简述了情况，之后S总说明会议目的是尽快确定问题和解决思路，而且动作必须快，因为很多开发工作都已经暂停了。
听完S总的发言所有人心里都沉甸甸的。大家都知道事关重大，而且万一是自己负责的部分有问题责任可就大了。由于有这个担忧，在接下来讨论中各个小组重点都在阐述自己那部分的处理机制如何完善，逻辑怎么严谨，力图排除自己那一段的出错可能性。
S总突然意识到讨论的方向不对，于是把责任扛了下来并重新引导讨论方向。他说，自己是项目的主管，不管出了什么问题都将承担主要责任。所以，请大家不必担心责任问题，而是尽量思考可能是哪里出现了错误。S总重新引导果然奏效，会议的方向猛然转变，各组互相之间开始猛挑毛病。
矛头首先指向了前台组。从最直观的现象看前台组的处理是有一定缺陷的，如果发送的是A交易的数据，接收后台返回结果时应该先检查是不是A交易的结果；如果不是A交易的结果应该直接报错，这样就不会出现错位现象了。前台组长承认前台处理机制有缺陷，但是也提出这不是问题的根源，根本问题是错位而不是错位之后怎么处理。
很快讨论重点又指向了平台组，确实有可能是平台把报文送错了。但是，平台组长解释了平台的报文传送机制，简单说只负责按地址把信送到收信人那里。从目前所有监测到数据看报文都正确送到了。而且，按照最初的设计要求，报文的内容平台不关心也不应该关心，所以平台分不出哪个是A交易哪个是B交易的数据。
快速开发工具也被大家怀疑过，因为很多代码都是自动产生的，不知道其中是否会有不可预知的逻辑错误。小M认真分析过产生交互错位的几个交易的代码，从功能上看快速开发工具只是做了某种翻译动作，不会产生意外的不可知错误。
接下来，有人怀疑是操作系统有病毒，建议重装所有系统；还有人怀疑网络受到了干扰，建议调来专用的仪器从传输层查找原因。一时间各种观点层出不穷，但都没有令人信服的核心意见。
刚才在大家激烈讨论的过程中，很多人都没留意S总旁边坐着一位上了点儿岁数的老专家一直没说话。现在大家的观点基本都说完了，老专家这才开口发言。他基本认可刚刚大家的分析，不过提醒大家可能忽视了一个重要方面：对一个复杂的系统来说，可能存在“系统性问题”。也就是说各部分之间的合作关系没有设计好，虽然各部分分开看都没问题，但是合起来就有问题。因此，老专家建议从各模块之间接口标准和通信协议等方面查找原因。(www.xing528.com)
老专家的这个建议很快得到了大家的认可。因为这项工作无法由一个小组单独完成，因此成立了一个跨小组的“攻关小组”专门解决这个问题，小M也被调入其中。
在专家的带领下，攻关小组确定了两个工作方向：第一，全面梳理各组之间的接口和协议，查找可能的疏漏；第二，压力测试小组重新测试，尝试再现错误并且锁定错误的触发条件。
在攻关小组中小M有机会全面了解了“1号工程”的整体工作原理：系统的前台和后台是通过报文联系的。比方说，前台把要处理的事写成一个电报，然后通过平台将电报传输给后台，后台根据电报的内容处理完之后，再把结果通过平台反馈给前台。这种处理机制的好处是一个后台程序可以同时处理很多前台的请求，比传统的一个前台独占一个后台的方式效率高很多。但是，这样的处理机制要求前台、平台、后台三个部分之间密切配合，如何配合的约定就是老专家所说的“协议”。
就在大家梳理协议的过程中，压力测试小组传来好消息，经过了多次尝试之后终于找到了错位现象出现的规律：问题总是出现在最大超时时间附近。
所谓的最大超时时间，是指前台提交交易数据之后多长时间没有收到反馈就认为出错了。比方说，如果最大超时时间是60秒，60秒之后还没有收到后台的反馈前台就报错。现在压力测试小组发现，交互错位现象总是出现在部分交易等了60秒超时报错的时候。
接下来，测试小组就直接在60秒这个临界值附近反复测试并跟踪数据。通过逐笔核对前后台交易数据，很快又有了一个重大发现：在发生交互错位的时候，有些交易前台和后台记录的（成功/失败）执行结果不一致。也就是说，有的交易前台认为失败了，后台却认为成功了。
这可是个重要线索！大家觉得距离问题根源越来越近了，既兴奋又紧张。通过检查那些执行结果不一致的交易的日志文件，终于锁定并再现了问题：
问题的产生过程是这样的。比如前台在第0秒时向后台发出来一个A交易的请求，后台处理完之后时间是第59秒，按照约定后台认为执行成功，于是向前台返回A交易的处理结果。但是，由于存在网络延时或时钟差异，前台等到60秒时并没有收到返回结果，于是超时报错中断执行。但中断之后A交易的返回结果却在第61秒时被送到前台报箱里了。过了一会儿，前台又发起了B交易的请求，后台处理成功之后前台按顺序从报箱里取报文，显然这时取出的报文是刚刚A交易的结果。就这样错位产生了，如果连续积累多次错位之后，系统就彻底凌乱了。
没想到问题原因竟然如此简单，只是前后台的协议没有考虑周全。找到原因后解决起来就比较简单了，而且有多种应对措施。例如，考虑到网络延时和时钟差异，可以让前台多等一会儿，保证超时报错的时后台也认为超时了；还有超时报错之后前台不要立刻进行下一笔交易，而是问问后台刚才最后一笔成功交易是什么，如果是A交易就可以继续执行，如果不是则可以确定失败。当然，原来发现的前台那个处理的疏漏也应该完善。
问题解决之后，S总说新架构下出现的这个疏漏能够早发现是好事，虽然停工几天交了些学费，但改进之后不仅解决了原来的问题，还大大增强了产品的健壮性。
通过这个“小问题”小M对全局的“系统性问题”有了形象的认识。即使每个部分分开看都是对的，但是加起来却可能是错的。同样的，对项目团队而言，只保证自己完成任务是不够的，必须从整体出发考虑问题才能实现目标。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
