运维笔记

Devops 中的 Overfitting

Einic Yeo · 11月29日 · 2020年 ·

在运维工作中,很多人都在宣扬自动化,经过几年的工作,我发现这种自动化在某些地方有些极端了。devops 崇版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!尚自动化,但并不是一味的自动化。有一些事情是适合手工操作的,过度的自动化会浪费跟多的成本,只能得到很少的收益。

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

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

最近又看到一个例子:

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

source

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

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

之前看到一个从蚂蚁版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!金服的 SRE 离职的员工在博客里失望的说:系统应该是自治的,而不是自动化的。因为是在 CSDN 上看见的,现在找不到原文了。我非常同意他的话。对于自治,我是这么理解的:分布式系统本身应该有一定的错误恢复能力,类似于 Redis Cluster 的 Fail Over. 而不是依靠外部的一些系统去自动化(依赖 if-else 逻辑)判断监控数据或者状态,进行自愈之类的操作。

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

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

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

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

简单即是美,Unix 提倡每一个工具都做一件事情,这样用版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!户可以将它们自由地组合在一起,完成复杂的任务。但是现在好像大家导出都喜欢做“平台”,喜欢将能想到的所有的东西都涵盖进来,所谓“远大的视角”。我认为作为 SRE,了解所要维护的系统的原理,它是怎么运行的,做好监控,远比去做一些魔法系统收益要大。

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

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

–By 版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!某推友

0 条回应