本故事纯属虚构，请勿对号入座，更别把故事跟作者mapping
================================
公司的会议室里，VP of Engineering踱来踱去，一脸的震怒：
“这个memory的问题，为什么产品Ship之前没有抓到？你们，Hardware Engineering, Software engineering 和 Testing Engineering, 全部失职！你们知道这个bug会给公司带来多大的损失？这个大客户，已经连续在一个星期内，由于这个Bug，发生过四次Network Outage。知道这意味着多少$吗？这个客户已经要求在全网范围内swap out 这种型号的line card,所有的RMA， logistics, etc,费用都是公司负担， cost 大到不可想象！”
Testing Engineering的老印总监马上说：“Software 出Beta release的时候一直都不能on time delivery，我们要meet FRS的deadline,能够把所有的feature测完已经很不容易。customer scenario就没有时间很密集的测了。”
Hardware Engineering的老印总监也随其后说：”我们的hardware，一共spin过4个version，每一次的proto type，都是一早就准时交到software 和testing手里了，他们从来没反馈回来说有发现过memory的error。
VP 转头对着Jack，脸色很难看的说，“你们software，那一张Line card的feature，是谁负责写的？”
Jack还没开口，绮霜说，“是我们组负责的。”
VP很硬气地说：“我不管你用什么办法，立刻找到bug的root cause,先给客户交一个root cause analysis,然后赶紧出个fix！”
绮霜说，“我需要testing部门先allocate resource, 搭一个类似客户环境的test bed, 跑一下客户用的所有feature和等同于客户用的网络traffic 流量，reproduce了这个bug,然后我的staff才能debug找出root cause。而且我觉得hardware部门也得在这件事上allocate 资源，我们现在只知道有memory的error，并不知道这是一个hardware的bug,还是一个software的bug,如果是software的问题，那我部门当然全力以赴立刻出个fix，可是如果是hardware的bug话，问题就大了。"
Testing的老印总监叫苦连天，说我们现在无法分出资源，要reproduce 你们software自己reproduce, 或者你们去找客户支持部门reproduce.
Hardware的老印总监也说，就是，我们忙翻天了，你们software先去reproduce/debug,如果真不是software的问题，再hand over给我们。
绮霜说，”我们software也在开发新feature新产品忙翻了天，而且我们也没有那么多的设备可以用，我也没精力去跟TAC（客户支持部）扯皮，你们testing部门一定得搭环境reproduce"
VP盯着绮霜看了一眼，有些不耐烦的说：“你们各部门之间别相互扯皮了，测试部去找个Engineer搭环境reproduce, software 找个engineer负责debug, hardware待命，三天之内，一定要有root cause analysis 和solution!"
晚上12点，绮霜一脸疲惫的回到家。李毅抱住她，说，怎么样，知道是什么问题了吗？
绮霜摇摇头，测试部的工程师还没把问题复制出来，我刚和下面的工程师 review了我们所有可能trigger memory error 部分的code,没发现有什么可能出错的地方。
然后她叹了口气，说，你说老印们，出了问题永远能理直气壮的把责任推给别人，我们当初software 不能on time delivery,是因为Sales和你们产品市场为了赢客户不停的加feature进来，他们测试部当初在代码 没有ready的时候有大把时间可以用心写出很好的t测试计划，囊括很多customer cases，然后automate 测试计划，等我们的代码一ready,立刻run script来测试所有的test case，完全不会耽误任何测试. 可是他们并没有这样做，所以后来测得很匆忙,很多Scenario都没有测到。这个bug就是个show stopper,如果他们在测试期间抓到，FRS 的dealine 是一定会延迟的。现在问题这么大，给公司造成这么大损失，那个Ravi可是轻飘飘一句话就把问题转移到software来了。
