导读：本篇文章首席CTO笔记来给大家介绍有关devops怎么统计指标的相关内容，希望对大家有所帮助，一起来看看吧。
DevOps 标准是什么？
DevOps 标准是指《研发运营一体化（DevOps）能力成熟度模型 》 ，是指包含总体架构、敏捷开发管理、持续交付、技术运营、应用设计、
安全及风险管理、评估方法、系统和工具的系列标准。
4.DevOps-4.度量指标--0.度量指标(Metrics)
微服务实践目录 ，可以参见连接。
在很多人的想法里认为事务是无法考量的。无法说明的，就想老子所说的：
人对不了解的事务的学习与分析过程中有个分歧：
对于现代学科来说，现代的理学和文学都最终会归化到数学，数学会归化的哲学。例如：美学中的黄金比例，文学中的逻辑学，经济学中统计学等等。
但是，对于软件工程一门工程类学科来说无法考量与度量某一项事务是否是可行？答案自然是明确的软件工程必须是可以度量的，虽然在这么多年的发展过程中没有一套完整适应时代与技术的度量方法。但是度量对于一个工程类学科来说是必须的，而且之后也会不断的朝着可度量的方向发展。
度量是了解事务内部特征的最基础的方法。但在国内度量其实是从上到下都回避的一件事，所以，需要考量加入度量指标的时间点，以及加入的度量指标，加入方式等。不过可度量的标准是公司达到一定水平是一个标志。
本文主要描述度量指标的实践，上面这些社会学的理论请自行把握。
在网上找了很多关于 度量、指标、维度 的资料。这几个词可以从《统计学》到《软件运营》、再从《分析指标体系》到《软件过程度量模型》。就这几个词我找了很大一圈还是没有找到很好的解释，所以，我就妄自尊大的自己对度量指标进行一个解释：
度量出自维基百科，指标出自以上是从Wiki上找到的介绍。简单的看度量就是描述事物的一个特定方面的数字。
度量指标(Metrics) : 指用于描述一个物体或事物的某个性质的指数、规格、标准，使其可以和其他的物体或者事物的提交。
从软件的角度讲度量即把所有东西都量化、数据化、可采集。指标即表示对这些量化后的数据的目标值。维度即标识一个事物某一个侧面的一组指标。
大概说明了度量指标的内容之后，接下来以工程化实施方案的思维方式思考如果要实施度量指标需要完成怎样的工作。借鉴一些ToGAF的概念，每一项事都是需要有目标的，在目标的指导下去做具体的实施工作。度量指标工作具体的实施步骤如下：
引自《统计学教程》(主编：王怀伟 清华大学出版社)
从上图可以看到在软件行业内指标体系可以分为很多种。最终对客户有意义的，有价值的肯定是运营指标体系。运行软件指标体系是本次的目标，主要描述软件运行过程中的一些参数。《软件过程指标》、《软件指令指标》、《DevOps指标》都是软件在开发以及运营过程中的软件过程指标。
下图中是指标体系的一个实例，用于描述DevOps指标体系中的一些指标：
这个实例中描述了DevOps的几个指标。主要的指标目标是为了体现DevOps怎样为客户提供价值，并在这个基础上提出适应多变的环境（需求环境，开发环境，质量环境，过程环境等）。
真对于软件运行指标体系的目标是提高稳定性，减少故障，降低运营成本。
在驱动指标体系搭建形成闭环的最后一步就是数据应用，在采集的数据验证无误后应用于实际业务中，驱动业务增长。常用的分析理论有：4P理论、PESTEL理论、SWOT理论、5W2H理论、逻辑树理论、用户使用行为理论、AARRR理论。可以参照： 数据分析方法论（二）——常用数据分析方法
真对于软件运行指标体系的目标，分析方法需要满足故障检测，平稳程度，自动化程度几个方向。分析方法以统计方法为主，统计故障情况，统计自动化占比，统计测试质量等。
上面说明了度量指标的目标和指标分析方法。都是一些通用性的分析，未对某一个特定领域中的指标体系进行分析。一个特定领域中的指标体系包括的内容有哪些，这些内容起着怎样的作用。这些内容会在本节加以分析与描述。
先给出一个指标体系的整体架构：
分析方法：
在整个指标体系中分析方法提供跟业务相关的，对业务负责的内容。因为分析方法是根据要解决的问题域进行建立的，并对业务是有意义的。分析方法是多变的，在针对同样的行业、同样的场景、不同的公司时使用的分析与建模的方法都可能是不同的。因为分析方法是真对大环境去把控的，所以，需要做的是真对这些元知识（分析方法），进行分析与总结之后在应用于不同的场景。
从某个侧面来说，数据分析技术（大数据，BI等）最终有意义的方面都是分析方法。具体使用哪项分析方法，怎样做展示其实对整个数据分析来说意义不大。
数据可视化：
数据需要展示出来才可以体现出数据的意义，所以，就像敏捷中“交付价值”一样。数据有了必须要提供价值才可以展现出数据的意义。这里的数据可视化的方式还是需要针对度量进行相关的分析与展示的，或者直接使用相关的内容进行展示的能力。下面说明另种可以进行定制化的展示的可视化工具。
数据基础平台：
数据基础平台即包括数据采集，数据接收，数据存储，数据分析基础等内容。主要满足基础的数据处理要求，可以与现在流程的DMP概念认为是等同的。大数据的基础也就是：
至于其他的指标可视化工具：Tableau，FindReport，Splunk。都是商业版软件，不适合在小公司使用。所以，不会选择这些商业化软件。
上面定义了软件指标的目标以及方法，现在需要将度量指标体系确定并细化到可度量级别。所以，就需要对指标进行拆解工作。
事件、参数和属性 说明：先给大家解释三个概念，事件、参数和属性。事件可以理解为用户的某个行为，比如登录、注册、购买，都统称为事件；事件和参数结合起来就是指标，比如登录次数、注册人数、购买金额这些我们称为指标，而次数、人数、金额就是事件的参数。事件属性可以从某个维度对事件进行拆分分析，比如登录方式就是登录的属性，分析不同登录方式的登录次数。
上图为运营指标的实例，软件运行指标体系的例子服务从异步消息系统接收到一个消息。事件即接收到消息，参数可以是处理时长（消息处理时长以及消息处理事件）。指标是处理时长必须在10ms之内。属性是消息可以是定时任务，异步任务等等。
下面会具体的介绍软件运行指标体系中会涉及到的度量。
软件本来就是数字化的事物，不过就是涉及到度量的维度。根据度量维度的不同，可能会涉及到很多模糊不清的指标。所以针对每一个度量指标必须遵循SMART原则：
这样既有度量目标，又可以具体的去实施。不存在不可度量的指标，方便具体的落地实施工作。
以上的度量指标分类是从 Metrics-Java版的指标度量工具之一 和
Metrics Core 整理出来的。
本阶段主要分析了度量指标的成因，以及度量指标中相关的分类方法。所以，这里只介绍了度量指标的前期概念。在下面一篇文章中给出相关的技术设计以及具体实践。
度量
互联网运营，该分析哪些数据和指标
数据分析方法论（一）——构建数据指标体系
数据分析方法论（二）——常用数据分析方法
创业公司如何构建数据指标体系？
电商数据分析基础指标体系
如何搭建指标体系
从 0 到 1 搭建数据运营体系
数据体系搭建 | 梳理架构和指标体系
metrics
Metrics-Java版的指标度量工具之一
JAVA Metrics度量工具 - Metrics Core 翻译
第 44 课 度量指标（Metrics）
度量指标类型
智能分析最佳实践——指标逻辑树
利用Metrics+influxdb+grafana构建监控
基于dropwizard/metrics ，kafka，zabbix构建应用统计数据收集展示系统
软件度量
软体度量
软件过程质量度量与控制
软件过程度量模型
软件度量与软件过程管理
质量度量指标设定分析-1
常见软件项目度量指标介绍
敏捷软件估算和度量
Devops概述
目前在国外，互联网巨头如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，传统软件公司如Adobe、IBM、Microsoft、SAP等，亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用DevOps或提供相关支持产品。那么DevOps究竟是怎样一回事？
DevOps一次词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
DevOps概念早先升温于2009年的欧洲，因传统模式的运维之痛而生。
DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。
换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。
由上所述，相信大家对DevOps有了一定的了解。但是除了触及工具链之外，作为文化和技术的方法论，DevOps还需要公司在组织文化上的变革。回顾软件行业的研发模式，可以发现大致有三个阶段：瀑布式开发、敏捷开发、DevOps。
DevOps早在九年前就有人提出来，但是，为什么这两年才开始受到越来越多的企业重视和时间呢？因为DevOps的发展是独木不成林的，现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。
当今世界改变的速度已与过去不同，而每当经历一个颠覆性的技术革命时，都给这个世界带来了深刻的变化，大数据、云计算、人工智能、VR/AR和区块链等新兴技术推动着世界不断变化，如何应对这样一个VUCA时代，让我们能够在环境变化的时候快速响应呢？
在些我引用了圣贤王阳明的一句名言，他提倡“知行合一”，通俗的讲就是做事情要理论与实践相结合。我们在实现DevOps落地时也一定要遵循“理论与实践相结合”的方式进行，理论就是我们做事的指导思想，而实践就是具体做事的方法，接下来我就从我在公司中是如何按照理论与实践相结合来推动DevOps落实地。
首先我们还是要回到什么是DevOps，如果大家忘记了可以回到之前再温故一下，包括我总结的DevOps公式。
其实DevOps核心思想就是：“快速交付价值，灵活响应变化”。其基本原则如下：
DevOps的一个巨大好处就是可以高效交付，这也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告中，根据全球4600位各IT公司的技术工作者的提交数据统计，得出高效公司可以完成平均每年1460次部署。与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。在工作内容的时间分配上，低效者要多花22%的时间用在为规划好或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。
DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感；调查显示高效员工的雇员净推荐值（eNPS:employee Net Promoter Score）更高，即对公司更加认同。
快速的部署其实可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地相应。而且，DevOps小步快跑的形式带来的变化是比较小的，出现问题的偏差每次都不会太大，修复起来也会相对容易一些。
因此，认为速度就意味着危险是一种偏见。此外，滞后软件服务的发布也并不一定会完全地避免问题，在竞争日益激烈的IT行业，这反而可能错失了软件的发布时机。
技术的发展使得DevOps有了更多的配合。早期时，大家虽然意识到了这个问题的，但是苦于当时没有完善丰富的技术工具，是一种“理想很丰满，但是现实很骨感”的情况。DevOps的实现可以基于新兴的容器技术；也可以在自动化运维工具Puppet、SaltStack， Ansible之后的延伸；还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。
IT行业已经越来越于市场的经济发展紧密挂钩，专家们认为IT将会有支持中心变成利润驱动中心。事实上，这个变化已经开始了，这不仅体现在Google、苹果这些大企业中，而且也发生在传统行业中，比如出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等等。能否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得至关重要。
DevOps 2016年度报告给出了一个运维成本的计算公式：
而对于工程师而言，他们也是DevOps的受益者。微软资深工程师Scott Hanselman说过“对于开发者而言，最有力的工具就是自动化工具”（The most powerful tool we have as developers is automation）。工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话：“谁开发谁运行”。（You build it, you run it）
上文提到了工具链的打通，那么工具自然就需要做好准备。现将工具类型及对应的不完全列举整理如下：
在工具的选择上，需要结合公司业务需求和技术团队情况而定。（注：更多关于工具的详细介绍可以参见此文： 51 Best DevOps Tools for #DevOps Engineers ）
DevOps成功与否，公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习，从而拥有高生产力。并且协作也存在在业务人员与开发人员之间。出席了ITV公司在2012年就开始落地DevOps，其通用平台主管Clark在2016年伦敦企业级DevOps峰会接受InfoQ了采访，在谈及成功时表示，业务人员非常清楚他们希望在最小化可行产品中实现什么，工程师们就按需交付，不做多余工作。这样，工程师们使用通用的平台（即打通的工具链）得到更好的一致性和更高的质量。此外，DevOps对工程师个人的要求也提高了，很多专家也认为招募到优秀的人才也是一个挑战。
DevOps正在增长，尤其是在大企业中：调查发现，DevOps的接受度有了显著提高。74%的受访者已经接受了DevOps，而去年这一比例为66%。目前，在81%的大企业开始接受DevOps，中小企业的接受度仅为70%。
那么具体而言都有些公司在采用DevOps呢？Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Target（泛欧实时全额自动清算系统）、Walmart、Sony等等。
首先，大企业正在自下而上接受DevOps，其中业务单位或部门（31%）以及项目和团队（29%）已经实施DevOps。不过，只有21%的大企业在整个公司范围内采用了DevOps。
其次，在工具层面上，DevOps工具的用量大幅激增。Chef和Puppet依然是最常用的DevOps工具，使用率均为32%。Docker是年增长率最快的工具，用量增长一倍以上。Ansible的用量也有显著增加，使用率从10%翻倍至20%。
并且调查还发现不到半数（43%）的公司在使用诸如Chef、Puppet、Ansible或Salt等配置工具；然而使用配置工具的公司更有可能同时使用多个工具。25%的受访者使用两种或更多配置工具，只使用一种工具的比例为18%。其中Chef和Puppet是最常用的组合：使用Chef的组织中有67%同时也使用Puppet，类似的，使用Puppet的组织中也有67%同时使用了Chef。
DevOps的设计实践
起初对于DevOps的概念的理解仅仅停留在“使用Bamboo自动化部署服务到指定环境上”，当我们开始尝试着对DevOps的流程开始做推广，首先确定的方案是，推动各组使用Bamboo做CI/CD的集成，第二是针对当前项目面临管理混乱的痛点问题，进行项目发版采用语义化版本管理。但正如康威定律所言，“设计系统的组织其产生的设计等价于组织间的沟通结构。”，我们不能仅仅在一次讨论中确定的方案就企图变革组织间的长达几年的沟通协作习惯。并且DevOps也不简单是一个普适的解决方案，它是一个 平台（Platform）、流程（Process）和人（People）的有机整合。
根据 martinfowler博客 中发表的对DevOps文化的见解（如下图），他认为DevOps文化中最重要的原则是 责任共担和质量导向 。在这点上，我认为我司有天然的优势，在项目开展的初期，包括当前项目运行生命周期中，研发包揽了大部分运维工作。可以说我们不从来不缺敢于担责的“勇士”。但同时，在我司大幅扩招的现状中，加强流程管理，保证这种文化的延续，同时在人员流动中能动态的加强文化导向，这是DevOps指导思想中重要的一环。
工具 = 平台+ 流程，首先，平台最重大的意义是承载企业内部的标准化流程，平台固化的每种流程，都可以用来解决某些实际问题，这样就会形成一下特征：
通过平台赋能，所有人都能以相同的操作，获得相同的结果。这样一来，跨领域之间的交接和专家就被平台所取代，当一件事情不再依赖于个人的时候，等待的浪费就会大大降低，平台就成了组织内部的能力集合体。
任何方法论不结合企业实际的现状来分析都是耍流氓（无处不在的康威定律），那么对于我司的实际现状，建立这一套体系能解决哪些问题呢？在和研发童鞋讨论问题的时候，能看到他们往往是处于只见树木不见森林的状态，整个“森林”往往是被少数的人所掌握的，这点在季度述职时候已经被不少人提出来过。诚然我们作为安全公司，部分产品是敏感且需要保密的，但是从整个层次和架构来讲，我们需要适配一套流程，达到 对技术开放，对数据加密 ，安全的流程正是SecDevOps需要解决的问题。同时这也很切合“三步工作法”中 流动 原则，只有 把复杂的流程简单化，可视化 我们才有机会让更多的人看见森林。而目前结合生态，软件交付的效率和质量成了当今企业的核心价值和核心竞争力，DevOps作为软件工程的第三次革命，总结来看它的价值体现在以下两点：
让一切软件交付过程的手动环节，都是未来可以尝试进行优化的方向。DevOps倡导职责共担，持续改进是需要将规则内建于工具之中，并通过工具来指导实践。如果仅仅是把线下的流程搬到线上执行，是没法发挥DevOps真正的价值。说到底，工具没法解决人的问题，这样一条看似取巧的路径，却没法解决企业的根本问题。这时候，就需要文化闪亮登场了。
总而言之，DevOps 中的文化和工具，本身就是一体两面，我们既不能盲目地奉行工具决定论，上来就大干快干地采购和建设工具，也不能盲目地空谈文化，在内部形成一种脱离实际的风气。我们要做的是 关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践。
敏捷管理不仅仅与研发敏捷，同时也要针对于业务敏捷， 开发更少的功能，聚焦用户价值，持续快速验证，就成了产品需求管理的核心思想。
另外通过“研发一体化流程”图示，我们也能见微知著。在我司目前在产品使用JIRA的看板形式做需求管理，这套流程在敏捷业务管理中已经有很好的天然优势， 我们需要做的是打通产品和开发的交流屏障 ，这部分流程以及功能，在我们的排期中暂时靠后，现未有具体实施方案，目前仅给出 BizDevOps 的核心理念：
关于持续交付功能，是初期内我们重点投入的阶段，这也是作为研发真正的用武之地，首先面临着第一个问题，自研OR开源？在我们开始做DevOps之前，已经有了部分在用的优秀开源工具作为支撑点，Jira、Bamboo、BitBucket。这些工具一定程度上减少了我们初期的工作量，在后续的项目计划中，我们做了基础存储，权限、DevOps流程等多方调研。关于存储和权限这类基础架构目前都有着成熟的开源解决方案。但是DevOps流程关联公司TOG的业务性质，以及目前的项目现状，我们选择自研平台，主要的规划方向有：
1.版本控制、变更管理
主要核心思想是： 版本变更标准化，将一切纳入版本控制，全流程可追溯和单一可信数据源。 ，一套标准化的规则和行为习惯，可以降低协作过程中的沟通成本，一次性把事情做对，这也是标准和规范的重要意义。
2.持续构建和持续集成、部署与发布的模式
主要核心思想是：用自动化的方式完成从项目编译到发布的流程
3.环境的搭建管理、元数据、初始数据的管理
这是目前我们项目发布中的瓶颈，配置、初始化数据应当纳入版本控制，同时制定标准的业务流程；
4.度量与反馈
针对于交付效率、交付能力、交付质量做指标统计，以及建立可视化平台。主要的指标包括， 需求前置时间、开发前置时间、发布频率、发布前置时间、交付吞吐量、线上缺陷密度、线上缺陷分布 等。
5.内建质量、保证测试
内建质量有两个核心原则 ：
在为期近4个月的DevOps实践中，我们主要做了三件事情， 部分项目Bamboo的集成、基础架构的建设、DevOps平台的开发 。
初期我们做了一些关于DevOps的调研和实践，在 尽可能采用开源项目 的原则上，依赖于现有的技术结构，摸出了一套关于Bamboo的使用流程
开源OR自研？这永远是一个需要不断权衡和取舍问题，之前我们已经谈论到持续交付要做的事情有哪些，当开源组件不能Cover我们当下的流程，自研平台自然得上线了
基于上图我们可以看到FlowDevOps平台的基本的交互和流向。平台开发到现在经历了四个小版本的迭代，主要包含以下几个特性：
值得一提的是，我们选型了Jinja2作为配置模块统一管理，对各个环境公共组件的地址存放与平台，保证了服务离线部署中各类连接出错的问题。同时这种方式对业务的侵入较小，符合我们短期内提升部署效率的预期。
诚然，DevOps的建设在短期内已经做了不小的工作量，但是还是存在一定程度的问题。包括以下方面：
根据全球云计算峰会成熟度模型预估来看
在我司云原生于我们似乎是非常遥远的，陌生的技术栈，各类反直觉的故障。但是为什么我还是坚持认为云原生是我们未来建立DevOps，以及发展基础设计的最佳实践呢？引用CNCF对云原生的官方定义：
关键词有 开源软件、微服务应用、容器化部署和动态编排 ，虽然我们目前部分业务场景有传输相关的瓶颈，容器化则可能带来更大的存储体积。但从宏观角度来看，这并不是大部分项目的现状，而我们更多的项目核心的问题在于 数据量大、业务和配置复杂、依赖模块多 。而云原生应用天生就和DevOps 是绝配，自带高可用、易维护、高扩展、持续交付的光环，同时原生支持微服务、不可变基础设施以及服务网格这些技术领域，能天然解决业务复杂，依赖模块多的现状。
这也是我在基础设施建设工作中，坚持积累云原生技术方案的原因，云原生的技术方案，我始终认为它能大大推进我司效率建设和技术发展。即便我们在云原生的方案技术积累还不足够，比如还不能确认大数据在容器中运行的效率这类技术问题，但是当我们建设起更具效率的运营一体化流程，也就有更多的资本去进行试错，这片星辰大海等待我们去探索。
我们都期待完美，但在绝大多数时候，任何事情都不可能完美。软件更是如此，DevOps亦是如此。我们能做的就是基于每次的反馈，一点点的改进流程，一次次的反思提高。在不断的持续改进中，可能永远触及不到完美，但是就像美国著名女演员莉莉·汤姆林（Lily Tomlin）的那句经典名言所说的那样： The road to success is always under construction.（通往成功的道路，永远在建设之中） 。
DevOps究竟是如何改变开发和运维人员的？
如今，DevOps已经被越来越多的企业认可，DevOps不仅仅停留在开发和运维的范围，如今的DevOps是软件研发全生命周期管理的一整套方法论和最佳实践，是DevOps文化建设和人才培养。如果只涉及开发和运维人员，下面从实施DevOps之前和之后做个比较。
1、强化共同目标 2、对开发人员的改变 3、对运维人员的改变
DevOps使得开发和运维人员联系更加紧密，通过建立和强化彼此的信任关系，基于DevOps自动化服务，共同实现高效，高质量，稳定的交付用户价值的目标。
我来说下，接下来2022年DevOps实践的4个关键点
1、评估流程永远都是第一步。
DevOps 其实不是一个非常好理解的概念。如果我们不能很好了解DevOps 是什么以及它对组织的意义，那将可能是一个灾难。
不仅如此，团队中的每一个人都需要同步自己对 DevOps 的了解，只有团队在充分沟通的“同意”下，DevOps 实践才能顺利。这也就是为什么所有公司在切换至 DevOps 时的难点和重点都是——文化建设和学习。
此外，对开发周期的评估也应该是全方位的、从头到尾的。开发的不同流程，有不同的瓶颈和低效率，只有找到当前流程不足的领域，才能在实施 DevOps 时锁定重点。
2、协作和目标是DevOps团队的预备动作。
在实施 DevOps之前，就应该要确定团队有没有准备好一起工作和沟通。向每一位成员灌输强烈的协作意识，并为他们提供有助于他们沟通和协作的工具。
此外，明确的目标则为DevOps 实践设立方向，否则任何DevOps实践都将毫无意义。通常，我们可以从一个更小、更容易实现的目标开始，之后再转向更大、更复杂的目标，以防止一次性改变太多带来不可修复的破坏。
3、自动化是DevOps 的重要组成部分。
在DevOps过程中，我们应该尽可能多地使用自动化手段。无论是扫描错误配置的代码还是自动化测试，现下都有各种不同的自动化工具来实现，这对效率的提升无疑是巨大的。
在这个基础上，如果还想进一步的自动化，项目就不得不考量团队是否能跟上了。所以，最好的办法是，从需要大量时间和手工的工作入手，去一步步实现自动化。采用自动化之初，也最好让团队先监控几周，看看进展如何。
4、了解关键指标是重中之重。
从实施DevOps的一开始就应该设置关键指标。如果没有指标，我们将无法跟踪进展，也无法及时发现问题。
飞算全自动开发平台项目发布的应用服务，在监控运维指标方面已集成 健康 检查、审计、统计和HTTP追踪等运维性能指标数据，所有的这些特性可以通过JMX或者HTTP endpoints来获得。
同时还可以与外部应用监控系统整合对接，可以方便地通过第三方系统进行监控告警，比如 Prometheus、 Influxdb 、Grafana等。这些系统提供了非常好的仪表盘、图标、分析和告警等功能，使用户可以通过统一的接口轻松地监控和管理应用。
devops的概念我觉得很难用一句话去定义或解释，主要是流程和工具的结合，规范的流程加上高效的工具构建符合业务和公司实际的运维场景
说到底就是把繁琐的操作自动化，在得到快速集成和快速部署的同时，减少人为引入的失误。符合自动化发展的趋势，算是自动化在软件开发运营中的成功。
DevOps是一种打通开发和运维，并将所有环节自动化，摆脱人工束缚的理念，不仅仅只是字面上的将开发和运维打通结合。
多年以来，这两个群体一直被分开，尤其是在大型企业IT组织内部。开发者只关心编码，运维人员则确保其正常运行。他们之间完全脱节，导致需要更长的QA周期。并且经常不能在环境上部署新程序，因为这样可能会导致宕机或者破坏其它程序。
DevOps实现了高标准化，仅需几个工具，就可以替代人工干预，使用有效的方式来部署、配置和运行许多的服务。
随着DevOps的诞生，开发人员可以拥有配额，在一定的范围内他们可以按照需求，实时部署环境。
运维团队不再需要关心部署单个的应用程序，他们仍然采购硬件并且配置和管理服务器，但是规模远远大于单个的应用程序，他们的责任变成了管理开发人员更容易使用的自动化DevOps服务。
关于DevOps 的那些事
在2008年多伦多举办的敏捷大会（Velocity Conf 2008 ）上，Patrick DeBois 和AndrewClay Shafer 先生首次提议讨论“敏捷基础架构”这个话题。在第二年的敏捷大会上有一个具有里程碑的意义技术分享，来自Flickr公司《每天部署10次》的分享，它激发了随后Patrick DeBios在同年十月，在比利时的根特市举办的首届DevOpsDays活动，这个活动是两天的日程，为了大家方便在twitter上的传播，人们把DevOpsDays这个词简写为 “#DevOps” 。 此后，“DevOps”一词问世了，这个词所包含的理念和实践一时在越来越广大的人群中产生了共鸣，随后成为全球IT界在各种大会和论坛里热议和讨论的焦点话题，很多大型IT论坛也都开设出了DevOps专题讨论。这就是DevOps这个词的由来。
DevOpsDays活动随后在Patrick DeBios等相关核心发起人的推动下，在全球范围内蓬勃发展了起来。2010年在美国山景城(Mountain View) 举办的DevOpsDays 活动中，Damon Edwards先生使用“CAMS”这个缩写，高度概括和诠释了DevOps，即文化（Culture）、自动化（Automation）、度量（Measurement or Metrics）和分享（Sharing）。随后Jez Humble先生将“L”精益 (Lean) 原则也加入其中，最终变成了CALMS。
♣ Culture（文化）- 是指拥抱变革，促进协作和沟通
♣ Automation（自动化）- 是指将人为干预的环节从价值链中消除
♣ Lean（精益）- 是指通过使用精益原则促使高频率循环周期
♣ Metrics（指标）- 是指衡量每一个环节，并通过数据来改进循环周期
♣ Sharing（分享）- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进
“CALMS”完全吻合Patrick DeBois先生所一向倡导的“DevOps is a human problem” (DevOps 是关于人的问题) 的理念 。
从DevOps概念的产生，到如今它在全球范围内的蔓延和认同，已经经历了9个年头的时间。它的火爆推广也伴随着IT行业的迅速变迁和发展，现在已经到了移动互联网时代的后半场，国内的信息化建设已经完成了很多年；如今各行各业的企业也都亟待完成全方位的数字化转型。IT信息技术的先进程度标志着一个企业的核心能力，任何一个成功的企业，敏捷高效的软件开发创新实力和IT管理综合能力不只是门面而已，而是实实在在的市场竞争能力。DevOps倡导打敏捷、持续交付和ITIL三种实践的组合拳，同时应用精益生产理念为基础的管理思想，这正在逐渐地被广泛的接受和认可。
在过去的几年中，国内的各种IT大会也蓬勃发展，其中DevOps相关的专题和分会场也颇受人们的关注。各种云计算、运维等IT技术的社交媒体也都非常重视DevOps这个话题的分享。一个专属于DevOps社群的、国际性的、有影响力的DevOps大会正呼之欲出。在这样的时代背景下DevOpsDays大会北京站在2017年的3月18日来到中国，在同年的8月18日上海，还要举办DevOpsDays Shanghai站的大会。
下面列举一些DevOpsDays大会的相关数据，数据来源于DevOpsDays.org 网站。从2009年到2016年，已经在全球的61个城市/国家成功地举办了117场。
下图是在过去九年中DevOpsDays大会在各个城市/国家的分布和举办次数。
今年也就是2017年预计举办30场，其中已经有18场确定了举办城市和日期；还有12个城市的召开日期待定；这不包括年内还可能会提出申办的城市。以上数据的统计时间在2017年三月。
随着国内BAT等互联网巨头的崛起，互联网公司的开发运维经验也越来越多的在国内的各种技术大会上传播。从最近这两年（2016年和2017年）的技术活动日程中可以看出，国内互联网从业人员也不约而同的用DevOps来定位和分享自己的优势和经验。他们是传播和分享运维侧DevOps实践的先头部队。
出了技术论坛的分享之外，很多线上线下的大会、论坛和讨论组也都越来越热议DevOps这一专题。国内其它相关流派的人群，例如敏捷和精益等，也对DevOps的蓬勃发展表示比较惊讶，DevOps与老牌的敏捷和精益等阵营也产生过一些争论。但这一切的发生也都增加了人们对于DevOps的更深入的兴趣。
在培训认证这方面，Exin DevOps Master是一个国际认证的培训；其它公司和组织也正在举办关于DevOps工具链的培训，这些培训则注重于技术实操，关注在构建端到端的流水线的搭建方面。从DevOps的职位招聘方面，可以看到DevOps工程师相关的职位越来越多了，在职位需求中DevOps这个技能成了加分项，DevOps相关工具的技能也或将成为简历的亮点。在IT行业内不管是开发还是运维团队的人，都开始了学习和接受的过程。
据我观察DevOps方面的厂商在最近3年呈现爆炸式的发展。我把他们分为三类：
目前国内大部分企业慢慢地开始关注了DevOps，大型传统企业也开始逐渐地从各个角度做试点和尝试。试点的角度和方向各不相同，有的从底层基础架构的容器化开始，有的从交付部署流水线的自动化开始；总的来说还处于初级的尝试阶段，还没有大规模成体系的推广。
综上所述，目前国内DevOps发展的阶段还属于起步阶段。就像是ITIL/ITSM在2003年左右的状态。由于DevOps是去中心化的，所以没有唯一、权威的上游厂商的存在，各种理论实践的争执和PK都将终止与解决问题和提高效率的话题上，因此它具有百花齐放百家争鸣的发展条件。个人认为DevOps的实施和落地也不会完全依赖于传统的大型咨询厂商的咨询工作，由于它应该是在企业的内部，在内驱的作用下，自生长出来的；它必须是服务于企业的业务价值流的优化，加速业务价值产出的；而与之相关的工作和责任的担当，外部力量是很难以等量替换和承担的。
在谈这个话题前先看一下DevOps相关工具集的全貌，如下图所示：
最上面的箭头流程图表示了一个业务服务的全生命周期：开发协作、软件构建、质量测试、交付部署和投产运维。前三个阶段偏传统开发组织的工作内容，后两个阶段基本可以和运维组织的工作对应上。在每个阶段下可以看成是一个大分类，这些分类中还包含若干个小分类。这些工具可以粗放的划分为商业软件和开源软件两类；也可以分为SaaS服务类和企业内部部署型。大部分开源工具都有活跃的用户社区和群众基础，这给企业入手这些工具带来了很大的便利。在需要商业支持的场景里还可以选择使用这些开源软件的企业版。
Docker容器技术在最近三年中异军突起，持续交付的技术门槛因此被降到最低，软件生产供应链的格局和效率被彻底提升；基于Docker的微服务架构实践的热度和成熟度也与日俱增。因此，国内的传统企业纷纷试水DevOps和容器技术，在最近两年的各种技术大会中，我们可以看到国内各个行业出现了在不同维度上的DevOps先行者。他们分享的主题大多集中在自动化运维、容器化和PaaS平台的等项目经验。
从国内众多DevOps实践中，我们能看到下面三个技术尤其重要和火热：
以上三种技术相辅相成，有着比较深刻的关联。首先微服务和持续部署各自解决了特别多的传统IT的问题，这些问题都是长期以来制约企业业务发展的难题。容器技术由于它的快速、轻量、微服务化的天然特性，很好的从不同侧面支持了持续交付和微服务架构。容器可以为持续交付提供弹性和高速的系统资源，环境管理和利用率提高了很多；容器的不可变性的特点也更好地支持了微服务架构。
我把DevOps的按照不同的技术特征做了从到1.0 到2.0的时代划分，并尽量通过以下维度比较与传统方式的差异。
我比较认可和接受的企业实践DevOps参考框架如下，其中包含了所需的最佳实践，如下图所示。
（上图来源于：Exin DevOps白皮书）
下面简要描述一下这四大支柱型最佳实践：
由此可见DevOps在企业，特别是大规模传统企业的落地和推广还是比较复杂的。虽然相关的最佳实践都是已经存在了很多年的；但是，通过DevOps的价值观重构企业从研发到交付到运维的价值流谈何容易。基于我的IT从业经验，我似乎感觉到DevOps不能单独依靠自顶向下的推广，当然高层领导的支持依然是重要的和必备的支持条件之一。 可能还需要中层的带动和底层的创新；借鉴生产制造业已经久经考验的精益制造实践也是势在必行。总之DevOps运动会在近几年给IT行业带来较大影响。
结语：以上就是首席CTO笔记为大家整理的关于devops怎么统计指标的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～