在运维工作中,很多人都在宣扬自动化,经过几年的工作,我发现这种自动化在某些地方有些极端了。devops 崇尚自动化,但并不是一味的自动化。有一些事情是适合手工操作的,过度的自动化会浪费跟多的成本,只能得到很少的收益。
就好像一台电梯,用古老的电梯算法运行了很久,但是有一天有人觉得这个电梯运载能力没有发挥到极致,我们可以使用机器学习训练他采用更好的算法。于是就需要更多的人力资源来实现这个项目:一个小组提供训练数据,一个小组来训练新的算法模型,设计一套硬件设施监控和对比运载效率,设计回归的方案评估运载效率的变化,等等……
最终可能发现将原来两台电梯的运载能力变成了相当于2.5台的运载能力,但是这优化出来的0.5台电梯带来的问题有:1)某些情况下的表现可能还不如电梯算法 2)没有人知道现在电梯是怎么运行的了,因为这是机器学习训练出来的模型 3)复杂的算法从上线走向成熟需要持续的维护和优化,稳定性不如原来的电梯算法。等等。其结果还不如就再增加一台电梯。(当然,也可能因为当初楼里的设计结构不允许再增加电梯,软件工作中也有类似的问题。)
最近又看到一个例子:
牙膏厂生产流程会产出没放牙膏的空箱。
版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作! 厂长花8百万请专业顾问,用牛逼的秤测箱子重量,发现空箱就警报并停止流水线,员工手动除空箱。后来秤再也检测不到空箱了,为何?员工自动化了除空箱的步骤:用20元的风扇吹。
我同意《Google SRE 运维解密》中提到的一个观点:应该尽量避免黑魔法系统。但是“魔法”在大公司中好像非常受追捧。因为将原来人工操作的东西,变成自动化的东西,这对于赢得年终奖、晋升来说,太有说服力了。用20元的风扇吹,这么简单的方案,如何能体现出来你的工作价值,展现你的能力呢?
在很多时候,这种“过度的”自动化,只会产生一些只针对特定场景、特定的 Case 才能发挥出一点作用。我觉得这就是一种 Overfitting。比如很多公司都在做的故障自动定位系统,
之前看到一个从蚂蚁金服的 SRE 离职的员工在博客里失望的说:系统应该是自治的,而不是自动化
就像是智能手机出现之前,大部分的黑白屏手机都有一个功能叫做情景模式:选择一个情景模式,就会附带给你设置好铃声、震动、短信提示等。但是我从没见过周围有人使用这个功能。iPhone 出来之后,将提示音的设置做成了一个物理按键,你不再需要记住那么多情景模式下都是什么设置,只有一个按钮,关上之后不会发出声音,就这么简单。我们搞的那些黑魔法系统,背后设置了那么多东西,却无法告诉用户我们到底做了什么,这只会让SRE的心理负担越来越重。(另一个想说的点是,我实际上认为,当前公司的可用性有很大一部分
其实编程中也存在这种 overfitting,和 devops 一个道理,大量的if-else嵌套会让你看不出到
想起来 Linus 在谈到代码品味时说的:
对我来说,我愿意与之共事的人, 必须有好的品位,这就是如何…… 我举的这个例子很傻, 没什么意义,因为实在太短。 好的品位体现在更长的代码里。 好的品位体现在能看清全局 甚至有一种直觉, 知道怎么把事情做漂亮。
简单即是美,Unix 提倡每一个工具都做一件事情,这样用户可以将它们自由地组合在一起,完成复杂的任务。但是现在好像大家导出都喜欢做“平台”,喜欢将能想到的所有的东西都涵盖进来,所谓“远大的视角”。我认为作为 SRE,了解所要维护的系统的原理,它是怎么运行的,做好监控,远比去做一些魔法系统收益要大。
一个 SRE 团队中,这种有“品味”的人至关重要。太多的 Overfitting 会将整个团队带向一个无限复杂度的深渊,在这样一条路上无论如何挣扎、怎样加班,最后都会冲下去。
ML for Systems 我感觉在现在业界的情况来看就是伪命题,坑贼深.
–By 某推友