97 Things Every SRE Should Know-08
Table of Contents
Observability in the Development Cycle
开发周期中的可观察性
干净利落地捕捉bug，迅速解决bug，防止bug成为积压在开发过程中的技术债务，有赖于团队快速发现这些bug的能力。然而，软件开发团队往往因为各种原因阻碍了他们的能力。
考虑一下那些软件工程师不负责在生产中运维软件的组织。工程师们将他们的代码合并到master中，祈祷这个变化不会破坏prod(production)环境，并等待在出现问题时得到错误页面(http 500)。有时他们在部署后不久就会看到错误页面(http 500)。然后将部署回滚，可以检查触发的变化是否有bug。更有可能的是，在该代码被合并后的几个小时、几天、几周或几个月内都不会发现问题。到那个时候，要找出bug的起源，记住上下文，或者解读为什么要写那段代码或者为什么要发布代码的原始意图，都是非常困难的。
快速解决bug的关键在于能够在原始作者头脑中还记忆犹新的时候检查问题。调试问题再也不会像编写和发布之后那样容易了。从那时起，一切只会变得更加艰难;速度是关键。乍一看，可观察性和编写更好的软件之间的联系可能不太清楚，但正是这种快速调试的需要让这两者深深交织在一起。
刚接触可观察性的人经常会犯这样的错误:认为可观察性是调试代码的一种方法，类似于使用非常详细的日志记录。虽然可以使用可观察性工具调试代码，但这并不是可观察性的主要目的。可观察性是在系统的顺序上操作，而不是在函数的顺序上操作。在行级发出足够多的细节来可靠地调试代码，会发出大量的输出，以至于会用大量的存储和规模淹没大多数可观察性系统。花钱买一个能够做到这一点的系统是不切实际的，因为它的成本很可能是你的系统本身的1倍到10倍左右。
可观察性不是为了调试你的代码逻辑。可观察性是为了找出系统中哪里可以找到你需要调试的代码。可观察性工具可以帮助你迅速缩小问题可能发生的范围。错误源于哪个组件？在哪里引入了延迟？一段数据是在哪里混入的？哪一跳占用了最多的处理时间？该等待时间是均匀地分布在所有用户身上，还是只有其中的一个子集才会经历？可观察性有助于你对问题的调查确定可能的来源。
通常情况下，可观察性还能让你很好地了解受影响的组件中或其周围可能发生了什么，或错误可能是什么，甚至提供了错误实际发生的提示–你的代码、平台的代码或更高级别的架构对象。
一旦你确定了bug所在的位置和关于它如何产生的一些特质，可观察性的工作就完成了。如果你想深入研究代码本身，你需要的工具是一个调试器（例如，gdb）。一旦你怀疑如何重现问题，你就可以旋转一个代码的本地实例，从服务中复制过来完整的上下文，然后继续你的调查。虽然有关联，但可观察性工具和调试器之间的区别是一个规模的顺序；就像望远镜和显微镜一样，它们主要是为不同的事情而设计的。
改编自O’Reilly即将出版的《可观察性工程》一书，预计2021年出版。
我们如何构建本书的结构
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系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢