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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 275|回复: 0

服务级别目标SLO目标的选择

[复制链接]
发表于 2020-12-4 17:06:35 | 显示全部楼层 |阅读模式
选择目标SLO 不是一个纯粹的技术活动,因为这里还涉及产品和业务层面的决策,SLI和SLO(甚至 SLA)的选择都应该直接反映该决策。同样的,有时候可能可以牺牲某些产品特性,以便满足人员、上线时间(time to market)、硬件可用性,以及资金的限制。SRE 应该积极参与这类讨论,提供有关可行性和风险性的建议,下面列出了一些有用的讨论。: G! h+ |) L: x; E
  F& {9 G: w7 s1 c
不要仅以目前的状态为基础选择目标       
! Y7 W1 j9 N' o了解系统的各项指标和限制非常重要,但是仅仅按照当前系统的标准制定目标,而不从全局出发,可能会导致团队被迫长期运维一个过时的系统,没有时间去推动架构重构等任务。4 L! B, I, s* Y. G7 S/ f; @, L0 g
- ^4 M, Z- d& G
保持简单0 Q) s, T; B8 K
SLI中过于复杂的汇总模式可能会掩盖某种系统性能的变化,同时也更难以理解。
0 E8 _) |  c/ q! C3 \0 O+ R) o8 s6 i; B4 b+ Z# d# h& r; e, O
避免绝对值1 k. w$ k1 z' n1 J6 \
虽然要求系统可以在没有任何延迟增长的情况下无限扩张,或者"永远"可用是很诱人的,但是这样的要求是不切实际的。就算有一个系统能够做到这一点,它也需要花很长时间来设计和构建,同时运维也很复杂——最关键的是,这可能比用户可以接受的(甚至是很开心地接受的)标准要高太多。+ A( A$ ?; w5 Q+ t* ]- U# o; d  `

( \: X( [3 \1 {/ s$ B. tSLO越少越好
% s& h: D( T. L应该仅仅选择足够的SLO来覆盖系统属性,一定要确保每一个SLO都是必不可少的∶如果我们无法针对某个SLO达标问题说服开发团队,那么可能这个SLO就是不必要的准。然而,不是所有的产品属性都能用SLO表达,用户的"满意度"就很难。9 M9 |6 _: Z7 e3 j( C

. m5 X; D( M. V. T2 W不要追求完美
0 Z5 y& K4 Z8 I7 G! x2 \4 i我们可以随着时间流逝了解系统行为之后优化SLO的定义。刚开始可以以一个松散的目标开始,逐渐收紧。这比一开始制定一个困难的目标,在出现问题时放松要好画得多。
+ f9 B" s8 q$ F; n1 d: }4 K2 \
4 i! p) p# j0 N1 u. |/ u8 eSLO可以成为——也应该成为——SRE和产品团队划分工作优先级的重要参考,因为SLO代表了用户体验的程度。好的 SLO是对开发团队有效的、可行的激励机制。但是一个没有经过精心调校的SLO会导致浪费,某团队可能需要付出很大代价来维护一个过于激进的SLO,而如果SLO过于松散,则会导致产品效果很差。SLO是一个很重要的杠杆∶要小心使用。" q- n" D  L2 T: B+ R/ v  N




上一篇:SLO服务质量目标的标准化指标
下一篇:控制SLI和SLO实现的手段

本版积分规则

本站关键字: 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:52 , Processed in 0.143442 second(s), 28 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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