Linux 文件系统 inode 介绍

Posted on by 7 Comments

平常使用计算机，我们的直觉是计算机里面分成了文件夹和文件两种东西。但是实际上在操作系统的文件系统中，文件夹也可以被认为是存储了特殊内容的文件，“所有的东西都是文件”。而且文件系统并不用文件名来区分文件，而是使用一串不重复的数字。本文就来介绍一些文件系统的一些概念和原理。

Linux 的文件系统将磁盘分成了两部分。一部分存储的是 inode，一部分存储的是 block。文件的内容存储在 block 中。文件的元信息，比如 owner,group,atime 等，都存储在 inode 中，包括 block 的位置。如下图：

从图中我们可以看到，这里面没有文件名字的信息。而我们日常对文件的操作都是通过文件名来的。那文件名字在哪里呢？上面说过，文件夹也是文件，其实文件的名字，就在文件夹的内容里面（即 blcok）。文件夹也是上面的形式，由 inode 记录了它的元信息，然后 inode 指向了 block，block 里面存储了文件夹的内容，即文件名字到 inode 的映射。

虽然文件夹也是文件，但是操作系统并不提供 syscall 对文件夹的内容进行直接操作。比如，你不能 cp /dev/null directory 来覆盖文件夹的内容，也不能查看 block 存储的真正内容。而只能通过系统提供的 syscall 对文件夹进行有限的操作。这么做第一是因为对文件夹的操作就这么多，通过 syscall 就够了；第二是因为文件夹存储的映射如果被搞乱了，不光这个文件夹不可用了，相关的 inode 都拿不到了（因为我们针对文件的操作都是通过文件名，inode 被文件系统屏蔽掉了）。

所以，当文件系统拿到一个路径，是怎么找到对应的内容的呢？比如 /home/root/a.txt 。

首先文件系统会从 #2 inode 开始（注意这里说的经典的文件系统，不同的文件系统开始的 inode 可能不同，但为啥是2呢？），也就是 / ，找到 #2 inode 指向的 block 读到 / 下面的文件列表。然后找到 home 对应的 inode。然后通过 inode 指向的 block，打开 /home 下的文件列表，找到 root 对应的 inode，找到 inode 指向的 block，读到 a.txt 对应的 block，最后读到 block 存储的内容，就是 a.txt 的内容啦。

我们可以通过 ls 的 -i 参数查看一个文件夹下的名字对应的 inode（跟上面说的从 #2 开始不一样，因为我这个环境是 xfs）：

文件系统一旦创建，inode 的数量或 block 的数量就确定了，不能修改。如果 inode 用完了，文件系统就再也不能创建新的文件了（不太可能发生，除非创建的小文件非常多）。df -i 可以查看系统的 inode 使用情况。

inode 到 block 的寻址

你用过U盘吗？可否遇到过U盘不能存储超过4G的文件的问题（FAT32文件系统）？即使U盘是32G的。这其实是文件系统寻址的限制。接下来我们以 EXT4 文件系统为例，看下有了 inode，文件系统具体是怎么找到 block 的，顺便计算一下 EXT4 单文件最大可能是多少。

在前面的那种图中，可以看到 inode 包含了文件拥有者，访问时间修改时间等信息。最重要的，是 block 的位置，毕竟这是真正存储了文件内容的地方。

如果给你一个 inode，你怎么把 block 的位置存到 inode 里面呢？文件的大小是未知的，可大可小。基于这个特点，首先想到的可能是用一个 LinkedList 来存储 block 的位置，block 留出一个位置存储下一个 block。但是要知道，机械硬盘顺序读很快，随机读的话磁头移动是非常慢的。所以 block 肯定是尽最大的可能连续使用，用 LinkedList 来做寻址就太慢了，比较合适的是 Array 这种相邻的形式。

那么在 inode 中我们应该为 block 的地址留出多少位置呢？太少的话，单文件的上限就太小了。太大的话，如果系统中都是一些小文件，就太浪费空间了。

Ext2/3 文件系统是这么做的（也是大多数文件系统的一个做法）：留出15个位置来负责存储 block 的地址。一个文件只能有 15 个block 吗？当然不是。这15个地址里面分成了直接指向（Direct Block Pointers），间接指向（Indirect Block Pointers），双重间接指向（Double indirect Block Pointers），三重间接指向（Triple Indirect Block Pointers）。

其中表示直接指向 block 的地址占了12个，这里我们假设一个 block 的大小是 4K，那么如果文件如果小于 4*12=48K 的话，直接使用 inode 中的直接 block 指针就可以存的下。综上，Direct Block Pointers 一共有12个，每一个表示一个 4K 的block。一共可以存储 48K。

第13个指针表示的是 Indirect Block Pointers。这个指针指向的地址也是一个 block，但是这个 block 里面存储的并不是文件的内容，而是一些指向 block 的指针——整整一个 block，存储的都是像 Direct Block Pointers 那样的指针哦！满满 4K 的指针。Block 指针是 32bit 的，一个 block 可以存储 4K/32bit = 1024个 Block 指针。综上，Indirect Block Pointers 就一个，里面使用一个 block 存储了 1024 个 block pointers，可以存储 1024 * 4K = 4M 数据。

第14个指针是 Double indirect Block Pointers，比较好理解了，这个位置存储的地址依然指向了一个 block，但是这个 block 里存储的还是 block 指针，这些 block  指针指向的 block 里面存储的还是指针！这些指针再指向的block存储的才是文件的内容。见上图的最后那一个位置。我们知道 Indirect Block Pointers 可以存储 4M 的数据，那么这里的双重 Block 指针其实就是存储了 4M 的指针，4M 可以存储多少个 Block Pointers 呢？4M /32bit = 1048576个，每个block 4K，那就可以存储 4G 数据。

第15个指针，很好理解了吧，让我绕个圈子，这里存储的是指向 Block 的指针，指针指向的 Block 存储的还是 Block 指针，指针指向的 Block 存储的还是Block指针，这里存储的 Block 指针指向的还是 Block 指针（数数这里面有几次 Indirect吧）。这些指针指向的Block存储的是文件内容啦。这里最多可以有多少个 Block 呢？Double indirect Block Pointers 可以有 4G，那么这 4G 数据都是指针的话就是 4G / 32bit * 4K = 4G * 1024 = 4T.

综上，文件最大是 48K + 4M + 4G + 4T。是不是很巧妙的设计？

因为这种方式指向无法动态给二重或者三重指针分配大小，未免有些浪费。在 Ext4 中，ext4_extent_header 的多重指针是动态分配的，简单来说，eh_depth 字段标识了目前的 block 是第几重指针，如果是0，说明指向的 block 直接存储的是文件内容，如果不是0，那么 block 存储的就是 Indirect Block Pointers, 并且 eh_depth 标识了会有几重指针。在 Ext4 中，但文件最大大小不再受层级限制，而受 logical block number 的限制，即 block number 最大是 2^32，在 4K block 下，就是 16T。eh_depth 最大是 5，仅仅是因为 5 就可以存储下 2^32 个 block number 了，再大也没有意义。(ext4_extent_header 长度是 12bytes，4*(((blocksize - 12)/12)^n) >= 2^32 中 n 最小是5）

最后需要强调一点是，不同的文件系统 inode 数据结构有所不同，比如 ext4 文件系统就支持将很小的文件直接存储在 inode 中，不使用 block。

Hard Link 和 Symbolic Link

上面我们说过，文件夹的内容其实是文件名字到 inode 的映射。

那么是否可以有两个 name 映射到同一个 inode 呢？

答案是可以的，这就是所谓的 Hark Link.

通过 ln source-filename target-filename 可以创建一个 Hard Link，即创建一个 target-filename 映射到和 source-filename 一样的 inode number。

举个例子，我们现在有 hello 这个文件：

可以看到它的 inode number 是 12945694378, 然后我们再创建一个 Hark Link：

我们可以观察到两个有趣的现象：

1）hello 和 world 有相同的 inode number，这意味着这两个文件名字对应的 inode 是一样的，即它们的 owner、atime，以及指向的 block 一模一样，文件内容也当然一模一样。如果我们改变了一个文件的权限，那么去看另一个文件名字，也会跟着改变。

2）有一个数字从 1 变成 2 了。这数字叫做 Link Counts，就是在 inode 中有一个字段记录的是有多少 filename -> inode number 的 mapping，当没有 filename 指向这个 inode 的时候，说明这个 inode 可以被回收了。

从上面我们可以看到，创建一个 Hard Link 之后，实际上就有两个 filename 指向了同一个 inode。即新创建的 Hard Link 和原来的在本质上没有什么区别，也分不出来谁是 Hard Link 谁是原来的文件。删除文件这个操作其实是 unlink，就是删除了一个 filename -> inode 的 mapping 而已，当一个 inode 的 Link Counts 为0，inode 才会被删除。

有没有感觉像 GC 中的引用计数？那么新的问题就来了：怎么解决循环引用的问题呢？比如像下面这个情况，子文件夹里面建立了一个指向父文件夹的 Hard Link.

可能的循环指向问题

这样在整个父文件夹删除的时候，这些 Hard Link 指向的 inode 的 Link Counts 依然不会下降，导致释放就有问题。文件系统是怎么解决的呢？禁止对文件夹建立 Hard Link，只允许对文件建立 Hard Link.

另外，你有没有想过为什么我们可以使用 cd .. 跳转到父文件夹呢？其实就是在文件夹创建的时候，会自动创建一个叫做 .. 的 mapping，指向父文件夹的 inode。即一个新文件夹创建之后，它的 Link Count 就是2了，一个是 .，一个是 .. 。

相对而言，Symbolic Link 更常用一些，因为 Hard Link 的管理成本太高了。你删文件的时候，得把所有的 Hard Link 都删掉才行。

Symbolic Link 可以理解成一个特殊的文件，文件的内容指向的是真正的文件。这样一来，如果删除了源文件，Symblic Link 还是存在的（用过 Windows 的朋友可以理解成 Windows 的快捷方式）。

早期符号链接的实现，采用直接分配磁盘空间来存储符号链接的信息，这种机制与普通文件一致。这种符号链接文件里包含有一个指向目标文件的文本形式的引用，以及一个指示自己为符号链接的标志。

这样的存储方式被证明有些缓慢，并且早一些小型系统上会浪费磁盘空间。一种名为快速符号链接的新型存储方式能够将文本形式的链接存储在用于存放文件信息的磁盘上的标准数据结构之中（inode）。为了表示区别，原先的符号链接存储方式也被称作慢速符号链接。

Source

Fun with inodes

  • 移动文件、重新名等操作，实际上只是修改了 parent directory 的 block 中存储的 filename -> inode 映射，所以跟文件多大是没有关系的，都是 O(1) 复杂度；而且这也不影响 inode 的号码。
  • 理论上，当文件创建，inode 分配，就不会再变了。移动、重命名、写入文件、截断文件都只是修改 inode 的元信息或者修改 parent directory 的内容，inode 总是不变。所以像日志收集程序，使用 inode 来区分日志文件，是非常可靠的。日志被 rotate 了也可以做到不重不漏。
  • 如果你知道一个 inode ，怎么找出这个文件呢？$ find . -inum 23423 -print
  • 但是直接操作 inode 是不允许的，Kernel 提供的 syscall 只能通过 filename 来操作文件。理由同上，文件系统 corrupt 了是很危险的。
  • 文件系统里面有一个文件带着古怪的名字，怎么删除？可以通过 inode 删啊。 $ find . -inum 234234 -delete .

 

最后再强调一下，本文介绍的是大多数 filesystem 的表现，具体到一个特定的 filesystem 可能会有所不同。如果本文有疏漏，欢迎指出。

参考资料（以下列举了一些参考资料，和文件系统的实现）：

2024年9月12日更新：原文介绍的 inode layout 其实是 Ext2/3 文件系统，不是 Ext4 文件系统，进行了纠正以及补充 Ext4. Debian 中文群 dududu 和 Yancey Chiew 指出。

 

Gitops 的一些实践经验

Posted on by Leave a comment

之前看过多很多讲 Gitops 概念的文章，今天终于看到一篇讲实践的（原文见这里），我觉得这篇文章很有参考价值，介绍了一些 gitops 实在会遇到的问题和工具，和大家分享一下。

1.只用一个 git 仓库

建议所有跟基础设施有关的内容都放到一个仓库，包括有的团队、所有的项目。比如 kubernetes 的 template， infra as code 的平台，比如 terraform，比如 ansible playbooks，监控设施比如 grafana dashboards, alerts, 等等。

这样有哪些好处呢？

  1. single source of truth。线上的真实环境，实际在生效的配置，都可以在这一个仓库找到，就避免了去各个平台看现在生效的是什么配置的问题；
  2. 可以将在 CI 中设置 lint、准入检查等。虽然如果分多个仓库，也可以分别设置 CI，但是那样毕竟容易乱。用 CI 我们可以自动的检查某些变更是否符合标准，一开始可能是全部要人工检查(去 Review Merge Request)，但是逐渐自动化起来难度也不大；
  3. 灾难恢复更简单。都放在一个仓库里面，可操作性就很强了，不然你要处理多个仓库的先后顺序问题，相互依赖的问题等等。
  4. 加强了管控能力和审计。这个很好理解，毕竟只有一个仓库嘛。但是 git log 一定要写好，审计才方便。

作者推荐了一个目录结构：

思考：

只用一个仓库所带来的透明性，收益是很高的，审批可能都是 merge requests 了。我们也不必各种问”最近有什么变更”了，每个人都可以去看 git log。如果操作都能设计成声明式的，那么回滚也很方便，revert log 就可以了。

恢复整站，或者再搭建一套环境速度也大大提高，waveworks 经历过所有机器都被抹掉的情况，得益于 gitops，集群的重新 provision 只用了 45min.

2.自动化

Automation is key because it speeds you up immense.

作者在这里举了一个例子，如果用 Prometheus 的话，可以将 HTTP 服务的大盘监控抽象成一种通用的模板，新加一种 HTTP 服务的话大盘可以自动生成。(监控规则同理)

思考：

在Web平台上点点点，是比较难自动化和复用的，但是如果是 Code 就不一样了。你可以用你最喜欢的Vim编辑器快速处理大量的配置文本，也可以用脚本批处理，可定制化很高。但是这依赖于 Infra as Code,监控代码化，configuration-as-code、database-as-code、infrastructure-as-code 等。

配监控太痛苦了！我觉得比较理想的监控是：中间件层收集一些通用的 metric，开发同学在代码中(用注释或者继承类的方式？)暴露关键的业务指标，大盘可以根据template自动生成。(要是真这样就好了)

3.能用Operators就用Operators

简而言之，可以减轻手动 Apply 的负担。(既然都 gitops 了，鼠标能少点几次就少点几次吧。)

举几个例子：

  • Atlantis: 基于 PR 的 Terraform 流程，看这里一张图就明白了。
  • flux: waveworks的作品，确保 git 仓库的配置和 k8s 集群中的状态一致。(消除 diff 应用变更，readme 里面也有一张图展示的很明白)

思考：

XX as code, 声明式，diff merge 应该是 gitops 的核心吧？

4.Secrets 能够被自动获取

Secrets are still just parts of the deployment, that is why they are required for full disaster recovery for example.

推荐将 Secrets 存在仓库中(当然了，加密存储)，或者在部署后能以某种形式自动地获取。这里的关键和难点是保持 Secrets 以加密的形式存储，严禁明文存入 repo。

Problem: “I can manage all my K8s config in git, except Secrets.”

Solution: Encrypt your Secret into a SealedSecret, which is safe to store – even to a public repository. The SealedSecret can be decrypted only by the controller running in the target cluster and nobody else (not even the original author) is able to obtain the original Secret from the SealedSecret.

— sealed-secrets

推荐的几种形式有：

  • 用类似 sealed-secrests 的 Operator，已加密形式将 Secrets 存到仓库，Secrets 到达集群的时候进行解密。(同类产品还有 Mozilla 的 SOPS)
  • 使用 Hashicorp Vault 类似的集中式 Secrets 管理工具
  • 云服务商提供的同类产品
  • 使用 git-crypt 或 git-secret 进行手动加密

以上，水平有限，如果有疑问可以看下原文确认，如有理解错误欢迎指出。如果原文有错误欢迎讨论。

 

virtualenv的原理

Posted on by 9 Comments

每个语言都是有自己的包管理工具，包管理是一个又复杂又难的话题，我觉得复杂度跟GC这个话题相比都不为过了。有趣的是，每个语言选择的包管理方案、依赖解决方案都多多少少不太一样，或多或少每个语言都做出了一些选择和取舍。比如 Go 是直接依赖 Github 做依赖管理(被大家吐槽很多次)，node 是根据 package.json 下载到项目的 node_modules 目录(被吐槽也很多，主要是下载的东西太多了，js 社区的一个风格又是依赖层层嵌套比较重)。Python 的包管理也被吐槽很多，大家吐槽的点主要是太复杂了吧，解决方案又太多，这方面很不Python哦。比如你要去了解 virtualenv,virtualenv wrapper,pyenv, pip, pipenv, 等等……

但是 Python 语言的机制决定了它解决依赖的原理是一样的，这篇文章就来解释 virtualenv 机制的原理。

首先我们来看一下，这些包管理机制要解决的最根本的问题是什么？是多个项目的版本冲突呀！比如A项目依赖了 x package 的版本1，B项目依赖了 y package 的版本2，两个版本又是不兼容的，怎么办？如果都装到系统目录下，那么肯定就有一个项目不可用了。virtualenv 就是来解决这个问题的。

一个实时是，Python 一开始并没有涉及 virtualenv 这样的机制来管理这个语言的包，而是因为 Python 自身寻找包的机制，导致了 virtualenv 这种包管理形式的出现。

从 sys.prefix 说起

当 Python 解释器启动的时候，它会从解释器所在的 Path 开始，加上 /lib/python$VERSION/os.py 来逐层向上查找。因为 os.py 是解释器启动强依赖的包。比如我现在的 Python 启动目录是 /usr/bin/python3.7，那么查找过程就是：

这里贴一下 strace python 的记录，以下是在我电脑上启动时候的真实查找 os.py 的过程：

找到之后会设置 sys.prefix 这个变量，解释器去找包的时候，就去 prefix/lib/PythonX.Y 中去找。virtualenv 的工作原理就是基于这个：如果你需要一个隔离的项目 virtualenv，那我就给你复制一个独立的 Python 解释器可执行文件，然后根据相对目录把你需要的包都放在这个解释器所在的目录下，这样这个解释器启动的时候就可以找到（并且只能找到）这个目录下的包，virtualenv 就实现了独立包依赖的方案。

virtualenv 工作原理

virtualenv 是这样工作的：首先 virtualenv 会复制 Python 解释器的可执行文件到 $VENV_PATH/bin/python，然后创建 $VENV_PATH/lib/python3.7/xx.py 到系统的 os.py 所在的目录的模块的软连接（这样可以节省空间）。根据我们上面说过的解释器的启动原理，启动的时候，根据解释器所在的目录，会找到 VENV_PATH 下面的包，我们安装包的时候，也是安装到这里。这个解释器所使用的包就和其他解释器隔离开了。

为什么解释器的可执行文件需要拷贝一份，而不是也通过软连接的方式呢？因为解释器会解析软连接的目标地址，如果使用软连接的话，包也会使用系统Python的。那硬链接可不可以呢？这个我没研究过，我看 virtualenv 的源代码里面有一个 FIXME 提出了这样的想法，但是没有去实践。

这就是它的基本工作原理了，使用的时候，无非就是将这个 virtualenv 的 bin 目录插入到 $PATH 的最前面。然后我们执行 pip Python 这样的命令，就会执行到 virtualenv 里面的。

Python3

如果使用 Python3，那么在生产环境就不需要安装 virtualenv 来创建虚拟环境了，Python3 内置了 venv 模块。

直接使用 python3 -m venv myenv 创建虚拟环境即可。

这个 venv 的原理，还是和上面我们说过的一样。但是 Python3 有一些提升，它的 Python 可执行文件是一个软连接了，用一个 pyvenv.cfg 来标志出 home 的位置。

它的文件内容如下：

如果 include-system-site-packages 为 true，解释器启动的时候就会将系统的库添加到 sys.path 里面，这样我们在虚拟环境就可以 import 系统中安装的包了。

参考资料：

  1. https://realpython.com/python-virtual-environments-a-primer/#why-the-need-for-virtual-environments
  2. https://rushter.com/blog/python-virtualenv/
 

Kernel space, user space, and syscall

Posted on by Leave a comment

这篇文章介绍什么是 kernel space 和 user space，以及系统调用（System call，以下会用 syscall表示）。

为什么要分成 kernel space 和 user space 呢？

这要对系统对进程的抽象说起，每一个进程看到的内存空间都从固定的位置开始，main() 总是从 0x4005db 开始，stack 也总是从特定的位置开始。那么不同进程使用的内存都是重叠的吗？

当然不是。这就是系统对进程的抽象。每个进程只能看到自己的内存，MMU（内存管理单元）将解决每个进程看到的虚拟内存和实际物理内存的对应（内存管理是一个很大的话题，这里只是简单的描述，有关内存管理有很多资料可以参考，这里提供一个有趣的文章：Virtual Memory With 256 Bytes of RAM – Interactive Demo）。不仅仅是内存，每个进程只能使用有限的资源，而 kernel 可以使用所有的资源。当 user space 需要使用硬件资源时，user space 通过 syscall 告诉 kernel space，kernel space 来完成调用。

这样做的目的是将资源隔离开，确保 user space 崩溃不会影响 kernel space；以及限制 user space 所能做的事情，不能让程序可以随意进入 kernel space 进行任意的操作。怎么做到的呢？当计算机启动的时候，CPU 会进入 ring0，即特权状态，在一个地址设置好 syscall 的对应关系（这个对应关系可以在这里查），比如 1 对应的就是 write() syscall，然后 CPU 退出到 ring3，即 user space。再次进入 ring0 的唯一方法就是通过 syscall。syscall 要求传入一个 int 表示要调用哪一个 syscall，这样，kernel 就可以控制所能执行的动作，即只能执行事先定义好的 syscall mapping。

Syscall 和一般的函数调用是不一样的，这一点读者应该已经明白了。因为在程序内部，可以使用 stack 或内存在调用之间传值，但是 user space 和 kernel space 是隔离的（当然也可以通过共享的内存传值），stack 不是共用的。如果写一个简单的 write() 程序反编译，可以看到 syscall 的汇编代码是 mov exa, 1 syscall ，其中1就是前面我们说的 syscall mapping，即 write()，然后 syscall 是 user space 向 kernel space 发出的软中断，进入 kernel space，kernel 会检查 exa 寄存器的值，找到对应的函数执行。（不同的架构实现会有所不同）

简单来说，kernel space 和 user space 是两个世界，syscall 就是连接这两个世界的桥梁。虽然这个桥梁我们一般不会直接使用，而是通过 glibc，glibc 是 syscall 的一个 wrapper，让我们 call 起来更加简单方便。比如说 printf 函数，其实就是 write() 的一个 wrapper。

通过 man 2 write 可以看到 write() 的原型如下：

所以我们可以这么调用，向屏幕打印字符：

有关 syscall 大体就是这样。以上是我的理解，如果有错误欢迎交流。下面再介绍一些相关的工具。

上面那张截图 radare2 的界面，一个反编译工具。使用方式是 radare2 -d ./a.out ，然后在s sym.main ，设置断点，可以看到 syscall 是如何执行的。

通过 man syscalls 可以查看系统提供的 syscalls. strace 工具可以将一个进程使用的 syscall 输出到 stderr，包括调用的参数，和返回值。比如查看 ls 使用的系统调用：

-c 参数很有用，可以显示每次 call 花费的时间，call 的次数，占用的总时间等，是一个 perf 的好工具。

 

参考资料：

  1. Linux System Programming
  2. Youtube: Syscalls, Kernel vs. User Mode and Linux Kernel Source Code – bin 0x09
  3. jvns 的这篇漫画：https://drawings.jvns.ca/userspace/
 

谈谈预防故障的性价比

Posted on by 1 Comment

说到保障系统的稳定性上，从预防的层面上看，总是有无数的事情可以去做。我觉得人们经常陷入的一个误区是，总是假设系统的某些方面会出问题，然后想办法针对这些特定的问题去做预防，认为预防好了这些问题自己的系统就万无一失了。这就导致很多时间花费在穷举系统可能出现的错误上、针对特定的错误做预防措施上。

最常见的错误就是增加流程。比如上线的流程、修改某个参数的流程。很可能一开始所有的流程都是简洁并快速的，每个人都可以将精力集中在自己的工作上。直到有一天出现了故障，大家在复盘的时候，发现“哦！假如说我们在发布之前增加一个流程，可以确认一下某个东西没有错误，那这个错误就可以避免了！” 这样的故障复盘越来越多，流程也就开始堆积的越来越多了，比如发布之前要求满足多少的覆盖率测试才能发布，某个变更做出之前必须经过某某审批才能执行。

其实添加一个流程是复盘最容易做出的决策——如果什么都不做的话，就等于问题发生了，作为领导或者负责人什么作为都没有，这个事情后面再发生或者再说起来就会很尴尬。事实上，但很多时候这么做其实是没有什么用的，首先，发生的故障一般都是新的故障，对已经发生的故障进行预防性价比太低；然后增加的很多流程其实并没有什么实际作用，最后会变成一种形式主义。比如强制要求测试的覆盖率，会导致程序员去写一些除了增加覆盖率并没有实际测试功能的代码；增加审批流程会徒增同事之间的沟通成本和审批时间，审批人大部分情况下可能也不知道他审批的是什么东西，背后有什么风险，最后也变成了纯粹的“走流程”。

另一种错误是试图穷举出系统中所有可能发生的故障，对这些故障设定自动化的处理方法或做好这个特定故障的应对方案。在一个很复杂的大型的分布式系统中，穷举出所有的故障几乎是不可能的。针对已经发生的故障提供针对的应对策略或者自动化的解决方式也帮助不大，虽然看起来给人一种安全感——我们每次的故障都不会再发生啦！但实际上就算什么都不做，相同的故障再发生一遍的概率又有多少呢？这又犯了形式主义了，我们从错误中学到的不是预防这一个错误，而是想想这个错误为什么会发生，是不是我们现有的机制出了问题（不要盲目修改机制，不然就犯了上面说的“流程”类的错误了。增加一个流程应该是慎重的，要考虑到这对将来每次的流程都会增加成本。）问题发生之后我们用了多长时间恢复，能否提高恢复的速度？还有一个方面，这种强调特定错误的“自愈”一般是和业务强耦合的，业务在发展，“自愈”的测试成本又很高，很难保持这种“自愈”长期有效。

将大部分的成本花在这部分上面，可能看起来让人很有安全感：“看，我们能应对这么多的情况了。”但是这些穷举出的情况并没有多大的意义，故障依旧会发生，并且总是以我们没有想到的方式。

所以我觉得将精力放在补救措施上会更有意义。寻找那些应对场景广泛的补救方法，不去针对特定的场景，而是针对特定的表现。比如部署在多个 Available Zone，如果监控显示一个 AZ 的流量有问题，无脑切换到其他 AZ 就可以；比如对非关键的服务提供降级措施，日常可以快速发布和迭代，如果出现故障立即降级即可。

以前软件行业那种开发与运维职能分开的模式，典型的矛盾就是开发想快速迭代，运维为了稳定性不想做出任何改变。现在流程的 devops/SRE 文化其实并没有从根本的解决这个矛盾。我觉得答案可能就是 Facebook 那句话“Move fast and breaking things.” 错误终究会发生，不要试图完全预防错误，应该尝试提供快速补救、简单可靠的方案（简单很重要，只有简单的东西才是值得依靠的）。并且还有要 blame free 的文化——建立学习和责任的平衡，不带有惩罚性、责备性的报告。不要再使用不专业的（恐吓性质）的故障责任机制。

相关阅读：

  1. 谈谈 Ops（最终篇）：工具和实践