03月10, 2017

读SRE Google运维解密有感(二)

前言

这是读“SRE Google运维解密”有感第二篇,第一篇参见

这本书最近又读了几章,结合自己的经历,有些地方真的能感同身受,有些地方也惊叹SRE充满辩证的思想,总之SRE是好一本好书,会给你很大的启发。

充满辩证的思想

本书主要是讲通过SRE思想进行运维体系的构建,除了技术层面以外,我更关注SRE内在充满辩证的思想。

一个辩证的思想是凡事都有两面性,这个道理很简单,大家一听就说“对啊,这不是废话么”,可是面对具体问题的时候,有时候往往做不到这一点。

服务太稳定不好

“什么?我有没有听错”,一直以来运维人员所追求的不就是稳定的服务么?可是谷歌认为“在内部程序质量没有达到一定标准,服务太稳定会产生盲目的依赖”

它举了一个例子,谷歌的chubby锁服务,它是一个基础服务,做为基础组件很多上层服务依赖于它,但是工程师们认为它还是有缺陷,有问题隐患,而在一段时间内它的表现还异常稳定,这样就给调用方一种错觉,这个服务很好,越来越多的服务依赖于它。
于是,谷歌干了一件“不可思议”的事情,对chubby计划内停止服务,捅破这种稳定的假象,让调用方感受到“原来没有那么稳定”,这样减少了对chubby的过度依赖。
这就是一种辩证的思想,我们一直以来都想追求绝对的稳定,没有辩证的看稳定的系统有好处,也会有坏处,它会被外界过度依赖,大家用的很开心,可是这个系统如果还有隐患,造成了稳定的假象,一旦出了问题,可能就是大地震。

琐事也有好处

工作中的琐事是指那么“无聊”,“无效率”,“流程化”的事情,很多人都很抵触,认为它把你的时间碎片化了,使工作没有效率。 SRE有很大篇幅讨论了琐事(toil)的问题,它认为琐事也有好处,比如可以适当的减压,因为做起来不用过多的思考,可以做为创造性工作的一种调剂,从中也能发现需要优化的问题。

当然SRE还是在尽量减少琐事,它的坏处还是多于好处。

少即是多

谷歌追求一种简单,有效的解决方案,比如监控项不是越多越好,它列出监控的4个黄金指标

  • 延迟
  • 流量
  • 错误
  • 饱和度

通过这四个指标,基本可涵盖大部分问题,设置监控项的时候,我们往往生怕漏掉某个项目,设置非常详细的监控策略,这些监控项不一定真的有意义,反而会带来大量的干扰报警。

在代码层面也遵循少即是多的原则,无用的代码,大量冗余的注释都要删除掉,提供简单的api入口,我们常常为了以后的扩展性,预先加入很多冗余功能代码,谷歌反其道而行,鼓励代码的精简。

每一行代码都是负担,所有代码都必须有存在的目的,软件工程少就是多!

自动化的坏处

“什么?我没有听错?自动化会有坏处“,是的,谷歌认为运维自动化是有坏处的。
在运维领域,自动化运维是很多公司的目标,我们认为运维自动化,减少人力,规范操作流程,我们恨不得完全自动化早一天到来,怎么还能有坏处?

自动化的坏处在于,对于一个运维工程师来讲,操作变成黑盒了,他不用明白一个脚本的原理,只要运行就好了,对于他来讲是一件很开心的事,可是带来的副作用是他对于线上的熟悉程度越来越少,他只会执行这个脚本,那么这个脚本一旦出问题,因为缺少对线上环境的了解,无法很快进行修复。

体会到了自动化带来的负面作用,谷歌希望使用自洽的方案解决问题,这样才诞生了Borg系统。

故障演习

谷歌会定期举行故障演习,而且他们是真的在线上演练。
书中的一个例子是随机的关闭一个数据库实例,看看会有什么问题,然后真的出现了一些问题,影响了业务的访问,通过这次演习他们发现了流程的问题,问题及时修复,避免了隐患。
所以谷歌的思想是:

你是希望系统在星期六凌晨2点,公司大部分同事还在参加黑森林中的团建时出现故障,还是希望和最可靠和最聪明的同事一起仔细监控着他们上周详细评审过的测试时出现故障呢?

结语

SRE不仅是一些运维的方法论,它的辩证看问题的思想值得我们学习。
先写这么多,我得去搬砖了。

本文链接:https://www.opsdev.cn/post/sre-read-and-think-2.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。