Devops 中的 Overfitting

在运维工作中，很多人都在宣扬自动化，经过几年的工作，我发现这种自动化在某些地方有些极端了。devops 崇尚自动化，但并不是一味的自动化。有一些事情是适合手工操作的，过度的自动化会浪费跟多的成本，只能得到很少的收益。

就好像一台电梯，用古老的电梯算法运行了很久，但是有一天有人觉得这个电梯运载能力没有发挥到极致，我们可以使用机器学习训练他采用更好的算法。于是就需要更多的人力资源来实现这个项目：一个小组提供训练数据，一个小组来训练新的算法模型，设计一套硬件设施监控和对比运载效率，设计回归的方案评估运载效率的变化，等等……

最终可能发现将原来两台电梯的运载能力变成了相当于2.5台的运载能力，但是这优化出来的0.5台电梯带来的问题有：1）某些情况下的表现可能还不如电梯算法 2）没有人知道现在电梯是怎么运行的了，因为这是机器学习训练出来的模型 3）复杂的算法从上线走向成熟需要持续的维护和优化，稳定性不如原来的电梯算法。等等。其结果还不如就再增加一台电梯。（当然，也可能因为当初楼里的设计结构不允许再增加电梯，软件工作中也有类似的问题。）

最近又看到一个例子：

牙膏厂生产流程会产出没放牙膏的空箱。厂长花8百万请专业顾问，用牛逼的秤测箱子重量，发现空箱就警报并停止流水线，员工手动除空箱。后来秤再也检测不到空箱了，为何？员工自动化了除空箱的步骤：用20元的风扇吹。

source

（这个例子被指出只是一个段子，详见这里。2022年3月更新）

我同意《Google SRE 运维解密》中提到的一个观点：应该尽量避免黑魔法系统。但是“魔法”在大公司中好像非常受追捧。因为将原来人工操作的东西，变成自动化的东西，这对于赢得年终奖、晋升来说，太有说服力了。用20元的风扇吹，这么简单的方案，如何能体现出来你的工作价值，展现你的能力呢？

在很多时候，这种“过度的”自动化，只会产生一些只针对特定场景、特定的 Case 才能发挥出一点作用。我觉得这就是一种 Overfitting。比如很多公司都在做的故障自动定位系统，有一种做法是，当一个故障发生之后，SRE 去写一堆 if-else，实现如下的效果：只有仅当系统 A 出现 X 错误，并且系统 B 执行了 Y 操作的时候，这个故障定位系统能够将问题的根因准确无误的报告出来。但是一模一样的错误，在一个复杂的分布式系统中重新出现一次的概率，又有多少呢？这么做的意义，最多只不过是给领导一个交代罢了：看，虽然这次故障造成了损失，但是如果相同的故障再发生，我们花几分钟就可以恢复了。

之前看到一个从蚂蚁金服的 SRE 离职的员工在博客里失望的说：系统应该是自治的，而不是自动化的。因为是在 CSDN 上看见的，现在找不到原文了。我非常同意他的话。对于自治，我是这么理解的：分布式系统本身应该有一定的错误恢复能力，类似于 Redis Cluster 的 Fail Over. 而不是依靠外部的一些系统去自动化（依赖 if-else 逻辑）判断监控数据或者状态，进行自愈之类的操作。

就像是智能手机出现之前，大部分的黑白屏手机都有一个功能叫做情景模式：选择一个情景模式，就会附带给你设置好铃声、震动、短信提示等。但是我从没见过周围有人使用这个功能。iPhone 出来之后，将提示音的设置做成了一个物理按键，你不再需要记住那么多情景模式下都是什么设置，只有一个按钮，关上之后不会发出声音，就这么简单。我们搞的那些黑魔法系统，背后设置了那么多东西，却无法告诉用户我们到底做了什么，这只会让SRE的心理负担越来越重。（另一个想说的点是，我实际上认为，当前公司的可用性有很大一部分是建立在对员工的心理负担上面的。如果造成P1故障，全年3.25取消年终奖。就算更改一行代码，要经过至少40min，还有层层审批，才能发布。等等）

其实编程中也存在这种 overfitting，和 devops 一个道理，大量的if-else嵌套会让你看不出到底是哪一些逻辑在执行。这会造成代码异常复杂并且难以维护。

想起来 Linus 在谈到代码品味时说的：

对我来说，我愿意与之共事的人， 必须有好的品位，这就是如何…… 我举的这个例子很傻， 没什么意义，因为实在太短。 好的品位体现在更长的代码里。 好的品位体现在能看清全局 甚至有一种直觉， 知道怎么把事情做漂亮。

简单即是美，Unix 提倡每一个工具都做一件事情，这样用户可以将它们自由地组合在一起，完成复杂的任务。但是现在好像大家导出都喜欢做“平台”，喜欢将能想到的所有的东西都涵盖进来，所谓“远大的视角”。我认为作为 SRE，了解所要维护的系统的原理，它是怎么运行的，做好监控，远比去做一些魔法系统收益要大。

一个 SRE 团队中，这种有“品味”的人至关重要。太多的 Overfitting 会将整个团队带向一个无限复杂度的深渊，在这样一条路上无论如何挣扎、怎样加班，最后都会冲下去。

ML for Systems 我感觉在现在业界的情况来看就是伪命题，坑贼深.

–By 某推友