|
|
51CTO旗下网站
|
|
移动端

1.1.1 认识运维

《智能运维:从0搭建大规模分布式AIOps系统》第1篇开门见山:运维发展史,本篇主要展现运维的发展历史和经历的不同历史阶段,以及运维工作的现状。本节为大家介绍运维。

作者:彭冬/朱伟/刘俊来源:电子工业出版社|2018-11-27 12:06

第1篇 开门见山:运维发展史

中国互联网从20世纪90年代开始形成,随即进入了快速发展阶段。第一阶段是以新浪、搜狐和网易为代表的门户网站时期,解决了信息尤其是新闻信息的传播问题。第二阶段是以腾讯、百度和阿里巴巴为代表的科技型时代,解决了社交、信息获取及电商等需求问题。第三阶段进入一个新的时期,从直播、网红到短视频类公司,以及人工智能公司的兴起,足以说明要解决的是心理需求。短短二十年,中国互联网发生了翻天覆地的变化,网民数量已经增长到9亿,其中使用手机的用户量已经达到7亿,中国也被称为具有全球最大消费能力的国家,很多企业只要做好中国市场,就能与其他做全球市场的企业比肩。科技的进步需要技术的支撑,运维技术也在不断地发生着变化。

运维的技术体系伴随着互联网的发展而愈加完善,从最开始的纯人工运维到脚本和开源工具的使用,再到平台建设,运维也紧跟时代的步伐,逐渐向智能化方向发展,通过应用机器学习的一些算法和模型将极大简化运维对数据的理解,大幅度提升效率。与此同时,运维工作也面临着非常大的挑战,在大数据场景下信息过载、多维度和更加复杂的业务环境,以及故障的定位、检测等工作,都已经超过了单凭人工能够完成的极限,新的技术需要被引进和普及。

近年来,人工智能技术备受关注,开始将AI引入IT运维领域,AIOps的概念由此应运而生。Gartner的报告宣称,到2020年,将近50%的企业将会在他们的业务和IT运维方面采用AIOps,智能化已是大势所趋。

本篇主要展现运维的发展历史和经历的不同历史阶段,以及运维工作的现状。本篇主要分两个章节:

第1章 运维现状

第2章 智能运维

第1章 运维现状

1.1 运维工程

1.1.1 认识运维

运维,通常指IT运维(IT Operations),是指通过一系列步骤和方法,管理与维护线上服务(Online Service)或者产品(Product)的过程。运维有着非常广泛的定义,在不同的公司不同的阶段代表不同的职责与定位,没有一个统一的标准。尤其是随着互联网的发展,运维的含义也在逐渐互联网化。互联网运维通常属于技术部门,与研发、测试、系统管理同为互联网产品的技术支撑,这种划分在国内和国外以及大小公司之间都会多少有一些不同。

运维的重点在于系统运行的各种环境,从机房、网络、存储、物理机、虚拟机这些基础的架构,到数据库、中间件平台、云平台、大数据平台,偏重的也不是编程,而是对这类平台的使用和管理。运维的水平可以成为衡量一个公司(IT公司)技术实力的标准。

运维工程师(Operation Engineer),是指从事运维工作的工程师。运维工程师的工作范围非常广泛,包括服务器购买、租用和上架等基本管理,调整网络设备的配置管理和部署,服务器操作系统安装调试,测试环境和生产环境的初始化与维护,代码部署和管理(Git和SVN等),设计和部署线上服务的监控与报警,服务安全性检测(防止漏洞和攻击),数据库管理和调优等。在大型公司中,运维工程师根据工作内容被细化为网站运维、系统运维、网络运维、数据库运维(DBA)、IT运维、运维开发(DevOps[1])、运维安全等方向。

运维的工作内容决定了对运维工程师的要求会非常高,运维工程师需要对服务器资源(CPU、内存、磁盘、网络IO等)非常了解,对Linux系统和常见的开源框架、工具非常熟悉,因此在运维工程师中更容易诞生架构师,因为他们知道如何优化服务、如何使得资源利用最大化。

运维工程在国内也被称作SRE[2](Site Reliability Engineering,来自Google),直接翻译为网站可用性工程。SRE工程师需要具备算法、数据结构、编程能力、网络编程、分布式系统、可扩展架构、故障排除等各方面技能,其核心工作包括容量规划与实施、服务集群维护、系统容错管理、负载均衡、监控系统以及值班等,最终为产品上线后服务的稳定性负责,但是不负责具体的机器运维。

SRE工程师的首要工作任务是保障SLA(Service-Level Agreement,服务等级协议),它定义了对服务有效性的保障,比如对故障解决时间、服务超时等的保障。根据这个协议标准可以定义系统的可用性(Availability),这里需要掌握如下几个衡量指标。

1. 平均故障间隔时间(MTBF)

平均故障间隔时间(MTBF,Mean Time Between Failure),指相邻两次故障之间的平均工作时间。MTBF通常是衡量一个产品可靠性的指标,这个间隔时间越短说明系统可靠性越差。

2. 平均修复时间(MTTR)

平均修复时间(MTTR,Mean Time To Repair),指产品由故障状态转为工作状态时修复时间的平均值,即故障修复所需要的平均时间。MTTR值越低说明故障修复越及时。

3. 可用性(Availability)

可用性是系统架构设计中很重要的衡量指标。根据GB/T3187—97对可用性的定义,可用性是指在要求的外部资源得到保证的前提下,产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。它是产品可靠性、维修性和维修保障性的综合反映,如公式(1-1)所示。

业界一般通过N个9来对可用性进行量化。如表1-1所示为对可用性的量化及描述。

表1-1 系统可用性量化指标

续表

可以看出,当系统可用性超过3个9时,全年停机状态持续时间低于8.8小时,此时一般可以称作高可用性系统,可用性越高,对系统的设计要求就越高。需要注意的是,在分布式系统中,可用性和性能应该遵循CAP原则,即数据一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)三者通常只能满足其中两者,无法兼得。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书会第9群:808517103

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

SQL实用简明教程(第2版)

SQL(结构化查询语言)是数据库系统的通用语言,利用它可以用几乎同样的语句在不同的数据库系统上执行同样的操作,在数据库系统的开发中有着...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊