前言：在上一篇文章《建立数据指标体系，推动DevOps全链路度量闭环》中，我们描述了基于数据来建立数据指标体系，通过指标体系达到主观事件客观呈现的效果。信通院的一些分析数据表明，企业IT的信息化历程逐渐完成，同时企业对IT的精益运行的需求越来越迫切，在这个场景下，数据的思维和使用能力成为制约提升IT生产效率的桎梏。
笔者以为，企业数字化的范畴放在运维领域，更多的场景还处在数据量化的扩展，因此除了服务输出和业务连续性能力输出以外，还有一个重要的场景需要开辟，其中就包括运维的数字信息能力输出。同时根据《企业IT运维发展白皮书》所述，在数据驱动的基础上，运维的重要职能已由安全、稳定逐步延展至高效和低成本。在本文中，我们重点以运维的数据思维和数据的场景运用进行展开。
一、运维方式和运维数据的发展历程
从企业的信息系统规模、复杂程度变化以及运维技术的应用等方面考虑，我们大致可以把运维方式的发展分为五个阶段：手工运维、流程化运维、自动化运维、DevOps、AiOps。在这五个阶段中，运维的场景输出能力在不断的提升，从最初的各类资源的分配控制到容量管理，资源交付到持续部署，被动的问题受理到提前预测问题，乃至到现在已经主动介入用户体验和增值服务投入的技术运营场景。因此运维方式的发展也遵循运维无边界的思路，“浸润式”的进入整个IT服务体系，从业务的角度来提升运维价值，提升技术的投入产出比和减少企业成本的压力。
运维数据根据上述运维方式的发展历程逐步构建数据生态，如果我们把运维方式的发展浓缩成运维技术提升和工具建设，那与之相对应的，运维数据的发展也有四个阶段：自动化运维能力、平台化运维能力、数据化运维能力、智能化运维能力。在数据化运维能力中，运维数据已初步形成初步数据生态标准，具备构建运维数据中台和数据可视化，同时也能对数据的进行血缘能力和影响能力的初步分析。在智能化运维能力中，运维数据已形成较大的规模，因此将运维经验和大数据、机器学习的技术相结合，开发成一系列智能策略，提升运维数据的输出能力，让运维的数据边界延伸至更多的场景。
二、什么是运维的“数据思维”
运维方式的发展提升了运维人员的基础门槛能力，在现在很多的企业中，运维人员的日常离不开数据，运维的过程和结果靠不靠谱，都可以通过数据来验证。
（1）数据对运维打通业务服务链路的价值
数据的价值，在企业数字化实践过程中处在核心地位，对于运维来说也亦然。不同的数据对于不同的运维人员价值也不一样，同样数据对于不同的运维人员来说价值也不一样，因此对于运维来说，数据对运维打通业务服务链路的价值主要有以下。
在产品的运营阶段，快速发现业务问题。公司管理层通过经营指标发现公司运营中的问题，同样的，运维人员也能通过业务数据发现产品运营中的问题。业务数据的背后是每个用户行为的堆砌，如数据有波动，一定是某些节点和步骤不同于往常，需要重点关注。举一个简单的场景，如多个第三方渠道出现访问量、成功率下降，而系统无故障的情况下，是不是第三方渠道出现问题，还是新上线功能出现bug导致了数据变化，还是某些开关和策略遗漏，因此在产品的运营阶段，数据是沟通科技和业务的桥梁。对于运维来说，监控着力点的前置，有助于更快速的发现业务问题，在业务监控中，数据波动的点是公司运营的问题点，也是运维在工作中的重点。
辅助运维人员做决策。在实际的运维资源输出工作中，一般会有一些特殊场景是流程无法覆盖的，如重大活动的资源扩容和紧急情况下的系统降级。在链路系统扩容方面存在A系统扩容和B系统扩容，如果有数据支撑能直接证明A系统扩容比B系统扩容方式好，那就采取A系统扩容。可能有人说，为什么不用链路压测来决定，在庞大的业务系统链路中，涉及外部第三方系统的多级调用，并不一定能够协调到足够多的资源，因此只能基于现有的数据支撑进行决策，紧急情况下的系统降级也一样。在数据积累过程中，如果数据表现向好的方面发展，要放大这个效应，全面去应用让数据好转的措施。如果数据表现向不好的方面发展，快速定位导致数据波动的真正原因，给予解决。不管是运维方向的决策还是运维方案的决策，都能通过数据来指导。
运维成本复盘和项目的后评价。对于企业来说，每个项目和需求的上线，有且只有一个最合适的指标来评估其结果，因此项目后评价是进行成本复盘的重要手段。是判断人力资源、软硬件资源的投入和产品运营后的产出对比，也是判断项目或产品的成功与否，更是从较高的视野来进行项目和产品优化的重要手段。对于运维来说，除了基于容量管理，运维的成本复盘也是至关重要的一个点。项目上线前的预期收益和项目上线后的阶段性实际收益相对比，相关数据可以决定了软硬件的投入是否形成收益，也能将此类数据作为业务继续迭代优化和下线止损的参考。
（2）运维人员的数据观
无数据，不工作。在进入运维自动化阶段，对于运维人员来说，日常工作如果没有数据作为参考，工作的方向和思路会造成严重的偏差。你所负责的业务线和系统已无法给予你最准确的状态和及时的反馈。同样的，资源的管理和分配也因数据的实时性和准确性大打折扣，导致不能高质量的进行交付。因此，对于运维人员来说，要充分使用数据的反馈和支撑。
数据让一切问题及时暴露。线上bug，第一时间反馈在数据波动上；系统和资源的问题，第一时间体现在监控反馈上；代码质量，第一时间反馈在持续构建环节；渠道质量不高，第一时间反馈在数据的同比环比上。总之，在业务连续性的问题上，数据让一切问题及时暴露。
用好数据即可，不必成为数据的生产者。运维领域集中了公司展业的所有数据，有资源数据、监控数据、业务数据、后台支撑数据，因此运维人员只需要合理的使用数据，进行运维场景和数据输出场景相互匹配。大数据工程师负责将业务经营数据进行分析并提供结构化，数据研发工程师负责满足为公司各类数据需求方出数，运营人员负责对业务数据给出建议和实时反馈。而运维人员只需要将运维场景的数据和其他第三方数据进行有机的结合，因此运维人员随时看数据，并不需要成为他们，运维服务能力的边界延伸并不意味运维技术的延伸，运维人员跟需要善于运用现有的数据来获得想要的结果和反馈。
三、运维人员如何落地“数据思维”
在上一篇文章《建立数据指标体系，推动DevOps全链路度量闭环》中，我们讲到了什么是数据指标体系，如何进行构建数据指标体系。因此运维人员在落地数据思维中的第一步是形成初步的运维数据的生态，具备数据的输出场景能力。
（1）具备运维数据生态
通俗点说，运维数据生态是集中了公司展业的所有数据，并让适配场景的数据进行流动。对于资源管理来说，基于CMDB的数据大致有以下两类，数据中心数据，包括了机房、机柜、U位、设备、服务器和配件、系统版本、IP信息。云管数据，包括了宿主机、虚拟机、容器、系统版本、IP信息、承载系统、负载均衡、系统信息、中间件信息、业务信息。基于系统的数据均来自有业务日志，包括时间、请求号、系统、接口、方法、耗时、响应码。基于业务的信息大致有pv、uv、转化率、成功率、新客人数、利润等。基于组织架构的信息大致有部门、团队、人员等。另外还有一些文档数据，如需求文档，接口文档，知识库。
如下图所列，具备运维数据的生态基础需要将上述源数据进行采集、存储、加工、分析，最终达到应用的效果。
（2）提供数据使用场景
运维的日常场景很多，看似复杂，终究离不开对稳定、安全、高效、低成本四项基本价值的更高追求。通过运维数据化能力，运维能为企业决策提供有力支撑，实现稳定、安全、效率的提升，和对成本的合理把控。在本文中我们只对常见的场景进行简单的描述，详细的场景分析将在下一篇中体现。
知识图谱，使用统一的语言来定义运维数据，将运维对象通过实体与实体间的关系来表达，整合运维领域内的实体关系形成知识图谱。运维领域的关系包括但不限于产品、服务、集群、服务器、网络、IDC等。
数据中台，建立面向运维域的数据中台，统一纳管如资源数据、告警数据、性能数据、业务数据、日志数据、工单数据、指标数据、拨测数据等，面向上层运维分析场景提供统一的数据访问路由、数据服务目录、数据接入管理、 数据可视化等功能，以期打破“数据孤岛”，通过整合关联和对外开放来深度 挖掘运营数据的价值。识别前台数据需求，整合后台数据，对数据进行加工和输出，建立数据中心级的数据服务共享平台。通过对数据的梳理，数据源的规划，数据流程的整合，对存量数据进行加工整合，达到以数据服务化的方式来 实现数据监控，资源使用率分析。
数据可视化，通过对数据的可视化呈现，帮助运维人员直观、便捷、快速的进行问题分析，还可提供一系列的工具组件让运维人员根据自己的业务情况对海量数据进行快速进行视图编辑、多层下钻分析、多维度关联分析、报表编排，横向纵向大盘数据对比等，将传统的运维经验进行数字化转变，大大提升了问题排查、风险发现和知识沉淀。
下一篇文章中，将进行更高阶的场景描述，如无人值守变更、故障自动评估、故障自动预测。
（3）养成每天看数据的习惯
运维人员应具备看数据的好习惯，以笔者为例，每天最重要的的事是随时看监控数据，同时兼顾业务数据，同时保持对数据的敏感性。对于数据的表现，不管正常还是异常，都需要跟研发团队、产品团队、业务团队保持沟通，让大家知晓目前的项目和线上产品的数据表现。这样做一方面能获得来自团队的反馈，有反馈会进一步强化我们看数据的行为。另一方面也建立自己靠谱的形象，能做到每天看数据、看业务指标，这就是运维人员的靠谱。
四、后记
总之，运维离不开数据，尤其在企业IT逐步进入精益运营和价值交付的今天，离开了数据，运维路上终究布满坎坷，尽信数据，比自己瞎想强。
