第 23 章 SRE 反模式
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
人类的大脑是为规避威胁而构建和训练的。我们可能不善于权衡相对风险、1但我们很擅长从一堆事情中挑出一件看起来像我们以前见过的故障模式的事情。2
面对现实吧。失败很有趣!3失败也是一个好故事。因此,将不应该做的事情编入目录,而不是只将应该做的事情编入目录,往往更容易也更有效。
但是,"反模式 "并不是 "这一次,在 Foo 夏令营 "的失败故事。它们是我们见过的出大错的事情,不是一次,不是两次,而是一次又一次。反模式是有吸引力的谬误。这些策略成功的时间比你需要的时间要短一些。常识比道理更常见。
在本书的其余部分,你会发现一些你应该做的事情的例子。这不是我在本章要讲的内容。把这一部分当作你的 "防御'哦!'艺术 "词汇表吧。或者,你也可以坐下来,尽情想象我和许多过去和现在的同事为了与你分享这份简短的清单而不得不搞砸的事情。SRE 并不完美。其中有些错误我自己甚至犯过不止一次。这就是它们成为反模式的原因。
反模式 1:网站可靠性运营
旧的工具和方法不一定能完成新的任务。
网站可靠性运营:在不从根本上改变运营人员处理问题的方法以及他们应完成和有权完成的工作性质的情况下,将运营人员重新命名为网站可靠性。
网站可靠性运营不是一回事。现场可靠性是一门软件、网络和系统工程学科。你不能把一群坐在网络运营中心(NOC)的技术人员,给他们一个 GitHub 账户和公共云预算,告诉他们把一些东西转移到容器中,然后神奇地把他们重新塑造成 SRE。4
NOC 是几种过时观念的产物。首先,有一些特定人员的工作就是不惜一切代价保持已构建系统的运行。SRE 并不这样做。SRE 构建的系统需要的人工干预更少,故障频率更低,他们修改现有系统以消除突发故障模式。他们不会照看机器,也不会用鲜血、汗水、泪水、恐龙油脂或其他生物制品喂养机器。
SRE 应将一半以上的时间用于构建更好的系统,而不是执行或记录操作任务。一句话,他们应该从事工程设计。好的工程设计需要流程。流程会在中断的环境中消亡。为团队提供所需的时间和空间,让他们通过工程设计来解决技术问题,这样,即使规模、速度和范围不断扩大,也能提高所有工作的效率。
我们看到很多人在 SRE 会议上谈论他们为 SRE 建立的 NOC。NOC 很酷。它们鼓舞人心。其中的佼佼者会让你感觉自己像个英雄,世界的命运--或者至少是业务的命运--都掌握在你的肩上。但英雄文化本身就是一种反模式,SRE 不适合在 NOC 中工作,尽管 NOC 最初的发展原因是可以理解的。
有时,让所有人在同一个物理空间内解决问题所带来的通信带宽是无与伦比的,但他们用来完成这项工作的工具不应该被束缚在那个房间里,工作和/或人员也不应该被束缚在那个房间里。网络中心不利于良好的工程工作。
国家控制中心是最开放的开放式办公室,在茫茫人海中还会有额外的闪烁和嘈杂干扰。令人费解的是,我们这个以数据驱动为荣的行业怎么会对越来越多的科学证据视而不见,不知道开放式办公室是多么不适合工程团队的工作。5
不要把时间和财力花在建造房间上,试图让操作人员全天候接近机器和彼此。
这里的关键在于分布式共享和随时随地的协作,这样,只有真正应该随时待命的工程师才能立即做出反应,而无需离开他们舒适的家、办公室或设计精良的立方体。6如果您想共享某个时间序列图的链接,您应该能够将其发布到聊天或事件响应工具中,这样,对事件感兴趣的每个人都可以通过流量、开始和结束时间、分辨率等相同的过滤器查看相同的图。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access