运维系统业务价值
那我们做运维平台的意义在哪里呢？对内价值就是降低了多少故障率、提升了多少工作效率、节约了多少人力资源等；最好是不仅将其定位为一个内部辅助系统，需要将其和业务侧的墙打破，介入业务发展的生命周期，这样做才能将运维价值最大化地变现。
运维平台中和业务运营相关密切的功能模块一般有数据分析、弹性伸缩(辅助运营)、成本核算、用户体验优化(业务监控)等等，如何才能包装好运维平台和为其讲一个好故事，也是运维产品经理的职责所在。如何能让不了解运维业务的领导们或者外部门的同事们都能理解、认可运维价值，其意义是非常重大的。
作业平台
使用平台前：
项目同事放下手头工作 ->通过邮件或者 IM 通知运维同事执行某项操作 ->运维同事放下手头工作，读邮件或 IM，理解项目同事的操作内容 ->执行操作 ->通过邮件或者 IM 反馈项目同事 ->运维同事返回原来工作 ->项目同事放下工作读邮件或 IM 再返回原工作
使用平台后：
项目同事操作平台直接执行某项操作得到反馈
这个过程对于项目同事和运维同事双方总共至少能节约人力 15 分钟，减少了很多沟通、理解、反馈的时间成本。
一个站点或者App，大致经历着这样的诞生过程：PM设计出产品原型，交给 Dev 开发实现，最后交付给 Ops 部署到线上运行，最后供用户使用。
在这几个简单步骤中却涉及了众多的人、角色、交付等对象，这是一个完整、复杂的系统工程，而任意一个环节的失误都可能影响最终呈现给用户的体验以及效果。
但是我们却不可能一个个子步骤都去加监控、加数据分析，这样做是非常吃力不讨好的事情，甚至会产生很多监控冗余的情况，所以我们要做的是抓住核心指标。
什么是监控冗余
随着我们的业务发展慢慢变得庞大、复杂，其需要监控的点会变得越来越多，如果我们对每个环节、每个组件可能的异常都做对应的监控，那么一台host可能会要有数十个监控项，这是不太科学的做法。监控的意义在于迅速发现问题，如果存在过多的冗余监控，可能会影响运维人员对于告警的敏感性。例如每天好几百条告警短信接收下来
，又没有非常准确地发现真正的故障情况的话，这个告警就没有存在的意义。
我们该如何监控，首先是找到核心指标。
什么是核心指标？对于不同角色会有不同的侧重点：
对于PM：PV、UV、日活、月活、ARPU等
对于Dev：Bug、TPS、QPS、JVM、消息队列 等
对于Ops：服务可用性、机器负载、带宽流量 等
以上都是核心指标，但是缺偏偏少关注了一个重要角色--用户，对于用户来说，他们不会关心站点的PV、日活，也不会关心TPS，更加不会关心我们线上用了多少机器多少带宽。
用户只关注我们的业务产品更否提供稳定的、快速的、高质量的服务，用通俗的语言来描述，就是我打开网站是否秒开，登录app是否秒进，购物付款是否快速完成等等。
从用户的角度分析问题，才算是真正的通过运维技术加上运营理解来保证服务的高效稳定运行，这就是所谓的技术运营需要关注的。
那么问题来了，到底什么才是用户关注的核心指标？
不同业务形态有不同的用户关注指标：
对于信息类站点（例如门户网站等）：首屏时间、完整首页时间
对于电商类站点：首屏时间、登录时间、付款时间
对于页游：首屏时间、登录时间、进服时间
对于手游：启动时间、登录时间、进服时间
这需要不同业务形态的运维工程师从用户角度来分析，通过技术手段来挖掘、定位出一些核心的步骤，然后在这些核心步骤作出可监控的方法，如 URL拨测、服务端监控API、页面JS被动检测等方式。
业务监控
监控的作用是对业务具有全面的诊断能力，按各种层次各种维度的监控方法，建立一套立体的监控模型，对影响业务的各个核心数据指标进行采集、分析、建模、展示、处理，最终得到一套可量化可计价的业务运行状况，以确保业务正常稳定运行以及最佳的用户体验效果。
模拟用户行为
一个互联网产品可以看作由一系列独立且具有特定功能的模块组合而成，这些模块间的相互作用构成了整个产品的所有功能。而任意模块的故障都会影响整个业务的正常运行，所以我们都会对产品的关键模块会重点关注。
对于关键模块，我们可以要求 Dev 提供监控接口，通过 curl 或者 API 的形式，定期获取响应码以及响应时间，保存历史数据并制作图表。
监控接口应该是完整的，可以模仿用户行为的，比如一个电商站点，一个用户必然会做这些操作：
注册
登录
添加购物车
生成订单
付款
这些步骤都属于用户级别的核心体验指标，必须提供相应的监控接口供运维长期监控其正常运行，监控数据也需要可视化处理，任何异常都能直接通过图表反映出来，后期也根据实际情况建立相应指标的告警模型和容量管理模型。
业务监控--用户来源分析
用户来源分析也是一个非常实用的业务级监控，通过各种客户端技术获取用户真实IP，如果是通过HTTP协议则需要 x-forwarded-for 来跟踪用户的真实IP，收集好IP信息和用户对应关系后，通过数据分析IP库得出用户所在地区、ISP等信息，然后就可以得出我们实际业务的当前用户地区、ISP分布图，然后结合中国地图前端控件制造图表。
只是展示还是不够的，还要结合类似前面例子的历史对比方法，如果发现某省份或者某ISP的用户比上个对比周期剧减了，那就反映了当地骨干网、DNS或者CDN等发生故障，让运维工程师可以迅速定位故障源头。
智能伸缩(辅助运营)/成本控制
辅助运营的说法是运维业界近几年才提出来的，
游戏行业经常有开服、合服的操作，用通用的说法就是扩容和缩容，因为一个游戏的生存周期很短，从内测、公测、引入期、成长期、成熟期到衰退期说不定总共就一两年的时间，扩容和缩容操作的高效、快速反映了运维团队的服务能力，也对公司的运营成本节约有着重大的意义。
开服，即扩容的操作一般经常发生在引入期和成长期；合服，一般是在成熟期和衰退期。
开新服是游戏运营中的一种刺激玩家人数增长的良好手段，因为在老服中排名相对一般的玩家，去新服往往可以获得更多的进步空间和利益，刺激用户消费来换取用户成就感。
而合并老服务器，可以把N个活跃人数较低的鬼服组合在一起重新焕发生命力，游戏必须基于一定的人数才能完全体现游戏价值，这样用户才有继续升级的欲望。
开服策略
那么怎样选择最佳的开服时间呢，运维部门怎样利用技术手段协助判断？
根据运营策略，开服的最佳时间是用户登录数最高的时间段，因为这样用户才更高的概率发现有新服开了并进入新服。
在前面的业务监控部分，我们已经掌握了各种业务指标数据，当然必须包含用户登陆数这个重要数据。
可以看出，对于手游来说用户登录数在12点、19点以及23点左右都有一个峰值出现，分别对应午休、下班和临睡觉的三个时刻，我们该如何选择呢？
一般在开服前，运维工程师已经对机器初始化完毕，并部署好业务代码，联调各种辅助系统并交给QA测试。测试完毕后会经过清档、业务活动配置、再次测试等流程。
这些环节都需要技术同事和运营同事共同参以确保整个流程正确无误，所以开服时间理论上放在工作时间会比较好，因为这个时间大家都在公司可以更好地沟通交流。
如果游戏是联运项目还需要和第三方供应商联调，就更加需要在双方都在线的时间比较好，否则一旦出现异常情况就会影响处理的响应时间。
综上，开新服时间要么定在12点要么在19点比较合适，至于具体的精确时间，可以根据历史峰值所在的时刻自动触发即可，这在技术层面很容易实现。
合服策略
对比开服，合服是一个更加复杂的业务操作，能否正确选择哪些服该合并既反映了运营人员的业务水平的高低，也对公司的业务运营情况有正面促进的作用。
我们也可以通过系统运维的角度来协助分析，利用数据指标来给他们提供更优的选择。
合服需要考虑的指标大概有以下两大类：业务指标和系统指标。
其中业务指标大多数需要通过业务数据库统计获得，而系统指标需要根据 CMDB 的各种信息统计，最终可以匹配出一系列适合合服的服列表信息。
至于具体的判断算法和评判标准，需要和 运营、开发 等业务部门同事反复讨论确定，因为各家业务情况不同，这里不多作展开。
成本控制
线上服务器以及带宽等硬件资源是否已经达到最优利用率？我们有没有可量化的分析方法并持续优化？
业务是否有不科学的功能点在极度浪费线上硬件成本资源或者对用户体验不佳，运维部门如何量化并反馈业务部门整改？
如果运维团队能做到以上内容，我们的定位就不再是一个支撑后勤岗位，不再是成本中心，而是作为一个可以理解运营策略且可以为业务部门作出价值贡献的核心环节。
先举一些其他业务形态的例子：比如某某业务功能同比增加了多少活跃用户、提高了多少付费率，为公司创造了多少GDP等等。
那我们做运维平台的意义在哪里呢？对内价值就是降低了多少故障率、提升了多少工作效率、节约了多少人力资源等；最好是不仅将其定位为一个内部辅助系统，需要将其和业务侧的墙打破，介入业务发展的生命周期，这样做才能将运维价值最大化地变现。
运维平台中和业务运营相关密切的功能模块一般有数据分析、弹性伸缩(辅助运营)、成本核算、用户体验优化(业务监控)等等，如何才能包装好运维平台和为其讲一个好故事，也是运维产品经理的职责所在。如何能让不了解运维业务的领导们或者外部门的同事们都能理解、认可运维价值，其意义是非常重大的。
讲故事的核心一般是围绕四要素：「质量」、「效率」、「安全」、「成本」，每年的业绩、KPI、成果汇报不外乎都是落在这四个纬度。
怎么体现整个运维团队的价值体现，简单粗暴就是数据说话，因为老板们才不管运维团队具体用了什么黑科技。
比如：
核心业务全年可用时间达 99.999%，全年故障次数低于 3 次；
人均维护机器数 10000 以上，人均维护业务集群数 5 个以上；
日持续发布频率达到 30 以上，故障率低于 0.1%，发布时长低于 60 秒；
大数据平台数据量 1000T 以上，全国 CDN 流量 10000G 以上；
硬件成本降低50%，每年为公司节省10个亿；
备注：以上数据纯属虚构！
总结
所谓的产品思维在不同的业务形态中可以演化出不同的能力，而运维也是一种特殊的业务形态，我们可以利用产品思维来更好地解决工作中遇到的问题。把运维服务当作一种产品，我们可以将这个产品平台化、精细化、实体化，通过实践 DevOps 理念，打破业务侧、研发侧、运维侧之间无形的墙， 然后用一种类似 PaaS 的方式来为业务团队提供高质量、高性能、高可用、低成本、快速的运维体系服务。而基于产品思维来驱动运维团队，也许能让运维工作更有意思。