Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1121065
  • 博文数量: 197
  • 博客积分: 4141
  • 博客等级: 中将
  • 技术积分: 2263
  • 用 户 组: 普通用户
  • 注册时间: 2009-03-21 20:04
文章存档

2019年(32)

2016年(1)

2014年(16)

2011年(8)

2010年(25)

2009年(115)

分类: 系统运维

2019-02-22 11:11:23



  1. B. Google SRE指导思想 - 拥抱风险
  2.     概述
  3.         目标:快速创新和高效的服务运营业务之间的风险的平衡
  4.         提升可靠性的成本
  5.             冗余的物理服务器/计算资源的成本
  6.             机会成本
  7.         度量服务的风险
  8.             基于时间的可用性
  9.                 系统正常运行时间 / (系统正常运行时间 + 计划外停机时间)
  10.             合计可用性
  11.                 成功请求数 / 总请求数
  12.     服务的风险容忍度
  13.         辨别消费者服务的风险容忍度
  14.             风险评估因素
  15.                 需要的可用性水平
  16.                 不同类型的失败对服务有不同的影响吗?
  17.                 我们如何使用服务成本来帮助在风险曲线上定位这个服务
  18.                 有哪些其他重要的服务指标需要考虑
  19.                 等等
  20.             可用性目标
  21.                 用户期望的服务水平是什么
  22.                 这项服务是否直接关系到收入(我们的服务还是我们的客户的收入)
  23.                 这是一个有偿服务,还是一个免费服务
  24.                 如果市场上有竞争对手,那些竞争对手提供的服务水平如何
  25.                 这项服务是针对消费者和企业的
  26.                 等等
  27.             故障类型
  28.                 给定服务的故障预期:不同类型的服务能够接受的故障不一样
  29.             成本
  30.                 可量化的:直接计算,比如说广告系统
  31.                 不可量化:低于背景(各种协议)误差率,基本上在0.01% ~ 1%
  32.             其他服务目标
  33.                 响应延迟时间
  34.                 等等
  35.         基础设施服务的风险容忍度:以Bigtable为例
  36.             概述:有多个用户,每个用户有很多不同的需求
  37.             关键战略:明确划分服务水平,从而是客户能够在构建系统时正确的风险和成本平衡
  38.             可用性目标
  39.                 消费终端团队:低延时,高可靠
  40.                 离线数据分析团队:高吞吐量
  41.             故障类型
  42.                 低延时用户:请求队列为空
  43.                 离线分析用户:队列总是满,Bigtable应该避免处于空闲状态
  44.             成本
  45.                 针对不同的目标部署多套系统,比如说低延时集群和高吞吐量集群
  46.                     低延时集群:资源冗余度高
  47.                     高吞吐量集群:资源冗余度低
  48.     错误预算
  49.         问题:系统可靠性和产品创新速度之间的矛盾
  50.             软件对故障的容忍度:做的太少,产品脆弱无用,做的太多,失去市场机会
  51.             测试
  52.             发布频率:每一次发布都是有风险的
  53.             金丝雀测试的持续时间和大小
  54.         步骤
  55.             产品管理层定义一个SLO,确定一项服务在每个季度预计的正常运行时间
  56.             实际在线时间是通过一个中立的第三方来测算的:我们的监控系统
  57.             这两个数字的差值就是这个季度剩余的不可靠性预算
  58.             只要测算出的正常在线时间高于SLO,也就是说,只要仍然有剩余的错误预算,就可以发布新版本
  59.         好处:统一产品和SRE的目标

阅读(1201) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~