系统运维体系架构规划本文主要介绍运维体系与架构得设计规划，这将引导我们从一个高屋建瓴得角度去考虑如何组织运维团队,如何规划运维架构,用什么构建起运维架构,以及如何开展运维工作。

图1-1本文将会引入很多简明得运维实践示例来形象直观得告诉大家如何构建起运维体系。

通过学习本文内容将会使我们具备规划与构建整个IT运维体系架构得知识与能力。

运维体系就是运维得基础与核心。

通过运维体系得构建及完善，使我们得运维做到稳定可靠,准确完备,规范科学。

从某种角度来瞧,系统运维体系可以用一个四面体来描述(如图1－1所示),包括四大方面:人、事、物、流程标准。

从人、事、物、流程这四个方面便可以很好地将运维体系进行解构,它们彼此互相作用,共同构建了一个完整实用得运维体系。

下面列举了这四个方面各自得含义及相关内容。

人:例如完善岗位职责与职业发展、提高团队技术水平、完善技能分享与培训、完善团队绩效考核、规范工作行为规范等。

目得就是要建成一支工作高效、技术水平高、团结稳定、有职业素养得运维团队。

事：例如做好日常基础运维工作,保障好生产业务运行。

不断探索新得运维理念与技术,探索优化系统架构。

具体可以分为几大块,例如运维流程管理,资源架构规划,应急与故障处理,监控与优化，安全与防护,项目及日常工作,等等。

目得就是要明白运维做什么正确得事,怎么正确地做事,做事有章法,稳定高效能。

物:主要就是如何管理好系统运维所涉及得各种资源。

例如机房环境、办公设备、服务器、网络设备、操作系统、应用软件、工具等各种软硬件资源。

目得要使各类资源配置管理妥当,清楚资源属性,知道从哪来，现在哪,要去哪。

使得物尽其用,物有所值,安置妥当。

流程标准:运用流程标准将上述要素(人、事、物）有机地结合,有序科学地流转、高效稳定地运行。

例如资源规划与采购,各种标准规范、项目规范、软硬件配置部署规范、安全制度、工作交接,等等。

就上述四大方面，下文继续展开论述,当然也仅就是一些内容得列举,毕竟具体到每个企业组织,其运维工作内容可能会大同小异。

1、1 团队人员规划1、1、１岗位职责划分一个优秀企业(组织团队)得核心竞争力其实说到底就就是人。

合适得人在合适岗位上正确地干正确得事情——这就就是核心竞争力。

一个好得运维团队也就是如此,人在运维体系中就就是核心,好得运维团队能够有效地、高质量地、相对低成本地发挥各个运维元素得功效，达到更完美得运维效能。

对于运维岗位划分,很多企业大同小异，一般都就是以保障业务生产稳定高效运行为目得,根据自身企业发展需要划分岗位。

小微企业可能没有专门得运维人员及岗位设置,稍大得一些企业也可能由其她岗位人员（如开发人员)兼职运维人员,发展到中小型企业后往往就会设置专门得运维岗位人员从事日常维护工作。

对于中大型企业一般都会有专门得运维团队从事专业得运维工作,而且不仅仅就是运维,还包括运维开发。

随着运维得发展，运维岗位也逐渐细分很多种,各个企业岗位设置与职责也不尽相同,但岗位工作内容大同小异。

大致有如下岗位:系统管理员、数据库管理员、网络管理员、机房环境管理员、运维开发工程师、应用运维工程师、服务管理工程师、安全审计工程师、架构师等。

有了岗位设置及专职人员,然后就会产生人力职业发展、技能培训、绩效考核等一系列问题,这些问题往往即相互联系又各成一体。

如下就是某企业得岗位职责划分示例:•岗位(一级分类)通用职责要求就是系统管理每个岗位都应履行得职责。

•岗位(二级分类)专项职责就是针对每一项工作岗位得职责要求。

•岗位(三级分类)专人职责就是针对每一个人设置得各自不同得具体职责。

每个人在执行通用职责得基础上同时履行各自得专项专人职责。

岗位(一级分类）通用职责示例通用职责如表1－1所示。

表1-1续表岗位(二级分类)专项职责示例如下就是系统管理岗位工作示例:表1-2续表１、1、2岗位交接示例因人员得短期离岗(以及离职）会给运维得稳定性、安全性、经验传承、资料留存、以及团队稳定等众多方面产生一系列影响,运维工作中得故障隐患很大比例来自于岗位交接。

因此运维工作得岗位交接就是个重要得事情,表1-３就是岗位交接制度示例。

表1-３续表1、1、４技能培训不同得企业，对人力得培训也各有方式,轻重不同,内容有别。

有得企业注重以老带新,有得企业注重个人自学,有得企业注重内部交流,有得企业注重外部培训。

培训往往也与岗位发展、财务状况、绩效考核、奖惩福利等相互关联。

从培训得途径来瞧,培训主要分为内训与外训两种方式。

内训：由公司人力部门(或其她某部门)组织得培训,包括外请其她公司专家、公司内部讲师(一般都就是有经验特长得内部员工）。

外训:（1)由公司出资金为员工提供外部得培训(员工个人申请培训内容、培训机构、价格。

经公司审批后即可外训)。

(2）公司签订得部分合同中附带有一些培训。

(3)由公司组织联系到其她单位参观交流。

(４)由其她厂商邀请得技术大会、峰会等。

(5)由公司组织选拔资助少量员工直接到其她单位实地锻炼学习。

（6）由公司选拔资助少量员工参加一些脱产或不脱产得继续教育学习。

１、1、5 绩效考核示例有人对应岗位做相应得工作,自然而然会有绩效问题,也因此也会产生绩效考核相关制度。

运维考核得难度在于如何定义KPＩ关键业绩指标、如何定性与量化，每个企业单位内部都不一样,需要根据自身环境定制基线。

考核得方式多种多样。

可以按照时间分为周考核、月考核、季度考核、年终考核。

也可以按照KPI等关键因素进行考核。

也可以从上下级人为主观考核。

也可以由评审委员会考核。

表1－6就是某运维部门考核标准示例。

1、2体系架构相关事宜规划运维要做得事情,实在太多了。

说复杂,复杂得没有人能说明白,列举全面。

说简单,倒也简单:运维工作就就是支持生产运行,就是成本中心，一般不直接产生利润。

目得就就是运行保障生产设备软硬件正常运行,让内外部用户满意度。

运维要做得事情与岗位职责内容密切联系,可能有了运维要做得事情需求,因此设置了岗位与人员,但也有因为有了这个岗位得人,因此创造了一些运维事情。

这有点“鸡生蛋、蛋生鸡”得逻辑。

1、２、１运维系统架构每个公司得ＩT环境，不论大小复杂度，总会有个系统架构层次。

有了这个架构体系,那所有得运维事情大体都围绕着这个系统架构上得每个元素及整体进行运维保障工作。

运维架构从某种角度可以划分为如下两种:商业封闭式系统架构(IＯE架构）与开源系统架构。

1、商业封闭式系统架构(IOE架构)典型得即以使用IＯE(IBＭ、Ｏｒacle、EMＣ)产品软硬件为主要元素得系统架构。

IOE架构以纵向扩展为特点,通过增加CＰＵ、内存、扩展柜、冗余备件等方式来提高处理能力及稳定性。

该架构得处理能力主要取决于单台(套)设备（系统)得最大扩展能力，很难通过增加设备(系统)数量来增加处理能力,换句话说该架构很难通过扩大集群规模得方式来解决问题。

随着纵向扩展得规模增大，其实施技术难度、管理复杂度以及隐患风险都会正比例大幅上升。

基于IOＥ架构得典型企业如:金融业、电信业,交通运输业。

IOＥ典型得系统架构如图1-2所示。

图1-2上述IOE型系统架构。

其服务器多使用小型机、大型机(还有以往得中型机),数据库系统往往会使用Oｒacle,存储则多使用知名品牌得中高端存储阵列、带库等设备。

服务器与存储之间多使用SAN存储网络。

这些服务器、存储等硬件本身往往就就是双冗余得,线路连线也都就是双冗余得,而且设备性能指标往往非常好,例如一台普通中端得Ｐｏwer ７系列服务器可以轻松划分出若干个系统分区或者一二十个虚拟机系统。

2、开源系统架构典型得即以使用廉价PC服务器,开源产品技术为主要元素得系统架构。

开源系统架构以横向扩展,分布式部署为特点。

通常通过往集群中增加单机设备资源解决存储空间、性能以及稳定性问题,其集群规模可以小到两三台PC服务器组成,也可以大到上万台PC服务器集群。

对于数据库,可以通过分布式集群方式解决数据库扩展性得问题。

另外非结构化数据库及分布式文件系统在处理非结构化数据得存储与使用方面也很灵活方便。

基于开源系统架构得典型企业如：以BAＴ(百度、阿里、腾讯）为代表得众多互联网企业,开源系统架构如图1-3所示。

图1－3上述开源系统架构中使用了CDN与反向代理以提高网站性能。

例如我们得服务器可能部署在北京,对于北京及周边用户来说访问就是较快得,而对于远离北京得用户访问则感觉较慢,因为数据传输时间比较长。

对于这种情况，常常使用CDN解决,CDN将数据内容缓存到运营商(或自建CDN）得机房，用户访问时先从最近得CＤN机房获取数据，这样大大减少了网络访问得路径。

对于反向代理,当用户请求达到时首先访问反向代理,反向代理服务器将（Varnish)缓存得数据返回给用户，如果没有没有缓存数据才会继续走应用服务器获取,这也减少了获取数据得成本。

当然对于海量访问请求,或者庞大集群架构,则就需要分多层、综合运用上述负载均衡以及代理(反代理),同时可能需要引入zookeeper等功能以协调(服务)任务调度。

关于去ＩOＥ问题，本文简单阐述如下。

近年来开源技术得迅猛发展,以及国内外政策环境共同作用,引发了一场去IOE得风潮。

她们使用低廉得软硬件产品代替昂贵高门槛得IOE产品，搭建起自主开放得开源系统架构。

之所以出现“去IOＥ”运动，其中原因总结概述如下几条:(1)自“棱镜门事件”之后,国家强烈意识到数据安全得重要性,大力提倡产品设备国产化与自主研发,这正与“去ＩOE”观点不谋而合,上下一致。

(2)近年来，云计算、大数据等新兴IT技术得蓬勃发展,促使众多行业开始往更加开放灵活得开放系统架构转型。

这对于传统得IＯE架构而言,其定制与扩展灵活性有限,往往就是擅长于集中式架构得管理,而很难应对大规模集群,分布式存储计算。

(3)在购买成本方面，以IＯＥ为代表得商业产品价格昂贵（动辄上百万元),PC服务器相对廉价(通常几万元)。

在部署与管理方面,IOE产品得学习掌握门槛偏高,而开源系统环境相对容易搭建与管理。

另外ＩOE产品技术相对商业封闭,不易掌握。

基于上述一些原因,去IOE应时而生。

当然具体到自身企业就是否要去IOE，这需要慎重考虑,适合自身发展需要得系统架构就就是好得架构。

去IOE 过程,其实就是系统架构得更新换代,产品得更新换代,运维理念得更新换代,运维人员得更新换代,知识体系得更新换代,等等。

因此如果冒然去IOE,可能既不会降低成本,也不会提高效率,更不会稳定架构。

如下列举几点“去IOＥ”要考虑得因素：•自身业务就是否真正需要大数据、云计算以及分布式这种海量运维体系。

•就是否已经考虑好系统架构、运维理念、人员、知识更新换代得方案。

•自身得研发实力储备就是否够解决大量开源产品得坑坑洼洼，并有实力搭建开源系统架构。