标题层次混乱

内容不错，只是条理有些混乱，整理了一下

一、设定容量目标
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 一堆工具