《Web Operations:Keeping the Data on Time》笔记一
第一章：关于运维的一些基本素质
扎实的计算机背景：包括对体系结果，内存系统，存储系统，网络和交换的料及，数据库概念等
娴熟的判断力
沉稳的性格
知识来自于web和互联网
工具的使用
经验是一个运维的武器，获得经验和应用经验去挑战和解决问题
纪律
第二章：Picnik 云计算的教训
什么地方适合云计算（为什么？）
存储，因为大部分服务是CPU密集型的，因此需要将IO充分利用。
混合计算需要可伸缩的环
第三章 基础机构和应用程序测量
任何规模的web运维，采集测量数据就像将服务器连到网络上一样重要，对于一个规模不断增长的基础架构来说，或许更加重要。
数据的自动采集，存错，显示，应该和异常或在数据中检测的问题时的报警却别对待。
时间分辨率和存留时间的考虑是重要因素，因为数据的采集对磁盘空间是一个挑战。有系统采用高分辨率采集的数据，并存入关系数据库，解决独立的查询问题，有些仅仅是日志文件。采集帮助你获得模式的历史意义，回答对于特定资源的峰值和峰值日，季节模式，峰值和谷值，分布情况等
测量数据采集和存错的地点
测量数据的层次：应用和业务层数据，采集频度一般为天，功能特定一般为实施，高分辨率为秒，一般在RRD中
高层业务或功能的特定的测量数据
系统及服务层面的测量数据
采集数据一帮用来回答如下问题：
平均的web请求的CPU时间
和纯粹应用执行的时间比较起来，用于数据库擦讯的最慢的API调用花费时间和百分比是多少
对文件系统缓存的依赖有多大
响应时间随请求率的时间变化
用于Web页面，AJAX，RSS和API方法的前端请求占用的比例各是多少
一文件大小来计，最大的页面响应是多少？
响应时间随响应大小比例变化吗？
最慢的数据库查询是什么，调用频度？
用的最多的数据库查询是什么，调用频度？
采集系统的必须为检测和报警提供环境，日志记录也是测量数据。将变化管理和时间的timeline建立关联，给测量加入报警机制，建立加载和反馈机制
推荐采集系统：Ganglia
组件描述：Ganglia监控进程（gmond），Ganglia元数据集成（gmetad），Ganglia web前端，Ganglia测量工具（gmetric）
调研Ganglia
第四章：连续部署
小批量意味着更快的反馈
小批量意味着问题即刻被本地化
小批量能够减少风险
小批量可以减低总开销
小批量连续部署的步骤：
连续继承服务器（Buildbot）
源代码控制提交检查
简单的部署脚本
实时报警
根本原因分析（5个为什么，5wh？）
QA
第五章 作为代码的基础架构
基础架构分解为可以重用的，可以通过网络访问的服务
将服务集成
面向服务体系结构
配置管理非常重要，四个步骤实现：
把问题和解决方案的最终结果记录文档
写出在CelView执行中的代码
确认最终结果得正确
重复这个过程
第六章：监控
网站下的可用性受下面4个参数的影响：
MTTD（平均故障诊断时间）
MTTR（平均修复时间）
MTTF（平均无故障时间）
MTBF（平均故障间隔时间）
监控的步骤：
理解在监控什么：注意组件依赖和部门边界，适当的冗余机制，并行依赖和耦合依赖，各种常见的检查，不同层级的检查
理解正常行为
有备而学
系统研究：Nagios
本文为Lokie.Wang原创文章,转载无需和我联系,但请注明来自lokie博客http://lokie.wang
- 最新评论
- 总共0条评论
