随着行业的发展，运维职能在发生微妙的变化，现在谈大厂SRE的方向，其实我觉得更像是技术运营，通过运营的方式技术的手段牵头协同各部门来保证产品的SLA（服务质量），控制产品的成本，提高管理的效率，从传统运维转身至SRE，SRE慢慢从后台部门走向前台，从成本部门走向生产力部门，从系统稳定性走向用户稳定性，未来甚至会参与到前端经营，SRE是有数据技术能力的。
作为技术运营来说，最重要的是拿到产品运行的各种信息来描述产品的健康状态，也就是通过数据将产品的形态画出来，然后通过这些指标的波动来建立质量告警、产品决策和改进方向，同时为管理层制定产品战略提供输入，而这些信息全部来自系统运行过程中产生的数据，所以数据的应用是运维非常重要的工作，建设好后，它可以从全局视角指导工程师的工作方向，当前SRE使用的主要是质量和容量指标。
科普一下运营的概念，运营是指有明确目标，要持续循环往复做的事情，而项目是指临时的一次性任务。
1.数据的认识
从认识上看，运维中数据应用的本质是对系统进行画像，通过画像对系统进行全面认知，开放给不同角色的同学使用。
一个产品在运行中会产生各种数据，而产品的健康情况、业务指标就藏在这些数据里。数据通过汇聚整理形成有组织的信息，这些信息服务于运维就是监控告警、异常检测、apm等，服务于业务部门就是DAU、PV、UV等各种运营指标，服务于老板就用于公司决策，继续对这些信息进行归纳总结形成知识，对处理方式进行归纳总结形成经验，对经验抽象总结形成方法论也就是规律。
数据到应用有三个环节：采数据、管数据、用数据。其中偏技术能力的是采数据和管数据，比如说从海量数据里实时汇聚计算出有用的数据按照特定条件发送给相关人，1G、2G的数据好处理，但是1T、2T数据的实时处理就是个技术工作了，这也是考验运维人员技术能力的一个点；用数据更多的是考验业务能力，对各种业务场景进行指标的建模，然后使用BI工具进行多维度呈现，有些指标可以为具体的动作提供输入。下图是在新浪时，我主导设计建设的一个基于ELK的数据架构，麻雀虽小五脏俱全，道理万变不离其宗。
2.数据的应用
在运维中，我们会将服务器（CPU、内存、IO、网络等）、业务和依赖资源的信息进行采集，就形成一个庞大的运维数仓。
对这些数据进行实时收敛画成曲线就形成了监控，对监控继续收敛将一些能反应业务健康的指标提炼出来并加上触发器就形成了告警，这些监控和告警都是需要管理的，因此就诞生了监控告警管理系统，但是有了监控告警并不能根本解决问题，你还需要看到一些详细的信息，就有了日志分析系统...自然而然的一环扣一环的发展。
再看运维中的数据有哪些使用场景？采集服务器上的数据，收敛聚合做成实时监控图像，结合关系形成链路监控，添加触发器形成告警，告警的同时附上数据分析报告形成告警分析，为了提前预防故障，将还没有形成故障的产品薄弱点做成异常检测分析报告定期发送预警，为了根因排查必须做到可以随时查询详细日志，还需要通过SDK等将代码内部执行层面数据收集起来进行性能分析，通过采集数据中各种指标的计算又形成了容量评估…所有运维的数据场景就顺其自然的出来了，这些都是运维的数据应用。
3.数据驱动运维
数据驱动运维的核心是——建指标，定目标。将运维关注的质量、成本、效率数据化，建立衡量指标，通过对指标制定目标，驱动工程师为达成更优秀的指标而努力。
指标一定要简单、聚焦，越少越好，复杂了，执行不下去，比如对于云端服务而言，SRE一般会定义可用性、时延、QPS三个核心指标，分别用于反应质量、性能和容量，其它大量的指标都是二级三级或更低级别的指标，分别用于其他用途。
SRE可以根据业务的实际情况，建立适合业务的分级指标，要注意的是，指标是工具不是目的，不要被指标绑架。
欢迎关注原创公众号「运维网咖社」——矢量比特（高利绪）
