srework
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的理念，不过也混杂了一些其他理念和思维，因为很多东西是不能单纯的撕裂开来的，一个企业的管理和工作理念很多也是以其中一种主要理念为纲，再杂糅另一些先进的理念，总终形成适合内部的文化体系。