Table of Contents

In Search of the Lost Time

寻找逝去的时光

谁没有面临过因一个你认为可以再等六个月的问题而造成的重大故障——呼!。我们多么希望我们能避免这场火灾,如果有那个时间来防止它,那该有多好。但我们从来没有这样做;时间是工程中最稀缺的资源。

我们总是被困在这里,而且我们知道为什么。基础设施团队身兼数职:支持产品团队并运行现有的系统,on-call【1】,开发人员工作流程,以及供应;这个名单可以继续下去。由于每天的时间太少,资源有限,偿还技术债务、构建自动化和工具变得不受重视,转而支持功能工作。毕竟,产品才是卖点;公司正在努力发展和保持活力,所以大部分的精力都用在了通过为客户的问题建立强大的解决方案来获取新客户。

对这项工作的轻视使我们失去了对变化持开放态度的机会,也失去了弄清绿地工作(greenfield work)【2】如何与当前工作相结合的机会。在这个世界上,等待一个圣杯型的项目(Holy Grail–type of project)来解决问题,而不利于小的、持续的改进,这看起来不是更明智吗?

空间或时间的缺乏是为什么一些组织需要很长时间才能弄清楚 CI/CD(持续集成/持续交付)之类的事情的原因。他们关注的是这个概念的艰巨性及其相关的风险,而不是一点一点地展开。这就是为什么我们仍然在半夜被告警叫醒,因为需要阅读运行手册并反复应用相同数量的步骤,而不是投资于任何形式的自动修复的事件。所有的解决方案都感觉很庞大,而时间是有限的,所以即使尝试又有什么意义呢!?我们必须继续这条老路,忍受痛苦。

不在两方面平等投资的问题是,在可靠性方面的投资成本会随着时间的推移而增长。新功能所增加的复杂性给工程师们增加了更多的认知负担,使得可靠性工作变得更加困难。这些问题开始在我们的脑海中浮现,以至于我们最终推迟,直到我们有更多的时间,也许是在遥远的未来——直到不可避免的故障发生。

解决方案的一部分是每天优先处理一些小事,以实现整体的可靠性目标,而不是工作了一个星期后又继续工作(而且再也不回来了)。组织我们的日子以适应较短的琐事,使我们的大脑感到更轻松,并建立起一种习惯。从商业角度来看,它也允许更多的定期检查和持续改进。

我们如何巩固这一模式?这要从公司层面的承诺开始,为工程师创造自由,让他们在项目中持续解决他们的可靠性问题。

这种自由转化为时间,根据你的工程模式,它可以是每天、每天或每周X次(6周至1季度)的某个百分比,完全用于技术债务。然后是工程团队和基础设施之间就最需要改进的领域达成协议。

所以,下次你有30分钟的时候,想想如何能摆脱一些烦人的东西。每天的30分钟加起来就是每周150分钟,每月600分钟,每年7200分钟!想象一下,你可以用这些时间来解决什么问题!

我们如何构建本书的结构

SRE虽然涉及复杂的技术系统,但归根结底是一种文化实践。文化是人的产物,这启发我们根据你在组织中的SRE数量来组织本书的各个部分–你具体处理什么,你的一天是怎样的,取决于有多少个SRE工程师。我们将本书的文章分为 “SRE新手” 、0-1个SRE、1-10个SRE、10-100个SRE和 “SRE的未来 ”。

读者如果想找寻先从哪里开始的指导,可以直接跳到最适用于自己的部分;但是,你仍然会发现阅读那些目前并不适用于你日常的部分的文章的价值。

在0到1个SRE时,还没有人被指定为SRE,或者你已经找到了你的第一个SRE,这个角色看起来几乎是孤独的。

在1到10名SRE时,你正在组建一个团队,有知识共享和分工的能力。

在10到100个SRE时,你已经成为一个组织,你需要思考的不仅仅是你所从事的系统,还需要思考如何组织这么多SRE。

“SRE新手” 涵盖了基础性的话题(尽管并不详尽!),对于那些刚刚开始SRE之旅的人来说是很有帮助的,即使是最有经验的SRE,也是一种复习。 “SRE的未来” 包含了一些文章,这些文章探讨了SRE潜在的发展方向,或者是(目前)坐拥时代潮流。

没有必要按照任何特定的顺序阅读本书。你可以从头到尾读一遍。或者,如果你对某个特定的主题感到好奇,可以翻到索引,在那里你可以找到关于该主题的所有文章。把它作为参考指南,或者是灵感的来源–可以在需要的时候提供一个震撼。或者,也许可以建立一个阅读俱乐部,每周一次挑选一篇文章与同事讨论。这就是散文集的魅力所在。我们希望你和我们一样喜欢阅读它们。

结语

SRE系列的文章,有时间我就会翻译一些,希望大家能学到对自己有用的东西。谢谢

翻译不易,转载时请注明原文链接,谢谢

延伸阅读

1.on-call
2.Greenfield work
In software development, a greenfield project could be one of developing a system for a totally new environment, without concern for integrating with other systems, especially not legacy systems. Such projects are deemed higher risk, as they are often for new infrastructure, new customers, and even new owners.

A greenfield project is simply a new project, not building on anything existing. The analogy is to building on a green field - there are no existing buildings or infrastructure.

This is opposed to brownfield projects - which would involve changes and maintenance to an existing piece of work.

The term is not unique to IT.