企鹅

　　好像评论畅销书时常会有意外之喜，上次是芒果街小屋，这次是How to be Good。今天收到企鹅中国的豆油，要求授权给他们的官网博客使用，回报是会提供新书的预读本。真不错，很高兴，这样大概可以省掉些淘原版书的麻烦吧。是这篇:如何是好?
　　突然明白豆瓣可能的一种盈利模式，企业用户使用豆瓣资源肯定和我们这些免费散户有所不同吧。不知是不是这样。
　　
　　前两周都比较忙，一周要应付考试，一周DEA，那活不好做，遇到的又是个极强势tough的老大，每日被challenge，通常我叽叽咕咕汇报了一大通当前状态，得到回答是：But you still didn't answer my question。他的question通常都很难搞，不过，此人虽然作风彪悍，自身倒的确很强大，思路清晰，所说是对的，所以，被当面憋在那边倒也没什么太郁闷，反正咱皮厚得很，转身跑出去再四处询问补信息就是了。还是颇有收获的。
　　那里处理的都是真正严重的问题，有趣的地方包括：
　　deadline的意思是，过了这个line，那些客户就真的要死了。死法多种多样，可以是真的工厂无法生产，也可以是被SEC罚重款，更有趣的一种是，员工不能及时得到承诺的培训，劳资关系破裂，工会就组织起罢工了。
　　出问题的业务也花色繁多，非常有趣，比如给各家发廊生产供应洗发水啊什么的。
　　五年前我们每天都在处理客户生产系统数据库崩溃这样的事件，那时候我们都很单纯，每天都煞有其事地和客户讨论你现在该怎么restore数据库，当时我们必须象念经一样的对客户说一句：恢复前，你得和应用人员商量啊，他们同意了，觉得没影响了才可以restore啊。说过这个了（通常还会写下来立字为据的），两个纯DB技术人员就兴致勃勃继续商量怎么进行恢复才好。那时候从来不明白，真正是为什么。现在才清晰起来，重点是，任何技术上的inconsistency都不是最要害的问题，最关键的是系统和现实之间的inconsistency，这才是要付出惨重代价的。纯技术性地消除错误数据，很可能导致不可挽回的严重后果。这种情况下的最佳措施是不要去碰那台已经崩溃的系统，这样至少还保持了大部分现场，补救措施都必须在其它地方进行。从当初念经到现在的清晰真是有很长的过程啊。
　　然后下班时候一片黑茫茫里等班车，听到CoE的人在闲聊，说真搞不懂，那些个客户，就装了使用个DB，怎么就老会down呢，这怎么可能呢？忍不住插了句：每家客户down都是小概率事件，好几年不一定会出一次，但全球那么多系统，每天down个几个是很平常的。人家没说话，但显然不以为然。
　　好吧，当年我们有很长的路要走，现在这个自信的青年离现实就更远了，他还沉浸在完美的理想世界里，都还没开始向外张望呢。沉默是金，黑暗里大家低头上车。冬日渐近，夜长昼短。