Table of Contents

Applicable and Achievable Static Analysis

可适用和可实现的静态分析

SA（静态分析）(static analysis)是一种在不执行代码的情况下分析软件属性的方法，其严格程度各不相同，包括从句法检查（如linter）到形式验证技术的分析。静态分析可以是手动的，也可以是自动的，前者需要数学证明，后者需要静态分析器的自动检查。

一般来说，静态分析可以分为三大类，按照严格程度的递增排序，具体如下：

1. 代码合规性和指标分析
2. 完整性分析
3. FV（形式验证）(formal verification)

代码合规性根据一组定义好的语法规则检查源代码。支持代码合规性的工具通常包括旨在评估代码复杂性的度量分析，其中包括诸如以下度量：

• 循环复杂性（一个模块中决策点的数量）
• 路径复杂度（通过一个代码模块的可能路径的数量）

代码合规性检查器可以通过识别构造不良的代码、语法不符合性或可能导致缺陷的复杂控制流，建立对代码质量的信心。这可以减少，而不是消除手头的代码表现出意外行为的概率。

一般来说，最适合验证和确认软件系统的静态分析技术将取决于SLO/SLA（服务质量目标或协议）【1】内定义的服务可用性等因素。在这种情况下，代码符合性适用于所有级别的SLO和SLA。

完整性分析旨在确保程序永远不会进入编程语言所不能定义的状态。这通常等同于运行时错误，包括读过了数组的末端，读了未初始化的内存位置，或除以零。它还考虑与语言无关的缺陷，如缓冲区溢出或任何可能破坏代码正确执行的并发问题（如数据竞赛、竞赛条件等），或涉及并发模块之间非故意的互动，如死锁。

因此，完整性分析是最适用的分析，可以使系统的性能和可用性受益。也就是说，去除常见的漏洞可以确保系统的性能不会出现意外的异常，特别是对于需要更高的可用性的系统（99.9%以上）。如果存在完整性错误，系统在功能上是不正确的，而完整性分析可以被视为形式验证的一个子集。

幸运的是，大多数完整性分析工具不需要SA或FV方面的深入专业知识，因为有大量的工具可以现成地、自动地、大规模地应用，包括Polyspace、CodeSonar、Frama-C和Facebook Infer。

形式验证(formal verification)的目的是根据一组需求或规范，用数学方法证明给定程序的功能属性。它可以为系统的行为提供测试无法提供的保证。要做到这一点，首先必须将程序形式化为一个模型或抽象，然后用形式化规范语言定义程序的功能要求。因此，形式化工具通常是半自动的，需要形式化方法的专业知识来形成模型和规范。

形式验证通常只对要求99.99%以上的服务可用性的系统是必要的，因为相对于避免的风险来说，严格的要求和人工努力是昂贵的（见ALARP【2】）。

静态分析和形式验证技术没有被充分使用，因为人们误认为它们是不必要的严格和复杂的。不幸的是，这阻碍了SRE【3】去考虑那些可以指导消除生产系统中出现的繁琐而昂贵的缺陷的工具。SRE可以轻松地部署SA工具，而不需要对基础设施进行大修，同时获得SA和FV技术提供的系统保证的好处。

我们如何构建本书的结构

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.Service-Level

2.ALARP
ALARP (”as low as reasonably practicable”), or ALARA (“as low as reasonably achievable”), is a principle in the regulation and management of safety-critical and safety-involved systems.[1][2] The principle is that the residual risk shall be reduced as far as reasonably practicable. In UK and NZ Health and Safety law, it is equivalent to SFAIRP (“so far as is reasonably practicable”).
“ALARP” 原则是“最低合理可行(As Low As Reasonably Practicable，ALARP)”原则的俗称。ALARP原则是当前国外风险可接受水平普遍采用的一种项目风险判据原则。

3.Site Reliability Engineering-中文
   Site Reliability Engineering-english