一个Bug的价格

最近工作中的一个例子：

我们的应用系统涉及了多个机器，开发的软件运行在系统Ｃ，从前端系统Ｇ下载配置文件，处理实时数据输出到中间系统Ａ，然后转发到系统Ｅ，最终到达客户端；一般而言开发人员仅在Ｃ上检查结果，测试人员在客户端进行端到端测试．

测试人员报告了一个诡异的ｂｕｇ：软件在Ｃ上第一次启动后，系统在Ｅ端没有输出，必须重新启动一次后， 系统才可以正常工作。开发人员检查了系统Ｃ和Ａ，在重启前后系统Ｃ和Ａ一切正常，进一步研究发现第一次启动时G上的配置文件可以生效，但系统不能正常工作，重新启动后G上的配置文件部分生效，但系统可以工作，然后扯皮开始：

测试：我们只看端到端测试结果，请开发人员检查中间系统

开发：　我们的开发部的职责仅限于Ｃ系统，Ｇ／Ａ／Ｅ上运行的都是通用系统，种种迹象表明这一个G上的配置问题，或者是一个A上的环境问题

G系统支持人员：为什么只有你们的配置文件有问题？给日志先...

A系统支持人员：别人没有报告类似问题，给点日志先...

...

讨论一周未果，最后开发和测试一起在Ｃ上进行网络抓包，比较可以工作的包和不能工作的包， 发现重启动前网络通信协议包被破坏，原因在于软件在解析Ｇ上的配置文件时，将一个字符串类型当作ｕｉｎｔ６４传给了Ａ系统（协议包被破坏，但是系统不报错），导致了Ｅ不能从Ａ获取数据，　修改了一行代码后问题解决， 为什么重启后可以工作呢？原因在于软件的另一个bug：重启动后，软件不再去从G系统下载配置文件而采用了系统默认值。

该ｂｕｇ的价格＝３个人周（１ＱＡ＋１Ｄｅｖ　＋１ＰＭ＋１技术支持）〉１０，０００　ＣＮＹ

经验：

1。复杂系统中错误处理的蝴蝶效应： 一个不恰当的错误处理会让错误以一种不可思议的表象蔓延到毫不相关的模块

2。复杂系统中模糊的团队的职责边界

3。永远不要对自己的代码过于自信