游戏平台运维自动化扩展之故障自愈

LinuxcloudwiseAPM 发表了文章 • 0 个评论 • 145 次浏览 • 2016-11-22 11:04 • 来自相关话题

马辰龙,负责某大型网页游戏平台的运维开发,专注于运维自动化、监控系统故障自愈研究,擅长Perl开发、正则表达式、日志精确匹配。




 

网络游戏是对用户体验要求最严苛的IT行业之一,任何IT问题造成的业务不稳定,都可能导致玩家的流失,进而影响游戏商的营收。因此,自动化运维对于游戏平台的重要不言而喻,各种DevOps产品和自动化运维技术方案不断涌现,包含发布变更、容量伸缩、故障自愈等多种场景的游戏运维技术日趋成熟,这些改变都让运维工作流程越来越简化。
然而流程的简化并不意味着运维变得容易,恰恰相反随着云计算、移动互联网的广泛应用,游戏业务对运维的要求水涨船高!相比起对IT基础设施运维操作的需求,业务侧更需要运维提供高质量的业务保障服务,包括对业务架构及部署的持续优化,精细化的游戏健康度管理,以及快速的故障处理服务等。
以下就是由马辰龙先生为我们分享他在日常工作中总结的《游戏平台运维自动化扩展之故障自愈》:
大家好,我们用一个例子作为今天分享的开始,越来越复杂的网络问题常常会造成各种误报,导致各种误报信息的轰炸,出现报警我们一般先看报警内容,这种情况大家都遇到过吧?久而久之就造成了对告警信息的麻木。比如凌晨2点某机房切割网络抖动,一下过来几百条告警短信,相信大家不可能一条条的看。
首先我们要解决的是误报的问题。现在的监控软件无非就是Zabbix 、Nagios或者 SmokePing 这类,还会有一些单点监控软件。如果想消除误报只有多IDC去部署监控服务器,搭建多节点去监控网络问题,但这就需要使用大量的服务器资源,有没有什么好的解决方案呢?而且即使我们搭建了大量的监控服务器,又怎么去集中处理告警消息呢?
经过对市面上流行的监控类产品进行广泛调研,发现云智慧的监控宝可以通过分布式监测节点,多区域同时监控服务器、网站的健康状况,同时还提供一些国外节点(我们的业务涉及海外)监测海外用户的业务访问体验,而且阈值和监控方式也可以根据业务的实际需求去自定义。
当然作为一个崇尚运维自动化的运维人员,我看中的不仅是这些,更重要的是能够callback告警消息。如果是因为服务器网络或者其他原因导致宕机,在收到告警消息之后,让后端系统能够根据消息去自动处理是不是会更好呢。给大家看一副图来理解下:




根据回调信息,事先将其定义成一些规则,当我们匹配到了告警信息中的特定信息可以自主切换。
监控宝的URL回调可以在这里设置:




运维监控的发展: 
过去:Nagios、Cacti、Zabbix 监控单一,对告警后知后觉;
现在:API监控数据聚合、告警信息收敛,自动化感知;
未来:挖掘故障信息,制定故障自愈规则,提前感知。




运维的建设有四个阶段,简称为四化建设:第一个阶段就是标准化。标准化的意思是把主机名、内网以及配置文件统一起来,如果不统一,后面的东西就无法继续。没有一个标准化的环境,脚本是无法写下去的。第二个阶段是自动化。中小型企业阶段都是自动化到平台化的过渡,平台化就是把自动化的东西分装,把功能整合,把数据做聚合,然后放在平台上来可视化。第三个阶段是平台化。以后的趋势是脚本和功能必须是外部化的,这样新来的一个人才能接手。不用在服务器上跑脚本,还要同下个人交代在哪儿装。最后一个阶段就是服务化。服务化是指现在云平台所承载的东西。举个例子,搭一个redis集群,用户不需要知道服务器有多少个,因为所提供的NOSQL服务打开后,用户就可以直接使用了。
所以我们未来要做的就是收集告警信息进行自动化处理,而不是通知运维上线处理。我们要脱离那种每天等着告警信息去处理故障,要主动出击,不要等到故障了再去处理,而且即使事后处理好了,那么时间成本也是很高的。
再举个栗子,一个网站在全国各地会解析为多个IP,而且还会有备用IP用来切换(被DDOS的时候,IP被封,我们需要切换)。我们会有一个脚本去检测这些IP的状态,当这些IP正常的时候才会切换到这些IP上,如果Ping不通或者有其他故障就不会去切换,否则去切换一个故障IP不是没有用吗?
我们在做监控的时候需要考虑很多不可控的因素,因此在写代码的时候要首先考虑异常状态,否则会造成二次故障,这是我们不愿意看到的。当故障IP 2小时内不丢包,我们就把他去掉,下次切换的时候就可以用到,反之亦然。这里提示下,对于这种时间周期可以使用redis,expire 指定ttl。
给大家一张图来理解下告警信息的分类:




我们要做到能自动化的尽量自动化,不能自动化的我们要让它半自动,人工介入处理是最后的方案,因为是人就会犯错,尤其在业务出现异常,操作都是不可控的。
说这么多 ,核心就是需要建立自己的消息处理中心来分析问题,充分利用告警信息,大概的模型可以是这样:




最后,故障自愈能够给我们带来什么:
1、非工作时间运维人员处理故障以及响应时间;
2、减少直接的线上操作、避免出现人为原因的二次故障;
3、提高运维人员对故障原因的分析、以及工作积极性;
4、提升运维的自身价值。
Q&A
问:如何做告警收敛?
答:比如我们以一台服务器为单位,每分钟的告警信息分为系统和网络告警,统一处理。(当然也能以收件人,业务关联为单位。)
问:对于传染型的故障,不知道有没有什么好的方案呢,就是反复访问一个问题导致骨牌性的反应。
答:比如网站报了500错误,那么我们发现500错误的时候,在告警的时候可以让它去错误日志里收集关于相同IP的error,一起发送。
问:怎么自动化的?
答:减少我们去服务器查日志的时间,频繁的grep xxx。
问:百度爬虫并发大没抗住,怎么自动化处理?
答:首先你是想让它爬还是不爬,不爬就匹配useragent。
问:你们故障自愈是哪些情况?是通过日志?还是api url监控?通过特定故障返回特定值??因为java的日志各种情况都有。
答:面对DDOS流量型攻击,通过分析url使用防火墙封禁,首先是日志。
问:DDOS怎么分析url??有什么特征吗??
答:DDOS是没有日志的,可以通过网络告警去触发,CC攻击分析你的URL,规则可以自己去定义,有些注入、刷API等通过正则去匹配。运维人员要利用好日志,所有的问题都是从日志中分析行为发现的。
问:我们上了ELK,Java除了假死自动重启,好像没什么自愈的。
答:ELK可以使用API拉日志,去分析业务的运行状态,ELK的面太大,这里细节就不多说了。




云智慧是业务运维解决方案服务商,旗下产品监控宝、透视宝、压测宝,已累计为电商、移动互联网、广告传媒、在线游戏、教育医疗、金融证券、政企等行业的几十万用户提供了一站式的应用性能监控、管理及测试服务。 查看全部
马辰龙,负责某大型网页游戏平台的运维开发,专注于运维自动化、监控系统故障自愈研究,擅长Perl开发、正则表达式、日志精确匹配。

图片1.png
 

网络游戏是对用户体验要求最严苛的IT行业之一,任何IT问题造成的业务不稳定,都可能导致玩家的流失,进而影响游戏商的营收。因此,自动化运维对于游戏平台的重要不言而喻,各种DevOps产品和自动化运维技术方案不断涌现,包含发布变更、容量伸缩、故障自愈等多种场景的游戏运维技术日趋成熟,这些改变都让运维工作流程越来越简化。
然而流程的简化并不意味着运维变得容易,恰恰相反随着云计算、移动互联网的广泛应用,游戏业务对运维的要求水涨船高!相比起对IT基础设施运维操作的需求,业务侧更需要运维提供高质量的业务保障服务,包括对业务架构及部署的持续优化,精细化的游戏健康度管理,以及快速的故障处理服务等。
以下就是由马辰龙先生为我们分享他在日常工作中总结的《游戏平台运维自动化扩展之故障自愈》:
大家好,我们用一个例子作为今天分享的开始,越来越复杂的网络问题常常会造成各种误报,导致各种误报信息的轰炸,出现报警我们一般先看报警内容,这种情况大家都遇到过吧?久而久之就造成了对告警信息的麻木。比如凌晨2点某机房切割网络抖动,一下过来几百条告警短信,相信大家不可能一条条的看。
首先我们要解决的是误报的问题。现在的监控软件无非就是Zabbix 、Nagios或者 SmokePing 这类,还会有一些单点监控软件。如果想消除误报只有多IDC去部署监控服务器,搭建多节点去监控网络问题,但这就需要使用大量的服务器资源,有没有什么好的解决方案呢?而且即使我们搭建了大量的监控服务器,又怎么去集中处理告警消息呢?
经过对市面上流行的监控类产品进行广泛调研,发现云智慧的监控宝可以通过分布式监测节点,多区域同时监控服务器、网站的健康状况,同时还提供一些国外节点(我们的业务涉及海外)监测海外用户的业务访问体验,而且阈值和监控方式也可以根据业务的实际需求去自定义。
当然作为一个崇尚运维自动化的运维人员,我看中的不仅是这些,更重要的是能够callback告警消息。如果是因为服务器网络或者其他原因导致宕机,在收到告警消息之后,让后端系统能够根据消息去自动处理是不是会更好呢。给大家看一副图来理解下:
图片2.png

根据回调信息,事先将其定义成一些规则,当我们匹配到了告警信息中的特定信息可以自主切换。
监控宝的URL回调可以在这里设置:
图片3.png

运维监控的发展: 
过去:Nagios、Cacti、Zabbix 监控单一,对告警后知后觉;
现在:API监控数据聚合、告警信息收敛,自动化感知;
未来:挖掘故障信息,制定故障自愈规则,提前感知。
图片4.png

运维的建设有四个阶段,简称为四化建设:第一个阶段就是标准化。标准化的意思是把主机名、内网以及配置文件统一起来,如果不统一,后面的东西就无法继续。没有一个标准化的环境,脚本是无法写下去的。第二个阶段是自动化。中小型企业阶段都是自动化到平台化的过渡,平台化就是把自动化的东西分装,把功能整合,把数据做聚合,然后放在平台上来可视化。第三个阶段是平台化。以后的趋势是脚本和功能必须是外部化的,这样新来的一个人才能接手。不用在服务器上跑脚本,还要同下个人交代在哪儿装。最后一个阶段就是服务化。服务化是指现在云平台所承载的东西。举个例子,搭一个redis集群,用户不需要知道服务器有多少个,因为所提供的NOSQL服务打开后,用户就可以直接使用了。
所以我们未来要做的就是收集告警信息进行自动化处理,而不是通知运维上线处理。我们要脱离那种每天等着告警信息去处理故障,要主动出击,不要等到故障了再去处理,而且即使事后处理好了,那么时间成本也是很高的。
再举个栗子,一个网站在全国各地会解析为多个IP,而且还会有备用IP用来切换(被DDOS的时候,IP被封,我们需要切换)。我们会有一个脚本去检测这些IP的状态,当这些IP正常的时候才会切换到这些IP上,如果Ping不通或者有其他故障就不会去切换,否则去切换一个故障IP不是没有用吗?
我们在做监控的时候需要考虑很多不可控的因素,因此在写代码的时候要首先考虑异常状态,否则会造成二次故障,这是我们不愿意看到的。当故障IP 2小时内不丢包,我们就把他去掉,下次切换的时候就可以用到,反之亦然。这里提示下,对于这种时间周期可以使用redis,expire 指定ttl。
给大家一张图来理解下告警信息的分类:
图片5.png

我们要做到能自动化的尽量自动化,不能自动化的我们要让它半自动,人工介入处理是最后的方案,因为是人就会犯错,尤其在业务出现异常,操作都是不可控的。
说这么多 ,核心就是需要建立自己的消息处理中心来分析问题,充分利用告警信息,大概的模型可以是这样:
图片6.png

最后,故障自愈能够给我们带来什么:
1、非工作时间运维人员处理故障以及响应时间;
2、减少直接的线上操作、避免出现人为原因的二次故障;
3、提高运维人员对故障原因的分析、以及工作积极性;
4、提升运维的自身价值。
Q&A
问:如何做告警收敛?
答:比如我们以一台服务器为单位,每分钟的告警信息分为系统和网络告警,统一处理。(当然也能以收件人,业务关联为单位。)
问:对于传染型的故障,不知道有没有什么好的方案呢,就是反复访问一个问题导致骨牌性的反应。
答:比如网站报了500错误,那么我们发现500错误的时候,在告警的时候可以让它去错误日志里收集关于相同IP的error,一起发送。
问:怎么自动化的?
答:减少我们去服务器查日志的时间,频繁的grep xxx。
问:百度爬虫并发大没抗住,怎么自动化处理?
答:首先你是想让它爬还是不爬,不爬就匹配useragent。
问:你们故障自愈是哪些情况?是通过日志?还是api url监控?通过特定故障返回特定值??因为java的日志各种情况都有。
答:面对DDOS流量型攻击,通过分析url使用防火墙封禁,首先是日志。
问:DDOS怎么分析url??有什么特征吗??
答:DDOS是没有日志的,可以通过网络告警去触发,CC攻击分析你的URL,规则可以自己去定义,有些注入、刷API等通过正则去匹配。运维人员要利用好日志,所有的问题都是从日志中分析行为发现的。
问:我们上了ELK,Java除了假死自动重启,好像没什么自愈的。
答:ELK可以使用API拉日志,去分析业务的运行状态,ELK的面太大,这里细节就不多说了。
二维码.png

云智慧是业务运维解决方案服务商,旗下产品监控宝、透视宝、压测宝,已累计为电商、移动互联网、广告传媒、在线游戏、教育医疗、金融证券、政企等行业的几十万用户提供了一站式的应用性能监控、管理及测试服务。

坑爹双十一零点秒杀背后的API性能问题初探

LinuxcloudwiseAPM 发表了文章 • 0 个评论 • 122 次浏览 • 2016-11-14 14:19 • 来自相关话题

我很喜欢吃苹果,尤其是新疆阿克苏的冰糖心,这不,快到双十一了,有个店家的优惠力度很很大:1份5斤才79元,第2份1元,折合8块钱1斤。所以我早早的就把苹果放进了购物车里,想着香甜的大苹果,定了闹钟,就等着凌晨支付了,。

 






盼望着盼望着,终于可以支付了,我愉快地拿起手机打开应用支付订单,等支付确认之后,我才发现,貌似店家没有给我优惠哦!怎么两份苹果要了79*2=158元呢?真郁闷,这不简直是赤果果的消费欺诈不成?所以我选择退款!必须退!结果更让人崩溃,点击退款之后系统的提示是这样的!

 






不得不佩服这个店家的服务,一会短信就过来了,店家抱歉说是因为系统因为访问量太大出现了故障,所以可以支付完成之后找店家补差价。哦,原来是这样!本来还以为是店家欺诈呢。

 






郁闷地打开朋友圈,想发发牢骚,结果看见朋友圈里中招的小伙伴相当多呢。

 















 

看了这些顿时精神一震,好歹我也是个高级运维工程师呀,还懂代码开发,就是传说中的DevOps,爬起来我开始分析:一般这种商品两件优惠大致有几种策略(可能还有,我买的比较少,没有看到):

1) 第2份0元,就是所谓的五折嘛!

2) 第2份1元,比五折那么一点点;

3) 第2份每斤1元;

那么在加入购物车选择结账的时候,系统发生了什么?我猜想是这样的:

 






按照这个流程来讲的话,就是万恶的“减免计算接口”出现了问题!估计是对应的后端服务宕机了,或者我所在的北京地区的网络出现了问题,导致在调用这个接口的时候出现了异常,不过真心佩服电商平台技术,做了很多的异常判断,明显是当“减免计算接口”出现异常的时候,系统能够继续正常执行,当然此时就第2份就不会优惠了。

接口很重要!接口很重要!接口很重要!

所以在系统上线前有必要对接口进行大规模并发下的压力测试,首先要保障提供接口服务的程序不掉链子,能够抗住那么多流量,其实这样还不够,因为仅仅关注后端是不够的,现在的应用架构太复杂了,网络、CDN等都是影响接口正常质量的很重要的因素,所以必须能够在全链路的真实环境下对系统进行压测,这样就能判断哪些地区,哪些运营商可能导致的用户不爽。

正在这时,上海同学告诉我他在凌晨正常下单支付了!好吧,这说明上海并没有受到类似不良接口的影响。

仅仅是全链路压测够不够呢?其实还不够,因为在真实环境下,各种状况层出不穷,瞬息万变,测试做的再好也只能尽可能真实的模拟未来发生的情况,但是实际上还是会有不可预想的事情发生,所以我们还需要监控!比如我就用监控宝的API监控把公司应用里的那么多关键接口进行了7X24小时的实时监控,能够通过云智慧的全球监测点对接口调用的可用性、正确性和响应时间进行实时监测,当有问题的时候第一时间获得短信或者电话语音的告警通知,经过分析快照快速定位和解决问题——这一切只要在老板知道以前处理掉,今年的优秀员工就是我啦。

最后问一句,谁认识负责“减免计算接口”服务的运维同学?我想和他聊聊去。 查看全部
我很喜欢吃苹果,尤其是新疆阿克苏的冰糖心,这不,快到双十一了,有个店家的优惠力度很很大:1份5斤才79元,第2份1元,折合8块钱1斤。所以我早早的就把苹果放进了购物车里,想着香甜的大苹果,定了闹钟,就等着凌晨支付了,。

 
图片1.jpg



盼望着盼望着,终于可以支付了,我愉快地拿起手机打开应用支付订单,等支付确认之后,我才发现,貌似店家没有给我优惠哦!怎么两份苹果要了79*2=158元呢?真郁闷,这不简直是赤果果的消费欺诈不成?所以我选择退款!必须退!结果更让人崩溃,点击退款之后系统的提示是这样的!

 
图片2.png



不得不佩服这个店家的服务,一会短信就过来了,店家抱歉说是因为系统因为访问量太大出现了故障,所以可以支付完成之后找店家补差价。哦,原来是这样!本来还以为是店家欺诈呢。

 
图片3.png



郁闷地打开朋友圈,想发发牢骚,结果看见朋友圈里中招的小伙伴相当多呢。

 
图片4.png


图片5.png


图片6.png


 

看了这些顿时精神一震,好歹我也是个高级运维工程师呀,还懂代码开发,就是传说中的DevOps,爬起来我开始分析:一般这种商品两件优惠大致有几种策略(可能还有,我买的比较少,没有看到):

1) 第2份0元,就是所谓的五折嘛!

2) 第2份1元,比五折那么一点点;

3) 第2份每斤1元;

那么在加入购物车选择结账的时候,系统发生了什么?我猜想是这样的:

 
图片7.png



按照这个流程来讲的话,就是万恶的“减免计算接口”出现了问题!估计是对应的后端服务宕机了,或者我所在的北京地区的网络出现了问题,导致在调用这个接口的时候出现了异常,不过真心佩服电商平台技术,做了很多的异常判断,明显是当“减免计算接口”出现异常的时候,系统能够继续正常执行,当然此时就第2份就不会优惠了。

接口很重要!接口很重要!接口很重要!

所以在系统上线前有必要对接口进行大规模并发下的压力测试,首先要保障提供接口服务的程序不掉链子,能够抗住那么多流量,其实这样还不够,因为仅仅关注后端是不够的,现在的应用架构太复杂了,网络、CDN等都是影响接口正常质量的很重要的因素,所以必须能够在全链路的真实环境下对系统进行压测,这样就能判断哪些地区,哪些运营商可能导致的用户不爽。

正在这时,上海同学告诉我他在凌晨正常下单支付了!好吧,这说明上海并没有受到类似不良接口的影响。

仅仅是全链路压测够不够呢?其实还不够,因为在真实环境下,各种状况层出不穷,瞬息万变,测试做的再好也只能尽可能真实的模拟未来发生的情况,但是实际上还是会有不可预想的事情发生,所以我们还需要监控!比如我就用监控宝的API监控把公司应用里的那么多关键接口进行了7X24小时的实时监控,能够通过云智慧的全球监测点对接口调用的可用性、正确性和响应时间进行实时监测,当有问题的时候第一时间获得短信或者电话语音的告警通知,经过分析快照快速定位和解决问题——这一切只要在老板知道以前处理掉,今年的优秀员工就是我啦。

最后问一句,谁认识负责“减免计算接口”服务的运维同学?我想和他聊聊去。

什么是业务运维,企业如何实现互联网+业务与IT的融合

IT新闻cloudwiseAPM 发表了文章 • 0 个评论 • 134 次浏览 • 2016-10-27 11:33 • 来自相关话题

业务运维并不是一个新概念,针对传统信息架构提出的业务服务管理就是把以业务为核心的IT系统与IT基础设施性能进行整合运维的解决方案。然而随着互联网+转型的不断推进,基础设施的智能化和广泛云化成为IT发展的“新常态”,只关注IT基础设施、系统与应用软件的稳定性与性能状况的传统运维手段,越来越难以满足企业业务高速发展的需求。

互联网+时代的业务运维是IT运维与互联网深度融合的产物,是运维管理在云计算、大数据技术推动下的必然结果。业务运维是以用户体验为核心,以业务价值为导向,严格遵循业务运维监控指标体系和业务运维考评规范,通过梳理业务系统、支撑系统和管理系统的业务流程,对业务数据和IT性能进行大数据采集、整理和关联分析并实时映射到全局业务拓扑图上,借助数据可视化工具呈现出来,从而帮助管理者在纷繁复杂的业务数据和IT性能数据中找到业务规划和企业发展的方向,实现应用性能的持续提升和业务的高速增长。

 






以互联网成熟度最高的电商行业为例,当IT系统发生故障,通过浏览器、手机应用访问电商平台的广大用户会第一时间得到业务不可用的报错信息,传统IT面向技术和基础架构的运维模式由于缺乏对业务系统的深入了解,在接到运营部门反馈的业务故障投诉后,需要对各种关联系统的网络、应用、数据库、主机进行逐一排查,故障处置周期长、效率低,对业务造成严重影响。

因此,互联网+业务与IT的融合首先要求企业转变传统运维模式,在对基础架构和系统的运行质量进行主动式运维监控的同时,从真实用户体验的视角出发对业务系统的实际支撑环节进行关联和透视,并以此为基础构建起企业业务运维支撑平台。

 






业务运维支撑平台的构建要从业务系统、业务管理和IT支撑三个维度入手,对所有IT系统进行有效梳理。业务系统是企业生产、经营的基础,也是业务数据产生的源头,从功能上覆盖企业的营销规划、销售管理、客户管理等,具体包括ERP系统、交易系统、订单系统、支付系统、物流系统、供应链系统、CRM系统等;业务管理解决企业内部人员、绩效问题的组织系统,包括业务流程、业务结果、业务效率和业务评价等;而IT支撑则不但要覆盖传统IT运维IT基础设施监控,还要包括针对网络、应用端主动监控和应用性能管理的相关产品模块;这三个维度的系统和数据构成了业务运维的三维立体模型,并根据业务指标与用户体验指标建立起基于业务质量的动态监控指标体系,形成相应的S-KPI、KQI,为后期业务运维建立指标基础。






 

运维部门把业务系统、业务管理和IT支撑服务模块遵循三维模型映射到底层应用拓扑,再从业务流程环节对设备、平台、云资源、应用/服务、外部API进行梳理和关联,得到业务拓扑的分层逻辑架构视图,通过基于用户行为的端到端全栈性能问题定位、基于全球分布式网络的用户体验主动感知、基于云端压力测试平台的业务容量规划系统具对不同数据源的业务数据和性能数据进行实时采集、处理、预测和关联分析。

最后,把业务指标数据、性能指标数据和趋势分析、预测数据在业务运维大屏上进行实时展示,运维人员可以业务视角开展系统运维工作,第一时间发现业务性能瓶颈,快速准确的定位问题,提升业务和系统性能综合管理能力;运营人员能够实时了解前端用户体验、后端业务系统与底层基础设施架构之间的关联关系,正确应对各种突发状况;企业管理者能够根据数据分析报表进行准确的商务决策,从容应对快速变化用户需求和激烈的市场竞争。

业务运维在企业的落地,能够基于大数据技术对现有IT系统进行快速而高效的信息整合,围绕用户体验和业务价值实现用户、产品、业务环节之间实时交互和有效交流,让生产、经营和管理的网络化和扁平化成为现实,为企业的数字化、网络化、智能化、服务化转型打下坚实的基础。

     
  查看全部
业务运维并不是一个新概念,针对传统信息架构提出的业务服务管理就是把以业务为核心的IT系统与IT基础设施性能进行整合运维的解决方案。然而随着互联网+转型的不断推进,基础设施的智能化和广泛云化成为IT发展的“新常态”,只关注IT基础设施、系统与应用软件的稳定性与性能状况的传统运维手段,越来越难以满足企业业务高速发展的需求。

互联网+时代的业务运维是IT运维与互联网深度融合的产物,是运维管理在云计算、大数据技术推动下的必然结果。业务运维是以用户体验为核心,以业务价值为导向,严格遵循业务运维监控指标体系和业务运维考评规范,通过梳理业务系统、支撑系统和管理系统的业务流程,对业务数据和IT性能进行大数据采集、整理和关联分析并实时映射到全局业务拓扑图上,借助数据可视化工具呈现出来,从而帮助管理者在纷繁复杂的业务数据和IT性能数据中找到业务规划和企业发展的方向,实现应用性能的持续提升和业务的高速增长。

 
图片1.png



以互联网成熟度最高的电商行业为例,当IT系统发生故障,通过浏览器、手机应用访问电商平台的广大用户会第一时间得到业务不可用的报错信息,传统IT面向技术和基础架构的运维模式由于缺乏对业务系统的深入了解,在接到运营部门反馈的业务故障投诉后,需要对各种关联系统的网络、应用、数据库、主机进行逐一排查,故障处置周期长、效率低,对业务造成严重影响。

因此,互联网+业务与IT的融合首先要求企业转变传统运维模式,在对基础架构和系统的运行质量进行主动式运维监控的同时,从真实用户体验的视角出发对业务系统的实际支撑环节进行关联和透视,并以此为基础构建起企业业务运维支撑平台。

 
图片1.png



业务运维支撑平台的构建要从业务系统、业务管理和IT支撑三个维度入手,对所有IT系统进行有效梳理。业务系统是企业生产、经营的基础,也是业务数据产生的源头,从功能上覆盖企业的营销规划、销售管理、客户管理等,具体包括ERP系统、交易系统、订单系统、支付系统、物流系统、供应链系统、CRM系统等;业务管理解决企业内部人员、绩效问题的组织系统,包括业务流程、业务结果、业务效率和业务评价等;而IT支撑则不但要覆盖传统IT运维IT基础设施监控,还要包括针对网络、应用端主动监控和应用性能管理的相关产品模块;这三个维度的系统和数据构成了业务运维的三维立体模型,并根据业务指标与用户体验指标建立起基于业务质量的动态监控指标体系,形成相应的S-KPI、KQI,为后期业务运维建立指标基础。

图片2.png


 

运维部门把业务系统、业务管理和IT支撑服务模块遵循三维模型映射到底层应用拓扑,再从业务流程环节对设备、平台、云资源、应用/服务、外部API进行梳理和关联,得到业务拓扑的分层逻辑架构视图,通过基于用户行为的端到端全栈性能问题定位、基于全球分布式网络的用户体验主动感知、基于云端压力测试平台的业务容量规划系统具对不同数据源的业务数据和性能数据进行实时采集、处理、预测和关联分析。

最后,把业务指标数据、性能指标数据和趋势分析、预测数据在业务运维大屏上进行实时展示,运维人员可以业务视角开展系统运维工作,第一时间发现业务性能瓶颈,快速准确的定位问题,提升业务和系统性能综合管理能力;运营人员能够实时了解前端用户体验、后端业务系统与底层基础设施架构之间的关联关系,正确应对各种突发状况;企业管理者能够根据数据分析报表进行准确的商务决策,从容应对快速变化用户需求和激烈的市场竞争。

业务运维在企业的落地,能够基于大数据技术对现有IT系统进行快速而高效的信息整合,围绕用户体验和业务价值实现用户、产品、业务环节之间实时交互和有效交流,让生产、经营和管理的网络化和扁平化成为现实,为企业的数字化、网络化、智能化、服务化转型打下坚实的基础。

     
 

网站功能清单怎么写啊,有没有啥例子!

回复

开发阿书 发起了问题 • 1 人关注 • 0 个回复 • 216 次浏览 • 2016-09-27 15:30 • 来自相关话题