Engineering Reliability into Web Sites: Google SRE

Engineering Reliability into Web Sites: Google SRE

Alex Perry

alex.perry

原文:http://research.google.com/pubs/archive/32583.pdf

概要

这个主要讲的是在google的网站保障工程师(SRE, 国内应该称之为应用运维),解释了他的目标和描述它会遇到的挑战

在mountain view, zurich, new york, santa monica, dublin 以及 kirkland的SRE团队管理着许多google的服务和网站。

他们利用分布于全世界数据中心的基于linux的计算资源。

主要内容

  • 根据不同站点来划分组
  • 网站的失效和不可靠会耗尽人力成本
  • 工程师应该专注于消除未来的工作,而不是像救火队员一样,要有一定的预见性。
  • 一个新项目是如何转移到SRE团队的。这个主要是一个新项目是如何从开发转到SRE的。
  • 对于用户量的快速增长要有计划。主要是根据现有的增长速度来进行预测。
  • 估算SRE团队最合理的人数

网站 — 是一项综合的部署

  1. 团队需要确定用户可视化的(可测量的)的在线时间和质量水平
    1. 这个需要掌控所有相关软件和系统的情况
  2. 对于各个组件有深度的了解和知识是很有必要的
    1. 这是一个需要比较陡的学习曲线,这种曲线大部分由于各个组件的复杂性造成的
    2. 要持续的再学习,因为网站是一直都在升级的。要想一劳永逸是不大现实的。
  3. 对于使用共享组件架构的特殊性
    1. 要确定那些共享的组件有很好的可靠性。比如一个网站所用共享的中间层和底层组件。

Reliability – it just works

  1. 最小化的人力成本的使用
    1. 团队管理监控和开发都需要自动化。自动化监控和部署。比如puppet,nagios这些工具
    2. 这个意味着使用脚本工具和数据分析工具。一些初始化脚本和安装工具等等。
    3. 大部分失效都需要适当地自动恢复。当出现问题了能够自动恢复。比如自动切换和重启。
  2. 把更高的风险转移到方便处理的时候
    1. 在工作日之前学习那些已经处理掉的风险(Learn of age mortality risk during preceding workday)
    2. 那些刚开始的风险需要完美的解决,防止影响google现有的业务(Infant mortality ideally also avoids Google meals)

工程师—不是管理员

  1. 对于报警和通知规范需要细致的定义
    1. 在发出通知之前可能错误已经导致了问题。
    2. 通常定义报警和通知规范需要通过多个层次,多个级别,多个角度进行。这个主要是从多个维度来定义。
    3. 这些定义可以通过设计来手动和自动的进行增加。这个就需要自动化的管理平台
  2. 对于项目的升级和扩展进行负责
    1. 计划所有的需求,同时要重视效率。
    2. 文件的bug可以在合适的时候进行修复。

新思维: SRE是兼职的开发人员

  1. 一般工程师都会一周抽一天去做开发
    1. 在其它地方可能会就要利用晚上或者周末时间。
    2. Google的工程师每天都有20%的时间来做这些项目。
  2. 开发者有时候会有其它的想法
    1. 有多少老的网站的工作是需要快速回退的。
    2. SRE有20%的空余时间来做项目,这些项目有趣吗?

最初,网站是需要重点维护的

  1. SRE给出可以自动化的日常事务的指导
    1. 通过消除重复性的工作来减少工作负荷。
  2. SRE指出开发文档中的错误和疏忽,但是我觉得这个最好在开发阶段就指出来。
    1. 开发人员也许会在其它地方也同样给你帮助。
  3. SRE建议附加的长期的监控
    1. 这些建议应该覆盖所有的间隙和跟踪性能。
    2. 管理员需要充分的可信赖的监控。

上线一个新网站是一个契机

  1. 你不要对那些新上线的20%的网站而后悔
    1. 页面调度器可以发出比你想象的更多的警告(一般情况下网站会在任何时候发出警告)
  2. 但是在上线的几周内,SRE的专业知识是很有必要的
    1. 开发人员的工作压力可能降低到1%
  3. 剩余的1%可以在任何时候做
    1. 仅仅写好好的文档可以让别人方便接管
    2. 许多工程师都选择继续使用页面调度器

把网站推给了SRE

  1. 这个决定是逐步变为长期的
    1. 对于一个网站的日常工作会变得减少
    2. 通过优化和分析可以使软件逐步改进
  2. 开发人员仍然会保留很少的关注对于这个网站
    1. 工作主要对针对下一个版本,修复已知的bug
    2. 老的在线的版本会逐渐不重视了
    3. 一个明显的特征就是把这些网站推到SRE这边来进行维护了

on call – more than quick fixes

  1. SRE团队人员需要轮流值班
    1. 修复那些现在还不能自动修复的问题
    2. 通过累计发生的问题来确认优先级
    3. 把诊断的问题和解决方案进行文档话
  2. 一个永久的解决方案需要很长的时间才能完成
    1. 发现文件bug,开发补丁,测试,代码复查,提交
    2. 集成,版本和发布要进行日程安排
    3. 为什么要花大量的时间来做这些呢? 这个主要让SRE的变的更有条理。对于类似X度这样的公司整个运维部门整天就是忙上线实在是无语。

名声 – 越来越多的用户

  1. 网站的稳定性不能由于升级而降低
    1. 网站架构通常是可伸缩性和健壮的
    2. 这些是google软件工程师的核心技能。
  2. 算法的性能是成比例的扩大的
    1. 所以修复bug也要监控和自动操作
  3. 实际上工作压力是随着问题的增加而增加的
    1. 有效的人力确实被现有人数限制着的

事情的增加 — 更多的用户

  1. 工程问题可能会根据用户等比例的放大
    1. 软件中新的功能没有被完全实现。O(1)
    2. 在常规的硬盘挂掉导致服务器down掉。O(u)
    3. 内存中的宇宙射线,新用户的哈希是有效的。O(u2) 这个意思就是说由于算法的问题,导致本来2个用户应该是不一样的哈希结果,但是却变成一样了。这一般要到非常大的用户量才会发生。
    4. 以太网中的比特传输是无序的,所有包都是通过CRC校验的。O(u3) 这个的意思是由于网络流量非常大,以及并发特别高。导致CRC校验也会产生冲突。这得多大流量啊!!!
  2. 更高等级的请问题通常不太可能一开始就发生
    1. 因为他们是有可能发生的,但是是无形的,因此很难被修复。
    2. 但是它们发生后会使问题扩散的很快。

第一次出现 — 对于每一个小时

  1. 想象每10天用户数量就会翻倍
  2. 考虑网站的O(u3)问题
    1. 瞬时的页面比例 = exp(date /5)/k
    2. 累计的页面访问数量 = exp(date/5)5/k
  3. 在你收到第一个页面产生的问题
    1. 期望的第一个页面的时间 = 5 in (k/5)
    2. 在未来的3个星期内,它会每小时报告一次。

多久可以扩展一个网站

  1. 这个主要是看解决问题的决心
    1. 多长时间可以确定问题,并且一个一个解决
  2. 要早期的发现bug需要好的工具
    1. 远程诊断和相关维护的日志
    2. 在发现第2个警告前就要开始解决第一个问题。
  3. 一次就修复bug,这个需要快速地测试
    1. 确认以前的bug不会复现

false positives, false negatives

  1. 谨慎小心的报警会导致一个危机
    1. 导致在压力下会一有问题立即去修复。
    2. 这相反会消耗工程师的时间和精力。因为报警过于琐碎而浪费了工程师的精力。
  2. 通过对于归档数据的分析进行优化
    1. 监控系统通常是不出声的。(正常的时候当然不会报警呀)
    2. 新增加的问题会更容易被发现
    3. 一般问题马上会被侦测到,那网站会变的更快

轻量的SRE团队(Lower bound on SRE team size)

  1. 每周的一天:做自己的项目,就是那些20%没被分配的时间
  2. 每周的1天: 休息,公司事务, 志愿者,或者病假
  3. 每周的1天: 对于网站的特别培训, 学习网站的更改信息
    1. 所有的每个网站培训都是相同的对于团队大小。
  4. 每周的2天: 网站分析,计划相关内容,维护等等
    1. 对于一个网站来说每周需要多少人力?
    2. 这个是确定团队人数的低的边界。

估算on call能覆盖哪些需求

  1. 工程师能否对于一个警告不响应
    1. 如果是,那我们需要实现工程师冗余
  2. 你网站页面服务的失效比例是多少
    1. 有可能会超过10%,很难达到1%
    2. 5%会使用4种冗余的方法来达到99.999%
  3. 对于任何一个报警只能有一个工程师响应
    1. 使用优先级或者选举的手段来避免浪费精力。
    2. 那其它ON CALL的SRE不会感到困扰

网站是否需要合并

  1. 比较网站的工程操作和oncall需求
    1. 可能会让一个SRE团队来对多个网站值班
    2. 培训开销:每个工程师都要学习所有负责的网站
  2. 这种合并整合是一个长期的目标
    1. 有一些观点是,每个网站都会最终停止更新
    2. 然后工程师专门对付较低优先级的问题
    3. 比如一个网站,最终维护的趋势是变为0
    4. 但是覆盖需求的on call人员是固定不变的。

总结:

  1. 网站的有效性是需要不间断的工程性 的努力
    1. 这个比软件实现需要更长的时间段
    2. 工作要有短期目标和长期目标是非常重要的
  2. 大型网站需要一个管理员团队
    1. 如果他们一直都很忙,那就没有空间成长
    2. 让一个团队管理多个网站是比较经济的
  3. 撰写和修改软件来替代管理工作
    1. 随着网站的扩展自动化的好处会越来越多
  4. 团队尽量要小,每个团队都有一个合适的大小

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com

twitter: http://twitter.com/zauc
Linux System Admin & MySQL DBA

urchin中最常见内容中显示域名

在urchin显示的内容优化–最常见内容中默认是不带有域名的。例如
http://www.abc.com/test.html这里就只显示test.html,而万一我有test.abc.com/test.html那我就搞不清楚到底哪个是www子域名下的,哪个是test子域名下的。为了解决问题查看了urchin的帮助文档,居然还有现成的。
https://secure.urchin.com/helpwiki/cn/How_do_I_track_all_of_the_subdomains_for_my_site_in_separate_profiles%3F

   Filter Type: Custom filter > Advanced
   Field A: cs_host (Raw)
   Extract A: (.*)
   Field B: Request_Stem (Auto)
   Extract B: (.*)
   Output To: Request_Stem (Auto)
   Constructor: /$A1$B1

但是实际使用中却始终无法正常显示出来。为了解决这个问题无奈只好一个个查看urchin各个字段的解释。在http://www.google.com/support/urchin45/bin/answer.py?answer=28623&topic=7396你可以看到所有字段的解释

因为既然urchin能够获取主机名,那这里肯定也是可以显示的。最后解决问题的方法是:

   Filter Type: Custom filter > Advanced
   Field A: utm_request_hostname (AUTO)
   Extract A: (.*)
   Field B: Request_Stem (Auto)
   Extract B: (.*)
   Output To: Request_Stem (Auto)
   Constructor: $A1$B1

然后必填字段A 选择是,必填字段B选择否,覆盖输出字段选择是,区分大小写选择否。

这下终于OK了。

urchin的安装及使用

Urchin是google收购的一个日志分析工具。界面跟google analytics是几乎完全一样的。但是google analytics每个月的统计只能在500W PV以内,这个对于稍微有点规模的网站是不可忍受的。所以我们还是需要自己来架设一个urchin 首先需要下载一个urchin6501_linux2.6_kernel.tar.gz 这个是根据自己monitor的系统版本来进行确定的。然后还需要有一个mysql或者postgresql 创建相应的数据库和数据库用户。这里数据库名为urchin,数据库账户为urchin,urchin的账户密码为urchinapassword, urchin账户拥有urchin库的all权限。

root@monitor# mysql -u root -p
mysql> create database urchin character set utf8;
mysql> GRANT ALL ON urchin.* to 'urchin'@'10.2.%' IDENTIFIED BY 'urchinpassword';

接着使用程序目录下的install.sh脚本进行安装,这里主要是选择安装目录,数据库配置连接等等。

 ./install.sh 

安装完成后就可以通过下列网址查看urchin

http://yourserver:

修改admin用户的密码,因为我实在不知道默认admin的密码是啥

/usr/local/urchin/util/uconf-manager table=uusers action=update ucus_name="admin" ucus_password="123456" key1=ucus_name print=status

这里是把admin用户的密码设置为123456

这样我们就能通过上面的网站看到urchin的界面了,记住了申请试用必须使用IE来进行。Firefox一直有些界面看不到。

其他配置:

首先需要一个域名下放置urchin.js这个js代码。这个代码需要修改如下部分。

//-- UTM User Settings
var _udn="xiaonei.com";               //这个是你网站一级目录
var _ugifpath="http://track.xiaonei.com/__utm.gif";  //__utm.gif的地址

track.xiaonei.com 这个最好是独立的域名,这样urchin就不会分析这个域名内其他不相关的日志了。

__utm.gif和urchin.js都在安装文件中存在,根据上面的建议进行修改和放置。

关于日志配置:

默认nginx的日志格式,urchin是无法进行分析的。还必须要做相应的修改后urchin才能进行分析。

log_format urchin '$remote_addr $http_host - [$time_local]  "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_cookie"';

新建配置:

Urchin默认是英文界面,可以在显示中选择中文。基本设置如下:

step1

step2step3step4

urchin的原理:就是在所有的页面都会嵌入这个urchin.js来访问那个__utm.gif图片,通过这个来收集用户本地的相关信息来记录到gif图片域名下的日志中,然后urchin就来分析这个日志,所以这个分析结果的内容会比一般的多。

xiaonei

说说gtalk

google talk 简称GTALK

看了下,gtalk的音频使用的是跟qq同一家公司的global IP sound.所以这个优势并不很有特点。

使用EMAIL登录,这个跟MSN比同样也没有优势。

加密传输,现在通过查找的资料来看,现在测试版本同样是明文传输的,要等正式版本后才会真正做到加密,这无论如何都说不过去啊。

对于gtalk最有杀手锏的功能是保存聊天记录的功能,可以保存在GMAIL邮箱里,这个是无论QQ和MSN暂时都无法满足我的。

同时GTALK是基于JABBER开发的,在XNIX平台上可以方便的登录,这个跟QQ的做法来说是好太多了。

一个google爱好者的一天

打开计算机,首先进入www.google.com/ig查看今天主要的新闻和天气

打开google talk查看一下在线好友,同时查看自己的GMAIL邮箱

然后是查看google日历,看看今天的日程安排

接着有空就打开www.google.com/reader看看自己订阅的rss的各种更新

用google docs处理公司日常事务。