高效研发运维体系构建的流程和方法论

内容导航：

高效研发运维体系构建的流程和方法论

运维项目管理流程

关于运维体系建设有没有什么好点的建议？

如何提高运维管理工作效率？

一、高效研发运维体系构建的流程和方法论

云计算产品大多都会与云原生发生关联，云原生正在重塑整个软件的生命周期。但到底什么是云原生？云原生带来的最大技术创新和未来机会是什么？围绕云原生，是否可以构建出一套云上的开发&运维体系，打造新一代研发平台，实现研发效率的最大化？

我们邀请了阿里云云效研发平台负责人神秀，分享团队关于高效研发运维体系构建的流程和方法论。文章包括三个部分：首先从问题出发，分析在团队业务逐步壮大的过程中可能会遇到的问题，以及这些问题对团队效能的影响。然后结合问题看下什么样的效能体系能够满足团队效能提升的诉求。最后介绍阿里云云效团队对效能提升方法的一些总结。

一 团队效能的影响因素

1 团队效能的影响因素

首先探讨下企业人员规模增长对效能的影响。刚开始公司初创期，十几二十人组成全功能团队，此时团队分工边界并不明确，大家在一个非常敏捷的状态下工作，互相会进行一些补位，比如技术去做一些产品的事情，开发去做测试和运维。这种情况下团队协作起来基本上没有太多沟通损耗。往往瓶颈在个人能力上。此时初创团队为了更快的完成业务需求，在效能工具选择上更关注单点效率，比如好用的流水线工具、测试工具等等，上手门槛是第一考虑的因素。

当团队逐步扩张，人员分工开始专业化，多职能协同的问题开始凸显出来。如何合作，权责如何分配，大家之间的协作流程是怎样的，是团队非常关心的问题。此时团队并不太会因为个人能力而决定产品的成败，如何提升中位能力是关键问题。此时在效能工具的选择上会更偏向于有一定解决方案的产品，比如分支管理模式，测试环境管理模式，DevOps如何落地等等。这些工具的使用可以很大程度去提升团队之间透明度，提升沟通效率。比如分支管理模式的选择，解决开发与测试团队沟通的问题，DevOps模式更是将绝大部分运维工作交给开发独立完成，从而通过减少沟通来提升效率。

随着团队业务进一步扩大，开始出现有明显业务边界的产品，此时在沟通协作成本会被进一步放大，大家更加重视目标、共识和结果。当然可以以战役模式去承载目标、共识和结果，是非常好的一种汇聚人力资源，topdown的提升执行效率的手段。从另一面也要意识到，战役并不能解决所有边边角角的跨产品、跨团队协同问题，如何在日常状态下去解决这种兵力分配、业务技术拉通的问题才是关键。

2 软件服务架构对研发效能的影响

接下来看另一个问题，就是服务架构对研发效能的影响。服务架构其实和组织架构有很强的关联关系，比如在扁平化架构下，团队各自独立互相关联性不强，有很高的自给率，这里的自给率是指独立完成某个需求的能力。

在网状架构下组织形式往往是一体式的，由同一个部门老大带领，团队之间紧密配合，我中有你，你中有我。在这个阶段架构复杂度高，缺乏抽象。但是因为业务流程相对简单，做起需求来各团队点对点沟通也不是太大问题，决策链路短，共识快。从另一方面看，技术债务也在累积，当业务之间耦合到一定程度的时候就会出现维护债务的人力投入开始大过新需求人力投入。中台架构是解决此问题的一个路径。

到中台模式下，各种业务模块开始被抽象出来，随之技术侧也需要组建技术中台，将原来各自团队持有的工具开始收敛，流程开始统一。不过随着前台和中台出现分工后，各自发展路线独立设计，此时就会出现部门墙、前台业务自给率低、达成优先级、交付时间等共识很困难的问题。

经过这三种产品架构、技术架构、组织架构的分析，相信大家可以理解团队不断演进过程中面临的效能困局。

3 技术演化带来的效能变化

说完了协作问题，再来看技术的演化是如何影响研发效能的。先粗略的看看过去几年的几个技术变化。在2008年开始业界提出了微服务、持续交付、DevOps等等一系列的概念，延续至今。与此同时阿里巴巴也对电商核心系统进行了服务化改造，后来又发现服务多了，管理出现了难题，只有DevOps可以消除瓶颈，释放生产力。这几件事其实内部是有一定逻辑的，也就是业务驱动技术变革，技术促进架构变革，架构又推动研发模式变革。

再看最近几年日益兴盛的k8s生态，大致相同，新技术的应用，造就了很多新的架构模式比如serverless，小程序等，这些新的架构给原有的研发模式也带来了巨大挑战，比如在Function as Services模式下如何管理代码分支和环境，测试工具和方法会不会发生变化，测试团队的职责会不会发生变化等等。当然，大家可以再设想下，当未来服务数量进一步爆炸，架构复杂度进一步提升，这种复杂度超过人的掌控时，会出现什么样的变化，我们需要使用怎样的工具去解决那个时候的效能问题。

4 企业研发效能的制约因素

结合上面从人员、架构、技术三方面的分析，在进一步提取中间的关键因素，会形成这样的一个环。这三个关键因素就是成本、人、和人与人之间的协同损耗。成本是不可能无限放大的，所以是这个环里面的最关键约束。另外因为人的能力参差不齐，那么就无法创造出完美的架构和完美的组织设置，这里面就会出现大量的协同消耗。刚才也提到了，技术债务是会累积的，协同消耗往往会随着时间不断放大，消耗更多的人力，在固定的成本约束下会导致更少的业务人力投入。这个环就会出现负反馈，也就是越来越差。所以才有了探讨研发效能这个问题的必要性。

通常会采用技术去武装人，提升个人能力上限，这是笔者认为的重要破局点。接下来需要适应当前团队组织和架构现状的协同流程，去降低损耗。需要注意的是这往往只能带来改进，在固有架构和组织模式不变的情况下很难根本上改变局面。最后可以使用一些工具去让我们的工作更有效率，以前手工做的现在自动化去做，可以腾出更多时间去聚焦业务价值输出。

三管齐下后就可以有效驱动这个环进入正反馈，团队效率更高，技能提升更快，协同更加顺畅，业务发展好了又可以投入更多的人力成本。

在阿里自身的实践中发现，就是在在不断地改变这些要素，遇到瓶颈投入改进，走出负反馈，进入高速发展，然后又遇到瓶颈。

那么这些问题如何系统化的被提升或者解决，就需要一套适合的效能工具体系。

二 效能工具体系的建设思路

1 三种典型的研发团队

在我们的实践中会可以归纳出以下三种典型的研发团队。

第一种是前后台的应用开发，电商、SaaS等都是典型的形态。这种业务形态在工程侧比较容易标准化，工具比较完善，尤其是云原生技术的发展，让业务的关注点更加向上转移，底层技术越来越云化，越来越黑盒。第二种是底层基础软件研发，业务特点是用户交互简单，但技术深度和复杂性较大。这种软件往往是有状态服务，并且对硬件基础设施有强依赖，以至于在运维侧就较难标准化。另外在开发侧也存在技术栈复杂，多人在一个模块集中研发的情况，较难像前后台应用那样通过服务拆分进行解耦加快迭代，同时也衍生出比如分支管理、二进制版本管理等新问题。这种开发态和运维态的差异性导致了工具体系的差异。第三种是线下交付型的大型软件研发，以混合云、行业软件为代表的。因为系统耦合复杂，叠加客户专有环境因素，对多团队协同能力和交付运维系统能力要求很高。相对于第一种前后台应用开发，对版本管理、集成升级、远程运维能力特别关注。

2 分层建设效能体系匹配复杂协同场景

因此，面对不同的研发场景，不同的侧重点，需要对效能体系进行分层和抽象。在这里可以把整个体系分为4个层次，从下到上是基础底座、工具层、协同层、场景化。

在基础底座中应该关注产研核心资产的数据沉淀，确保整个体系的数据一致性，通常会提取研发体系中核心对象进行下沉，比如团队、项目、应用、代码、制品等。

之上是最关键的工具层，工具定义为解决单点问题的自动化手段。其中开放性和被集成性应该是工具最重要的能力。比如常说的api first就是这个道理。

再往上是协同层，这一层产品聚焦于解决人和人之间的信息传递问题，以及将这种协同流程进行线上化、标准化。通过对不同领域协同关系的抽象，并且串联单点工具，最终让使用者们可以在线完成一个完整的工作。

通用性、可配置性和体验有时候是矛盾的，因此还需要场景化层的产品去解决各自领域的精细化用户体验问题。可以看到最近几年业界的趋势就是如此，通用的研发平台在不断成熟和做深，而场景化研发平台不断产生，通过集成下层工具能力，快速覆盖细分研发场景。

目前云效正是按照这个分层思路在建设研发工具体系，希望可以将更多开发者纳入到这个体系中来，一同构建这个复杂的生态系统。

3 每个团队定制自己的效能方案

公司除了提供标准化的研发流程体系以外，每个团队都应该有自己的效能方案来满足自己团队的文化和习惯。在这里可以有这两三个层面可以去提供定制。

一个是团队工作台，这是团队的知识沉淀场所和协同空间。里面提供多种视图来浏览工作状态以及待办事项、进度等。还会为leader提供一些列管理工具。

另外两个是团队协同流程和工具，推荐大家深入学习效能提升方法、团队管理方法，并且结合团队现状，个性化到系统中，甚至创新出更适合业务特点的工具，逐步释放团队生产力潜能。

通过统一平台可以守住团队效能的下限，但是效能上限需要团队自身的努力来突破。

4 进一步的效能提升建议

基于以上分析，笔者提出以下三个建议：

第一个是团队需要着眼于从目标、业务、产品、研发全流程进行效能提升。举个例子，一个问题：测试团队如果成为交付瓶颈，是不是完全是测试团队的责任？很显然，这里面可能是需求侧用户链路分析不全面，或者开发团队交付质量差，更或者是架构设计不合理导致可测性不强等等，这些都会加重测试团队负担，让测试团队成为瓶颈。因此团队负责人需要端到端的去思考，掌握方法并具备宏观视野，而不是头痛医头脚痛医脚。第二点是团队需要为自己的效能负责，是第一责任人。自己最了解自己的团队，往往采取的措施也是最有效的。第三点是提升团队产品设计能力、技术能力，减少技术债务，构建内建质量对效能提升非常重要。效能工具体系只能提供最基础保障，要让团队效能更健康，需要从最基础的软件工程细节入手，逐步改善，在这方面没有银弹。三 效能方法体系的演进

1 从强调工具流程走向强调价值交付

当团队分工开始细化以后，从组织角度更加专业化，资源效率更高，但是从业务价值交付的角度来看，周期非常长，而且中间还伴随着各种等待。

因此可以得出这样一个结论就是局部效率，并不代表可以高效的交付业务需求。局部效率有很多工具和手段去提升，这是一个相对收敛的问题，甚至可以通过加班去弥补效率的不足，但是高效的交付用户能够感知到的业务价值并不容易做到，上面这张图就说明了这一点。同样也并不代表可以持续的高效交付，因为从本源上没有办法保障永远用全局最优的组织和架构以及流程去对应，甚至没有机制去发现瓶颈问题。当然也并没有办法去回答业务成功问题，因为业务团队与产研团队距离过远，这种部门墙阻断了产研去思考和理解业务成功与自己产出的关系。

2 实现端到端可见的业务价值

所以笔者认为效能提升首先要做到的就是端到端可见的业务价值。从业务团队到产研团队有以下几个实施路径。首先是建立以业务价值流为视角的协作链路。以往多半是通过项目管理软件解决产研团队的协作问题，以一个产品或者团队为单位组织需求、缺陷、任务等等。在新的体系中需要将业务团队也纳入其中，并且拉通业务价值与产品研发需求、任务之间的关系，从而实现端到端透明可视。

在产研侧采纳大量自动化工具仍然是基础工作，除此之外需要将工具产出的数据能够链接到价值流上，并且尽量沉淀到数据平台。这里可以采用比较简单的评判方法，比如有多少百分比的工作是在线完成的，是否有统一的数据模型去积累数据。

在前面两步完成后，仍然要解决对齐业务、产品、技术团队目标的问题，比如业务诉求的优先级是什么，时间点是什么，其中的各环节瓶颈是什么，并且在过程中实时追踪。各环节负责人可以感知到异常事件和资源瓶颈，第一时间去着手解决，达到高效的目的。

第三步要做到持续高效，一定要基于前面积累的数据去量化分析，此时数据的魅力得到展现，越多的工作在线，分析会越准确。哪个团队在积累债务，哪个团队在积累资产，哪个团队是阻塞点，是调整架构还是调整组织分工，这种决策会更加有效率。

3 ALPD—新一代的精益产品开发方法

基于以上的分析，再结合了精益思想、云思想、以及架构设计思想等多方面，可以构建出来的一套方法体系。

这个图蓝色部分是本文关注的重点。其中分为三个部分，全链路数字化的精益协作，解决业务和产品技术协作问题。第二部分是领域驱动为核心的技术实践，解决日益复杂的架构问题。第三部分是云原生的工程实践，用这套工程实践去进一步释放云原生对每一个业务开发者的红利。

4 全链路的精益协作

首先全链路的精益协作。之所以称为全链路是在这个方法中将业务、产品、技术等多种角色全部纳入。最关键的是分层理念，分为业务、产品和技术三部分。分别对应业务和目标管理、需求和产品管理和团队交付视图。

在这个模型下，配合一系列高效率在线化工具，让尽可能多的工作在线完成，数据以价值流为核心串联和透明化，最终达成精益协作的目标。

5 领域为核心的技术实践

再来看领域为核心的技术实践。这里分为三个部分，分析、架构以及对应的实现。分别为业务引领的领域建模、领域驱动的微服务架构、以及契约导向的软件实现。

领域模型的设计是产品以及架构设计的核心，良好的设计可以轻松地解决技术团队的变更、测试、交付耦合问题，提升系统可测性和可运维性，并且通过一些防腐设计，降低技术债务对整个系统的影响。

6 云原生的工程实践

最后是云原生工程实践。这张图把工程实践分为了三个部分，最底层是不可变基础设施，中间是持续交付流水线，最上层是质量守护体系。

重点在中间红色部分，也就是GitOps Engine，用这个引擎来全面落地所谓的以应用为中心的IaC体系。笔者认为IaC的设计是开发者对云的运维界面和使用方法的重大重构。通过代码这种最符合开发者习惯的形式，叠加开放更多自定义能力，可以进一步释放云原生的技术红利。

作者 | 神秀

原文链接：http://click.aliyun.com/m/1000288975/

本文为阿里云原创内容，未经允许不得转载。

一、运维项目管理流程

运维项目管理流程

　　导语：没有任何一个项目能轻而易举的成功。但是你却可以努力去争取更大的成功率，靠的便是精心设计、并且行之有效的流程管理。下面我为你整理的运维项目管理流程，希望对你有所帮助！

　　1、生命周期与方法论

　　这是项目的纪律，为项目开展划出了清晰的界限，以保证项目进程。生命周期主要是协调相关项目，而方法论为项目进程提供了持续稳定的方式方法。

　　生命周期通常由项目的阶段组成（包括：开始、规划、执行/控制、完成），或由工作的重复周期构成。项目生命周期的细节一般都会随具体业务、项目、客户要求而改变。因此即使在同一个项目中，周期也会有多种可能的变化。对工作细致度、文件管理、项目交付、项目沟通的要求体现在生命周期标准和考核的方方面面。大项目的阶段一般更多更长，而小项目的阶段少，考核点也少。

　　与生命周期类似，项目方法也因项目而易，细节关注程度高。产品开发项目的方法经常涉及使用何种工具或系统，以及如何使用。信息技术项目的方法包括版本控制标准、技术文档管理、系统开发的各个方面。

　　项目方法往往不是由项目团队自行确定，而由公司为所有项目设定。采用与否，其实项目团队没有太多选择。公司管理层设定的方法本身代表权威，也是你作为项目领导获得项目控制权的一个途径。考虑项目方法某方面的作用时，始终要把握其对项目人员管理的效率，即在可能出现问题的地方争取正面效应。

　　2、项目定义

　　清晰的项目描述决定了你的项目控制能力，因为接下来所有工作都在描述范畴之内。不管你如何并为何要进行描述，你要对你的项目进行书面定义，让项目各方和项目组随时参考。

　　项目定义的形式和名称各式各样，包括：项目章程、提案、项目数据表、工作报告书、项目细则。这些名称的共同点在于，项目主管方和其他相关各方面从上而下地传达了他们对项目的期待。清晰的项目定义还包括以下方面：

　　项目目标陈述 （一小段文字，对项目交付成果、工期、预期成本或人力进行高层次的描述）

　　项目回报（包括商业案例或投资分析的回报）

　　使用中的信息或客户需求

　　对项目范围进行定义，列出所有预期的项目成果

　　成本和时间预算目标

　　重大困难和假设

　　描述该项目对其他项目的依赖

　　高风险、所需的新技术、项目中的重大问题

　　努力将尽可能多的具体信息，囊括在项目描述或章程中，并使其在项目主管方和相关方面获得认可，进而生效。

　　3、合同与采购管理

　　不管你在你的组织内有多大的影响力和权力，你对受雇于其他公司的项目成员的影响会比较小。虽然不一定普遍适用，但你可以尽量不将项目工作外包，这是提高项目控制力的一个技巧。

　　在考虑启用合同商或外部顾问之前，对整体采购流程进行重检。寻找有服务合同起草经验并可以帮助你的人。

　　建立成功的外包关系需要时间和精力，这些工作要及早着手。为了不误项目工期，你要及时做到所有细节到位，所有合同及时签订。你打算外包哪部分项目交付成果，对这部分工作的细化就是你实施项目控制的着手点。记录这些细化内容、评估和接收标准、所有相关要求、必要时间规划。项目定义信息一定要包括在合同之内，相关责任及早确定。和所有你考虑到的供应商讨论这些要求，这样你的项目期望才会在各方之间明晰。

　　4、项目规划、执行、跟踪

　　作为项目领导，通过制定有力的规划、跟踪、执行流程，你可以建立项目控制的基础。争取各方面的.支持，进而在项目内全面推广。

　　让项目组成员参与规划和跟踪活动，这可以争取大家的支持并提高积极性。睿智的项目领导往往大范围地鼓励参与，并通过流程汇聚大家的力量。当大家看到自己的努力以及对项目的贡献被肯定的时候，项目很快就从“他们的项目”变成“我们的项目”。当项目成员视项目工作为己任的时候，项目控制就会简单得多。较之于漠不关心的团队，此时的项目管理成功几率更大。运用项目管理流程也会鼓励项目成员的合作，这也让你的项目控制工作更加轻松。

　　5、变化管理

　　技术性项目中问题最集中的方面就是缺少对具体变化的管理控制。要解决这个问题，需要在项目的各方面启用有效的变化管理流程。

　　解决方法可以很简单，例如被项目团队、项目主办方、相关方认可的流程图。这提醒了项目人员，变化在被接受之前会进行细致地考察，并且提高了变化提案的门槛。

　　审查变化提案的时候，要注意该提案是否对变化有清晰到位的描述。如果变化提案的动因描述得不清不楚，该提案就要打回去，并且要求对变化所带来的益处进行定量评估。对于那些仅局限于技术解决方案的变化提案，要多打几个问号，因为提案人也许不能全面地判断问题。如果变化提案过多地关注问题的解决，而不注重实际问题，打回去并要求关注具体的业务形势。

　　最后，如果不接受某变化提案，一定要做到有理有据。而且，对项目时间、成本、精力等其他相关因素所受的影响，进行合理的估计。

　　6、风险管理

　　风险管理的流程能让你制定出全面的规划，找出潜在的麻烦，就风险问题的解决方法达成一致，根除严重的问题。

　　风险管理要做到事半功倍，就要与项目规划同时进行。进行项目工作分解安排时，注意对项目活动的不恰当理解；分配项目任务和开展评估时，寻找风险；资源匮乏或项目资源不足，或项目工作依赖于某一个人时，要知道风险的存在。分析项目工作将遇到的困难，鼓励所有参与规划的人在规划过程中，设想最坏的情况和潜在困难。

　　7、质量管理

　　质量管理提供了另一套搭建项目结构的流程，保证项目领导提出的工作要求一个不落地执行到位。项目质量的标准分两类：行业内实行的全球质量标准，公司或项目独有的质量标准。

　　如果你的公司实行或接受了质量标准，要注意该标准对你和你的团队有何要求。具体而言，这些标准会包括ISO 9000标准或六西格玛。进而确定质检清单、质控流程及相关要求，并将其与你的项目规划进行整合。项目必须遵守的书面步骤、报告、评估，对团队成员是强有力的推动，让大家步调一致。标准比你的临时要求更有效。

　　质量管理流程还能将项目要求与客户心声联系起来。不管你说什么，只要是在传递客户或用户的要求，你都要加以强调。市场调查、标杆分析、客户访谈都是评估和记录用户需求并确定项目要求价值的好工具。

　　8、问题管理

　　项目开展过程中问题的出现不可避免。在项目初期，在资源、工期、优先事项等其他方面为项目的问题管理确定流程。争取让团队支持及时发现、跟踪、解决问题的流程规定。建立跟踪流程，记录当前问题。问题记录信息包括：问题描述、问题特征或表现（用于沟通）、开始时间、责任人、目前状态、预计结束时间。

　　处理待解决问题的流程很简单，包括列出新问题的流程、定期复查待解决的问题、处理老问题的方法。对于没有太多组织管理权的项目领导而言，问题跟踪流程的力量在于让其把握了问题状态和进度的实时信息。一旦问题责任人承诺了问题解决的时限，你可以任意公布问题解决过程中的变数。不管问题责任人是本项目成员，还是其他项目或部门的成员，谁都不乐意随时将自己的大名置于人们质疑的目光中。问题清单的公开使得掌握该清单的人获得一定的影响力和控制力。

　　9、决策

　　项目管理时时有决策，快速得当的决策对于项目控制至关重要。即使项目领导掌握了控制权，完善的集体决策流程仍然裨益颇多，因为共同决策能获得更多内部支持，效果自然会更好。

　　项目工作中的决策绝非易事，项目组内纷繁复杂的观点让决策更加困难。项目各方认同的问题解决流程可以简化决策的过程，照顾各方要求。

　　尽早和你的项目组一起设立决策流程，或采用现有流程，或对现有流程做适当的修改。好的决策流程能为你的项目控制提供强有力的支持。该流程应该包括以下步骤：

　　清楚地陈述必须解决的问题。

　　吸纳所有需要参与决策或将会受该决策影响的成员参与决策过程，这样可以争取团队支持。

　　与项目组一道重审项目陈述，必要时进行修正，让每位成员获得一致认识。

　　针对决策标准（如：成本、时间、有效性、完整性、可行性），开展头脑风暴或讨论。选择那些与计划目标关联的、可执行、可供项目各方参考供决策之用的标准。

　　与项目组一道确定各标准的权重（所有标准的权重总和为100个百分点）。

　　设定决策的时限，规定用于调查、分析、讨论、最终决策的时间。

　　开展头脑风暴，在规定时间内尽可能多地产生决策想法。多方发展整个项目组都能接受的想法。

　　通过集体投票的方法进行筛选，至多确定六个考虑项进行具体分析。分析其与决策标准的契合度。

　　理性对待讨论中出现的异议。有必要的话，可增加决策标准。

　　根据评估和权重标准，将这些选项进行排序。

　　考虑采用首位选项的结果。如果没有异议，则结束讨论并开始实施决策。

　　将决策写入文件，并与团队成员及项目相关方面沟通决策结果。

　　10、信息管理

　　这项是非常关键的资源，如何管理值得仔细思考。有的项目使用网站和网络服务器，或信息管理系统，进行项目重要信息的存储。有的项目则使用群件来维护项目文件，并提供电子邮件等服务。

　　不管你用何种方式存储项目数据，要保证所有项目成员能随时获得所需信息。将最新的项目文件存储在方便查找的位置，进行清楚地标记，及时删除过时信息。

;

二、关于运维体系建设有没有什么好点的建议？

作为企业数字化转型的重要手段，IT运维效率的高低会直接影响到业务的正常运转，传统运维走向智能运维，其实就是运维数字化的过程。在智能运维建设过程中，先平台还是先场景，对于很多企业用户来说一直是个难题。如果用户对自身数据情况了解非常清晰，且希望打破数据孤岛以建立统一运维数据平台，那么可以优先选择平台建设；如果用户明确知道底层平台需要的能力，寄希望于能直接带来业务价值，可以优先选择场景建设。

例如一家城市商业银行，它目前最大的问题可能只是监控效能低下，误报漏报多，我们可以先从集中告警入手，利用算法去重降噪，再查看相关告警之间的有效告警场景，筛选出最可能影响业务问题的告警。在提高告警处理效率后，再通过分析告警的源头，进一步解决监控指标静态阈值设定不准确的问题，用智能异常检测替代之，从而根本上提升监控效能。这就是场景化方式导入智能运维的方法。

智能运维建设，可以根据用户实际运维情况，同步开展，循序渐进地进行建设。擎创根据以往经验，总结出三个原则六步走的最佳实践方案，我们首先可以通过集中监控智能化改造、指标监控智能化改造和日志异常检测（弥补监控手段不足）等提升实时性数据处理能力，再通过智能故障排查（根因分析和定位）、智能知识管理（知识图谱）和故障自愈提升数据事后分析和处理能力。

对于有些公司提出的，运维成熟度不高不敢考虑智能运维？

运维成熟度度高的的企业，可以按照数据处理能力的维度，统一规划、分层实施，实现从运维数据局部集中到跨域集中，也就是先建立运维大数据平台，通过加强数据治理、优化数据质量，而后再过渡到基于算法的统计分析乃至流式实时处理，构建多样化智能运维场景，逐层实现智能运维能力建设。

但这种方式并非放之四海而皆准，对于成熟度不高的企业，迫切需要解决的是实际运维问题，而智能运维这时应该能成为解决实际问题的工具，它可以根据客户当前的运维成熟度选择具体应用场景，按照不同的路线图进行建设，这才是智能运维的应有的能力。智能运维的本质就是逐步提升对运维数据的分析处理能力。

三、如何提高运维管理工作效率？

1。以终为始
以终为始是一种以结果为导向的思维方式，提示人们在做事情前要先明确做事情的最终目的，也就是“不忘初心，方得始终”。数据中心的终极目标是支持业务系统的不间断运行。在接手一个数据中心的运维任务之前，我们首先需要明确业务连续性目标，然后才能制定相应的运维策略。
2。以人为本
70%的数据中心故障是由人为造成的。与此同时，即使有最先进的监控系统，数据中心内无论主动保养操作，还是应急反应，都还需要依赖于人员的最终决策和操作。所以，配备足够的人员、有责任心、经验丰富的人员、对于数据中心的安全运行至关重要。
3。培训与学习
学习是一种修炼。有一种说法“最好的运维团队只不过是犯了足够的错误就修炼出来的”。数据中心基础设施牵涉到电力、暖通、弱电、消防、建筑等诸多专业，对于数据中心运维团队来说，需要学习的专业知识非常多。同时，每一个数据中心的配置和特定的操作流程都不完全相同。因此，培训与学习应该成为运维团队管理的一个重要组成部门。
4。建立管理体系
数据中心基础设施的运维管理工作的管理对象包括整个庞大的基础设施、运维团队、服务对象(IT部门或者IDC客户)，是一项系统性很强的工作，需要建立起一个管理体系。在整个运维管理系统体系中最重要的三个方面是设备保养体系、与所有相关部门的沟通机制、以及支持整个数据中心生命周期管理的财务预算体系。
5。规范操作流程
任何规范化的企业管理，都不可避免地需要引入流程，数据中心运维管理也不例外。完全基于个人经验和判断的操作，往往隐藏着重大的故障风险。数据中心就是要强化流程管理。任何重要的操作，必须严格按照流程执行。建立流程文化是数据中心规范化管理的一个重要环节。数据中心最重要的三类流程是标准操作流程(SOP)，维护保养操作流程(MOP)，和应急相应流程(EOP)。
6。动态管控
除了之前提到的管理体系和操作流程这些相对静态的工作以外，数据中心还需要进行动态的管控。近几年，IT负载的动态性表现得越来越明显。一方面，IT设备的增加速度比较快。新的业务系统上线可能导致IT负载在短期内有较大的增加。另一方面，企业大量采用虚拟化技术以后，可能会出现机房内各机柜的IT负载在一天范围内有较大变化的情况。基础设施运维团队需要针对这种IT负载的动态性作出相应的对策。
7。持续改善
大型数据中心的出现只是近几年的事情。当数据中心超过一定规模的时候，管理变得复杂，已经超越原来简单的依赖于少数运维人员的责任心的时代，需要的是完整的管理思想和方法论。国内数据中心基础设施运维体系的成熟度大致处于三个等级的状态：基础级、成长级、文化级。
8、用运维管理工具

实践已经证明，用一个优秀的运维管理系统可以大幅度的提升运维管理效率。可以理顺运维流程，并对每一个运维事件进行时间限制。督促运维工程师解决故障。另外，运维经理可以从PC或者移动端随时关注运维事件的进程。运维管理工具的知识库、配置管理、拓扑图、监控管理等功能，也是提升运维效率的有效功能。