先讲一个小故事，有一次，笔者和几个网站架构师讨论的问题，期间，一位架构师被他们部门总监叫去面试一位应聘者。结果过了十几分钟，这位架构师就回来了，我们都是很奇怪，他笑道：“这位老兄，工作十几年，什么都不会，没有什么好问的。我们问他都问了什么问题，结果都是一些如果没有经历过，就永远不会想到问题，而这些问题只要在大型网站技术一线呆上两三年，就一定会碰到。
一位网站资深架构师曾经说过；在互联网公司呆上一年，相当于在传统软件公司呆三年，他的意思大概是在互联网公司一年遇到比传统软件公司三年遇到问题好多。而且随着业务的快速发展，问题也层出不穷，每年遇到的问题都不同，遇到问题，解决问题，经历了这个过程，技术才能升华，人和技术才能融合为一体，才知道什么技术是真正有用的，什么技术是花拳绣腿。
大型网站的技术本质都很简单，没有花哨的东西，掌握起来也不难。大型网站的架构师最有价值的地方不在于他们掌握了多少技术，而在于他们经历过多少故障。每一次故障都会给公司带来难以估计的利益损失，所以培养一个网站架构师的成本不单要看付了多少薪水，给了多少股票，还要看位引起的故障买了多少次单。 这里列举一些网站的典型故障，我们会发现，在高并发和海量 数据的情况下，很多一般情况下不是问题都会涌出来。 故障现象：某应用服务器集群发布后不久就出现多台服务器相继报警，硬盘可用空间低于警戒值，并且很快有服务器宏机，登录到线上服务器，发现log文件夹的文件迅速增加不断消耗磁盘空间。 原因分析，这是一个普通的应用服务器集群，不需要存储数据，因此服务器配置是一块100GB的小硬盘，安装完操作系统、web服务器Java虚拟机，应用程序后，空闲空间只有几十GB了，正常情况喜下这些磁盘空间足够了，但是应用的开发人员将log输出的level全局配置位Debug。这样一次简单Web请求就会产生大量的log文件输出，在高并发的用户请求下，很快就消耗不多的磁盘空间，
经验教训 应用程序自己的日志输出配置和第三方组件日志输出要分别配置。
检查log配置文件，日志输出级别至少为Warn，并且检查log输出代码调用，调用级别要符合其真实日志级别。
有些开源的第三方组件也会不恰当地输出太多的Error日志，需要关闭这些第三方库的日志输出，至于那些第三方库有问题，只有在遇到问题时才知道。
一起设计吧
