回到2000年

Google是SRE概念的发明者，并且将实践经验总结成《Site Reliability Engineering》一书。 SRE这个词汇也在这本书出版后流行了起来。

彼时（2000年左右）的Google属于初创公司，雅虎是当时的顶流网站。敏捷开发流行，作为技术起家的Google也同样采用Release early, release often文化，很长时间Google的产品都带有BETA标签。新功能快速迭代和新产品的快速上线有助于Google更快的获得更多用户，占领市场⁶。

快速的迭代和发布，意味着引入更频繁的变更，也意味着系统和服务出现错误的概率会更高。

软件系统或服务经常出错，甚至崩溃/不可用，轻则导致用户流失，市场竞争力下降，造成公司经济损失。重则可能会对公共安全和生命安全造成威胁⁷。Google当时所面临的是第一种情况，也是现在大多数互联网公司所面临的情况。

另一方面，用户规模的快速增长，导致增加更多的硬件资源和支撑型的组件，这又会增加额外的复杂性和不确定性，同样会提升系统或服务出错的概率。

Borg，Kubernetes的前身，就是那时开发的⁸。

2003年⁹，正是在这样的背景下，Google的SRE团队成立。我们现在得到的信息是什么？

1. 快速迭代和服务质量（可靠）的冲突
2. 市场竞争和用户规模的快速增长的压力

在那个时候，还不流行小而美这种不追求规模的创业理念。大家都想变大，Google也是。想要变大就必须在这两者之间寻求一种平衡。 SRE团队要解决的就是高速迭代和高质量服务之间的矛盾。

缓冲

Google选择在这两者之间设置一条缓冲带：当缓冲充足时，让迭代尽可能的快，而当缓冲快要填满时，降低迭代速度，甚至暂停迭代，直到缓冲区有足够的空间，并且给这个缓冲起了一个名字–错误预算（Error Budget）。

The structural conflict is between pace of innovation and product stability, and as described earlier, this conflict often is expressed indirectly. In SRE we bring this conflict to the fore, and then resolve it with the introduction of an error budget.

Tenets of SRE

软件制品的生命周期分两部分：生产和运行。产生阶段通常由产品开发团队负责，部署运行阶段则交由运维团队或者负责。

生产阶段为了更快的推出新功能，往往采用敏捷开发理念，让产品和功能的迭代速度变快。正如上图所描述的，更频繁的变更带来的是服务脆弱的风险。SRE团队则采取”反敏捷”的方式来平衡这种风险。

错误预算让产品每次迭代的质量可度量¹⁰，Google通过服务等级目标（SLO）来计算错误预算的数值。这里，错误预算和SLO，以及SLO的下级指标SLI都是为了解决速度和质量矛盾的产物。

缓冲的两侧

左侧，是产品服务的开发侧。右侧，是产品服务的运行侧。

软件工程学科的存在让我们将太多注意力集中在左边，而右边长久以来由松散的脚本和人力经验支撑，直到Google将右边工程化，平衡才得以实现。

非常有趣的是，在有些企业中，当右侧团队尝试用工程思维解决问题时，比如尝试运用数学方法和统计理论构建告警，得到了来自左侧团队的评价是「一个告警而已，搞那么复杂干什么」

更糟糕的情况，左侧团队几乎不使用任何工程化方法和理论进行产品开发工作。

工程化（Engineering），我指的是运用科学理论和数学工具进行产品研发。构建规模化的产品和服务，不能仅仅依靠对编程工具的熟练掌握，更不能期望通过这种方式构建可靠的产品和服务。

SRE之道

寻求创新速度和服务质量间的平衡，正是SRE之道。

实现这种平衡，要求我们采用多种手段¹¹：自动化，数据化，可视化…

采用SRE方法之所以困难，一个重要的原因是，我们在进行自动化，数据驱动开发，业务可观测的过程中，常常不记得这么做究竟是为了什么。

Tools were only components in processes, working alongside chains of software, people, and data. Nothing here tells us how to solve problems universally, but that is the point. Stories like these are far more valuable than the code or designs they resulted in. Implementations are ephemeral, but the documented reasoning is priceless. Rarely do we have access to this kind of insight.

via

工作, 是同公司合作

公司雇佣员工, 出发点是为了让员工帮助公司完成一些工作. 是用薪水置换员工的时间, 服务, 劳动力或者专业知识.

在这个过程中, 公司和员工之间建立的是一种合作关系. 你被公司聘用, 是因为公司通过面试过程, 认为你可以完成需要完成的工作. 你接受公司的聘用, 是因为公司为你支付的薪水在你的接受范围.

奉献, 是自己的选择

员工完成公司支付了薪水部分的工作, 是应该的. 除此之外的工作, 是员工的奉献, 是员工的自由.

选择奉献, 可能会给员工带来超额的回报, 比如更快的涨薪, 更快的升职. 但也可能什么都不会发生. 收益和风险总是并存, 期待获取收益而无视风险, 是危险的.

当员工的利益和公司的利益深度绑定时, 奉献所带来的收益往往才会更客观.

因为自己在公司很多年, 就要求公司必须珍稀自己, 是幼稚的.

应该怎么做?

没有人比你更关心你的钱, 也没有人比你更关心你的生活.

除了完成公司付你薪水的工作之外, 你可以选择奉献. 当你在奉献时, 请明白你正在攀爬第几座山. 明白奉献的收益和风险, 永远不要把奉献当成是一种义务, 因为你总是在追寻一些东西.

公司作为一个追逐利润的组织, 每个选择都在平衡风险和收益. 自己也应如此.

The Senario

以生产Kuberntes集群中的Deployment为标准, 列出验证环境Kuberntes多余的Deployment.

要解决这个问题, 大致分为下面几步:

• 列出生产环境的Deployment, 保存到文件prod.txt
• 列出验证环境的Deployment, 保存到文件staging.txt
• 结果集 = staging.txt - prod.txt

每个文件里的内容大概是这样的, 每一行是一个Deployment的名称:

prod.txt

frontend-web
backend-api
database-mysql
redis-cache
elasticsearch-cluster
auth-service
logging-fluentd

唯一不同的是staging.txt里的内容比prod.txt多一些:

要得到staging.txt比prod.txt多出的部分, 计算staging.txt和prod.txt的差集¹是一个符合直觉的做法.

Before shell solution

在Python中可以用set来表示集合, 用-来求差集:

set_a = set([1,2,3,4])
set_b = set([3,4,5,6])
difference = set_a - set_b

difference

{1, 2}

使用Python完全可以胜任,但是使用*nix环境给你提供的默认工具, 会让这个问题得以优雅的解决.

The Shell Solution

grep 是Linux环境下最常见和常用的过滤工具, 我之前没有意识到他在处理这个问题上可以这么优雅.

grep -vFf prod.txt staging.txt

三个参数:

• -v : 反向匹配, 即只匹配不包含的行
• -F : 以固定字符串而不是正则表达式进行匹配
• -f : 从文件中读取匹配模式

也就是: 从staging.txt中匹配不包含在prod.txt中的行. 即staging.txt比prod.txt多出的部分.

三个参数中, -v 也许是我使用最多的,因为在筛选某些进程的进程(号)时,并不希望看到grep本身进程的进程(号).

ps -ef |grep nginx |grep -v grep