架构师最优价值的地方不在于他们掌握了多少技术，而在于他们经历了多少故障。
写日志引发故障
硬盘空间低于警戒值, log 输出的 level 配置为 debug, 这样一个简单的web请求就会产生大量的log。
经验教训:
- 应用程序自己的日志输出配置和第三方组件日志输出要分别配置。
- 检查 log 配置文件，日志输出级别至少是 Warn
高并发数据库引发的故障
某应用发布后，数据库 Load 居高不下，超出正常水平，报警。
原因分析: 检查数据库，发现报警是因为某条SQL引起，调查发现SQL本身没有问题，但是SQL执行频率非常高，追查发现，原来这条SQL是在网站首页被自动调用，而网站首页被访问的最频繁，所以SQL自然就被频繁执行。
经验教训:
- 首页不应该访问数据库，可以从缓存读取
- 首页最好是静态的
高并发情况下 锁 引发的故障
现象，服务器响应超时，很快又恢复了。
原因分析: 程序中某个单例对象中多处使用了 sychronized(this), 由于 this 对象只有一个，所有的并发请求都要排队获得唯一的锁.
经验教训: 使用锁要非常谨慎.
缓存引发的故障
故障现象: 没有新应用发布，但是数据库服务器突然 Load飙升，并很快失去响应. DBA 将数据库访问切换到备机，Load也很快飙升，最终网站瘫痪。
原因分析: 这次一个缺乏经验的工程师关闭了缓存服务器集群中全部的十几台 Memcached 服务器，导致网站全部瘫痪.
经验教训: 当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。
应用启动不同步引发的故障
故障现象: 应用发布后，服务器立即崩溃。
原因分析: 应用程序 Web 环境使用 Apache + JBoss，用户请求 Apache转发 JBoss, 发布时, Apache和 JBoss同时启动，由于JBoss加载需要很长时间，结果JBoss还没启动完，Apache已经开始接收用户请求，大量请求阻塞在JBoss进程中，导致JBoss崩溃。类似场景还有很多
经验教训: 先启动 JBoss, 待OK后，再启动Apache.
大文件读写独占磁盘引发的故障
故障现象: 某应用主要功能是管理用户图片，街道用户投诉，图片上传慢
原因分析：存储服务器中有大文件正在读写。
经验教训：这类资源的存储的使用要根据不同文件类型和用途进行管理。
滥用生产环境引发的故障
故障现象: 监控发现某个时间段，应用突然变慢
原因分析：网卡流量下降，但没找到原因，过一阵子才发现，原来有工程师在线上生产环境进行性能压力测试，占用了大部分交换机带宽。
经验教训：访问生产环境要规范，不小心会导致大事故。
不规范的流程引发的故障
故障现象：某应用发布后，数据库 Load 迅速飙升。
原因分析: 发现该应用发布后出现大量数据库读操作，而这些操作本来应该是从分布式缓存读取，检查缓存，发现数据已经被缓存，检查代码，发现访问缓存的那行代码被注释掉了。原来工程师在开发时，为了方便测试，特意注释掉读取缓存的代码，然后忘记把注释去掉了。
经验教训: 代码提交前使用 diff 命令进行代码比较，确认没有问题后再提交.
不好的编程习惯引发的故障
故障现象: 某应用新功能更新后，少量用户投诉无法正常访问。
原因分析: 分析这些用户，都是第一次使用该功能，检查代码，发现程序根据历史使用记录构造一个对象，如果该对象为 null, 就会导致 NullPointException.
经验教训: 程序在处理一个输入对象时，如果不能明确该对象是否为空，必须做空指针判断，程序调用其他方法时，输入的对象尽量保证不是 null.
架构师
共同参与架构, 架构师对系统架构负责，但并不是说一定要架构师自己完成架构设计，并要项目团队严格遵守架构决策。
不要只有架构师一个人拥有架构，要让大家都觉得自己是项目架构的重要贡献者
学会妥协， 不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老大的，所以，我是来实现客户价值的，不是来证明谁对谁错的。
要学会成就他人。
给上司提 A 或 B 哪个方案好? （封闭性问题）
给下属提 “元芳，你怎么看”？ （开放式问题）
指出问题不是批评人，用赞同的方式提出问题 “我非常赞同你的观点”，不过我有一个小小的建议。。。