关于SRE

简介

SRE是源自Google的一个devops岗位

故事背景

有两个交战的王国 - 开发和运维。 开发人员有兴趣构建和向用户发送有趣和有用的功能。 创新越快,效果越好。 在开发者部落的完美世界中,永远不会有新产品和真棒产品的开发和部署中断。 另一方面,运维王国担心系统运行的可靠性,因为它们是在发生故障时在凌晨3点分页的。 一旦系统稳定下来,他们宁愿再也不发运新东西,因为100%的新bug来自新代码。 几十年来,这些王国发生了战争,许多血液流了出来。 (好吧,不是真正的血,但电子邮件可能会变得非常暴躁……) 那么,有一天这个人有一个想法。 有个人意识到这个年代久远的冲突的基本假设是错误的,并将这个问题改写成一个全新的概念 - 错误预算。

您可能建立的任何系统(可能是起搏器除外)都不需要在100%的时间内提供服务。用户有很多中断,他们从来没有注意到,因为他们忙于生活。 因此,对于几乎所有的系统来说,都有一个非常小的(但非零)可接受的不可用量。这种停机时间可以被认为是预算。只要系统低于预算,它就被认为是健康的。 例如,假设您需要一个99.9%的时间(三个九)的系统。这意味着系统在0.1%的时间内不可用(对于任何给定的30天月份,即43分钟)。 只要你没有做任何事情导致系统下降超过43分钟,你就可以开发和部署到你的内心。但是,一旦您打破预算,您需要花费100%的工程时间编写解决问题的代码,并且通常会使系统更加稳定。您制作的东西越稳定,下个月您发布错误预算的可能性就越小,您可以构建和部署的新功能也越多。 总之,错误预算符合开发者和运营部门的利益,并创造一个良性循环。 由此,一个新的职业诞生了:站点可靠性工程(SRE)。

工作约定

在以下情况下,SRE将承担系统正常运行时间和健康运行的责任:

  • 该系统(如所开发的)可以通过严格的检验流程 - 称为生产准备评审(PRR)
  • 构建该系统的开发团队同意维护关键支持系统(如监控),并成为定期评估和事后检查等关键事件的积极参与者
  • 该系统不会经常打击其错误预算
  • 如果开发商没有在关系中维护他们的责任,那么SRE就会“离开”系统。

这种基本关系有助于创造一种合作文化,从而实现令人难以置信的可靠性和超快速创新。

成员组成:

50%左右为纯开发;50%左右为具备85-99%的开发技能+其他技能(主要为Unix系统内部细节和1-3层网络知识,即系统工程师的主要技能)

工作方法论:

  1. 用软件工程方式解决运维问题。
  2. 50%时间用于开发
  3. 在保障SLO的前提下最大化迭代速度

待更新…