3.4 KPI为王
我在Hadoop运维组做到第4个月的时候，一手创立Hadoop运维的经理走了，空降了一位新来的经理。当然，这位经理是不懂Hadoop的，加上他又实在繁忙，所能做的就是从报表入手。比如说每周几千台机器几百条小报警有没有都处理掉，预算做的怎么样，总之都是报表性的东西。至于技术上的，监控怎么做，如何才能更好的自动化，怎样统一归约化的整合集群的各个系统，从来就不是他关心的重点。我辛苦两周做出来一个小的监控系统，可以自动的检测各个集群的一些指标参数，并且支持自定义插件，自动化的生成监测报告发送到邮箱中，他给的评价是“这算啥，T2的工程师都能做。我当时特别火也特别委屈，心里想“T2的工程师都能做，可是为什么一直没有人做呢？站着说话不腰疼。
再比如我们每周都要写Hadoop集群运维周报，内容无非是去几个监控系统上鼠标copy/paste一些数据到一个模板里。其实这样的东西完全可以稍微花些人力写点程序抓点网页完成，可是一直没有人做这个事情，大家就这样一周一周的写下来。反正经理要的就是这个，谁管你怎么得来的呢。
当一家技术公司由技术驱动变成KPI驱动的时候，也就意味着这家公司发展到了一个瓶颈期。不断有前同事跟我聊，说自己想做一些事情，但是经理不让。为什么呢？比如说一个4、5年的产品代码，由于人员的交替加上技术的封闭，必然是有很多丑陋的代码的，这个时候后来接手的人如果是个有责任心又有代码洁癖的人的话，自然就想对代码做些重构和改进。这就带来了一个问题：万一由于这种额外的改动造成产品出现事故，怪谁？经理是不想承担这样的责任的，因为百度的经理不写代码，多一事不如少一事。这样一个技术人员的积极进取心就这样被压制了。还有的经理说，做，可以做，如果一个星期之内可以完成，就去做。可是有多少伟大的产品是一个星期内完成的呢？GFS不是，MapReduce也不是。可是经理才不会管这些，他关心的是他的KPI，是报表。一个东西，如果短期内无法出成果，就不要做。
所以像Puppet这样的工具是不可能出自百度之手的。即便是工程师在平时的工作之中有一些思考，但也很少能有时间形成系统化的，并且能够走出百度被业界认可的东西的。
3.5 会议，还是会议；总结，还是总结；沟通，还是沟通
百度的会议之多，总结之烦，沟通之杂简直是令人闻风丧胆。我在百度的时候，每周至少开3个会，每个会不少于1个小时；每天发送查看邮件不少于40封；每天花在Hi上交流的时间不少于3个小时。有人会问，这么多的沟通会议时间，还有时间干正事嘛？怎么会需要这么多时间沟通交流呢？首先是百度非常看中邮件文化，所有事无论大小都要有个邮件性的总结，学会设定邮件规则是每个百度人的第一课；其次就是百度的部门极其多，据统计整个公司大概有500多个部门和组，工种单一，想要完成一个Project需要跨越很多部门。这就导致了百度内部的沟通成本一直居高不下，会议室都要提前一周甚至两周才能订上。很多rd都是上午过来处理邮件，下午开会，然后晚饭后写代码。
