www.ca88.com启使人陶醉该怎么觉醒,你必要领悟的那几个Abilities

www.ca88.com 4
www.ca88.com

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

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

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.ca88.com 1

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

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

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

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

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.ca88.com 2


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

www.ca88.com 3

来自泼辣有图

如果你去买一部手机,你会考虑什么因素呢?一般我们都会首先考虑智能手机、照相功能、多大容量等。而除了这些,我们通常还会考虑品牌、颜色、外型好不好看、时尚与否。作为一个软件产品也不例外,用户首先会期望系统要满足正常的功能需求,同时系统还要满足好用、性能好、稳定可靠等其他特性。一般我们会把这些称为非功能性需求或者跨功能性需求。系统的每一次故障和宕机对用户都是不可忽视的损失,所以这些非功能性需求也是软件质量非常重要的属性,是软件架构设计需要满足的目标。

在运行时的非功能需求中,我们常常会提到几个词有
Availability、Stability和Reliability,即系统要高可用、高可靠和稳定。那么可用、可靠还有稳定是什么意思呢?如何衡量?它们之间又有什么区别?我经常在不同场景下听到这几个词的混用。今天就先来谈一谈这几个ability。

1. Availability 可用性

Availability defines the proportion of time that the system is
functional and working. It can be measured as a percentage of the
total system downtime over a predefined period. Availability will be
affected by system errors, infrastructure problems, malicious attacks,
and system load. – Microsoft Application Architecture Guide

可用性指系统在给定时间内可以正常工作的概率,通常用SLA指标来表示,如下图所示。

www.ca88.com 4

SLA指标

墨菲定律说“会出错的事总会出错”,可用性做到100是可望而不可及的。对于SLA指标来说,9的数字越多可用性越高,宕机时间越少,系统就可以在给定的时刻内高比例地正常工作。然而对系统的挑战就越大,投入的成本也会越高。
比如5个9要求系统每年只宕机5分钟左右,而4个9要求每年宕机时间不超过一个小时。这就使得系统需要在设计、基础设施、数据备份等不同层面采取多种方式,甚至增加基础设施投资来保证可用性。

“当你的设备处理人命关天的事情,或业务中断一分钟就会损失百万美刀,那么你可以考虑99.99%的可靠性。”
Robertson(Linux高可用项目开发者)

不同系统的可用性要求也是不同的,比如:淘宝、京东等这些电商系统用户量很多,不同区不同时刻都有大量的用户在使用系统,这必然对系统的可用性要求很高。据以往这些系统的故障统计和不准确地测试数据推测,它们目前的可用性是在3个9到4个9左右。相对而言,企业类的工作软件因为通常只在工作时间被使用,或只在某些特定的地区使用,或只给某部分人某一特定时间使用,可用性的需求就会低一些。典型的系统就数salesforce了,经常会看到“周末又要升级了”的提示。

影响可用性的因素有很多,包括系统故障、基础设施故障、数据故障、安全攻击、系统压力等等。

2. Reliability 可靠性

Reliability is a measure of the probability that an item will perform
its intended function for a specified interval under stated
conditions.

可靠性是在给定的时间间隔和给定条件下,系统可以无故障持续运行的概率。那么可靠性和可用性有什么区别呢?在《分布式系统原理与范型》中提到的下面例子中比较准确的解释了两者的区别:

如果系统在每小时崩溃1ms,那么它的可用性就超过99.9999%,但是它还是高度不可靠。与之类似,如果一个系统从来不崩溃,但是每年要停机两星期,那么它是高度可靠的,但是可用性只有96%。

简而言之,可用性关注的是系统任何时刻可以持续正常工作的能力,关注的是服务总体的持续时间。系统在给定时间内总体的运行时间越长,可用性越高。而可靠性更关注系统可以无故障地持续运行的概率,关注的是故障率。故障的频率越高,可靠性越低。可靠性差一定程度上是会影响可用性的,但反过来不一定成立。

这里面还有一些常用的指标来衡量可用性和可靠性:

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

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

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

基于以上指标,可用性可以如此计算:

Availability = UpTime/(UpTime+DownTime) = MTBF / (MTBF + MTTR)

作为系统的响应,首要目标是先降低故障的次数,频率要低,从而提高可靠性;同时在故障出现后,要提高故障的恢复时间,速度要快,从而提高业务的可用性。

影响可靠性的因素就是能够引起故障的所有因素,包括软件设计错误,编码错误,硬件故障等等。

3. Stability 稳定性

Stability is about how many failures an application exhibits; whether
that is manifested as unexpected or unintended behaviour, users
receiving errors, or a catastrophic failure that brings a system down.
The fewer failures that are observed the more stable an application
is.

软件的稳定性,指软件在一个运行周期内、在一定的压力条件下,在持续操作时间内出错的概率,性能劣化趋势等等。如果一个系统的故障率很高,它一定是高度不可靠的,也一定是不稳定的。那么如何区分稳定性和可靠性呢?

对于电力系统而言,稳定性就是“人民用电不要忽明忽暗忽快忽慢”,可靠性就是”不要用着用着突然没有啦“。-知乎盛夏白日梦

如果一个系统的性能时好时坏,它一定是不稳定的,而不一定是不可靠的。稳定性更关注系统在给定条件下的响应是否一致,行为是否稳定。可靠是可用的前提,稳定是可靠的进一步提升。

今天在Stackoverflow看到这样一段代码来表示这两个的区别,甚为有趣:

Reliable but unstable:
    add(a,b):
     if randomInt mod 5 == 0: 
        throw exception
     else
        print a+b        
Stable but unreliable:
  add(a,b):
    if randomInt mod 5 == 0: 
        print a+a
    else
        print a+b

不知道写到这里,你是否对可用性、可靠性和稳定性有了更清晰的了解了呢?有了这些指标可以帮助我们去分析系统存在的问题,比如说故障频率较高,故障恢复时间较长,那么系统的可靠性可用性一定很低,对用户的影响一定很高,就可以促使我们去从各个角度去改进和提高,去找架构设计的问题,去找系统实现的缺陷,去找依赖的基础设施问题等等,从而改善我们的系统。尤其是在当下复杂的分布式系统下,这些显得尤为重要。

那么,最后请问我们常见的容错处理、蓝绿部署、回滚、cluster、灾备会有助于提高以上哪个ability呢?

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图