cloudwise

好像挂了有一小时。

监控宝可以多区域去监控服务器，网站的健康状况，还包含了一些国外节点（我们的业务涉及海外），而且阀值这块可以自己去定义。其中最重要的就是 callback 告警消息。如果我们在服务器网络或者其他原因导致宕机，收到的不是告警消息，而让他们能够根据消息去自动处理是不是会更好呢。给大家一副图来理解下：


根据回调信息，事先将其定义成一些规则，当我们匹配到了告警信息中的特定信息可以自主切换.

监控宝的 URL 回调可以在这里设置：


运维监控的发展： 
过去： nagios 、 cacti 、 zabbix 监控单一，对告警后知后觉
现在： API 监控数据聚合、告警信息收敛，自动化感知
未来：挖掘故障信息，制定故障自愈规则，提前感知
所以我们未来要做的就是要收集告警信息进行自动化处理，而不是通知运维上线处理。
我们要脱离那种每天等着告警信息去处理故障，要主动出击，不要等到故障了再去处理，及时处理好了，那么时间成本也是很高的。

监控宝可以多区域去监控服务器，网站的健康状况，还包含了一些国外节点（我们的业务涉及海外），而且阀值这块可以自己去定义。当然作为一个运维人员，我看中的其实并不是这些。其中最重要的就是 callback 告警消息。如果我们在服务器网络或者其他原因导致宕机，收到的不是告警消息，而让他们能够根据消息去自动处理是不是会更好呢。给大家一副图来理解下：

根据回调信息，事先将其定义成一些规则，当我们匹配到了告警信息中的特定信息可以自主切换

比如我们以一台服务器为单位，每分钟的告警分系统和网络统一来处理。（当然可以以收件人，业务关联为单位）。对于传染型的故障，比如网站报了 500 错误，那么我们发现 500 错误的时候，在告警的时候是不是可以让他去错误日志里收集关于相同 IP 的 error ，一起发送
所以我们未来要做的就是要收集告警信息进行自动化处理，而不是通知运维上线处理。
我们要脱离那种每天等着告警信息去处理故障，要主动出击，不要等到故障了再去处理，及时处理好了，那么时间成本也是很高的。我们在做监控的时候需要 考虑很多不可控的因素。在写代码的时候 要首先考虑异常状态，否则造成二次故障，是我们不愿意看到的。当故障 IP 2 小时内不丢包，我们就把他去掉。下次切换的时候就可以用到，反之亦然。这里提示下，对于这种时间周期可以使用 redis ， expire 指定他的 ttl
给大家一张图来理解下告警信息的分类


我们要做到能自动化的尽量自动化，不能够自动化的我们要让他半自动。人工处理是最后的方案，因为是人就会犯错，尤其在业务出现异常，操作都是不可控的。推荐大家试试监控宝： http://www.jiankongbao.com

其实这个问题可以先来看未来需要怎样的 cio ，然后按照这些要求来准备。随着大数据、互联网的发展，以及对用户体验的要求不断提高， CIO 的侧重点也会有所变化
1 、最基本要求， IT 系统的稳定性保障，比如“系统稳定运行时间 99.9%”等。这要求运维非常清楚自己的 IT 环境，性能监控、优化等。
2 、对业务的关注度越来越高。在竞争异常激烈的互联网+时代，业务对 IT 的依赖程度越高， IT 对业务的影响就越大，根据 IT 基础架构运行指标建立的 ITIL 管理体系已经无法满足企业 IT 互联网化的发展需求，必须重新建立符合互联网+业务运维指标体系和管理平台，这就对企业管理层提出了更高要求：如何将运维与业务紧密关联，甚至直接提升为企业核心高度进行统筹管理。
3 、运维的本质是可视化。随着大数据的应用越来越深入，运维的所有决策也要依赖数据。如果让运维数据如何快速的可视化，也是一种技能。
现在 CIO 自身价值的体现与商业模式创新和企业核心业务转型已经是密不可分的。最近我们云智慧在这个趋势上就做了一些调整，提出了业务运维体系，就是以业务增值为目标，在原有 IT 系统的基础上，对业务、 IT 支撑和管理三个维度进行有效梳理，把业务流程、业务结果、业务效率和业务评价数据和基于前端用户体验的 IT 性能数据，通过统一的大数据平台进行采集、存储、处理和趋势预测分析，最后通过数据可视化工具把分析结果以报表和趋势图的方式展现出来。
所以在这些变化的基础上来补充自己的能力。比如：对系统架构的熟悉度、对业务流程的深度理解、对大数据可视化对应用，还有沟通能力等等。



另外，炫耀下我们业务运维可视化的效果：）

其实这个问题可以先来看未来需要怎样的 cio ，然后按照这些要求来准备。随着大数据、互联网的发展，以及对用户体验的要求不断提高， CIO 的侧重点也会有所变化
1 、最基本要求， IT 系统的稳定性保障，比如“系统稳定运行时间 99.9%”等。这要求运维非常清楚自己的 IT 环境，性能监控、优化等。
2 、对业务的关注度越来越高。在竞争异常激烈的互联网+时代，业务对 IT 的依赖程度越高， IT 对业务的影响就越大，根据 IT 基础架构运行指标建立的 ITIL 管理体系已经无法满足企业 IT 互联网化的发展需求，必须重新建立符合互联网+业务运维指标体系和管理平台，这就对企业管理层提出了更高要求：如何将运维与业务紧密关联，甚至直接提升为企业核心高度进行统筹管理。
3 、运维的本质是可视化。随着大数据的应用越来越深入，运维的所有决策也要依赖数据。如果让运维数据如何快速的可视化，也是一种技能。
现在 CIO 自身价值的体现与商业模式创新和企业核心业务转型已经是密不可分的。最近我们云智慧在这个趋势上就做了一些调整，提出了业务运维体系，就是以业务增值为目标，在原有 IT 系统的基础上，对业务、 IT 支撑和管理三个维度进行有效梳理，把业务流程、业务结果、业务效率和业务评价数据和基于前端用户体验的 IT 性能数据，通过统一的大数据平台进行采集、存储、处理和趋势预测分析，最后通过数据可视化工具把分析结果以报表和趋势图的方式展现出来。
所以在这些变化的基础上来补充自己的能力。比如：对系统架构的熟悉度、对业务流程的深度理解、对大数据可视化对应用，还有沟通能力等等。



另外，炫耀下我们业务运维可视化的效果：）

用我们做过的一个案例来说吧：
是一个比较知名的全球快消连锁公司，系统包括订单系统、 CRM 系统、日志系统、交易系统、订单系统等。他们的需求是通过一个大屏，一眼看到这些用户交易是否正常、是否有失败的交易，如果有故障能够快速准确定位到故障位置。



原来他们的系统是比较分散的，出了问题，查起来也比较麻烦，有时候都无法重现。

所以我们总体的思路是先梳理业务流程，然后把用户体验的数据监控起来，并把业务和 IT 数据进行关联，最后借助数据可视化平台进行展示。
基本上是个这个结构：



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

给你们炫耀下最后实现的大屏样式





所以，现在他们看一个大屏就能知道那个业务系统有问题，问题在哪里，从过端到端一排查，一层层追踪定位，很快就可以知道问题在哪里了。

是不是很酷：）

最后做个广告，需要我们云智慧这种业务运维解决方案的同学，快来找我，快来找我。

费用根据肯定是根据自己的需求来定制的，反正现在是免费的，先用呗~