系统运维体系架构规划
分享
本文主要介绍运维体系与架构的设计规划，这将引导我们从一个高屋建瓴的角度去考虑如何组织运维团队，如何规划运维架构，用什么构建起运维架构，以及如何开展运维工作。
图1-1本文将会引入很多简明的运维实践示例来形象直观的告诉大家如何构建起运维体系。通过学习本文内容将会使我们具备规划与构建整个IT 运维体系架构的知识和能力。
运维体系是运维的基础和核心。通过运维体系的构建及完善，使我们的运维做到稳定可靠，准确完备，规范科学。从某种角度来看，系统运维体系可以用一个四面体来描述(如图1-1所示)，包括四大方面：人、事、物、流程标准。
从人、事、物、流程这四个方面便可以很好地将运维体系进行解构，它们彼此互相作用，共同构建了一个完整实用的运维体系。下面列举了这四个方面各自的含义及相关内容。
人：例如完善岗位职责与职业发展、提高团队技术水平、完善技能分享与培训、完善团队绩效考核、规范工作行为规范等。目的是要建成一支工作高效、技术水平高、团结稳定、有职业素养的运维团队。
事：例如做好日常基础运维工作，保障好生产业务运行。不断探索新的运维理念与技术，探索优化系统架构。具体可以分为几大块，例如运维流程管理，资源架构规划，应急与故障处理，监控与优化，安全与防护，项目及日常工作，等等。目的是要明白运维做什么正确的事，怎么正确地做事，做事有章法，稳定高效能。
物：主要是如何管理好系统运维所涉及的各种资源。例如机房环境、办公设备、服务器、网络设备、操作系统、应用软件、工具等各种软硬件资源。目的要使各类资源配置管理妥当，清楚资源属性，知道从哪来，现在哪，要去哪。使得物尽其用，物有所值，安置妥当。
流程标准：运用流程标准将上述要素(人、事、物)有机地结合，有序科学地流转、高效稳定地运行。例如资源规划与采购，各种标准规范、项目规范、软硬件配置部署规范、安全制度、工作交接，等等。
就上述四大方面，下文继续展开论述，当然也仅是一些内容的列举，毕竟具体到每个企业组织，其运维工作内容可能会大同小异。
1.1 团队人员规划
1.1.1 岗位职责划分
一个优秀企业(组织团队)的核心竞争力其实说到底就是人。合适的人在合适岗位上正确地干正确的事情——这就是核心竞争力。一个好的运维团队也是如此，人在运维体系中就是核心，好的运维团队能够有效地、高质量地、相对低成本地发挥各个运维元素的功效，达到更完美的运维效能。
对于运维岗位划分，很多企业大同小异，一般都是以保障业务生产稳定高效运行为目的，根据自身企业发展需要划分岗位。小微企业可能没有专门的运维人员及岗位设置，稍大的一些企业也可能由其他岗位人员(如开发人员)兼职运维人员，发展到中小型企业后往往就会设置专门的运维岗位人员从事日常维护工作。对于中大型企业一般都会有专门的运维团队从事专业的运维工作，而且不仅仅是运维，还包括运维开发。
随着运维的发展，运维岗位也逐渐细分很多种，各个企业岗位设置与职责也不尽相同，但岗位工作内容大同小异。大致有如下岗位：系统管理员、数据库管理员、网络管理员、机房环境管理员、运维开发工程师、应用运维工程师、服务管理工程师、安全审计工程师、架构师等。
有了岗位设置及专职人员，然后就会产生人力职业发展、技能培训、绩效考核等一系列问题，这些问题往往即相互联系又各成一体。
如下是某企业的岗位职责划分示例：
?岗位(一级分类)通用职责要求是系统管理每个岗位都应履行的职责。
?岗位(二级分类)专项职责是针对每一项工作岗位的职责要求。
?岗位(三级分类)专人职责是针对每一个人设置的各自不同的具体职责。每个人在执行通用职责的基础上同时履行各自的专项专人职责。岗位(一级分类)通用职责示例通用职责如表1-1所示。
表1-1
续表
岗位(二级分类)专项职责示例如下是系统管理岗位工作示例：
表1-2
续表
1.1.2 岗位交接示例
因人员的短期离岗(以及离职)会给运维的稳定性、安全性、经验传承、资料留存、以及团队稳定等众多方面产生一系列影响,运维工作中的故障隐患很大比例来自于岗位交接。因此运维工作的岗位交接是个重要的事情，表1-3是岗位交接制度示例。
表1-3
续表
1.1.4 技能培训
不同的企业，对人力的培训也各有方式，轻重不同，内容有别。有的企业注重以老带新，有的企业注重个人自学，有的企业注重内部交流，有的企业注重外部培训。培训往往也与岗位发展、财务状况、绩效考核、奖惩福利等相互关联。
从培训的途径来看，培训主要分为内训和外训两种方式。
内训：
由公司人力部门(或其他某部门)组织的培训，包括外请其他公司专家、公司内部讲师(一般都是有经验特长的内部员工)。
外训：
(1)由公司出资金为员工提供外部的培训(员工个人申请培训内容、培训机构、价格。经公司审批后即可外训)。
(2)公司签订的部分合同中附带有一些培训。
(3)由公司组织联系到其他单位参观交流。
(4)由其他厂商邀请的技术大会、峰会等。
(5)由公司组织选拔资助少量员工直接到其他单位实地锻炼学习。
(6)由公司选拔资助少量员工参加一些脱产或不脱产的继续教育学习。
1.1.5 绩效考核示例
有人对应岗位做相应的工作，自然而然会有绩效问题，也因此也会产生绩效考核相关制度。
运维考核的难度在于如何定义KPI关键业绩指标、如何定性与量化，每个企业单位内部都不一样，需要根据自身环境定制基线。
考核的方式多种多样。可以按照时间分为周考核、月考核、季度考核、年终考核。也可以按照KPI等关键因素进行考核。也可以从上下级人为主观考核。也可以由评审委员会考核。
表1-6是某运维部门考核标准示例。
1.2 体系架构相关事宜规划
运维要做的事情，实在太多了。说复杂，复杂得没有人能说明白，列举全面。说简单，倒也简单：运维工作就是支持生产运行，是成本中心，一般不直接产生利润。目的就是运行保障生产设备软硬件正常运行，让内外部用户满意度。
运维要做的事情与岗位职责内容密切联系，可能有了运维要做的事情需求，因此设置了岗位和人员，但也有因为有了这个岗位的人，因此创造了一些运维事情。这有点“鸡生蛋、蛋生鸡”的逻辑。
1.2.1 运维系统架构
每个公司的IT环境，不论大小复杂度，总会有个系统架构层次。有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体进行运维保障工作。运维架构从某种角度可以划分为如下两种：商业封闭式系统架构(IOE架构)与开源系统架构。
1. 商业封闭式系统架构(IOE架构)
典型的即以使用IOE(IBM、Oracle、EMC)产品软硬件为主要元素的系统架构。IOE架构以纵向扩展为特点，通过增加CPU、内存、扩展柜、冗余备件等方式来提高处理能力及稳定性。该架构的处理能力主要取决于单台(套)设备(系统)的最大扩展能力，很难通过增加设备(系统)数量来增加处理能力，换句话说该架构很难通过扩大集群规模的方式来解决问题。随着纵向扩展的规模增大，其实施技术难度、管理复杂度以及隐患风险都会正比例大幅上升。基于IOE架构的典型企业如：金融业、电信业，交通运输业。IOE典型的系统架构如图1-2所示。
图1-2
上述IOE型系统架构。其服务器多使用小型机、大型机(还有以往的中型机)，数据库系统往往会使用Oracle，存储则多使用知名品牌的中高端存储阵列、带库等设备。服务器与存储之间多使用SAN存储网络。这些服务器、存储等硬件本身往往就是双冗余的，线路连线也都是双冗余的，而且设备性能指标往往非常好，例如一台普通中端的Power 7系列服务器可以轻松划分出若干个系统分区或者一二十个虚拟机系统。
2. 开源系统架构
典型的即以使用廉价PC服务器，开源产品技术为主要元素的系统架构。开源系统架构以横向扩展，分布式部署为特点。通常通过往集群中增加单机设备资源解决存储空间、性能以及稳定性问题，其集群规模可以小到两三台PC服务器组成，也可以大到上万台PC服务器集群。对于数据库，可以通过分布式集群方式解决数据库扩展性的问题。另外非结构化数据库及分布式文件系统在处理非结构化数据的存储与使用方面也很灵活方便。基于开源系统架构的典型企业如：以BAT(百度、阿里、腾讯)为代表的众多互联网企业，开源系统架构如图1-3所示。
图1-3
上述开源系统架构中使用了CDN和反向代理以提高网站性能。例如我们的服务器可能部署在北京，对于北京及周边用户来说访问是较快的，而对于远离北京的用户访问则感觉较慢，因为数据传输时间比较长。对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商(或自建CDN)的机房，用户访问时先从最近的CDN机房获取数据，这样大大减少了网络访问的路径。
对于反向代理，当用户请求达到时首先访问反向代理，反向代理服务器将(Varnish)缓存的数据返回给用户，如果没有没有缓存数据才会继续走应用服务器获取，这也减少了获取数据的成本。当然对于海量访问请求，或者庞大集群架构，则就需要分多层、综合运用上述负载均衡以及代理(反代理)，同时可能需要引入zookeeper等功能以协调(服务)任务调度。
关于去IOE问题，本文简单阐述如下。
近年来开源技术的迅猛发展，以及国内外政策环境共同作用，引发了一场去IOE的风潮。他们使用低廉的软硬件产品代替昂贵高门槛的IOE产品，搭建起自主开放的开源系统架构。之所以出现“去IOE”运动，其中原因总结概述如下几条：
(1)自“棱镜门事件”之后，国家强烈意识到数据安全的重要性，大力提倡产品设备国产化与自主研发，这正与“去IOE”观点不谋而合，上下一致。
(2)近年来，云计算、大数据等新兴IT技术的蓬勃发展，促使众多行业开始往更加开放灵活的开放系统架构转型。这对于传统的IOE架构而言，其定制与扩展灵活性有限，往往是擅长于集中式架构的管理，而很难应对大规模集群，分布式存储计算。
(3)在购买成本方面，以IOE为代表的商业产品价格昂贵(动辄上百万元)，PC服务器相对廉价(通常几万元)。在部署与管理方面，IOE产品的学习掌握门槛偏高，而开源系统环境相对容易搭建与管理。另外IOE产品技术相对商业封闭，不易掌握。
基于上述一些原因，去IOE应时而生。当然具体到自身企业是否要去IOE，这需要慎重考虑，适合自身发展需要的系统架构就是好的架构。去IOE 过程，其实是系统架构的更新换代，产品的更新换代，运维理念的更新换代，运维人员的更新换代，知识体系的更新换代，等等。因此如果冒然去IOE，可能既不会降低成本，也不会提高效率，更不会稳定架构。如下列举几点“去IOE”要考虑的因素：
?自身业务是否真正需要大数据、云计算以及分布式这种海量运维体系。
?是否已经考虑好系统架构、运维理念、人员、知识更新换代的方案。
?自身的研发实力储备是否够解决大量开源产品的坑坑洼洼，并有实力搭建开源系统架构。
?是否有足够的资金应对“去IOE”转型中的成本，例如从硬件高成本转向人力技术高成本。
去IOE只是给予我们一些最佳实践与选择路子，但去IOE技术门槛较高，一般企业很难复制。从目前发展来看，IOE架构与非IOE架构仍将长期并存。一时间很难找到一些能够完美替代以IOE为代表的成熟(且普适)产品方案。
1.2.2 运维工作层次分类示例
例如《海量运维、运营规划》(作者：唐文)一书，作者很有观点地概括了运维要做的事情，他以质量、效率、成本为核心，从运营规划、管理、流程/规范、系统/平台、监控、告警、安全、优化、考核等几个维度来阐述运维工作，如图1-4所示。
图1-4
另外也可以从逻辑框架的层次来分类运维工作要做的事情。如下借鉴美团的分享者(唐君毅、邱剑、朱晏)关于企业运维的观点，运维框架可以概括为五横三纵。
从横向来看，自底向上分为五个层次：
?物理层：包括机房网络、硬件设施相关工作。如采购招投标工作、机房实施工作、机房环境(强弱电、照明、通风、网络布线、温湿度等)，各种设备上下电与维修工作等。
?系统层：包括操作系统、虚拟化、云计算等一系列系统环境所涉及的部署、配置、优化等工作。
?服务层：包括Webserver、缓存、代理、数据库等所涉及的软件应用的部署、配置、优化等工作。
?逻辑层：包括业务逻辑、数据流。这一层的主要工作是发布和变更。
?应用层：包括用户可见部分。所有前端平台，主要涉及与前端用户交互或提供信息(服务)的平台。比如前端网站、各种新媒体平台的维护与监控。
从纵向来看，有三部分工作，对上述五个层次是通用的：
?监控：从物理层到服务层的监控和报警都是运维来跟进、响应的。对于逻辑层和应用层，一般由运维提供监控API的规范，开发人员自己创建监控项、设定报警规则、进行增删改查。
?安全：建立部署统一的安全接入平台，所有线上的人工操作都需要登陆跳板机，每个人有独立的登陆帐号，所有线上操作都有审计日志。更多的安全工作由专门的信息安全组负责。
?流程：早期基于Jira做了一些简单的流程，但需要改进。现在正在针对比较集中的需求，开发相应的流程控制系统，方向也是自动化、自助化。从业务部门申请VM资源，到业务扩容的整个流程，未来可以在Web界面上通过很简单的操作实现，也提供服务化的API，方便其他业务平台进行集成。以期实现虚拟化覆盖全业务线。
1.3 基础设施相关物资规划
做饭要有材米油盐，打仗要有弹药武器。干运维，也要有一系列软硬工具。什么算是运维工作的工具，恐怕这个也没有明确定义。运维所涉及的工具物品，有看的见的，也有看不见的;有摸得着的，也有摸不着的。这里简单概括一下运维工作会用到的各种软硬件、工具、设施。
1.3.1 机房基础设施环境示例
如下列举的是机房基础设施环境相关要素，如表1-7所示。机房不论大小，基本上都会涉及到如下几大主要工程(系统)。
续表