谷歌解释周日宕机原因,如何保障系统高可用

谷歌解释周日宕机原因

6 月 2 日,谷歌在全球范围内遭遇了大规模中断,包括Gmail、YouTube和Google Drive在内基于谷歌云架构服务的诸多谷歌服务均受到影响。本次宕机于北京时间6月3日凌晨2点58分开始,用户访问谷歌服务出现各种错误提醒,并且阻止用户访问电子邮件、上传YouTube视频等等。受影响的服务包括Gmail, Calendar, Drive, Docs, Sheets, Slides, Hangouts, Meet, Chat和Voice在内的谷歌服务均无法使用以及那些依赖于谷歌云架构的第三方服务同时也受到影响。

针对此次故障,Google 官方博客解释了事故原因:服务器配置变更导致。Google 称,配置变更原意是应用于单一区域的少数服务器,但却错误应用于多个毗邻区域的大量服务器,导致这些区域停止使用一半以上的可用网络容量,进出这些区域的网络流量试图适应剩余的网络容量,但未能成功。造成网络开始拥堵,网络系统对过载流量进行分类,丢弃了大部分对延迟不那么敏感的流量,以保护少数对延迟敏感的流量。Google 称它的工程师团队立刻探测到了问题,但诊断和修复花了更长时间。在此次事故期间,YouTube 流量下降了 10%,Google Cloud Storage 下降了 30%,1% 的 Gmail 活跃用户无法接收和发送邮件。

宕机是运维人员的痛

其实,服务宕机一直是运维人员的”痛”,而运维人员因为有宕机的存在,一直素有”救火”和”背锅侠的”头衔,宕机的原因也多种多样,简单来说包括:

  • 硬件故障导致的宕机
  • 配置问题导致的宕机
  • 网络异常导致的宕机
  • 断电导致的宕机
  • 系统或服务自身 BUG 引发的宕机
  • 突发流量,例如双十一电商大促或遭遇流量攻击

可以说宕机问题在互联网行业大大小小的公司中是时有发生。

2019 年6月6日晚间,林志玲宣布婚讯引发微博短时间宕机 已逐步恢复,这已经不是新浪微博第一次因为明星结婚事件导致宕机了。

2019年3月3日凌晨,阿里云出现宕机,华北2地域可用区C部分ECS服务器等实例出现IO HANG。

2019年1月24日,微信系统瘫痪,从其他app分享内容到个人微信和微信群,都无法正常分享,页面显示红色感叹号。微信Bug话题也迅速被刷上微博热搜榜第一。

2018 年 8 月 5 日,北京清博数控科技有限公司(以下简称“前沿数控”)在官方微博发布了一篇题为《腾讯云给一家创业公司带来的灾难》的博文,文中表明,2018 年 7 月 20 日,腾讯云云硬盘发生故障(腾讯云后期给出的事故原因说明),导致该公司存放的数据全部丢失,并且不能恢复,这是该创业公司近千万元级的平台数据,包括经过长期推广导流积累起来的精准注册用户以及内容数据。

2018年9月12日,12306系统崩溃导致网站系统错误,多人无法购票,出票。给人们的出行带来了很大的困扰。

笔者从事云计算行业多年,为各行各业的客户提供公有云和私有云服务,在我的从业经历中,不论客户多大,都遇到多次宕机事故,我总结了下原因主要包括以下几点:

  • 运维人员技术和职业素养不足
  • 缺乏相关的运维保障流程和制度
  • 缺乏相应的资金和人力投入将服务高可用化、自动化
  • 没有完善监控报警机制
  • 频繁的人工运维,导致出错几率飙升
  • 没有安排 7*24 小时 on call。
  • 服务不可弹性伸缩扩容

我上家公司是一家创业公司,在系统运维方面也是在不断的挖坑和踩坑中度过,在公司创业初期,面临和大多数公司一样的困局,缺资金、缺设备、缺专业的人才,后面公司不断壮大,慢慢的总结出自己的一套运维体系和制度,逐步的去完善使其能够保障服务的高可用和稳定性,我们的运维总监编了一套《运维八荣八耻》,具体如下:

以可配置为荣,以硬编码为耻 。

以系统互备为荣,以系统单点为耻 。

以随时可重启为荣,以不能迁移为耻 。

以整体交付为荣,以部分交付为耻 。

以无状态为荣,以有状态为耻 。

以标准化为荣,以特殊化为耻 。

以自动化工具为荣,以人肉操作为耻 。

以无人值守为荣,以人工介入为耻 。

总结起来就是,要将运维工作向 Devops 的方向发展,把人从繁重的运维工作中解脱出来,尽最大可能保障整个服务的自动化,避免人工运维,因为人在任何时候相比较机器和软件而言不可控的因素太多了。

宕机是无法避免的

在云计算时代,当“上云”已经成为一家互联网企业的标配之后,IDC 在全球范围内针对多个行业下中小型企业(员工数小于 1000 名)的调研显示,近 80% 的公司预计每小时的停机成本至少在 2 万美元以上,而超过 20% 的企业估算其每小时的停机成本至少为 10 万美元。

上面的《运维八荣八耻》其实可以说是理想状态下的运维,是运维人员的一种追求和愿景,但是实际上,完全自动化是不可能实现的,因为企业的发展是要以业绩为核心,而业绩的来源是用户需求,用户就是爸爸,很多时候”爸爸”提出的一个紧急变更,运维人员作为后方支撑是无法做到将其临时发布到线上实现自动化的。

此外,从经济学角度要考虑投入产出比,在针对一些不是关键的业务时,要考虑其投入是否大于产出,对于投入较大产出利润较低的服务并非一定需要高可用。因为采用高可用必然会增加成本。

再者,不存在一套拿来即用的完美架构,在产品和服务的不断迭代过程中,架构会随之而变,因此变更也会不断的出现,在变更过程中就有可能会发生一系列的意外,例如新老架构之间的配置、网络等等问题导致的意外故障,因此宕机问题是是无法避免。

最后,没有一套完美的制度和流程,制度和流程并非制定完成就万事大吉了,就像法律条文可能适用于当下,但是未来可能就不适用了,因此随着产品迭代和公司规模的扩大不停的演化,运维部门人员的增加,不断的发现问题解决问题。制定和流程是会变化的。

如何保障业务的高可用

虽然宕机无法避免,但是一名合格的运维人员来说,尽最大可能保障核心服务高可用是运维人员的本职工作。

保障业务的高可用,并不只是运维部门的事情,很多人可能觉得高可用嘛,现在很多公有云上的服务,例如硬盘、操作系统、各种中间件都实现了高可用化了,但是其实不是这样的,一个服务的高可用是需要其他部门的配合共同保障服务的稳定运行。

首先,在开发过程中要让开发人员也参与到运维中,例如 Netflix 从一开始就强调开发人员进行自助化运维,他们的理念是:谁构建,谁运维。其运维工作全部由开发人员完成,只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。

阿里技术团队在 2016 年左右开始了一次大的组织架构调整,即把日常的运维工作交给研发做。原来的 PE(Production Engineer)要么转岗去做工具平台开发,要么作为运维专家做产品规划和设计,还有一部分无法适应的只能黯然离开。

其次,不要将每一次发布变更直接发布到线上,比有测试环境应当现在测试环境发布后进行相关测试,确认无误后在发布到线上环境,在线上环境也应当避免直接全网发布,而是要先选择灰度发布,减少因为错误而导致的服务不可用,从而造成重大的故障。

再次,架构部门或相应服务的架构人员要在架构设计时考虑到任何可能影响服务不可用的因素例如:

  • 面的突发流量时如何才可以迅速的进行扩容

  • 如何避免单点故障

  • 当系统出性能瓶颈如何快速提高性能

  • 当单节点出现故障如何快速迁移和恢复服务

  • 如何减少人工运维

这一系列问题都应当在一个服务上线时要考虑清楚并制定相应的备用方案和相关问题处理流程的引入。

最后,才是运维部门要做的事情,运维部门主要工作是:

  • 在业务上线前要进行相关的压测,发现性能瓶颈并优化,例如到底是硬件问题导致的瓶颈还是系统层面的问题还是应用本身的问题导致的,不同的问题优化方案是不一样的,有的问题是需要加机器解决,有的问题是需要优化参数,例如服务本身的参数或内核参数解决,有的是需要开发人员进行代码方面的优化解决。

  • 加强运维流程和制度的建设,完善运维体系建设,将运维过程中的各个环节都进入流程考虑每一步操作可能带来的影响。

  • 对于运维人员的安全意识进行培训

  • 对系统权限进行控制,不同的角色赋予不同的权限,避免越权操作,做到责任到人。

  • 加强和完善监控报警体系的建设

  • 7*24 小时安排人员轮流值守,一旦发现问题可以迅速响应

其实,并不是按照上面这样做就高枕无忧了,在实际的生产环境中会遇到各种各样的风险和各种各样的问题,我们需要做的就是在不断的发现问题和解决问题,在每一次故障后梳理故障发生的原因以及改进措施,避免下一次发生同样的错误。

本文仅授权 CSDN 公众号使用,如需转载请联系 CSDN