互联网时代的网络自动化运维

互联网时代的网络自动化运维

互联网上有两大主要元素"内容和眼球"，"内容"是互联网公司(或称ICP)提供的网络服务，如网页、游戏、即时通信等，"眼球"则是借指海量的互联网用户。互联网公司的内容往往分布在多个或大或小的IDC中，越来越多的"眼球"在盯着ICP所提供的内容，互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。为了保障对内容的访问体验，互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务，并为业务模块间的通信建立IDC内部网络、城域网和广域网，同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。因此随着业务的增长，运维部门也显得愈发重要。他们经过这些年的积累，逐步形成了高效的运维体系。本文将结合国内互联网公司的经验，重点针对IT基础设施的新一代自动化运维体系展开讨论。

一、运维的三个阶段

● 第一个阶段：人人皆运维

在早期，一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模)，不一定有专门的运维人员或部门，运维的工作分担在各类岗位中。研发人员拥有服务器权限，自己维护和管理线上代码及业务。

● 第二个阶段：纵向自动化

随着业务量的增长，IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模)，开始有专门的运维人员，从事日常的安装维护工作，扮演"救火队员"，收告警，有运维规范，但运维主要还是为研发提供后置服务。

这个阶段已经开始逐步向流程化处理进行过渡，运维部门开始输出常见问题处理的清单，有了自己业务范围适用的自动化脚本，开始利用开源软件的拼装完成大部分的工作。

具体表现为：各产品线有自己编写的脚本，利用如SVN+puppet或chef来完成服务器的上线和配置管理等工作。

● 第三阶段：一切皆自动

在互联网化的大潮中，越来越多的黑马团队应运而生，都曾有过短时间内用户访问量翻N倍的经历。在流量爆发的过程中，ICP的互联网基础服务设施是否能够很好的跟进，直接决定了业务内容能否满足海量用户的并发访问。

与此同时，运维系统需要足够地完善、高效、流程化。谷歌、腾讯、百度和阿里等规模的公司内一般都有统一的运维团队，有一套或多套自动化运维系统可供参照，运维部门与开发部门会是相互平行的视角。并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。

图1大型互联网公司IT基础设施情况概览

二、BAT(百度、阿里、腾讯)运维系统的分析

国内的互联网公司百度、阿里、腾讯(以下简称：BAT)所提供的主要业务内容不同，IT架构不同，运维系统在发展过程中有不同的关注点。

1腾讯运维：基于ITIL的运维服务管理

预计到2015年腾讯在全国将拥有60万台服务器。随着2012年自动化部署实践的成功，目前正在进行自动化验收的工作。在网络设备方面，后续将实现从需求端开始的全自动化工作：设备清单自动生成->采购清单自动下发->端口连接关系、拓扑关系自动生成->配置自动下发->自动验收。整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。

图2腾讯基于ITIL的运维服务管理

2阿里运维系统：基于CMDB的基础设施管理+逻辑分层建模

CMDB(Configuration Management Database) 配置管理数据库(以下简称：CMDB)，将IT基础架构的所有组件存储为配置项，维护每个配置项的详细数据，维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库，CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时，CMDB与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中，CMDB常常被认为是构建其它ITIL流程的基础而优先考虑，ITIL项目的成败与是否成功建立CMDB有非常大的关系。

3百度自动化运维：部署+监控+业务系统+关联关系

百度主要面临的运维挑战包括：突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为，当服务器规模达到上万台时，运维视角需要转为以服务为粒度。万台并不等于"百台100";机器的运行状态，也不再代表业务的工作状态;运维部门为研发提供前置服务，服务与服务之间关系也随着集群的扩大逐渐复杂起来。

图3百度自动化运维技术框架

百度的自动化运维技术框架，划分为部署、监控、业务系统、关联关系四大部分，整个框架更多突出了业务与IT基础设施的融合，注重"关联关系"的联动。所谓关联关系，主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系，分别对应到任务调度、数据传输、资源定位的服务流程中，形成了多条服务链。

关联关系的运维与业务较强相关，需要有一套系统能够理清楚关系的全貌，从而在复杂的服务链上，定位运行所在的环节，并在发生故障时预估影响范围，及时定位并通知相应的部门。在这样的一套系统中，自动化监控系统非常重要。百度的技术监控框架，主要通过数据采集、服务探测、第三方进行信息收集，进行监控评估后交给数据处理和报警联动模块处理，通过API接口进行功能扩充(如图4所示)。

图4百度自动化技术监控框架

其实无论是BAT等互联网企业还是其他行业的企业，在IT建设中都会遵循IT基础架构库(ITIL)或ISO20000服务管理的最佳实践，采用自动化IT管理解决方案以实现重要的业务目标，如减少服务中断、降低运营成本、提高IT效率等等。随着ISO20000、ITIL v30的发布和推广，两者已经成为事实上的某种标准。在当今企业IT管理领域，对两个标准有着很迫切的需求。特别是ISO20000的认证要求，已经成为企业越来越普遍的需求 。ITIL v30包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理，相关方案往往覆盖了多个领域和多个产品，规划实施和工具的选择会比较纠结。如果选择开源的工具，从CMDB开始就会遇到很多的开发工作，对于很多注重成本收益比的企业，可以参考，但由于无法保证性能与效果并不一定适用。因此，成熟的商业方案会是更好的选择。

最新的iMC V7版本，围绕资源、用户、业务三个维度进行创新，发布了SOM服务运维管理(基于ISO20000、ITIL标准)等组件，增加了对服务器的管理，能很好的满足更多互联网化的场景需求。

通常认为，一个高效、好用的配置管理数据库一般需要满足6条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。企业IT基础架构的元素类型、管理数据的类型往往有较多种，如网络设备、服务器、虚拟机等，因此对于多种信息的存储需要有合适的联合的方法。虽然 iMC智能管理平台在网络设备、服务器设备等方面已经能够较好的的满足，但是随着服务器虚拟化技术的发展，虚拟机正越来越多的成为IT基础架构的一大元素。因此，针对这一需求华三通信基于CAS CVM虚拟化管理系统，对服务器CPU、内存、磁盘I/O、网络I/O等更细节的重要资源以及虚拟机资源进行全面的管理。与BAT不同，华三通信的网管软件面向全行业，目前虽然没有对域名管理等特殊资源的'管理，但是能够通过API接口等方式与特有系统进行联动，进而满足定制化运维的需求，尤其是在互联网化的场景中，针对不同的业务需求，可以实现很多定制化的对接需求，例如，iMC+WSM组件与国内某大互联网公司自有Portal系统进行了对接，打通了iMC工具与用户自有运维平台，很好的实现了架构融和。另外，与阿里的逻辑分层建模相似，H3C "iMC+CAS"软件体系在上层也做了很多的逻辑抽象、分层，形成了诸多的模块，也即是大家看到的各种组件。

三、网络自动化运维体系

"哪怕是一个只有基础技术能力的陌生人，也能做专业的IT运维;哪怕是一个只有初中学历的运维人员，也能够带队完成中小型机房节点的建设，并负责数百至上千台服务器的维护管理工作"--这是一些公司对自己IT运行维护水平的一个整体评价。看似有些夸大的嫌疑，但实际上依托于强大的IT运维系统，国内已经有不少互联网公司能够达到或者接近这一标准。

这些企业都经历了运维发展过程中的各个阶段，运维部门曾经也是被动的、孤立的、分散的"救火队"式的团队，在后来的发展过程中，IT系统架构逐渐走向标准化、模型化，运维部门建立了完整的设备、系统资源管理数据库和知识库，包括所有硬件的配置情况、所有软件的参数配置，购买日期、维修记录，运维风险看板等等，通过网管软件，进行系统远程自动化监控。运维过程中系统会收集所有的问题、事件、变更、服务级别等信息并录入管理系统，不断完善进而形成一套趋向自动化的运作支撑机制。按照云计算的体系架构，在这样一套系统中，主要的IT资源包括计算、存储、网络资源，近些年随着网络设备厂商的推动，网络设备管理方面的自动化技术也得到十足的发展。

总结来看，一个企业在进行互联网化的建设初期，就需要考虑到随着用户访问量的增加，资源如何进行扩展。具体可以细化为规划、建设、管理、监控、运维五个方面。

1规划模型化

为了确保后续业务能够平滑扩容，网管系统能够顺利跟进，互联网企业一般在早期整体系统架构设计时便充分考虑到标准化、模型化，新增业务资源就好比点快餐，随需随取。

标准化：一是采用标准协议和技术搭建，扩展性好，使用的产品较统一，便于管理;二是采用数据中心级设备，保证可靠性、灵活性，充分考虑业务系统对低时延的要求。

模型化：基于业务需求设计网络架构模型，验证后形成基线，可批量复制，统一管理，也适宜通过自动化提高部署效率、网管效率。

图5常见互联网IDC架构

2建设自动化

互联网IT基础设施具备批量复制能力之后，可以通过自动化技术，提高上线效率。在新节点建设过程中，3～5人的小型团队即可完成机房上线工作。例如某互联网公司某次针对海外紧急业务需求，一共派遣了2名工程师到现场进行设备安装部署和基本配置，而后通过互联网链路，设备从总部管理系统中自动获取配置和设备版本，下载业务系统，完成设备安装到机房上线不超过1周时间。

要达到自动化运维的目标，建设过程中需要重点考虑批量复制和自动化上线两个方面(如图6所示)。

批量复制：根据业务需要，梳理技术关注点，设计网络模型，进行充分测试和试点，输出软、硬件配置模板，进而可进行批量部署。

自动化上线：充分利用TR069、Autoconfig等技术，采用零配置功能批量自动化上线设备，效率能够得到成倍提升。

图6批量配置与自动化上线

○ Autoconfig与TR069的主要有三个区别：

○ Autoconfig适用于零配置部署，后续一般需要专门的网管系统;TR069是一套完整的管理方案，不仅在初始零配置时有用，后续还可以一直对设备进行监控和配置管理、软件升级等。

○ Autoconfig使用DHCP与TFTP--简单，TR069零配置使用DHCP与>

ITSM，即：IT服务管理（IT service management 简写ITSM），是IT团队向其最终用户提供:设计、交付、管理和改善等所有IT服务的过程。ITSM致力于使IT流程和服务与业务目标保持一致，从而帮助组织更好地发展。

ITSM的核心概念是认为IT应该作为服务交付。ITSM最常见的场景是请求新硬件，例如：笔记本电脑。假设您要申请一台笔记本电脑，您需要在指定的地方提交请求，填写相关信息的工单，之后就开始对应的工作流程（这种工作流程是可重复的）。然后，故障单将落在IT团队的队列中，在故障单的队列中，传入的请求会根据重要性进行排序和处理。

人们经常将ITSM误解为基本的IT支持。相反，ITSM团队负责监督各种工作场所技术，从便携式计算机到服务器，再到关键业务软件应用程序。

IT行业中存在一个共同的思路，即正确的ITSM方法应按以下顺序执行三个步骤：

1）构建和实施IT技术。

2）引入并执行正确的流程。

3）人们可以学习技术并遵守流程。

团队是第一位的。IT团队应该不断学习和改进，以促进团队改善工作方式。IT团队无需回答分层报告结构或严格流程所强加的规则，而是可以就采用SLA和要实施的软件等方面做出明智的决策。由于IT团队可以实现生产力和数字化转型，因此强大的IT团队对于强大的组织至关重要。这样的团队是ITSM流程和技术的中心。

另外，软件和技术应支持团队的实践并扩大其影响。优秀的ITSM软件可通过跨团队协作帮助IT人员接触组织中的其他人员。它赋予最终用户权力，并使平凡的工作自动化，因此每个人都有更多时间专注于对他们最重要的事情。当ITSM的流程运转良好时，一切都非常顺利，但如果流程被技术阻碍，一切就会变得复杂。ITSM的流程越顺利，越能反映出IT团队的辛勤工作。

一款优秀的ITSM工具能让企业组织事半功倍。ITSM工具的选择上，并不是越贵越好，企业组织需要根据自己的需求和特点，选择适合自己的工具。ManageEngine ServiceDesk Plus 服务台，可根据不同情况配置不同的服务台功能，每个企业都可以选择最适合自己的功能。

参考文献：ITSM初学者指南

学习ITIL的好处：减少重复性的劳动、提高企业效率等。建议找一家培训机构跟着学习。

选择培训机构要看师资问题。师资的话老师都有各种背景，大家需要甄别，有些比较诚实，有些培训机构会夸大其词。

而艾威培训这家培训机构的师资就挺好的。艾威培训是PeopleCart认证中心，也是美国PMI 2003年授权PMP培训机构(PMI REP1887)，直接与厂商合作，培训有保障。

我建议，重新思考 “服务台（Service Desk）”带来的价值，重新定义其职责和能力的要求。

以往，更多的是强调“服务台（Service Desk）”是业务用户与信息化部门之间的“单一联系点”，是对业务用户请求的被动响应和记录。

但，“服务台（Service Desk）”不应该只是一个被动的响应岗位。

服务台是一个“单一联系点”，这没有发生改变，但这不是问题的核心。事实上，是不是百分之百的“单一联系点”，也不是苛求和评价服务台成功与否的标准。

原则是“关注价值”，因此服务台的人员应充分的了解客户和用户对每一项服务的价值预期。

信息化工作既要关注客户体验，也要重视用户体验。今天，用户对信息化的期望在不断提高，这意味着提高用户满意度变得比以往越来越困难。因此， 更需要主动的管理用户体验（UX），而服务台正在改变我们管理用户体验的方式。服务台的价值在于了解用户整体体验的每一个部分。

更可怕的是，如果过分强调“服务台”的响应性工作，那么就会让我们对服务台的测量偏重于“有多少”，“有多快”，而这真的是衡量服务台成功与否的重要指标吗？如果“服务台”的人员没有正确的心态，则极有可能产生出糟糕的用户体验（UX）。

随着手机端等移动技术的普及，服务台越来越有能力通过获得用户体验（UX）来贡献对价值的分析。这包括主动的了解用户对系统功能和性能的看法，也包括通过用户的感受（UX）来测量服务支持工作（包括服务台和其他技术支撑组）的绩效。

通过持续的用户反馈机制，创建一个积极的良性反馈循环机制。

以上部分，仅代表我的观点，仅供参考。

服务台实践的目的是获取故障的解决和服务的请求。服务台还应该是服务提供商（信息化部门）及其所有用户的单一联系点。

服务台为用户报告问题、查询和请求提供了清晰的路径，并让他们（用户）能够确认、分类、拥有和采取行动。管理和交付的方式（服务台的形式）可能会有所不同，从轮班工作的实际团队到虚拟连接的分布式组合，或者自动化技术和机器人。无论模式如何，服务台的职责和价值都保持不变。

由于信息化部门的规模不同，从4-5人到几百人不等。服务台究竟应该采用哪一种形式，以及要解决的问题都不相同。

如果信息化部门的整体人数不多，则可能不需要复杂的流程，只需要有“记录”能够跟踪和追溯。而如果信息化部门的人数较多，则清晰的流程更有助于提高效率，并且固化为闭环。

因此，我们将几种不同形式的服务台及优缺点做了如下提炼，仅代表我的观点，仅供参考。

随着自动化程度的提高和技术债务的逐步消除，服务台的重点是为“人员和业务”提供支持，而不仅仅是技术问题。服务台越来越多地被用来安排、解释和协调各种事务，而不仅仅是用来修复损坏的技术，服务台已经成为任何服务运营的重要组成部分。

业务用户致电给服务台，所需要获得的支持涵盖了信息化的方方面面，这不止是技术方面的支持，也包括与信息化有关的业务工作。因此，“服务台（Service Desk）”人员则需要了解本组织中更广泛的业务背景，包括业务流程和业务约束，并且需要更全面的了解各个应用系统的知识（专业技术岗位可能更偏重于某个领域或系统的技能）。

例如:在企业中，由于业务的约束而导致业务人员无法下“订单”，这对于业务人员来说究竟是技术问题，还是业务的约束。在医院中，“无法退费”是由于技术导致的，还是由于业务流程的原因。

这就决定了服务台能力的特殊性，要求服务台对组织业务的全面了解。因此，出色的“服务台（Service Desk）”都是熟知组织业务的人员。

因此，服务台人员与专业技术人员的不同：

简单说，专业技术岗位可能需要“一样精”，但服务台可能更需要“百样通”。

需要理解的一个关键点是，无论服务台及其人员的效率有多高，总是会存在需要升级的问题，以及其他团队的支持。支持和开发团队需要与服务台密切合作，向用户和客户展示并提供“联合起来”的方法。

“服务台（Service Desk）”不可能懂得所有的技术，这就需要清晰的“协作（Collaboration）”机制，包括：专业技术岗位和供应商的配合，如果信息化部门的人数较多，则需要清晰的流程。

原则是“协作和透明”，服务台不同于专业技术岗位，各个技术岗位和供应商应积极与服务台协作并共享信息。

服务台可能不需要高技术性，尽管有些是。然而，即使服务台相当简单，仍然在服务交付中起着至关重要的作用，并且必须得到对等组的积极支持。还必须了解服务台对用户体验和用户对服务提供商的感受有重大影响。

“服务台（Service Desk）”与运维支撑组、开发团队之间，需要紧密配合，“协作（Collaboration）”的原则至关重要。

除了，清晰的流程，以及积极的态度以外，通过情报共享和信息的可视化，能够有效的促进协作。因为“服务台（Service Desk）”人员可能不是网络或系统的技术专家。因此，“服务台（Service Desk）”更需要通过监测系统，全面的了解系统运行的性能。

也许，专业的技术岗位需要更专业的技术工具进行排错和部署。但“服务台（Service Desk）”需要更全面的视角，了解整体信息系统的运行状态。这既有助于更及时的了解用户的使用体验，也有助于协调各个技术岗位的支持工作。

让相互协作的人们通过情报共享、信息的可视化，大家都能够共同的看到，得知，了解变化和现状，才能促进他们之间的协作。

良好服务台的另一个关键方面是它对更广泛的业务环境、业务流程和用户的实际理解。服务台的价值不是简单的通过执行“故障记录”，这样的事务性工作来增值。而是在处理此类 *** 作时，能够理解这些行动的 业务背景 来增值。服务台应是服务提供商与其用户之间善解人意的信息联络人。

服务台不是简单的进行流水账一样的“故障记录”，重要的是这些支持工作的业务背景，这就需要服务台在这个方面具有更加广泛的业务了解。包括：每一个服务请求的“症状”和“原因”，因为有些“症状”和“原因”具有业务背景。此外，还包括不同服务请求的业务时段，紧急度，影响度，支持的结果应该找哪一位干系人来验证。

随着自动化程度的提高，人工智能、机器人过程自动化（RPA）和聊天机器人的出现，服务台正在通过在线门户和移动应用程序直接提供更多的自助记录和解决方案。对服务台的影响是减少了电话联系，减少了低级别的工作，以及在需要个人联系时更注重卓越的客户体验的能力。

“自动化（Automation）”为服务台带来了什么。通过AI、机器人等技术，提供了“自助记录（self-service logging）”和“解决办法（resolution）”。带来以下好处：

但是，值得注意的是“自动化（Automation）”同样是需要投入精力去维护的。

服务台提供各种通道供访问。这些包括：

1 电话呼叫，可以包括专业技术，如交互式语音响应（IVR）、电话会议、语音识别等

2 服务门户和移动应用程序，由服务和请求目录以及知识库支持

聊天，通过在线聊天和聊天机器人

3 用于记录和更新的电子邮件，以及用于后续调查和确认的电子邮件。非结构化的电子邮件可 能难以处理，但基于人工智能和机器学习的新兴技术正在开始解决这个问题

4 无需事先约定的服务台在某些领域变得越来越普遍，例如高等教育，那里的活动高峰需要体育活动。

5 文本和社交媒体消息，对于重大故障的通知和联系特定的利益干系人群体很有用，但也可用于允许用户请求支持。

6 公共和企业社交媒体和讨论论坛，用于联系服务提供商和获得同行的支持。

一些服务台有一个有限的支持窗口，可以提供服务覆盖（例如，0800–2000，周一 – 周五）。因此，工作人员应按轮班模式工作，以提供一致的支持水平。

在某些情况下，服务台是一个有形的团队，在一个地点工作。集中服务台需要技术支持，例如：

智能电话系统，包括计算机电话集成、IVR和自动呼叫分配

用于路由和升级的工作流系统

劳动力管理和资源规划系统

知识库

通话录音和质量控制

远程访问工具

仪表盘和监控工具

配置管理系统。

在其他情况下，虚拟服务台允许人员在地理位置分散的多个位置工作。虚拟服务台需要更复杂的支持技术，包括更复杂的路由和升级；这些解决方案通常基于云。

服务台工作人员需要跨多个广泛的技术和业务领域的培训和能力。特别是，他们需要展示出色的客户服务技能，例如同理心、故障分析和优先级、有效的沟通和情商。关键技能是能够充分理解和诊断业务优先级方面的特定事件，并使用可用的技能、知识、人员和流程采取适当的措施来解决此问题。

图533显示了服务台对服务价值链的贡献，涉及了除“计划（Plan）”以外的所有价值链活动：

对服务台的活动持续进行监测和评估，以支持持续改进、调整和创造价值。服务台收集用户的反馈，以此支持持续改进。

持续改进需要来自服务台的数据，包括：一段时间内的症状分布、知识库的质量、用户反馈。

服务台是与用户之间的非战略层面和运营层面的主要“互动”渠道。

服务台应获得用户体验和感受（UX），包括：业务用户对系统功能和系统性能的看法，以及日常支持的满意度。 服务台不仅是被动的响应服务请求，也是与业务用户“互动”的主要渠道。因此，“服务台（Service Desk）”是改善和加强服务关系的关键能力和重要岗位，是提高最终用户体验（UX）的关键因素之一。

服务台提供了一个与用户交流新服务和变更服务的渠道。服务台员工参与发布计划、测试和早期生命支持。

新功能和新系统的投入使用，往往意味着服务台的大量支持工作。

服务台工作人员可以参与获取用于满足服务请求和解决故障的服务组件。

良好的服务台和服务请求流程，有助于更好的确认和管理信息化资产。这包括申领和报废终端及办公软件，IP地址的分配。

服务台是管理故障和服务请求的协调点。

服务台是故障和服务请求流程执行的督促和协调点。

“服务台（Service Desk）”是业务用户和信息化部门之间的重要互动点，也是服务请求管理、问题管理、甚至是用户抱怨的起点和终点。因此，“服务台（Service Desk）”也是了解所有岗位参与情况，每一件工作进度情况的汇总点。

今天，用户对信息化的期望比以往任何时候都要高。这意味着现在让业务客户的满意度提高变得越来越困难。这就需要一个总揽全局的视角，能够更主动的了解用户整体体验（UX）的每一个部分。

随着ITIL 4的普及，许多人都开始从讨论“过程”转向讨论“实践”和“能力”。“过程”转为“实践”我会在另一篇文章中描述。至于能力，我一直有一个疑问，什么是“能力”，问了一位大咖，大咖说“能力是IT服务最基本的颗粒，但是ITIL里面没有给出名词解释。[小人摊手jpg]”。这可是被BA（业务架构）心脏的元素，没有它BA玩不转，ITIL或者ITSM估计也歇菜的东西，居然没有定义？！

最近刚好在学些BA的过程中，觉得BA的“客户主张——价值流——能力”的这一套模型，也许能纾尊降贵拯救一下似乎难以给出实际案例的ITIL 4的价值流。所以我打算参考BA学科中相关内容，看能否给出一个定义。

翻了一下故纸堆，找出关于能力的一堆定义：

●    TOGAF 91 ：能力是一个组织、个人或系统所拥有的才能（ability）。能力通常用一般的和高级的术语来表达，并且通常需要组织、人员、过程和技术的组合来实现。例如，营销、客户联络或对外电话营销。

●    BIZBOK 41 ：能力是企业为实现特定目的或结果而可能拥有或交换的特定才能。

●    ArchiMate31 ：能力代表一个活动结构元素(如组织、个人或系统)所拥有的才能。

●    Bas van Gils （战略联盟） ： CAPBILITY= CAPacity × ABILITY 。

- ABILITY指的是某一方面的技能和熟练程度。需要注意的是，ABILITY能力是一个相对的术语：一个行动者(人、机器、计算机)可能比其他人的熟练程度更高。通过(正式的)训练和实践，其水平可以提高。

- CAPacity指的是行动者(人、机器、计算机)可以利用他们的技能来实现一个目标的程度。向可用池（available pool）释放/添加资源会影响容量。

●    Bas van Gils  :业务能力是一个实体——个人或组织——在特定业务执行环境中创造或交付某种现实世界效果(结果)的才能。如果环境改变，昨天的能力可能会消失。即使你昨天做了某事是事实，但并不意味着你明天也能做这件事。只有当能力实现所需的所有资源都可用时，能力才存在。没有资源——没有能力；能力/知识/技能均不足以具备该能力。如果你采用了外包方式，则你失去了该能力。

●    Richard Hillier ：业务能力是指开展业务活动的才能，这种才能认为是成功的必要条件，需要具体管理。

●    Bain &company ：能力，将人员、流程、信息和技术结合起来，强化战略要素，使组织能够在竞争中脱颖而出。

参考以上，我尝试给出了 在ITIL语境下“能力”的定义：能力是流程、信息和技术、组织和人员以及合作伙伴和供应商的结合，可以使组织实现指定的结果。

简单来说就是借助资源（PPT）执行任务或活动，达成所需要结果（例如SLA）。另外，CAPBILITY= CAPacity x ABILITY，这条公式给我很大启发。会独立维修电脑是一项才能，但是能维护所有桌面终端则是一项能力。当一项能力被反复经常使用的话，其熟练程度（或者说性能水平）理应变得更高。想象一下在双十一当天，淘宝后台所承受的压力。这也是如Bain&company定义的一样，能力的熟练程度、丰富程度使得企业具有一竞争优势，甚至成为其核心竞争力。

至于 才能（ability），可以定义为：在没有任何帮助或支持下，个人或系统或组织可以出色完成的一项任务。

至于能力怎么使用，我翻译了一个图，供大家做参考：

     图 1：使用业务架构进行战略、业务架构和运营模型对齐图

在识别能力时，我们需要关注什么？

首先要强调的是 能力定义的是“what”，而不是“how” 。在定义能力的过程中，需要抛开技术，抛开系统，只关注当下有什么是必须做的，以满足现在和未来的挑战。值得一提的是，有种说法是“职能”因为各家都有，并非独有的“能力”，所以不应纳入能力范畴。而我个人认为即使从这个角度考虑，各个组织在各个职能内，也会有各自的特色，可能有的是围绕“稳”做文章，有的是围绕“敏”去挖潜，因此类似战略管理、客户关系管理、产品和服务部署、企业支撑（这里IT管理就派上用场了）、财务管理、营销和销售等都应该是组织的能力。

其次， 能力应该是相对稳定的 ，即使组织有变革，也不应有太大的波动。除非有重大的业务模式转型，才会对能力有影响。从这点看去，有点“第一性原理”的味道。看“能力”要从“静态”的视角观察，而看“价值流”则要从“动态”的角度去审视。因为后者由各个阶段/步骤组成，在流动当中，需要随需而变。

再次， 能力的提供未必只局限于某个BU ，有些时候，我们甚至需要跨组织来获取。例如作为国内大部分的IT组织，往往不具备财务管理能力甚至人事管理能力。需要获得或构建这些能力，只能假手于人。

第四，由于价值流和价值主张以及利益相关者的紧密联系，而能力是为价值流服务的，所以在定义能力的时候，除了获得专家意见之外，还应 抓紧机会向利益相关者宣贯 ，使其能进一步了解，获得其支持。

第五， 能力可以考虑分层 ，具体见微信ID：筱筱乘风所翻译来自BIZBOK的能力图。该图的将能力分为三级。我们可以具体关注支持能力一层，并考虑将ITIL相关实践作为不同层级的能力放于其中。

图 2：BIZBOK能力分级图

最后，能力的集合我们可以用一张能力地图进行展现，而能力地图不单可以与价值流映射，更可以在最高的层面为战略提供支撑。因此务必 将制定战略的相关方也请进能力定义团队中 。

而在构建能力时，我们还需要关注：

1、确定新战略和新竞争需要哪些能力

2、从技能和能力方面找出与当前业务所需能力的差距

3、需要哪些合作伙伴、供应商、知识、技术、系统和培训来发展能力

4、了解将IT能力转化为业务能力或业务功能需要什么，或者如何利用它提升业务能力，并与战略对齐。

     对于能力，我们可以考虑以如下模板进行记录：

·        能力:

·        名称:

·        声明:

·        理由:

·        所需技能:

·        所需容量:

·        文献参考及标准:

·        内部（可用）资源池:

·        外部（可用）资源池:

·        所有者:

·        工作流状态: 

·        版本:

·        来源:

注：以上文章内容，参考：

1、   文章来自LeanIX

2、   文章来自Dragon 1

3、白皮书：Aligning Operating Models with Strategy Using businessarchitecture

4、  微信ID：筱筱乘风的PPT

以上就是关于互联网时代的网络自动化运维全部的内容，包括:互联网时代的网络自动化运维、ITIL的目标是什么、ITSM系统全称是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！