Engineering Reliability into Web Sites: Google SRE

发表于 更新于 分类于 本文字数： 3.5k 阅读时长 ≈ 3 分钟

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. 团队尽量要小，每个团队都有一个合适的大小