baidu-technical-cluture_case.doc

百度工程师的六大意识 ——2006年4月整理 Topic 1：质量意识，——第2页 Topic 2：求实意识，——第4页 Topic 3：进取意识，——第6页 Topic 4：团队意识，——第9页 Topic 5：时间意识，——第11页 Topic 6：沟通意识，——第13页 Topic1：质量意识 ? Point1：不要想当然，不要总是认为质量没有问题，存在侥幸心理 ? Good Case: ??? ??? ?在某模块某天的日志统计中，连接超时的报警上升了3%，这有可能是正常波动，但负责该模块的工程师不是想当然的认为这是正常波动，而是仔细看了数据，最后发现不是正常波动、而是服务确实存在问题。 ? Bad Case: ??????? 某位工程师的程序崩溃了，分析原因时，他说“我当初以为XX程序和YY程序应该是这么定义接口的”， 但他并没有去实际的检查是否确实如此，这就是导致程序崩溃的原因。 ? Point2：时刻牢记：我们的每个程序每天要经受千万网民和亿万流量的考验，要对网民负责 ? Good Case: ??????? 很多相关性的策略改动，虽然可能只会影响0.1%的query，仍然每次都进行大规模的对比测试，来总体评估对用户体验的影响，以确保升级的有效性、避免引入不可知的负面影响。 ? Bad Case: ??????? 死链屏蔽策略出过一个问题，当时由于另外一个模块不稳定，会造成少数首页被误屏蔽。当时意识到这个问题后，觉得比例很小、不算很大的事情，后来发现，这部分被误杀首页虽然不太多，但其中包括一些非常重要的首页，直接造成了3%的用户体验受影响，应该算是很大的事故。 ? Point3：应该用流程来解决具有共性的重复性问题，有流程的严格遵守，没有流程创建流程 ? Good Case: ??????? Spider系统，曾经有一段时间是RD工程师自己运维，即使在此阶段，RD工程师的上线操作仍然按照流程转单，即使自己发起的单子最后是自己操作，也要严格执行转单流程。 ? Bad Case: ??????? 有一次，某位工程师对建库脚本改动了一行代码，在测试时，他觉得改动不大，就对相应的测试流程进行了裁剪，没有回归测试所有类型的库。结果漏过了问题，上线后导致建库事故。 ? Point4：不应该期待依靠别人来发现自己的问题，自己要对自己的代码/产品负责 ? Good Case: ??????? 尽管在大多数的单元测试CHECKLIST里面，并没有要求一定要GDB代码，但还是有很多工程师、主动用GDB来检验自己的代码，我们也提倡这种认真负责的方式。 ? Bad Case: ??????? 某位工程师写完代码后，不情愿自己进行完善的单元测试，而是匆忙提交测试组，结果被测试组稍微一测就发现bug，于是版本一再被打回，既耽误了任务进度、也影响了个人的质量表现。 ? Point5：线上服务永远是第一优先级 ? Good Case: ??????? 某位工程师收到了发给bugs邮件组的一封报告Bad case的邮件，尽管此时已经过了下班时间、他也正要回家，但他看了邮件后、感觉这个问题与自己小组有关、并且是一个需要立刻分析的问题，于是就立即着手推动。如果是自己负责的模块，他会回复email说明自己已经在分析，然后着手分析清楚问题后再定是走是留；如果是组内其他同事负责的模块，他会给组长打个电话，以保证这个问题能得到及时处理。 ? Bad Case: ??????? 某个模块在线上出了问题，自动发出了报警短信。负责该模块的工程师收到了报警短信，但思想上没有引起重视，没有仔细察看为何报警、而是想当然的归之于某个原因，结果拖延了线上服务问题的解决时间。 ? Point6：质量和进度发生冲突的时候，质量优先 ? Good Case: ??????? 做得好的工程师，当他发现实际的工作量超出预计的时候，会提前主动跟经理商量延期，以保证质量为重。 ? Bad Case: ??????? 某位工程师还没有完成所有工作，但是检查点已经到了，为了赶上进度，他在明知自己的版本还不够成熟的情况下，仍然提交测试。这种赶进度是毫无意义的。 Topic 2：求实意识 ? Point1：反对一切弄虚作假 ? -- Good Case ??????????? 工程师在可行性调研报告中，如实地列出在调研中发现的问题，哪怕这正好会证明自己提出的方案不可行。 ? -- Bad Case ???????????某工程师为了巩固某项调研结论，在撰写调研报告时，有意忽略对其不利的数据。 ? Point2：大胆假设小心求证，不放过每一个细节和疑点 ? -- Good Case ??????????? xxx模块过去已经有过测试结论，准确率是95%。但是在模块接手时，接手的工程师