97 Things Every SRE Should Know-02
Table of Contents
Do We Know Why We Really Want Reliability?
我们真的了解可靠性吗,或者说我们为什么会想要它?
这似乎是一个奇怪的问题。在这个社区里,这是一条信仰,即无法到达的在线服务没有价值。但即使是稍加思考,你也会发现这根本不是事实。你自己几乎每天都会遇到间歇性的电脑故障。有些情境甚至似乎预料到了这一点;对于网络服务,用户高度习惯于点击刷新或(对于更困难的问题)清除Cookie、重启浏览器或重启机器。甚至服务本身也有重试协议。
每一次人机交互都会有一定程度的虚化。即使是较长时间的中断,如果你宕机几分钟,人们几乎都会回来,甚至有更多的耐心,这取决于所提供服务的独特性。
这是一个轶闻轶事,但也具有启发性:几年前,我曾与一家非常知名的公司进行过一次对话,他们说:他们没有在可靠性上投入任何资金,因为他们的客户群没有其他地方可去。因此,他们花在可靠性上的时间就不会花在获取收入上,这不值得。
当时我内心惊呼,但此后我经常思考这个问题,现在我把问题转向我们,作为一个社区:作为一个社区和一个行业,我们有什么真正的论据来反对这种说法吗?我们能不能把任何数字放在它周围?理解什么是权衡?除了对品牌形象的情感诉求之外,还能提出什么其他的说法吗?想出一个真正的解释,为什么以前因为不可靠而受到指责的公司今天价值数百亿,更不用说那些网站无法访问要付出真金白银的公司了。故障经常持续数小时,但使用量、收入和利润却一直在上升?
我不喜欢这样的公司,但我认为这是事实,在一个不断上升的市场中,如果一个公司可以选择获取新的客户或保留现有的客户,那么每一个经济激励都是向着获取客户的方向发展,因为每失去一个客户都会被更多获得的客户所取代。当然,一个系统性不可靠的平台最终会让你失去和你获得的客户一样多的客户,但你有时间去解决这个问题,而且客户往往不愿意改变,即使给他们的服务不好。
产品开发人员知道这一点,这也是为什么我们的对话如此充满争议的原因。然而,我们今天还没有一个完全令人满意的方法来谈论这些权衡;可靠性的真正价值,特别是对于那些没有崛起的市场、非网络背景或其他不常见的SRE的领域,是很难阐明的。SLO模型的目的是为了能够准确地阐明一个给定的客户群在总体上能够容忍多少不可靠的细微差别,但实际上是不够的;按照通常的用法,它不能区分(比如)20分钟的几乎完全不可用或两个小时的间歇性不可用。这些情况从客户体验的角度来看,其实是非常不同的,从创收的角度来看,也有可能是不同的。
我们拥有稀少的数据点,这些数据点勉强地暗示了一种方法的轮廓,使我们能够理解,并成功地论证为什么在时间和资源有限的情况下–或者更糟糕的是,在一个不断上升的市场中–要在可靠性上花时间,但我们离理解这一切还非常遥远。
因此,根据你的观点,这是一个相当令人担忧的问题,或者是一个停止花费大量时间和金钱的绝佳机会。
我们如何构建本书的结构
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系列的文章,有时间我就会翻译一些,希望大家能学到对自己有用的东西。谢谢