请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 207|回复: 0

SRE基础知识快速普及

[复制链接]
发表于 2020-11-19 16:40:13 | 显示全部楼层 |阅读模式
SRE是什么?
[color=rgba(0, 0, 0, 0.75)]

SRE(Site Reliability Engineering),站点可靠性工程,起源于2003年。在系统管理员模式下,通常是通过人工操作完成任务,而SRE倾向通过设计、构建自动化工具来取代人工操作。SRE的本质是用软件工程的思维和方法解决复杂的运维问题。

[color=rgba(0, 0, 0, 0.75)]

DevOps是在2008年年末流行起来,强调自动化替代人工操作,以及利用软件工程手段执行运维任务。DevOps的核心是"全栈交付", SRE的出发点是“保障和提升系统稳定性”,两者要做的事情其实本质上差别不大,但是角度不同。可以认为DevOps是SRE核心理念的普适版本,SRE是DevOps模型在Google的具体实践。

[color=rgba(0, 0, 0, 0.75)]
Google SRE方法论
[color=rgba(0, 0, 0, 0.75)]
  • 确保长期关注研发工作
    6 |( n" P! i. P' W$ M0 J
[color=rgba(0, 0, 0, 0.75)]

Google将SRE团队的运维工作限制在50%以内,剩余时间花在研发项目上。实践中,SRE管理人员要经常度量团队成员的时间分配,有必要的话,可采取措施将过多的运维压力转移给研发团队。

[color=rgba(0, 0, 0, 0.75)]
  • 在保障服务SLO的前提下最大化迭代速度
    1 X) ~/ j. S3 C* s) d' V1 {
[color=rgba(0, 0, 0, 0.75)]

对于迭代创新速度与产品稳定程度之间的矛盾,可以使用“错误预算”工具处理。”错误预算”起源于这样的理念:任何产品不能,也不应该做到100%可靠。对用户来说,99.999%和100%的可用性是没有实质区别。其中,错误预算 = 1 - 可靠性目标。可以将错误预算用于新功能上线或者产品创新,如:最大化新功能的上线速度,同时保证服务质量。

[color=rgba(0, 0, 0, 0.75)]
  • 监控系统* H- @. M+ g$ D# B: O( G* v
[color=rgba(0, 0, 0, 0.75)]

监控系统不应该依赖人来分析警报信息,而是由系统自动分析,仅当需要用户执行某种操作时,才需要通知用户。

[color=rgba(0, 0, 0, 0.75)]
  • 应急事件处理
    % z8 u) `2 p8 b# x
[color=rgba(0, 0, 0, 0.75)]

可靠性是MTTF(平均失败时间)和MTTR(平均恢复时间)的函数,通过事先预案并将最佳方法记录在“运维手册”上通常可以使MTTR降低3倍以上。

[color=rgba(0, 0, 0, 0.75)]
  • 资源部署! Q2 t2 B7 ]4 D$ J
[color=rgba(0, 0, 0, 0.75)]

新资源的部署与配置是相对比较危险的操作,必须要小心谨慎地执行。

[color=rgba(0, 0, 0, 0.75)]
  • 效率与性能) l0 W: s1 S, {/ z. _- g
[color=rgba(0, 0, 0, 0.75)]

任何盈利性服务都关心高效利用各种资源,SRE最终负责容量的部署和配置,因此SRE必须承担起任何有关利用率的讨论和改进。

[color=rgba(0, 0, 0, 0.75)]
SLA、SLO、SLI
[color=rgba(0, 0, 0, 0.75)]
  • SLI, Service level Indicate, 服务质量指标1 ]$ Q& A/ D% {/ T& f
[color=rgba(0, 0, 0, 0.75)]

该服务的某项服务质量的一个具体化指标,请求延迟为大部分服务的一个关键SLI,除此之外有错误率,吞吐率,可用性等。这些指标的计算过程:在某一个度量时间范围内将原始数据收集起来,计算速率,平均值、百分比等汇总数据。通常用9的数量来描述可用程度,99%可用性被称为9个9,99.999%被称为5个9.

[color=rgba(0, 0, 0, 0.75)]
  • SLO, Service Level Object, 服务质量目标' Y+ I6 u- Q: S* X6 S2 Y
[color=rgba(0, 0, 0, 0.75)]

服务的某个SLI的目标值,SLO的定义是 SLI<=目标值。

[color=rgba(0, 0, 0, 0.75)]

SLA计算器

[color=rgba(0, 0, 0, 0.75)]
[color=rgba(0, 0, 0, 0.75)]
SLO百分位
一天
一周
一月
一年

( R* S& d2 k$ q. ]. y' B/ B
99%
14m12s
1h40m48s
7h18m17s
3d15h39m29s

% d4 _$ D$ }+ Y4 I4 O
99.9%
1m26
10m5s
43m50s
8h45m57s
% v5 y+ K+ \, z5 N" Z, {
99.99%
9s
1m
4m23
52m36s

4 `8 P2 ]! w) L6 T" H! h/ e) p
99.999%
<1s
6s
26s
5m16s
, o) ?+ U6 L% z2 n7 \7 T
99.9999%
<1s
<1s
3s
32s

$ o# E/ L/ [: p. Q. j; z
[color=rgba(0, 0, 0, 0.75)]
  • SLA,Service Level Agreement, 服务质量协议
    + ?- c. r8 v; _" ~1 M! M- L
[color=rgba(0, 0, 0, 0.75)]

服务与用户之间的一个明确的,或者不明确的协议,描述了没有达到SLO之后的后果。SLO和SLA的区别是,“如果SLO没有达到时,有什么后果?”如果没有明确定义的后果,那么我们在讨论的是SLO,而不是SLA。

[color=rgba(0, 0, 0, 0.75)]
SRE的目的
[color=rgba(0, 0, 0, 0.75)]

SRE的最终目的是提高稳定性,从业界稳定性通用的衡量标准看,有两个非常关键的指标:

[color=rgba(0, 0, 0, 0.75)]
  • MTBF,Mean Time Between Failure,平均故障时间间隔。
  • MTTR,Mean Time To Repair, 故障平均修复时间。4 y3 s" t$ I! u2 O7 C
[color=rgba(0, 0, 0, 0.75)]

想提升稳定性,就会有两个方向:

[color=rgba(0, 0, 0, 0.75)]
  • 提升 MTBF,也就是减少故障发生次数,提升故障发生间隔时长;
  • 降低 MTTR,故障不可避免,那就提升故障处理效率,减少故障影响时长。* M. \  L* @5 k. }) q0 V2 V# ~

+ X1 y! y3 C8 n




上一篇:工具栈,实施SRE的不可或缺
下一篇:SRE工程师,你我运维人的下一个Title

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-1-22 05:38 , Processed in 0.160783 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表