简单说来，Web应用慢，是由于下面的三点原因造成的...
在当今本质上要求一直在线的Web运维环境中，基本上没有时间用于计划中的停机、维护以及其他影响网站可用性和产生收入的普通操作。本质上，没有时间适合于停机，或适合于影响工作负荷，像例行备份、磁盘损坏、复制、软件及固件升级等任务都不能干扰工作负荷，设计存储基础架构时，必须把这些因素考虑进去。 ...
存储是很昂贵的，这是当今任何现代基础架构中成本最高的组件。尤其是在数据密集的环境，存储了大量用户产生的内容以及数百万的用户数据。正是由于这个原因，对于存储上的开支进行明智地规划是很重要的。在我负责部署大规模存储的时候，经手过大笔的预算，我学到了什么才是关键的问题，那就是对你所支持的应用程序为什么需要存储、应用程序是如何使用存储的、如何将存储设计和实现得尽可能高效这些问题有明确、具体的了解。...
在确保有效的数据保护之后，作为一名存储专业人员，容量规划就是第二项最重要的职责。规划在前，并且确保应用和服务有足够的资源来运行和成长，不至于碰到天花板，这不仅是重要的，同时也是必需的。将容量和成长空间提前规划为具有足够的可伸缩性的好处是巨大的，不仅对你，对应用也一样，都减小了压力，既能应付应用上出现的非预期的爆炸性增长，也有助于避免资金的非计划性支出。...
事后分析至少要包含这些内容...
对纠正措施必须进行追踪，直到执行完成。要记住，在纠正措施没有得到完全执行之前，事故重发的风险会一直存在。...
开始事后分析的时候，首先要做的事情就是明确基本规则，要明确告知参与事后分析的相关各方，事后分析不是指责谁，主要目的是为了使类似事件不再重复发生。快速发展的互联网站，问题是不可避免的，重要的是我们能够从错误中学到教训。...
构建用于测量(图示、装备应用程序)和监控(报警)的系统是一项很值得做的事情，这些系统是基础架构非常重要的核心内容，而且做起来也不是那么难。但据我所知，这些系统却常常被忽略。如果没有测量的话，很难对系统实现主动的管理。历史的测量数据对于容量规划和错误排查尤其有用。...
对于运维来说，对数据库模式进行更新，是许多非常困难的任务之一。将数据库模式与其他更新一起进行同步，有几种常见的情景:部署、快速开发、通过修改索引和其他结构优化性能。假如模式更新是一种阻塞操作(MYSQL中通常就是这样的)，这就真的成问题了。...
对备份，只是希望在进入正式话题之前，允许给一些小提示。...
