SRE运维(三)SRE黄金准则

2020年10月3日 发表评论 阅读评论

srework

SRE的工作是由日常运维、工具研发、应急管理三部分构成的,这个在之前也提到过了。但在具体落地的时候对应的有八大黄金准则。这八大黄金准则不是GOOGLE提出的,也不是我杜撰的,是GNSEC会议上有企业提出的总结,既然有这样的总结,我想也是有一定的道理的,这里分别做下说明。

  • 追求最大化SLO
  • 监控
  • 应急响应
  • 持久关注
  • 效率和性能
  • 配置
  • 容量规划
  • 变更管理

SLO(service level objective):服务等级目标,比如常见的qps 99.99% ,响应时间小于10ms,http站点请求可用性达到98%等。这里说的追求最大化SLO乍一听会和google的理念有点相悖,google 提到任何软件系统都不应该一味地追求 100%可靠 正确的可靠性目标,而且讲究SLO目标和开发进度、用户体验的一个平衡。不过这里的SLO最大化实际上是指在团队制定SLO目标时应追求最大化,从主观认知上是想SLO最到力所能及的最大化,而不是简单的制定一个很容易实现的SLO目标。

监控目前已经是所有运维里的基础内容了,如果没有监控,设备或系统出现异常肯定是无法及时知道的。在一个小型企业里,设备可能只有几台,监控可以追求尽可能的细,一点风吹草动,都可以考虑通过邮件、短信、IVR、APP等方式报出来。但在一个大型企业里,设备是万台做为计量单位的,这时候再按之前的思路做告警,显示是不合适的,我就曾经在一个刚入职的大型企业里,每天能收到上千条的告警 ---- 当时除了正向告警,管理人员甚至考虑做一了些业务的反向告警。正确的告警应该追求的目标是尽量有效的、合并的、及时的。比如刚刚说的一千多条告警里,实际1天需要我们关注的只有几个事件。其他大都是关联告警或无效告警,因些告警应该是加了滤网的漏洞,输入的信息很多,输出的口很紧。这个后面会有专门的章节讲告警。

应急响应这个感觉好像是没什么好说的,来了问题或故障,不应急响应难道还慢悠悠的?其实这个在很多企业,尤其是一些涉及大的企业,涉及产品互相关联的时候问题就尤为明显。出了问题,乱哄哄的像个集市,首先想的就是找出证明不是我的责任的观点先抛出去。应急响应这个需要有调度机制、有自相关工作组的检查手段,有事先的混沌演练来填坑和提高问题处理的协同。所以SRE理念就是设计和解决这个问题的。

持久关注这个我在SRE工具生产环节体验最深,团队生产出的工具有没有人用(其他人是不知道还是不好用未反馈)、好不好用、会不会用,是不是需要新功能或新版本迭代。还有是仅有需求方知道,其他人不知道,甚至一些人离职以后,变成了完全没人知道?当然持续关注不止在软件工具产出使用环节,你问题的出现和跟本解决环节,质量的持续跟踪环节都会涉及。

效率和性能这一块儿涉及的面比较广,涉及工具代替手工工作,涉及到一些流程优化……,这里能讲的点较多。这里举几个例子,比如:IVR可以代替人工进行值守通知、聊天机器人代替人工客服、工单流转在自动化程序实现策略的自动开通等等。

配置这一块儿这里就要提到的就是统一化管理,例如用etcd、consul等存储配置信息,这里就解决配置混乱和一些安全问题(发布的时候通过confd直接从库里拉取配置信息,自动完成配置更新,避免开发人员获取现网密码信息)。很多公司比较混乱的做法有:把配置完全写死在程序里,比如直接打在jar包里,这还算好,如果是golang或C/C++程序,那就是个崩溃的事了,开发人员跑路又没留下代码的话,随你怎么搞也找不出配置信息。

容量规划这个比较好讲也比较容易懂,这里主要设计两块,事前规划和事后规划。事前规划是根据当前规模和可预见的一段期限内空间的使用量,算出后面需要的资源情况,比如说设计一个监控系统,需要考虑今年1年可能的设备扩容量。监控的字段数量、需要保留的数据时间,每个字段的占用大小,最后就可以计算得出我该申请多大的存储空间,多大的IOPS能满足需求。事后规划主要是涉及业务暴涨和爆降时,原有的规划显然已不涉及当前的容量增减趋势,就要考虑空间的扩容或释放。这里也提下很大企业在这一块儿存在粗放式管理的现象,比如空间和容量申请时,不会考虑该业务之前的运行情况,你申请多少我就给你多少。而且像貔貅,只吃不拉,这个业务可能已经没人用了,资源还在占用。

变更管理这一块儿虽然随着devops理念的深入可以一天N迭代,不过变更本身还是需要一些流程来管理。从流程上来说可以根据变更可能影响的程度分为几个类:预授权变更、普通变更、评审变更。预授权变更这个就是明确不会造成影响的一些操作,这种是随时都可以进行的,可以简单通过内部IM进行下知会就行了。普通变更确认变更中存在一些可预知的风险,比如,会影响业务使用,这就要选取对业务影响最小的时间窗口进行操作,还会涉及提前通知。评审变更,这种就是涉及面会比较大,而且很可能一次都无法完全完成的变更,比如数据库由oracle切换为mysql或其他库,这就会涉及运维、DBA、业务、架构等可能一些评审存在的风险和问题才可以实施。评审变更是集体决策,变更出现问题不是一个人的问题,同样事后总结和下一次解决也是大家集团沟通和决策的结果,对事不对人。

上面这部分总结里面有些是SRE的理念,不过也混杂了一些其他理念和思维,因为很多东西是不能单纯的撕裂开来的,一个企业的管理和工作理念很多也是以其中一种主要理念为纲,再杂糅另一些先进的理念,总终形成适合内部的文化体系。




本站的发展离不开您的资助,金额随意,欢迎来赏!

You can donate through PayPal.
My paypal id: itybku@139.com
Paypal page: https://www.paypal.me/361way

分类: 协同敏捷自动化 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.