IT Operations(IT 运营），运维的更价值化认识

一直想努力向别人（甚至包括从事运维的人）解释清楚什么是运维，发现很难！

6月20号，在InfoQ高效运维群里面，对运维创业作了一次激烈的讨论，很天然地，过程当中不可避免的谈到运维苦逼和运维没法产品化的问题，这是一些运维须要说服本身，证实本身价值的问题。对于本人来讲，运维的价值无可置疑，只要咱们运维人能自我认识突破，更体系化的站在业务角度看待运维价值问题，那咱们就不是一个苦逼的成本部门。此时我天然的想到了【IT运营】，它带来的视界会更加开阔，可以帮助更好的从新认识运维。

1、运维是什么

运维从IT软件工程的阶段论来讲，通常分为用户需求阶段、软件开发实现、软件测试和软件维护几个阶段。所以不少人就把运维粗暴地解读为运行+维护。不过庆幸的是，运维人本身已经认为咱们不是简单的维护角色了。维护的角色是一种职能化的表述，意味着你是邮件工程师、服务器工程师、网络工程师等等。

其实运维对应的英语单词是Operations，而不是Maintenance。Operations有“操做、运营”的意思，通常会和IT一块儿出现，称之为IT Operations（IT运营），也就是咱们如今说的运维，Maintenance只是一个维护的定位，早已退化。

2、什么是IT运营（运维）

显然从阶段论的角度来看运维，没法归纳运维的全貌，因此本身一直和别人说运维就是IT运营，那什么是IT运营？如下是我作了一个产品通路的分解，而后分解出一条技术运营的主线。

当用户的需求被识别出来以后，这个时候必然会产生两种需求:一类是用户需求的功能性描述，一类是用户产品的技术实现描述。接下来从不一样的需求出发，此时会产生产品运营和技术运营的要求。技术运营必定是基于技术产品和业务产品中的技术部分，包括基础平台产品（网络、机房、服务器、DNS）、应用产品（application、协议）。为了确保它们可以知足业务的目标，运维须要提供多种保障措施，好比说构建自动化平台（配置管理、调度平台、IT产品管理平台）和技术产品数据运营平台(监控、应用性能管理、能力管理等等)。以上的分解思路，能够解释运维是否须要构建大数据平台，且和产品大数据平台的差别点与边界。

IT运营和产品运营不少落脚点是相似的，也是一种持续改进和闭环的策略，讲产品的生命周期管理和优化，产品说，我是为了提供给用户更好的服务或者价值；技术运营（即运维）说，我也是为了提供给用户更好的服务或者价值。真的如此么？那咱们在看看什么是用户的价值。

对于用户来讲，一种更低成本更高质量的服务才是他们须要的，所以把用户价值分红多个维度的描述，有产品功能和特性需求侧的，有用户体验侧的，有成本方面的（如上图）。由此也能够看出不少的用户价值诉求都会转换成对软件产品技术的需求，这类技术需求实现以后，须要运营手段来保证和持续改进。

在业务互联网化的今天，用户得到同质服务的触点变得愈来愈多，如何让自家的业务脱颖而出，一方面考验产品运营能力，另一个方面更是在考验技术运营的能力。在小米推出米聊后不久，腾讯就迅速推出微信，这是腾讯后台技术架构对业务的敏捷支持；在有相同功能的两个互联网产品选择下，你必定会选择那个访问快（速度），而且可用性高，易用性好的产品，特别是速度。在过去的工做中，能够列举不少IT运营能力不足而影响业务发展的例子。

Gartner早期还有一个关于IT价值的模型描述，会有稍稍不一样，列出供参考：

在这个模型图里面，关于IT产生的价值指标也很是明确，彻底的导向了业务价值，好比说经济性、质量、敏捷性、客户满意度和商业贡献度等等。

• 经济性。包含了投入成本、产出效率和生产率。

• 质量。包含了可用性、相应时间，交易速度等等。

• 敏捷性。IT对于业务变化的适应性和调整的速率，一个好的IT业务架构应该可以适应业务的变化，从而快速对市场相应决策。

• 客户满意度。能够各个渠道收集客户的意见，好比说appstore，产品论坛，客服，CRM渠道等等。

• 商业贡献度。提供更多的商业价值，好比说更大的市场份额，更多的用户获取，更高的市场占有率。

说这么多，是想改变你们对运维的一个错误认识----运维是成本部门，而非收益部门。在一个分散式的x86的复杂架构环境中，若是没有运维部门的统一规划和管理，等于一个乐队少了指挥，其技术建设、管理和运营确定会陷入混乱，最终影响的是使用咱们产品的用户。

3、什么是IT运营管理

IT运营管理，IT Operations Management（ITOM），其中最经典的描述是还来自于Gartner的经典解释。Gartner从一个更全局、更宏观的视野来分析了ITOM的组成及其趋势。Gartner每一年会发布多个领域的hype cycle的报告，hype clye是一种分析方法，把一个领域涉及的技术从诞生、发展、成熟等多个过程在一张图中描述出来，而且预估它将来会爆发的时间表。从图中的组成部分，能够看到IT运营的全貌，会涉及到ITOM的多个方面，2013年的报告内容以下（来自于Chuck Henry的一篇PPT分享)。

横坐标不解释了，你们能够本身查查英语单词，加深一下印象，另外不一样的形状标示着将来爆发的时间周期。好比说ITIL处于幻灭期，它的再次爆发至少要5到10年。

从这个PPT页面中，你能够看到不少个方向，好比说DevOps、ITIL、APM、IT能力管理、配置管理、CMDB等等，你能说它们和你运维无关么？其实作过互联网运维的人都或多或少的知道上面图形中术语的意思，由于不少都和咱们平常的工做相关，有些是在执行ITIL的过程当中接触到的，好比说IT service catalog、CMDB；有些是在DevOps实践中接触到的，好比Application Release Automation，固然全局的DevOps会包含更多哈；有些是咱们在作数据分析的时候接触到的，好比说Service-Level Reporting tool，Capacity Planning and Management。

这么多方向如要落地实施，必定是运维部门主导建设的，或许你们已经这么干了，此时你难道还说运维就是一个苦逼打杂的，运维没有价值的？ITOM能够帮咱们更全面的去看待运维。不过切忌照搬哈。

4、IT运营的目标衡量

IT运营对象是技术产品，它的特性决定了IT运营的要求和策略的不一样，概括总结有以下：

一、功能性

软件提供的功能是否知足了用户须要？这个地方还有不少个维度能够衡量里面有是否提供了正确的功能（适合性）、适合用户需求的功能（正确性）、安全的功能（安全性）等等。

二、可靠性

软件的运行是否可靠的？能够经过可用性指标来衡量，可用性的指标在上一篇文章结合故障有谈到过如何计算。典型的两个很衡量维度就是容错性和可恢复性。前者将对故障的容错处理能力（要么不出故障），后者对出现故障以后的恢复能力（出故障后，要么快速恢复）。

三、易用性

易用性是一种产品化的能力，能够体如今产品是否可以被用户快速理解的，可以易于使用的，且操做友好的。不要让用户拿到一个产品以后，本身捉摸该如何操做，对于某个核心功能来讲，操做的深度很深。操做友好就体现着相同的产品功能下，设计的不一样，给用户带来的操做复杂度是彻底不一样的。同是红包功能，微信红包、QQ红包、支付宝红包给用户带来的易用性彻底不一样。

四、效率

体如今面向用户的产品交付速度和内部IT支撑服务的响应速度。前者效率体现者用户等待新功能/新特性须要付出的时间成本；后者体如今内部IT支持须要付出的时间成本，在业务量出现增加的状况下，咱们须要多少时间可以把支撑的资源提供到位。效率维度基本上都是DevOps自动化解决方案的范畴。

五、可维护性

可监控性。对于一个复杂架构，是否具有可监控的能力，它是一种可以帮助你快速发现故障，快速定位故障直至恢复故障的能力。

可变动性。架构的变动能力很是重要，若是一个架构引入变动就须要对用户服务产生中断或者影响的话，说明这个架构是有不足的或者变动方案设计是不足的。

容错性。是一种容错的能力，特别是一些非指望错误的容错能力，这个在前期的设计准则中须要考虑到一些不可靠性的设定，好比说网络不可靠、硬件不可靠等等。同时对于一些未知的错误，提供自动的降级服务或者容错服务能力。

如何实现可监控性？我的以为首先要有一个监控平台，其次监控平台须要有采集一切数据的能力，且能自动分析数据的关联，最后才是经过数据实现端到端的监控能力。

可变动性和容错性，是在架构设计和实现的阶段，就要考虑后续对运维友好，设计和实现一个弹性可扩展服务架构对运维来讲很是重要，数据解耦和服务解耦是优先要考虑的原则。举个例子，对于一个用户注册的功能来讲，能够有URI和域名两种实现方案来区分服务，显然前者的区分对运维不友好，当由于容量的问题，要实现注册核心业务分离的时候，须要在七层代理服务上按照URI进行服务转发，而采用域名的解决方案，则简单许多，DNS指向修改便可。

六、可移植性

是IT产品的可迁移性，一则就涉及到IT技术产品的选型问题，当你选择的IT技术产品开源和公共化程度越高，迁移的成本就越低。公有云服务不少都是基于开源协议的实现，就是一个典型的例子，确保用户的技术产品可以无缝切入到公有云；

其次要考虑云端的服务迁移能力，包含了公有云之间的迁移能力（显然目前不具有）和私有IT环境向云端服务迁移的能力。

有了这些特性维度，基本上就有了IT运营的数据体系，作好IT运营，就是不断去挖掘技术产品所产生的日志和数据，去衡量IT技术产品的现状以及将来的运营优化的方向。不过要注意的是在可维护性里面不只仅是度量这么简单，还有自动化平台建设来知足可变动性的要求，它的直接衡量指标就是以前提到的变动延时。

不少时候，咱们会担忧运维作久了，特别是运维被杂事和故障所牵绕的状况下，会忘了咱们还能作什么，更是忘了咱们实际上是从IT运营而来，从IT运营的角度看运维，特别是和ITOM结合起来去看运维，带来的感受又彻底不一样：

第1、平时运维的工做层面到底还有多少提炼和认识不够的地方（以ITOM为对标）？一样是作应用性能管理APM，代码级性能管理是否是惟一的方法，结合互联网还有哪些实践，他们之间的互补又在哪儿？能力管理的必要性是在哪儿？如何建设能力管理系统，从能力管理的三个层次来看，他们的成本和收益是什么样的？我把这些归纳为运维的内在思考。

第2、不断去思考运维带来的业务价值。从以前的讨论中均可以看到运维的最终价值点，它们都有一个业务价值的通用描述，咱们是否有结合本身的业务仔细思考过，提炼过？我把这些又归纳为运维的外在思考。

当咱们把其内在和外在都思考清楚了，其实也就是把运维的某方面思考清楚了，此时咱们结合行业的特色去作运维，提炼最佳实践，是否是意味着运维更有价值了？

注：这篇文章还能够谈谈IT运营的方法和策略，可是限于篇幅，不做深刻展开！