2016 年 3 月最火爆的新闻,莫过于谷歌的 alphago 机器 4:1 大胜李世乭了。一时间各界议论纷纷,我的前同事,运维界非著名段子手 @orroz 在自己微博上写了两段话:

『跟其他运维工程师觉得这个职业将消失不同。我是对运维职业是持极端乐观态度的,也许运维职业将是人类最后一个职业。很可能祂们在能自理之前还需要我们伺候。。。也说不定,某几个运维工程师因为某种不知道的原因还会被祂们当宠物留下来,成为人类的最后的延续。』

『我终于明白这个图片的寓意了,它其实预示了人类的未来命运。』

看完一笑~

但是笑完以后,回头想想,运维和围棋手,其实还真是有相像的地方:传统说法中,与研发相比,运维总被认为是『更靠经验的』;一如我们说『人类棋手的经验和大局观』。

我们知道,运维的『操作』,已经是可替代的了,IaaS、PaaS、运维自动化,诸多概念的落地,环境部署、软件安装不再是运维的主要工作职责。运维的职位名称,从系统管理员到运维工程师到产品工程师到站点可靠性工程师,一步步远离了基础设备层面。

那,有没有可能,运维的『经验』,也是可以被机器替代掉的呢?

运维经验

我们先看看运维的经验到底是什么?

  • 一个 4 核 CPU 的服务器,loadavg 跑到 10+,我们就会说:负载过高了。应对办法最简单的就是『加机器』。
  • 一个 web 服务,每秒请求超过 1000,响应变慢了,我们就会说:还在用 apache 啊,快换 nginx 吧。
  • 要是动态服务呢,就会说:做个动静分离呗,加个缓存层呗。

这就是运维届的『定式』和『俗手』。

但是不巧,定式并不能一路保送我们最后顺利完工。

就好像这五场世纪大战一开始,人类棋手总觉得 alphago 水平不行——『职业初段的人都应该知道下这里才对啊』。但是一百多手不知不觉过去,局面就是不利了!

经验的坑

比方前面说的第一条经验,这几乎已经是运维共识了。但是把环境考虑进来:这如果是一台虚拟机呢?这如果挂载的是一个远端存储呢?这如果运行的是一个无法水平扩展的事务系统呢?

是的,『加机器』只能死的更惨。(此处应配有那两把著名的刘强东之刀)

所以,经验是否真的能成立,有赖于更复杂和深层次的分析。就像围棋依赖于算力一样。

大数据那么美好么

文章写到这里,似乎我要开始鼓吹运维届要如何如何上马大数据乃至机器学习了?

这种玩法看起来确实高大上,但实际上,并没有那么美好!我们不要忘了:运维始终是一个 IT 支出向的工作。DevOps 运动中说运维加快部署就是赚钱,那也是间接的。花钱是直接的。还是引用另一个微博上有关 alphago 的段子:

alphago 跑了 1000 个 CPU,李世乭吃了一餐饭,比一下资源消耗就知道谁赢了。

运维工程师拥有前所未有的多的机器数据,理论上当然可以通过大数据挖掘,通过机器学习获得相当多的收获。但是这些收获跟能间接带来的收益相比,性价比如何呢?

拿监控数据来说,我们知道监控产生的,大多是时序数值。对于时序数值的分析,金融界早有数十年的算法研究和积累。运维工程师照搬过来,未尝不可。但这其中一些算法消耗的 CPU 运算,没准比本身业务系统运行消耗的还高,那这个花费显然就不可能投入。

《人工智能的未来》作者,神经学家 Jeff Hawkins 成立的 numenta 公司曾经对市面上各种号称处理时序数据异常探测或者预测分析的开源实现做了对比性测试。结果,真正能满足『时序、动态』前提的都不多,有些算法长达一个小时都完成不了测试。更好玩的是:有的测试场景中,随机选异常点都有 25.9% 的准确率。

测试见:https://github.com/numenta/NAB。(当然我这里不是来推销说 HTM 算法是人工智能未来,毕竟 alphago 是 DNN 呢)

废话这么多,到底怎么办

又要深入分析,又要控制能耗。最好的办法,就是把不确定性降低,在一个较完善的运维体系框架基础上做数据分析,可以大大缩小数据集,降低复杂度。

运维体系怎么才算完善,已经有很多文章在讲了。以数据分析为目的的话,个人推荐王津银的数据驱动运维系列文章。

分析本身如何入手,其实简单算法也未必不好。百度云在 SREcon15 上的分享,同样推荐观看。在线数据通过简单的 3-sigma、ks-test、holt-winters、LOESS 来生成异常点,然后仅对异常点采用 Viterbi 计算同比的异常区域发出实际告警,配合通用的 tracing 调用链系统使用。

最后回到文章开头的段子:机器为啥留下几个运维工程师?或许因为这几个运维当初给机器安排的都是算 3-sigma 这样轻松的活,一报还一报吧:)