一个成功的软件，完整的开发时间可能只占其整个生命周期的四分之一不到。软件发布后，需要运维。运维的视角和开发的视角视角是很不一样的，但是有一点就是运维数据可以反哺开发。同时，在开发中也要考虑可操作性。很重要的一点是日志。没有日志，运维多半是盲目的。日志怎么写取决于运维的需要。通常有一些常见的场景（以典型互联网应用为例）：1.访问来源，包括访问次数、访问者数据，如用户名、IP等。2.基于上一点的细化，access接口，读，写，删除...3.软件系统里面的核心环节，比如我有一个直接同步中美文件的系统，同步情况的运维时间到掌握。4.软件系统对其他依赖系统的访问。比如我的系统依赖分布式缓存，所以需要了解缓存的访问量，是否超时等。5、系统异常，如磁盘已满。记录这些信息的目的一般是：帮助分析系统容量，方便扩容；及早发现系统的某些部分何时无法正常工作；发生严重故障后定位问题原因。认识到这些需求之后，接下来就是如何实现这些需求了。上面提到的5点，有的可以通过抛出异常来实现，比如访问分布式缓存超时，有的明显不会异常，比如正常访问缓存。我觉得可以统一规范的记录下来，这个方法就是编码。记得以前用Windows98/2000的时候经常遇到蓝屏。蓝屏上会出现一堆看不懂的英文，而且一直伴随着错误代码。虽然看到这个东西我心情不是很好，但是相信微软的工程师一定能从那个奇怪的状态码中判断出哪里出了问题，是硬盘坏了吗？光驱卡住了？等等……其实类似的做法也用在数据库中，比如MySQL。使用统一的代码来表示错误（或者正常但核心的业务点）最大的好处是便于查找、统计和分析，在几万行一页一页的日志文件中找到有趣的信息时间翻页是不现实的。稍微做过一点运维的，肯定会用到grep、awk、wc等工具。这时候，如果信息用代码标注，那真是方便啊！比如我用代码FS_DOWN_200表示系统下载访问正常，日志写在monitor.log文件中。我可以用一行shell统计4月22日5:00到6:00之间的正常访问量：$grepFS_DOWN_200monitor.log|grep"2014-04-2205:"|wc-l每个日志具体记录的是什么more详细的，基本上就是时间，日志编码，以及额外有用的信息，比如：2014-04-2205:06:18,561-FS_DOWN_200216UT8TFSDXc8XXXagOFbXj.jpg除了时间和日志编码，还有响应时间（216ms）和具体访问的文件名。当然如果有日志监控分析系统就更好了！可以在系统中输入关键字监控，比如统计每分钟出现的次数，然后查看一天或一周的流量趋势图。进一步的，如果金额异常，让系统发出警报。如果没有关键词，很难从海量日志中分析和监控复杂多样的信息。为什么日志代码要设计成FS_DOWN_200？让我解释一下。这段代码分为三段：1.FS：表示我们的系统，是最高级别。公司有很多系统，所以每个系统都定义了自己的标志。2.DOWN：表示我们系统中的一个核心业务点或者访问其他依赖系统，也可以是UP（上传），SYNC（同步），或者TAIR（访问缓存系统）。3.200：具体的健康码，参考HTTP规范，200表示OK，其他还有404（不存在），504（超时）等。有了这些代码，再结合公司的监控系统，我们做统计分析就很方便了。下载多少，上传多少，成功多少，失败多少，访问其他依赖系统多少，失败率一目了然。除了监控之外，当某些值突然发生变化时，比如下载/上传突然下降，或者访问其他系统的超时时间大幅增加，它可以及时做出响应。日志对于运维来说是非常重要的，如果你不接触运维，你怎么能了解它真正的需求，所以我说，你不做运维，你就不懂日志。
