【www.hj8828.com】Servicehot告诉你运维常说的 5个9、4个9、3个9啥意思?

从携程到知乎,运维人该如何觉醒?

最近互联网也是非常有意思,接二连三的发生故障,让我们一起先回顾一下。

2015年5月11号晚上21点左右开始,网易的网易新闻、云音乐、易信、有道云笔记等移动应用均无法正常刷新,网易名下的游戏也全线瘫痪。故障原因:骨干网络遭受攻击。

2015年5月27日下午,部分用户反映其支付宝出现网络故障,账号无法登录或支付。故障原因:光纤挖断。影响时长:4个小时

2015年5月28日上午11:09,携程官网及APP出现故障无法打开,到28日23:29全面恢复,整个过程耗费12个多小时。故障原因:误操作。影响时长:12个小时左右

2015年6月5日
今日头条网首页和APP都无法访问,直接提示500错误。故障原因:不明
影响时长:30分钟左右。

2015年6月15日12点30分
知乎网无法打开,直接提示服务器提出了一个问题】错误,在13点45分左右的时候,知乎页面恢复正常。故障原因:机房故障
影响时长:60分钟左右

 www.hj8828.com 1

到底是怎么了,是什么让我们的互联网业务如此脆弱?真的是运营商老是在后面干坏事?还是我们的系统架构不给力?还是我们运维能力真的很弱?如果广义的去看这个,我还会把它归结成运维问题。不过对于以上的故障,从运维的角度来说,我依然会说官方结论不够专业,希望内部不是这样的哈。

1、网易说骨干网收到网络攻击影响业务,貌似那天好像也就网易业务受到影响?

2、光纤挖断影响四个小时,从这么核心的业务来说,第一原则一定是恢复业务,我想支付宝即使没做双活,肯定也会有一个可用的备份中心,为什么没切过去了?一定是内部出了乱子。不过阿里流弊的地方,负面的事情他可以变成正面,他们把”5.27″变成了技术保障日,大肆宣传。

3、携程事件,我之前写过一篇文章携程事件:运维债务的深度分析和解决方案】,不详谈了。

www.hj8828.com,4、今日头条,500内部错误,这条新闻可以让自己上头条,但也没有正式的给出解释。从500错误的恢复时间来说,有点长,500错误是十分好定位,我的怀疑是数据库的压力不够,导致后面的扩容变更,也只有数据库分库分表扩容时间需要这么长了。另外头条君的首页上直接给个500的错误,技术表述,十分的不友好,建议你服务降级啊,推个大众版的新闻,不做个性化推荐,这个可以做一个缓存就可以解决的。

5、知乎故障,直接说是机房故障,太简单了,但我觉得最大的可能应该是Tengine后端服务超时导致的,而非简单的一个机房故障引起。

在每一次故障发生的时候,其实都是伤害了我们的用户,内部的表述就是可用性或者质量。因此我们必须要足够的重视,更需要我们把它变成宝贵的经验。那到底什么是可用性和可靠性?影响可用性的因素有哪些?运维如何提高可用性?等等。

一、什么是可用性和可靠性

可靠性是在给定的时间间隔和给定条件下,系统能正确执行其功能的概率。可用性是指系统在执行任务的任意时刻能正常工作的概率。先来看一些指标定义:

  1. MTBF——全称是Mean Time Between
    Failure,即平均无故障工作时间。就是从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高正确工作能力越强

  2. MTTR——全称是Mean Time To
    Repair,即平均修复时间。是指可修复产品的平均修复时间,就是从出现故障到修复中间的这段时间。MTTR越短表示易恢复性越好。

  3. MTTF——全称是Mean Time To
    Failure,即平均失效时间。系统平均能够正常运行多长时间,才发生一次故障。系统的可靠性越高,平均无故障时间越长。

可用性Availability = MTBF / (MTBF +
MTTR),一般我们都是用N个9来表达系统可用性,用宕机时长来说更好理解,如果以全年为周期(24*365=8760个小时),3个9(99.9%)就意味着全年宕机时长是525.6分钟,4个9(99.99%)是52.6分钟,5个9(99.999%)是5分钟。

从这些时间指标上可以反向去推导IT能力不足的地方,比如说一个故障恢复时间很长,一定是自动恢复、运维意识、处理过程、系统架构等地方不对,导致了这个宕机时间过长;平均失效时间短,一定是系统的可靠性出了问题,找技术设计的问题,找依赖的硬件环境问题等等

二、影响可用性的因素

影响可用性的因素非常的多,但是可以从几个维度去看,人与组织、流程、技术和业务管理等四个维度。

1、人与组织

其实这个地方可以谈谈你的人和组织类型了,领导是否重视IT?是否重视运维?组织是否已经认识IT带来的价值,把IT当作自己的一个核心能力来看待?是否把面向用户的业务能力和IT能力很好的对接?是否建立起用户质量的组织文化?等等。

2、流程

流程是梳理多个角色自己的关系和职责。我们第一个要去看这个流程在面对故障的是否起到了积极的作用,比如说能够确保故障信息的准确送达,同时保证处理人的角色和职责是清晰的。其次不断去检查流程是否可以自动化驱动,而非人为驱动。人是不可靠之源!我们最终希望形成是一个自动化、标准化的流程,这样的流程不容易被异化,且能保证预期执行结果一致。

3、技术

很多时候大家看到的技术是运维技术,其实恰恰相反对于互联网业务来说,对其高可用的影响,必然是业务IT技术架构,因此在其中需要遵循很多原则,有一些原则需要有普适的参考价值。比如说服务降级、灰度发布、过载保护、服务公共化等等。这些方法论是否已经融入到研发和运维的架构设计哲学之中?现实是产品功能需求优先,而非可运维性优先,可运维性最终就是业务的质量。

4、业务管理

把你的IT能力最终都业务能力看板化,你可以转换成我们多个业务指标,比如说质量、可用性、用户体验、用户满意度、成本等等,有了这些业务导向性指标,才能把IT能力和业务更好的对接起来。否则很容易在组织内,形成“IT是支撑部门”认识,而非创造价值部门。这一点还有一个重要性,就是让IT部门也要足够的认识到,他们的能力直接和业务相关,需要增强业务敏感度。

三、如何提高系统的可用性

刚刚上面讲到了影响可用性的因素,分成了四个方面,但我想提高系统的可用性从另外一个角度来描述,能把握一些核心准则(其实还有更多)。

1、故障发生前,建立运维质量仪表盘

我们一定要建立运维数据看板,这个看板的数据并且要在业务、研发、测试和运维达成一致,让大家足够重视这份数据,这样数据便有了推动力。建议这个地方的核心数据指标不要太多,因为涉及到多个团队,大家不能够一致理解,特别是传达到管理层,太多的指标,容易失去关注的焦点。

通行的做法,就是用可用性来做运维的数据看板。可用性的计算方法有简单的方法,也有复杂的方法。简单的方法就是在监控系统中搞一些探针来模拟用户监控,最后我们能得出故障的时长和可用性的时间,这样我们可以建立每天、每周、每月、每Q的可用性,可以做到分业务、分服务(更细粒度)等等;复杂的方法在模拟数据的基础上,可以把事件系统记录的时间数据拿过来作为评估的标准。另外可以把可用性上升到质量层面,这个里面涉及到的评估维度(成本、用户体验、满意度)就更多了,数据获取的来源也变得更多,有些是来自于客服系统,有些是来自于舆情监控,有些是来自于运维容量系统,有些是来自于事件系统等等,不过最终呈现的指标就是一个—质量。

运维的数据看板,最好能变成产研侧KPI的一部分,同时在运维和研发侧,需要周期性的把这份数据推送到他们面前。有了KPI,同时有了持续滚动机制,一定能建立起很好的业务质量意识。

一直觉得,数据文化,是运维能够建立影响力的重要一步,否则你就是一个支撑的支撑部门!

2、故障发生前,设定技术准则和要求

运维需要和研发建立整体的技术标准和规范要求,这块是腾讯做得非常好的地方,把海量服务提炼成多个关键词海量服务运营之道】,网上可以搜索到。当然这些关键词对于很多企业来说,想理解准确,也会非常的困难。因此从运维的角度来说,我们需要设定一个路线图,最终服务于这个技术目标。比如说之前我提到的运维三部曲】里面讲到了先做标准化(修炼运维内功),然后做公共服务化(修炼架构内功)、最终服务无状态化(修炼业务内功)。

运维一定要把标准化作为核心要务来推进,建立标准化的运维环境,建立标准化的技术栈(和研发确定),建立标准化的高可用方法论,最终这个业务的可用性一定是有保证的。

3、故障发生时,恢复是第一要务

故障发生的时候,“恢复、恢复、恢复”必须是运维人脑子里面要时刻记住的。

在故障的当下,定位故障原因是大忌,这往往让故障时长变得不可控,因为会直接影响MTTR(平均修复时间),影响用户的业务使用。不过有人会有疑问,不知道故障原因怎么知道如何解决?从经验来看,你一定有一些简单粗暴的原则去隔离故障,比如说服务器重启,链路禁用,DNS切换等等。

4、故障发生后,仔细的复盘

每一次故障发生后,运维人需要牵头去复盘故障,刚刚说了我们恢复是第一要务,所以故障的根本原因我们可能还不知道,此时就需要运维、测试和研发一起仔细的去看整个的故障过程,看看到底哪儿有什么问题?基本上也是从刚才说的四个方面来评估。不断的审视我们运维的能力和IT的能力,说“故障是运维最好的老师”的原因也在于此,它能够不断驱使我们走向更高的成熟度。

运维是复盘的首要负责人,复盘是为了找到根因(Root
Cause),根因和故障现象不同,举个例子,故障现象是交换机故障,根因是因为技术架构没有对交换机故障做到容错,根因是运维对这种故障缺乏有效的临时应对机制。

复盘是为了让我们走向更好的运维阶段!

5、故障发生后,复盘措施有讲究

故障复盘后,我们一定会写改进措施,对于这些改进措施,还是有些讲究的,看过一些故障报告,非常的不合要求。我个人的经验如下:

故障的措施必须是可落实,且具体的,要落实到具体的负责人,具体的时间

故障的措施优先是必须技术的,然后是流程,最后是人的

故障的措施可以分为长期措施和临时措施

故障的措施一定要仅仅扣住故障的根因,避免流于形式和表面

故障的措施切忌“亡羊补牢”式的,需要全面细致的分析

故障的措施一定要保证后续的持续跟进

一叶可以障目,但也可以一叶知秋,就看我们是否真的去认真对待。你们真的重视故障了么?你们真的重视运维了么?故障不能带来运维人的春天,从根本上去意识到运维的重要性,那才是运维人真正的春天。


www.hj8828.com 2


最近互联网也是非常有意思,接二连三的发生故障,让我们一起先回顾一下。
2015年5月11号晚上21点左…

1个9:(1-90%)*365=36.5天

第二个问题是故障事件的数量(多个MTTR求和)和MTBF的组合。旧版本的Uptime
Institute白皮书(现已作废)试图将可用率与四个Tier等级相关联,但没有定义测量时间。这导致了一个奇怪的情况,即Tier级别低的数据中心设施每年可以允许53分钟的离线时间,但级别最高的的Tier
IV级数据中心只能提供5.3分钟。这很奇怪,然而如果每年发生一次的故障,这个对于TierI-Tier
IV的任何级别的数据中心来说都是灾难。

一个系统的可靠性并不完全取决于硬件,而由软件和硬件共同来决定,如果是软件问题,最好的解决办法就是打补丁、升级,再好的硬件也没有办法解决软件的问题。要提高系统的可靠性,软件是没有太好办法的,只有依靠厂商服务来解决问题。用户可以选择的只有硬件,其中,包括网络、服务器以及存储设备。其中,网络可以借助多运营商接入来解决,存储有RAID、快照等应对技术,通过备份来提高数据安全性。但对于服务器来说,更多用户的选择是采用双机集群的方法。

【编辑推荐】

Repair,即平均修复时间。是指可修复产品的平均修复时间,就是从出现故障到修复中间的这段时间。MTTR越短表示易恢复性越好。

不管怎样,人们不要总是关注这个问题,而要考虑组合问题。这尤其影响到许多非常短暂的失败。最简单的说明方法,就是以人们的心脏跳动为例,某人的心脏是99.9%”可用”,这听起来还不错,一年有3153600秒,0.01%代表着一年中可能30000次心跳停止跳动,如果某次时间较长,就会带来生命危险,而如果它们在一年中平均分布,那么可能只是感觉不舒服。在数据中心的术语中,查看电源输入提供给负载的电压。许多现代的服务器无法承受10ms的电力中断,而在6毫秒时,电力系统的可用性为99.9999999%,因此每年可能会产生三个10ms的故障。

6个9:(1-99.9999%)*365*24*60*60=31秒

弹性对于数据中心基础管理和防止出现停机中断都是至关重要的。即使是最好的设计和运营也可能会发生失败。因此数据中心技术人员通过设计和测试来满足运营商操作人员的需求,减少对停机中断的恐惧,同时还可以提高工作人员管理维护数据中心,并提升对可用性的信心。

采用双机集群的方案是达不到5个9的要求的。原因很简单,双机集群是通过集群软件来构建方案的,当其中的一台服务器产生故障的时候,切换到备份主机继续工作,保持业务连续性。设备之间也可以依靠心跳线连接对故障进行判定。对于集群而言,故障切换是有严格要求的,要求主机、备用机的环境是一致的。在应用实践中,要求管理要到位,例如同步升级、升级,打补丁。如果管理不到位,很有可能会导致切换失败。这也是为什么,系统可以在演示环境下成功切换,但现实中往往做不到的原因。

当然,弹性数据中心的最终”失败”可能是最容易实现的:并不是通过黑客互联网入侵UPS,而是人为因素或故障关闭电源,提高服务器入口温度,使其宕机。

2个9:(1-99%)*365=3.65天

当然,数据中心的用户希望数据中心具有更高的可靠性和可用性,并且物有所值。那么,如何了解数据中心的可用性呢?以下两个有些相互关联的”指标”:

它是衡量一个系统的可维护性和可预测的平均所需的时间让系统工作的情况下再次出现系统故障。

  • “Uptime
    Institute(I-IV)”或”TIA-942″(I-IV)的”类型”,BICSI的”评级”和EN50600的”可用性类”
  • 可用性百分率,例如99.999%(所谓的”五个九”)

【4、修复率】修复率(μ) repair rate

除了指出,只有Uptime
Institute可以给出一个等级,TIA-942和BICSI是最适用于北美的ANSI标准,EN50600还没有被使用,人们可以将这些标准都概述成描述能力的四个级别”可维护性”和”容错”.这些原则是明确的,兼容的可维护性回答了一个问题,即建立一个非常可靠(可能是有弹性的)数据中心,这个数据中心必须每年关闭一次以便维护?虽然容错系统可能会有任何组件,路径或空间”失败”,但却不会影响ICT服务。

Failure”。是衡量一个产品(尤其是电器产品)的可靠性指标。单位为“小时”。具体来说,是指相邻两次故障之间的平均工作时间,也称为平均故障间隔。概括地说,产品故障少的就是可靠性高,产品的故障总数与寿命单位总数之比叫“故障率”(Failure

然而滥用最多的是可用性百分率,因为这很容易计算,但可以愚弄非专业的买方和用户,使其造成误解。其实要明确地表示可用性,只需要两个数字就可以,MTBF(平均故障间隔时间,小时)和MTTR(平均修复时间,小时),只需将MTBF除以总时间(
MTBF + MTTR)来表示可用性,再乘以100%,就是真正的可用性。

rate)。它仅适用于可维修产品。同时也规定产品在总的使用阶段累计工作时间与故障次数的比值为MTBF。磁盘阵列产品一般MTBF不能低于50000小时。

因此,拥有很长的MTBF和很短的MTTR可能会得可用性非常高的结果。不幸的是,MTBF和MTTR却是营销部门可以猜测的数字,如果他们使用这些数字来解释。例如,企业可以通过假设客户端具有丰富经验的工作人员和备件,并可在20分钟内修复UPS,UPS的可用性可以引用99.999%。然而真正的情况是,致电服务工程师上门维修,等待备件,重新投入使用之前进行测试(通常为一天或更长时间)。而假设MTBF为100,000小时(12年以下),而MTTR为20分钟到12小时,这可以产生任何人们想要的结果。

MTTR可以从几个毫秒,如不间断电源(UPS)的许多数小时甚至数天的情况下的应用软件或复杂的机制。

数字误导用户