运维的目标价值体系

运维价值的提炼，直接决定了团队（个人）对运维理解的高度和精度！

从很多传统的视角去看运维，运维的确承担了很多职能，但这些职能还是都和具体的岗位相关，如下：

在过往的运维经历中，很多研发甚至是运维自己都把运维就放在了一个资源（服务器、网络）提供者定位上，造成很多运维团队的成就感不是很强。很多运维人也经常问，我们的价值到底在哪儿？“保姆”/“救火”/“苦逼”好像就是运维的标签，难道我们的运维真的只能如此？这篇文章就和大家好好谈谈运维的价值在哪儿？让大家看看运维都能做些什么？

价值不等于作用，说到价值，一定有其内涵,该内涵且可以通过几个关键词来表达的。关键词表达的好处可以避免理解泛化，同时也概括了对运维理解的抽象能力。在早期的腾讯运维经历中，那时我们把运维价值分成了几个方向：质量（高）、成本（低）、效率（快）、安全（风险），到现在我始终认为这一模型还在普遍受用。具体的个人理解如下：

一、质量(Quality)

我们还需要从经典的质量定义开始，用【层次分析法】逐渐打开，去认识质量体系的全貌。

美国著名的质量管理专家朱兰（J.M.Juran）博士从顾客的角度出发，提出了产品(服务)质量就是产品(服务)的适用性，即产品(服务)在使用时能成功地满足用户需要的程度。

此时我们看到的“满足用户需要的程度”，其实是一个很不精确的概念。但是这个定义中提到了一个很好的词--“程度”，这就意味着产品的质量是需要被度量的，否则没法来说明我们现在产品(服务)到底怎么样，那如何可以被度量呢？我们还可以从运维的角度来看，把产品进一步进行归类：

A、内部产品

比如说像机房、机架、服务器甚至是OS等产品，这个产品完全是运维部门自己产出的，并且是提供给研发使用的，对用户是完全透明的，对内部产品的好与坏的最直接衡量就是可用性。比如说我们可以定时出具报告，最近服务器的可用性怎么样？最近OS的可用性怎么样？最近机房的可用性如何？用这些数据来驱动我们运维流程和运维规范不断完善。内部产品的可用性数据获取可以通过事件单的记录故障时间的方式来获取。

B、外部产品

首先需要把外部产品进一步分解成一个一个的功能（服务），然后衡量功能（服务）的可用性。就拿我现在维护的游戏SDK业务来说，SDK是一个产品，这个产品提供了很多功能（服务），有统一登陆服务、统一注册服务、统一支付服务等等，这些服务在用户使用的过程是否一直能满足用户的需要。注意：一定要从用户直接感知的功能和服务去分解，不要掺杂任何内部的视角，也不要去衡量非核心服务，比如说SDK的DNS自动切换能力。对非核心服务来说，服务的异常，客户不是太敏感，并且可以通过技术的手段（服务降级）去临时降低用户对产品的期望。

其次互联网产品是一个体验式服务，需要有一个对体验的衡量指标---速度。

许多研究都表明，用户最满意的打开网页时间，是在2秒以下。用户能够忍受的最长等待时间的中位数，在6～8秒之间。这就是说，8秒是一个临界值，如果你的网站打开速度在8秒以上，那么很可能，大部分访问者最终都会离你而去。研究显示，如果等待12秒以后，网页还是没有载入，那么99%以上的用户会关闭这个网页，不再等待。

Google也做过一个试验，显示10条搜索结果的页面载入需要0.4秒，显示30条搜索结果的页面载入需要0.9秒，结果后者使得Google总的流量和收入减少了20%。Amazon的统计也显示了相近的结果，首页打开时间每增加100毫秒，网站销售量会减少1%。

Google最新的pagerank算法中纳入了网站的速度指标，可见速度是多么重要。

再者用户满意度也是一个产品和服务的衡量标准。用户满意度可以通过客服投诉或者论坛的客户投诉情况来度量，设定一个产品的不满意的基准，然后根据这儿阈值去衡量用户满意度。满意度可以统计历史的数据，然后设定一个合理的基准，在这个基准之上，持续的改进，从而设定新的基准。

最后在业务自身维度上，还有一些指标可以采用。对于下载类业务来说，也许要看下载速度；对于通道类业务来说（短信网关），还要看到达率等等；对于流媒体类业务，可以看卡顿情况；对于资讯媒体类的业务，甚至还看百度SEO指数等等。这个地方可以采用层次分析法，多挖掘业务的特性指标。这个地方记得控制指标不宜过多，最好控制在3个左右，过多的指标会让最终的质量数据波动太大，从而不能更好的牵引优化团队向前，也可以A阶段用A指标，等A优化完成后，在B阶段再纳入另外一个指标。

此时我们也讲一下可用性和质量的区别，顺便也介绍一下可用性。业界有一个明确的定义，可用性就是连续服务时间占总服务时间之比，该文章【http://blog.csdn.net/cszhouwei/article/details/38459095】介绍非常详细，因此就有了不同时间粒度的可用性（日、周、月、季度）等等。那什么是可用的服务呢？对于功能（服务）来说，就是功能正常（服务状态码），并且能够快速的返回（低于服务延时），就是正常。

再用一个完整的图来概括一下运维质量的谱系，如下图：

二、成本（Cost）

运维不是直接的效益部门，但是可以通过成本控制产生效益。在一个海量服务的情况下，带宽/服务器/人力都是非常昂贵的资源，成本的控制精细化考验了运维团队的技术能力和管理能力。

首先需要一个完整的数据去展现当前服务资源的利用率情况，其次需要根据这份数据来推动不断推动相应的优化。

从服务器的角度来说，我们可以把服务器的四大资源(cpu、内存、IO、网络IO）的利用率作为直接的服务资源使用率参考（取他们的最大值），一定要注意避免使用操作系统的load来衡量服务器的利用率情况。设定一个合理使用率为基准，强制要求业务必须在这个阈值之上，并且鼓励业务更充分的利用资源。问题来了，研发会说，我如果把服务器资源利用率使用到50%，万一业务压力突增，会影响我的业务？对运维的技术要求就来了，我们是否有实时的扩容和调度能力，是对运维自动化变更能力的挑战，所以说考验运维的技术能力。

从带宽的角度来说，可以把单用户占用带宽的情况统计出来，同时也要把带宽的消耗分布提取出来，对web型业务，需要去分解页面的带宽占用消耗分布；对于下载类服务来说，多维度分析带宽的消耗原因，然后分析是否可以借助用户的下载灰度控制、P2P技术、错峰、增量更新、预下载等手段去控制带宽的使用。YY语音的带宽控制非常出色，最终到每个语音包上的苛求优化，非常精细。

在人力的角度来说，可以转换成人均维护服务器的数量，这个地方可以衡量人的运维能力，运维的服务器越多就意味着人力成本越低。也用一个完整的图来表达成本的控制：

三、效率（Efficiency)

运维效率能够看到运维平台化的能力。从场景的角度可以分解出很多种对运维效率的要求，比如说故障发现问题效率、故障定位问题效率、发布效率、(DNS/LVS/网络/业务)变更效率、资源交付效率等等。运维都不提倡面向业务部门的SLA，但所有的运维团队都在这些维度提出自我要求，从而不断去驱动运维平台和规范的建设。特别是涉及到线上服务部分，比如说故障定位能力、扩容变更能力等等，这些能力目标提出来之后，可以检验我们那些地方做的不足【PDCA的精髓】。大家现在经常说的持续集成，也主要是在效率维度能带来全流程优化的收益。具体也可以分解成如下图：

上图只是列了部分的场景，其实场景非常多，比如说DNS、LVS等等。在底层各专有事务系统成熟之后，最终检验运维效率的一个核心指标就是面向业务整体调度和整体交付能力。

四、安全（Security)

安全是一个互联网产品的生命基线，需尽早安全的制度和规范应该在早期的产品研发过程中参与进来，其次要建立一个全面的安全体系，从系统级、数据级别、应用级别等各个维度去对待安全的问题。对于数据的安全保护，更是中重中之重。数据要建立分级体系，不同的数据分级需要有不同的管理策略和数据使用策略，这些策略包含访问密码加密、访问日志的脱敏、数据隔离访问、数据加密、数据的备份、数据的加密获取等等。这里面涉及的内容非常的多，需要建设专业的运维安全团队。

在上面我们看到运维价值的四个维度，在其中有很多需要运维去细化的工作，此时你是不是觉得自己有很多事情要干了？你要搭建平台，你要建规范，做标准，还要学会用数据驱动运维/研发/测试。在之前的文章中也说过运维的本质是可视化，在这些维度的具体工作上都有体现，无论是自动化的可视化还是数据的可视化。

总而言之，运维需要建立一个强势且一致性的质量文化，由质量来驱动研发/测试/运维；用最低的成本和最快的速度完成面向用户的价值交付。

在后续会推出一系列的文章来多角度，多层次的来看运维，提前给出如下（排名不分先后）：

1、【平台篇】平台建设规划总体系介绍

讲讲我规划的几个运维平台体系。

2、【平台篇】运维系统之CMDB系统建设

传统的CMDB厂商或者规范有哪些CMDB建设误区？CMDB建设到底需要遵循什么样的思路，最终的产品形态如何。

3、【平台篇】运维系统之监控系统建设

你认为你做的是监控系统，其实你做的是一个告警系统。真正的监控系统要解决的核心问题是什么？秀架构、秀大数据处理的监控平台是不是一个好的监控平台？

4、【平台篇】运维系统之能力系统建设

什么是能力系统?能力系统如何覆盖应用的能力、资源的能力、人力的能力和接口的能力等多个层面的管理。

5、【平台篇】运维系统之质量管理系统建设

可用性和质量管理系统的区别在哪儿？是否需要建设一个真正的质量管理系统？

6、【平台篇】基于可视化的运维自动化平台建设

运维的本质是可视化，自动化的可视化带来的价值更是非常之大。那如何建设真正的可视化运维自动化平台。

7、【平台篇】持续集成之持续部署建设

基于持续集成理论的持续部署如何实现的？

8、【理论篇】DevOps到底给运维带来了什么变化？

DevOps这么火，很多人都已经把它当着运维的福音来看待了。那到底DevOps能给我们带来什么？

9、【理论篇】ITIL，是否昨日黄花？

曾经风光无限的ITIL，是不是真的一无是处了？

10、【扯淡篇】运维危机，你嗅到了么？

到底有什么样的运维危机，让我们惶惶不安？是什么导致了这样的危机？如何解决？

11、【扯淡篇】如何成为“T型”运维人

什么是T型运维人？在广度和深度上又有着什么样的理解？

12、【扯淡篇】运维人应该了解的理论

从PDCA/ERP/质量管理/价值链模型/供应链模型/平衡积分卡/商业智能/ITIL等多个理论上看理论的价值和意义。

13、【技术篇】运维的技术能力要求

从操作系统、网络、应用软件、存储服务等多个维度去看运维的技术能力的深度和广度要求。

14、【技术篇】统一存储服务的实现

存储是架构中最核心的服务能力，存储是很多运维人的弱点，让你认识一个完整的存储服务特点，可以让你更好的做好业务运维。

15、【技术篇】名字服务中心的实现

名字服务是分布式服务架构中的核心组件，我所看到的集中名字服务中心的架构是什么样的？最终我们的方案又有什么特点。

......