作者｜阿文
责编｜伍杏玲
出品｜CSDN（ID：CSDNnews）
北京时间 6月3⽇凌晨2点58分开始，有大量用户访问⾕歌服务出现各种错误提醒，并且阻止⽤户访问电子邮件、上传YouTube视频等。
针对此次故障，Google 官⽅解释是：服务器配置变更导致。Google 称，配置变更原是应用于单一区域的少数服务器，但却错误应⽤于多个毗邻区域的⼤量服务器，导致这些区域停⽌使⽤一半以上的可用⽹络容量，进出这些区域的⽹络流量试图适应剩余的⽹络容量，但未能成功。造成网络开始拥堵，网络系统对过载流量进行分类，丢弃了⼤部分对延迟不那么敏感的流量，以保护少数对延迟敏感的流量。Google 称工程师立刻探测到问题，但诊断和修复花了很长时间。
宕机是运维人员的痛
其实服务宕机一直是运维人员的"痛"，⽽运维人员因为有宕机的存在，素有"救⽕"和"背锅侠"的头衔，宕机的原因多种多样，简单来说包括:
硬件故障导致的宕机配置问题导致的宕机
⽹络异常导致的宕机断电导致的宕机
系统或服务自身Bug引发的宕机
突发流量，例如双⼗⼀电商大促或遭遇流量攻击
可以说宕机问题在互联网行业⼤小的公司中是时有发生。
前几天，林志玲宣布婚讯引发微博短时间宕机，这已经不是新浪微博第一次因为明星结婚事件导致宕机了。
今年3⽉3日凌晨，阿⾥云出现宕机，华北2地域可用区C部分ECS服务器等实例出现IO HANG。
1⽉24日，微信系统瘫痪，从其他App分享内容到个人微信和微信群，均无法正常分享，⻚⾯显示红色感叹号。
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小时安排人员轮流值守，一旦发现问题可以迅速响应。
其实，并不是按照上面这样做就⾼枕⽆忧了，在实际的生产环境中会遇到各种各样的风险和各种各样的问题，我们需要做的就是发现问题和解决问题。在每⼀次故障后梳理故障发生的原因以及改进措施，避免下一次发⽣同样的错误。
作者简介：阿文，网易云高级工程师，在边缘计算、云计算领域有多年的从业经历，曾担任过讲师，主讲思科路由交换技术。个人博客地址：https://awen.me
【End】
6月29-30日，2019以太坊技术及应用大会特邀以太坊创始人V神与以太坊基金会核心成员，以及海内外知名专家齐聚北京，聚焦前沿技术，把握时代机遇，深耕行业应用，共话以太坊2.0新生态。扫码或点击阅读原文，即享优惠购票！
热 文 推 荐
☞Google Cloud大规模宕机；中国正式进入 5G 商用元年！苹果发布SwiftUI ｜开发者周刊
☞9 年前他用 1 万个比特币买两个披萨, 9 年后他把当年的代码卖给苹果, 成 GPU 挖矿之父
☞他是哈佛计算机博士，却成落魄画家，后逆袭为硅谷创业之父 ｜人物志
☞惊！为拯救美国落伍的 STEM 教育，纷纷出手教老师编程？！
☞Python 爬取 42 年高考数据，告诉你高考为什么这么难？
☞11亿资金助力, 微软、三星、摩根大通多数巨头加持, 枝繁叶茂的它凭什么被低估?
谷歌开源张量网络库TensorNetwork，GPU处理提升100倍！
点击阅读原文，精彩继续。