没有天下第一的武功,但如果你的速度够快(比如接近光速),必然无敌。
11 月 20 日晚,深圳龙岗爱联爱新小区里的 54 辆私家车被刮花,等到车主们调取监控录像后才发现,竟是 4 名年龄都不超过 10 岁的「熊孩子」拿着石块把小区里的车辆当成了画画的面板。目前,爱联派出所已介入调查,熊孩子究竟是谁仍在核查中。
由刮车事件引发的联想......
「我们觉得这件事主要还是家长监管和平时教育不到位,并且事发已经好几天了,也没有人主动出来承担责任。」车主李先生表示,小区里过半车俩被刮花,修理费用加起来已超过了15万元,而且由于是人为损坏,保险公司不会理赔,大家都希望这件事能有个结果。「如果这次不弄清楚,担心以后还会出现类似的情况。」事发后业主们纷纷讨要说法。
事虽小,但出现的问题很发人深思:监管、监控不到位,导致群体悲剧上演。如果能在孩子身上放一个类似监控器的东西,当孩子刮第一辆宝马车或者将要做出刮车的这个动作时就可以受到制止,又或者车辆内有足够强大的告警系统,当受到侵害时就能够第一时间传达给车主或者鸣响报警,那结果是不是压根儿就不会这么严重呢?!
说多了,读者该嘲笑我异想天开了。但今天我想说的是,随着企业业务发展的深入,IT 系统也日益复杂。公有云、私有云大规模应用,网络、服务器、软件应用系统之间错综的关联关系,使得 IT 管理和运维人员面对最终用户反映的应用不稳定、系统中断等问题时,无法快速准确的定位问题根源,让企业数据中心的管理和维护面临前所未有的挑战。很多企业正是由于没有做到全方位的监控又或者是告警后没有及时做出有效的补救措施才导致以点到面的受到大批量不可修复的灾难,而 IT 世界里受到的损失可就不是单纯的6位数字那么简单了。
放眼全球,规模和成熟度都很强大的亚马逊、谷歌、Facebook,国内的 BAT 等企业,IT 故障也会频发。全球500强企业里 IT 故障引发的损失也是很常见的,每次故障带出的直接或是间接性的灾难更是巨大:
全球500强故障影响统计
常见的场景:数据服务器在晚间自动备份,引发磁盘空间不足故障,同时关联的应用程序引发故障,从而引发雪崩。2:00监控发现故障,并邮件通知运维一线杨过,然并卵过儿同学在甜蜜梦乡中,直到6点用户投诉,过儿接到老板小龙女的电话,才开始响应处理故障。
我们可以从以上场景中看到,该公司没有建立起有效的值班响应机制,首先没有分派通知到位(邮件不靠谱,电话才靠谱),其次没有形成多人同时支撑的值班流程。及时发现问题,并不意味着能够及时响应。
那么如何有效提升 IT 可靠性,将成为各企业 IT 支撑的重点。本质上来说,应该是及时发现、及时通知值班、及时处理,最终提升IT可靠性,所以需要一个靠谱的告警平台帮助他们解决上述所有问题。
好吧,铺垫这么多,我们也是想做一个小小的广告!下面这位就是广告的「主角」OneAlert ,它能够接收 IT 运营支撑过程中的告警事件,在一个平台上有序、更快的解决告警,让业务更可靠。为了实现这点,OneAlert 还引入告警压缩机制,减少告警数量;并通过多种渠道+自动升级的方式实现通知必达,不遗漏一个告警。
当管理服务器和应用服务规模较大,一般根据用途或者管理职责不同,分配和提醒不同运维负责人。
一线、二线自动化升级,可以根据企业的值班响应要求,设置自动化升级的时间间隔。例如,如果要求10分钟内必须响应故障(确认故障),那么应该设置为5分钟自动化升级。例如一线可以是运维人员,二线是相关测试或开发,三线为主管等。
一线的人员,可以设置为具体的人,也可以是一个排班。排班是指一组成员通过周、日、小时轮值的方式进行值班,有序分发找对人。
多渠道通知,总有一种方式打动你。微信、短信、电话、邮件、以及即将推出的 APP。日常过程中,微信的应用已经深入人心,在方寸屏幕中实现告警确认跟踪。在夜深人静、深入梦乡时,电话总能第一时间通知到达。
注意,这里的传达是指整个团队,从技术手段和团队协作管理手段多重冗余的角度实现。这样下来,我们不难把握所有的 IT 事件,并有序跟踪、建立起 7x24 on call 运维响应机制,IT 事件有序分发、有效通知、协作处理。降低故障恢复时间 MTTR,最终提升 IT 可靠性,即「天下武功无坚不破,唯快不破」,让现实中的悲剧不再重演。
OneAlert 是应用性能管理领军企业 OneAPM 公司旗下产品,也是国内首个 SaaS 模式的云告警平台,集成国内外主流监控/支撑系统,实现一个平台上集中处理所有IT事件,提升IT可靠性。想了解更多信息,请访问 OneAlert 官网 。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。