内容不错，只是条理有些混乱，整理了一下
一、设定容量目标
1. 不同的需求和测量方法
* 服务成功率 3个9还是5个9
* 业务容量需求
* 用户期望
2. 架构决策
* 提供测量点
* 找到可能瓶颈：磁盘吞吐、磁盘容量、CPU、RAM、网络
* 硬件决策：根据需求，确定合适的服务器架构
二、测量
1. 测量工具的功能
* 随着时间记录和保存数据
* 构建自定义度量指标
* 比较各种来源的度量指标
* 导入导出度量指标
Cacti/Munin/Ganglia/Hyperic HQ
2. 进行容量规划的必要测量
1. 测量记录服务器的主要功能：apache请求、数据库查询
2. 测量记录服务器的基础硬件资源：CPU、内存、磁盘、网络
3. 判断服务器的主要功能如何与其硬件资源相关联：并发N个请求占%M的CPU，N%的内存
4. 找到服务器可接受的最大资源使用量：线下模拟真实的生产负载（网络层引流）
3. 具体场景
1. 日志&SNMP
2. 应用层测量：产品指标，blog数量，用户注册，DAU...
3. 存储容量：存储消耗速率，读写操作比，IO_WAIT时间
4. 数据库容量：每秒查询、打开连接数、从库滞后时间、Cache命中率
5. 缓存系统：工作集大小和数据动态变化率
缓存类型 | 特 性 | 缓存上限 | 资源瓶颈
小或缓慢增长的工作集 | 100%命中 | 请求速率 | 磁盘IO CPU 内存
大或快速增长的工作集 | 移动窗口 持续迁出 | 命中率、LRU时间 | 缓存大小
三、趋势预测
1. 去顶测量和绘制每个资源定义的度量指标
2. 对拥有的资源应用约束限制
3. 使用曲线拟合推算出何时使用量会超限
四、部署
目标
* 最小化扩容需要的时间
* 配置集中管理
* 绝不进入单个服务器，使用集中式管理服务器完成
* 环境保持一致，使得故障排查变得简单
实现
1. 自动化环境初始化
* 基于package配置：Solaris Jumpstart/Red Hat Kickstart和Debian FAI
* 基于系统镜像：SystemImager
2. 自动化部署：配置管理系统
1. 该系统把配置文件组成有用的子系统，你可以才去不同的方式通过这些子系统建立生产系统
2. 该系统把当前运行系统的所有信息存储在一个地方，使得备份或者复制变得方便
3. 该系统从系统管理员的大脑中提取知识信息，然后以一种文档化和可重复利用的形式存储
3.权限管理和访问控制
LDAP或者使用配置管理系统完成
附录A 虚拟化和云计算
有几个是否选择云服务的决策案例，几个不使用云服务的原因
* 资源隔离不透彻，不同实例相互影响，使得性能变化多端难以预测（估计说的是IO）
* 没有合适的服务等级协议SLA（4个9之类）
* 法律方面第三方个人隐私、安全以及数据所有权的concern
附录B 对瞬时增长的处理
* 暂时关闭一些功能
* 页面静态化
* 开启临时性缓存
* 安抚用户
附录C 一堆工具