网站运维：保持数据实时的秘技

《网站运维:保持数据实时的秘技》：“Web正在改变我们的生活方式，并且触及到了每一个人。随着越来越多的人依赖于Web，他们最终将依赖于我们。网站运维就是这样的工作。”
Web应用涉及到很多专业人士，但只有网站运维人员才能确保在应用程序的生命周期中，一切运行正常。刚起步的网站，突遇流量高峰，或由于引入了一项新特性，而导致稳定的应用程序运行失败，这时，你就需要网站运维人员来帮助你解决这些问题，他们正是这方面的专家。在《网站运维:保持数据实时的秘技》的文章和访谈中，Theo Schlossnagle、Baron Schwartz以及Alistaiir Croll等Web方面的高手，为这个尚处于发展中的技术领域贡献了他们的深刻见解。关于如何才能让网站火起来，你会听到来自战壕的真实故事——来自一些最大的网站的建设者的亲身经历。
学习网站运维中所需要的技能，以及为什么这些技能是通过经验而不是学校教育获得的。理解从应用程序和基础架构中获取测量数据的重要性。考虑数据库架构的常用方式，以及伴随规模增长而来的陷阱。了解如何处理宕机及降级运行的人的因素。找出一家公司在巨大的流量汹涌而来之时是如何避免灾难的。发生问题时，发现问题出在哪儿，以及如何避免再次发生。

作者：(美国)约翰•阿尔斯帕瓦 (John Allspaw) (美国)杰西•罗宾斯 (Jesse Robbins) 译者：杨建华

目录
序 xi
前言 xiii
第1章 作为职业的Web运维 1
Theo Schlossnagle
为什么Web运维如此艰难？ 1
从学徒到师傅 4
结语 9第2章 Picnik如何应用云计算：所学到的教训 10
Justin Huff
什么地方适合云计算（以及为什么！） 11
什么地方不适合云计算（对Picnik而言） 17
结语 18

第3章 基础架构与应用程序测量 19
John Allspaw, Matt Massie
时间分辨率和存留时间的考虑 20
测量数据采集与存储的地点 21
测量数据的层次 22
为异常检测和报警提供环境 25
日志记录也是测量数据 26
将变化管理和事件的时间线建立关联 27
给测量数据加入报警机制 28
使用测量数据建立加载-反馈机制 29
展示一个测量数据采集系统：Ganglia 32
结语 43

第4章 连续部署 44
Eric Ries
小批量意味着更快的反馈 44
小批量意味着问题即刻被本地化 44
小批量能够减少风险 45
小批量可以降低总开销 45
质量卫士的挽歌 47
让我们开始吧 50
连续部署用于关键任务应用 54
结语 57

第5章 作为代码的基础架构 58
Adam Jacob
面向服务体系结构 60
结语 71

第6章 监控 72
Patrick Debois
故事：“旅程的开端” 72
步骤1：理解你在监控什么 76
步骤2：理解正常行为 84
步骤3：有备而学 90
结语 93

第7章 复杂系统是如何失败的 94
John Allspaw和Richard Cook
复杂系统是如何失效的 94
进一步的读物 101

第8章 社区管理与Web运维 103
Heather Champ和John Allspaw

第9章 处理非预期的访问量激增 112
Brian Moon
一切是如何开始的 112
警报连连 113
扑灭烈火 114
周末逃生 115
未雨绸缪 116
救命稻草CDN 116
代理服务器 116
围剿踩踏 117
将代码基流水化 118
我们怎么知道它能否工作？ 119
真实测试 120
学到的教训 120
自那以来的改进 121

第10章 开发者与运维者的协调与合作 122
Paul Hammond
部署 123
共享、开放的基础架构 126
信任 128
随叫随到的开发人员 131
避免指责 135
结语 137

第11章 你的访问者感觉怎么样：面向用户的测量 139
Alistair Croll和Sean Power
为什么要采集面向用户的测量数据？ 140
是什么使网站变得很慢？ 144
测量延迟 147
编写SLA 153
访客结果：分析 155
市场营销关心的其他测量数据 160
用户体验如何影响Web运维 161
Web监控的未来 162
结语 167

第12章 将关系数据库用于Web的战略战术 169
Baron Schwartz
Web数据库需求 170
典型的Web数据库是如何增长的 175
对集群的渴望 181
数据库战略 186
数据库战术 193
结语 198

第13章 如何优雅地失败：事后处理的艺术与科学 200
Jake Loomis
最糟的事后分析 200
什么是事后分析？ 201
什么时候引入事后分析 203
邀请谁参加事后分析 204
进行事后分析 204
事后分析的后续工作 205
结语 207

第14章 存储 208
Anoop Nagwani
数据资产的库存 208
数据保护 211
容量规划 218
存储大小的变化 219
运维 221
结语 223

第15章 非关系数据库 224
Eric Florenzano
NoSQL数据库概览 225
某些系统细节 228
结语 238

第16章 敏捷基础架构 239
Andrew Clay Shafer
敏捷基础架构 241
那么，问题是什么？ 244
兴趣与实践的社区 253
贸易区和道歉 253
结语 256

第17章 夜间鬼魅（以及如何高枕无忧） 257
Mike Christina
术语 258
多少个9？ 259
影响持续时间对事件持续时间 260
数据中心数量（footprint） 261
逐渐失效 262
不信赖任何人 263
故障转移测试 264
监控和历史模式 264
高枕无忧 265
合作者 267
索引 271

版权页：

插图：

首先，连续部署区分了发布的两种不同的定义，一个是工程师使用的，指的是将代码完全集成到生产环境中的过程；另一个是市场部门使用的，指的是客户看到的东西。在传统的批处理-排队开发方式下，这两个概念是连在一起的，代码一旦部署，所有客户都将看到新的软件。这就要求所有的测试必须在部署之前进行，测试在特殊的预演或测试环境中进行。这种做法使得发布变得很脆弱，即在这段时间（代码写完之后，在生产环境运行之前）内可能会出现预想不到的问题。这种将市场发布和技术发布合并在一起的做法，在总的开销之上，又增加了协调的开销。使用连续部署，代码一旦写完，就在去往生产环境的路上了。
这意味着我们经常会在一项功能只完成了1％时就进行部署——远在客户能够看到之前。事实上，涉及到一项新功能的大部分工作都是用户不可见的，而是大量的与其他已有功能进行集成的琐碎的接触点。只要想想那些API的微小改动就明白了，为了传送新值，必须要对API进行修改，这些修改通常都假定“不会引起副作用”，意思是不会影响系统行为——注意是假定。事实上，很多缺陷都是由这些修改产生的非同寻常或没有引起注意的副作用造成的。同样的事实也存在于生产环境中的配置参数的小小改动而引发的冲突中。这种情况下，反馈越快越好，而这．正是连续部署提供的。