运维2体系架构Word文件下载.docx

运维2体系架构Word文件下载.docx

《运维2体系架构Word文件下载.docx》由会员分享，可在线阅读，更多相关《运维2体系架构Word文件下载.docx（7页珍藏版）》请在冰豆网上搜索。

3.应用环境组建

运维2.0提出运维规划中需明确规定未来系统在生产环境中架构层级划分标准，架构层级和服务单元的衔接标准，应用系统中每个模块、每个组件甚至每个配置文件的配置标准，统一的标准化的应用环境和组件配置有助于促进一体化自动运维的实现，同时也有利于组件以及组件维护的迭代与重用。

（三）安全体系规划

生产系统的信息安全由运维部门主责，运维2.0在信息安全规划中提出运维部门除关注安全技术手段外，还要考虑配套的安全管理制度。

目前多数应用系统在生产环境上线后，运行维护时才开始设计相应的配套制度，这使得未来生产环境存在“先天不足，后天弥补”的风险。

比如由于数据篡改、伪造、中断或者截获造成信息反馈延时或由于病毒侵入造成系统紊乱的风险。

在运维之初，规划符合行业与监管标准的信息安全政策与制度，建立一系列运维框架，并将相应的制度和规通过技术手段落实到应用系统的设计中会起到“有备无患”的作用。

图示：

信息安全体系规划

（四）预算规划

运维2.0的预算规划提出了在保证提供“安全业务服务”得前提下，系统容量模型和预算模型之间的关系。

通过将业务需求指标与运维规划相结合，计算出每个层级架构中每个服务单元、每个模块能够支撑的业务指标，后续的预算填报根据业务需求中的业务指标就可以计算出每个业务需要多少模块，每个模块需要单台设备支撑多少业务指标。

对于定制化的模块，比如云平台套餐数目、可定制的计算资源等，用业务指标指导计算或存储资源的定制化，根据业务需求，对计算或存储资源规格进行必要的拆建，提供成本最优化的硬件资源。

根据服务并发规模、峰值并发规模以及每一模块可提供的动态服务支撑数量，推导模块的增量预算。

运维2.0以此关联模型将服务资源的需求量转化为运维预算。

二、监控体系

运维2.0倡导实现IT管理与业务服务的融合，建立面向业务服务、层次化、可量化的智能监控体系。

通过层次分析法将运维监控要素划分为相互联系的各个单元，根据上下层次之间的隶属关系以及同一层次同一服务单元中元素间的依赖关系进行定量描述，构建出一个关系矩阵。

通过对服务单元每一层次或模块的对服务完整性的贡献比例设置权重值。

该体系从上至下分为应用服务层、系统资源层、网络服务层和基础设施层，全面覆盖应用系统、数据库、中间件、服务器、存储、网络和动力环境各个领域。

确保任何一个领域出现风险隐患时，运维人员均可以主动、及时地发现、预警、分析和处置，把风险控制在萌芽状态，保证业务连续性。

图示：

面向服务的监控体系

在智能化监控方面，运维2.0提出通过历史运维数据分析，实现系统故障的预警和精确定位以及自动派单，通过预测走势进行主动触发式运维，使热门业务服务的资源占用、服务质量可视、可评。

通过服务单元、层次及模块间的关系分析（任务始止、关键组件、一致依赖、超出预期），对业务故障进行智能定界定位，快速处理。

对用户的服务体验的实时监控、提前预警。

比如通过动态感知技术实现对硬件故障的预测和自动化管理，实现对机器的管理的零投入;

通过智能实时分析、全局调度技术，合理分配存储资源，最大化减低预算开销。

通过对历史数据的学习和模块间关联模式识别实现服务的预测。

模块间关联关系智能监控预测

在技术层面上，运维2.0智能监控丰富业务系统的非功能性需求，使开发团队在业务需求分析和设计阶段，就把运维阶段需关注的监控指标考虑进去，起到“未雨绸缪”的防作用；

同时，业务的导向对于运维全面、有效设计预警指标，直观预警和定位故障，起到“有的放矢”的引导作用。

在管理层面上，中高层通过各维度、各层次数据的量化来量化业务的运行状态和趋势，起到“严谨”的科学指导作用。

三、度量体系

运维2.0的度量体系从面向业务的运维服务能力和运维架构能力两方面着眼，建立衡量运维质量的评估体系。

（一）运维服务能力评估

运维服务能力评估是面向提供给业务用户的自服务的评估，按照运维架构能力建设和管理的进化历程，运维服务成熟度可以分为四个级别：

1.基本级：

依据《信息技术服务运行维护标准》（GB/T28827.1）实施满足业务需求的运维服务管理，日常的运维活动实现了有序运行。

对标准的实施不要求全面性和系统性，而是根据业务发展情况，采用了标准提供的方法。

2.拓展级：

依据《信息技术服务运行维护标准》（GB/T28827.1）实施运维服务管理，实施标准要求全面性和系统性，并能与业务发展情况相结合，形成了较为完善的人员、过程、技术和资源等方面的管理制度，并得到有效实施。

3.改进级：

在全面和系统实施《信息技术服务运行维护标准》（GB/T28827.1）的基础上，从保障运维服务交付质量的角度出发，组织的运维服务能力发展战略和目标清晰，形成了完善的运维服务体系，建立人员、过程、资源和技术等能力要素协同改进的制度体系。

4.提升级：

在全面和系统实施《信息技术服务运行维护标准》（GB/T28827.1）的基础上，从量化提升运维服务能力的角度出发实施有关运维服务质量评价。

组织能够基于信息技术服务业务综合发展的需要，实现全面量化的运维服务能力管理，形成推动业务服务变革的机制。

运维2.0运维服务能力度量体系要求运维服务能力达到运维成熟度的提升级别，即从量化出发评价运维服务价值与质量，具体的量化标准参见下表

度量指标

子指标

分值

自服务合规

运维服务流程符合信息安全规

2

部署更新服务符合标准化要求

故障处理服务符合服务级别协议及问题升级流程

变更服务符合变更流程及规

事件响应服务的调用符合自服务承诺

容灾恢复设计达到RPO要求

5

容灾恢复设计达到RTO要求

工具

工具接口具备快速调用与部署能力

10

工具技术支持业务服务敏捷迭代要求

备份

业务数据备份

业务程序备份

容灾备份

监控历史数据

监控

对关键服务单元各节点有自动化、量化的监控、告警

对整体服务状态有监控、告警及定期分析

文档

针对特定系统维护文档持续更新

针对特定业务的运维流程规文档持续更新

运维服务能力度量分值表

（二）架构能力评估

架构能力的评估是针对运维对象的，即产品体系的评估。

运维2.0认为，运维部门作为生产系统的责任人，有权利突破传统的被动运维模式，通过一套可量化的指标，对产品系统进行评估，促使运维和研发加速融合，利于产品系统的

改进和优化。

架构能力评估参见下表。

评估指标

一级（<

60分）

二级（60分~70分）

三级（70分~80分）

四级（80分~90分）

五级（90分~95分）

容错能力

无容错考虑，仅实现业务功能

所有硬件、软件和数据都有备份，支持负载均衡

无单点故障，但台服务器的服务级别满足SLA要求。

无单点故障，整体服务达到SLA要求，对各种异常情况可以自动处理、自动预警和自动恢复

无单点故障，可进行自动故障定位、自动预警和自动恢复。

可估算主要模块的故障率和影响围

资源利用率

资源利用率小于20%

资源利用率小于80%

资源利用率小于85%

资源利用率小于90%

资源利用率大于90%

灰度升级

无灰度升级或者无规划灰度升级

主要模块可灰度升级，具有准确可用的检测手段，以检测升级效果，30分钟升级失败回滚

所有模块均能恢复生机，5分钟升级失败回滚

整个系统能纵向灰度升级，新旧并行互不干扰

多版本、多系统灰度升级

架构伸缩性

无伸缩性

可实现非在线纵向柔性可用和横向水平调度

通过细微代码改动可实现纵向柔性可用和横向水平调度

无需改动，只需调整配置就可以实现纵向柔性可用和横向水平调度

可实现自动化纵向柔性可用和横向水平调度

架构组建重用

无法重用

参与公用组件积累工作

公用组件可在系统重用

公用组件可跨系统重用

架构能力评估度量分值表

四、工具体系

运维2.0的工具体系是面向自服务的架构，辅助运维2.0“自动可视、集中管理、辅助决策”的理念落地。

对外，实现更好、更快、更省的价值交付，对，实现IT资源和工具的可视、可控、可管理。

（一）工具体系设计原则

1.自底向上，面向服务

面向业务自底向上集成工具并提供服务调用接口。

体系建设遵循先建设各个专业领域运维工具，通过API接口方式对上暴露服务，以供业务用户及业务平台调用。

2.整合共享，透明调用

把工具视为服务的组件，工具研发完成后，嵌入到整合的工具平台，由平台总线接管，根据服务生命周期进行自调用，透明的提供服务，平台整合避免服务被碎片化，从而让业务用户看到的不是一个一个工具或独立的系统，而是面向业务的整合服务，确保服务提供者和服务交互者之间的交互最少。

（二）工具体系建设容

运维2.0工具体系建设包含建立与运维规划相匹配的工接口标准、数据服务以及功能服务的标准三部分重点。

五、人才体系

运维2.0的人才体系建设强调培养知识型运维人才、服务型运维人才和全栈运维人才

（一）知识型人才

运维2.0实现运维的自动化、可量化和自服务体系，减少了运维人员机械性的重复劳动，要求运维人员注重工作中自我引导和自我管理，向创造性人才转变，依靠企业知识管理平台，进行创造性思维，不断形成创造性的成果。

（二）服务型人才

运维2.0是面向服务的运维模式，强调以业务为导向，关注用户体验，人才培养注重集中化服务型组织架构，突出集约化管理和主动性维护，人员的价值评价和考核体系也相应以服务质量为依据。

（三）全栈型人才

运维2.0弱化研发和运维界限，倡导IT融合，要求运维人员在兼顾横向专业领域，如web层、中间件层、数据库层等的同时，打破技术个性的壁垒，提升整体业务运营能力，向开发和运维全堆栈的每个层级发展。