原则四：监控，监控，还是监控（Monitor, monitor, monitor）

    从应用部署到数据中心的第一天开始，就要意识到，没有人能够7x24小时的盯着几十个应用系统，近百个应用程序的运行状态。有没有down机，有没有程序崩溃，有没有数据库死锁，服务是否始终可用，这些不但是困扰工程师的问题，更是牵扯到客户支持，乃至建立产品品牌的重要问题。如果你想"一切尽在掌握"，不想经常（偶尔总是有的，因为未知故障总会发生）在凌晨被运营团队的电话叫醒，那么赶快set up你的自动监控系统，让你的生活轻松起来吧。

    至少有两大类的Monitor群组需要建立起来：

    从客户角度：

    ·服务的可用时间/失效时间

    ·服务响应延迟

    ·客户累积服务次数

    从系统容量角度：

    ·各应用服务器的CPU/内存/存储负载统计

    ·高峰与平均比（Peak to mean ratio）

    ·应用服务失效/崩溃/延迟报警

    ·应用服务自动恢复通知

    ·数据同步延迟和失效警报

    ·后台日常处理日报/周报/月报，趋势图

    原则五：保持简捷（Keep It Simple Stupid, KISS）

    传统软件开发中的变更管理是一个难题，在互联网应用系统开发中变更则比过去更加频繁，同时对产品质量的要求则更高。面对这个难题，普遍的结论是，唯一不变的就是变化本身。然而实战中，控制变化的规模和影响，仍然需要找出一些"以不变应万变"的准则，这对于提高产品开发效率和保持高质量至关重要。

    分清"保持"与"非保持"内容

    ·业务需求总会变化，属于"非保持"，架构设计上充分考虑其变化，而非特化。

    ·而软件本身像一个不断成长进化的生命，有自己的DNA。找到DNA，就找到了"保持"，例如设计的可扩展性，可维护性，可测试性。

    简单原则

    ·代码写得越多，维护越复杂，需要不断地通过重构来简化。

    ·复杂的系统容易出错，维护成本高，要避免设计单个复杂系统。

    ·如果测试人员需要费九牛二虎之力才能理解"天才"的设计和实现，最好抛弃它。否则有一天你会为测试覆盖率难以提高，故障重现困难而沮丧。

    原则六：即时架构（Just in Time Architect）

    即时架构是在寻找非常好的设计和资源限制之间所做出的实用选择，此原则可能更加适用于快速变化的软件开发领域，例如互联网，而非严谨的产品线软件开发。"设计"和"重构"成为每个版本开发周期中不断重复的迭代步骤。

    即时设计

    ·在每个版本只有一个月的设计、开发和测试周期的约束下，要将基础设施（Infrastructure）一次设计到非常好的状态是不可能的。

    ·基础架构可满足未来6个月至1年（视业务增长与投入的预测而定）应用的扩展要求即可。

    即时重构

    ·知道何时、何处需要重构是关键，提前筹划，而不要临阵磨枪。

    ·要为重构预留足够的开发资源。在FreeWheel，新产品开发，现有产品维护和基础架构重构的资源比例大约是25% : 50% : 25%.

    ·重构不是"推到重来"，每次重构一部分要好得多，否则你的测试团队负担太重，会导致产品质量波动。

    以上是FreeWheel中国研发团队在研发Monetization Rights Management，MRM在线视频广告平台过程中的一些实战经验分享，在QCon 2009 Beijing大会演讲内容基础上部分整理。

作者简介：

    本文作者系FreeWheel核心系统技术总监，Email: wangdieda@hotmail.com，欢迎交流，今后有机会希望能与大家分享FreeWheel在利用Hadoop进行日志处理方面的一些心得。