程序开发中的“人类容错性” — — 老兵不死

周末得空，把前一阵买的MEAP版本的Big Data已经出了的两张给翻完了，觉得有点不划算，主要是内容之前在Nathan Marz的博客，以及Twitter发布出来的各类Slides里都已经看过了（话说Twitter去年年头上说Rainbird要开源到现在也是坑爹地没个影）。但是有一个新词儿还是让我觉得“心有戚戚焉”，把最近在Team里数据处理架构做的各种迁移工作的精髓给说出来了，就是这个Human Fault-Tolerance。

在这个人人都热衷于叫唤Big Data，讨论CAP理论的时候，Nathan同学一针见血地指出了一点，其实CAP也好，Cassandra的Dynamo模型也好，HBase的Big Table模型也好，看似非常酷非常好用，解决或者部分解决了各种一致性和可用性问题，但是其实对于Big Data处理的架构的最关键的一点，在于对于各种人类错误的容错性。

其实即使在没有海量数据需要处理的时候，各个程序也要考虑各种人类容错性。最简单的例子就在设计数据库的时候，对于删除操作大家都喜欢用个标记字段来标记删除，而不是真把记录删掉。类似的，在各种实时数据处理的事务里，除了普通的各种check和特殊情况考虑之外，通常有经验的程序员会做两件事情，一个是做日志，记录所有实时输入的日志，而是在整个处理的逻辑外面捕获所有的Exception，然后对Exception也会记录日志。做这些事情的原因是有这样一个假设，人会犯错，程序员会写出Bug。即使对程序做了充分的测试，但是当程序进入真实环境运行的时候，仍然会有你想不到的意外情况发生。当意外发生的时候，这些日志，记录能够帮助你把数据恢复到一个正常的状态下。记得在我工作的第一个年头里，就曾经花过一整天，将由于一个Bug引发的数据错误通过人肉SQL恢复过来。

当进入Big Data时代的时候，光光依靠简单的日志记录和人工恢复，已经不能够解决这些问题了。一天如果有个几条数据在几千条数据里面出错，也许你能够手工恢复过来；但是如果当一天的数据有几亿条，聚合后生成的数据记录也有几千条的时候，恐怕你就不能使用记录错误日志，然后人肉恢复的方式来解决问题了。而需要依靠在系统实现的架构层面来解决这些问题，Twitter推荐的实现方式就是让事实数据immutable，所以所有的数据都会记录，要看的数据是基于事实数据，计算出来的视图，非常简单粗暴，但是有效的方式。

话说回来，基本上，能不能写出Human Fault-Tolerance可以看做是一个程序员是否有充足的工业界工作经验的一条标准，这个不是依靠聪明和天赋能够解决的问题，而是完全依靠血泪教训得来的，从这个角度讲，老兵不死。虽然IT特别是互联网行业常常充斥着“30岁要转行，因为加班加不动了”，但是我向来是以为，有经验的工程师的价值始终被低估了。即使是不是Super Star的老工程师，也许光光写新功能写算法，未必比新人强出多少，但是这些血泪教训带来的经验，只要能够躲过一次问题，带来的价值也许就是一个工程师一两个月的工作量了（当然，无论如何记得，10年工作经验和1年工作经验重复10次的差别）。当然，更好地是团队能够拥有天才程序员，比你年轻比你聪明还比你身体好，比如Nathan Marz同学……