聊聊监控与运营平台中的一个小问题

最近和几个企业用户讨论运维自动化系统的时候,他们都表示出了对IT运营的一种渴望。其中一个客户说,他们的DBA团队,每天的30%时间要用于处置来自各个部门的各种数据字典变更请求,建张表、加个索引、增加一个表分区等。这不仅浪费了他们十分有限的DBA资源,而且因为运维与开发、业务的脱节,经常出现工单书写不规范,处置工作出现偏差等问题。该建到甲用户的表上的索引加到了乙用户上。他们希望今后的监控运营平台中,这些工作变成自服务工作,用户单位直接提出申请,经过各种审批流程后系统自动完成这些操作。

当时我觉得这些需要要实现自服务也不算困难,需求也十分明确,投入一些开发人员把这个工具做出来不就行了。他当时对我说,老白你仔细想想,这个事情确实是很简单就能做好的吗?于是我们对各种场景进行了讨论。比如说,添加一个索引确实不是什么难事,不过添加索引后可能发生什么,确实有时候会让人想象不到。他们有一次根据业务部门的要求添加了一个索引,然后核心业务就开始频频报警了。系统负载也急剧增加,一个多小时后,他们通过删除了这条新建的索引解决了问题,后来的业务积压使系统在高负载的压力下又跑了一个小时才恢复正常。听到这个故事,我立即就把这个问题想清楚了,以前在银行的核心系统中也遇到过类似的故障,有一次一个客户在交易核心系统的数据库上添加一个索引后,一些SQL的执行计划出现了变化,使用了错误的索引,从而导致整个核心业务的性能出现了问题。

让一个没有任何DBA经验的业务人员或者开发人员来干这种事确实存在很大的风险,哪怕让一个经验十分丰富的开发DBA来干这件事也不见得就能避免上面所说的问题。还有你要创建的索引的种类以及索引的一些参数,这些问题都需要具有一定的知识才能做好。如果我们的操作人员不一定能具备这些知识,那么我们的监控运营平台就应该具有这些智能。我们首先必须建立一系列的规范,根据这些规范可以生成相对合理的执行命令,避免一些低级问题的发生。这些规范可能比较教条和僵化,并不是最优的,但是是最不容易出问题的。另外,我们的平台必须能够一定程度上理解业务,能够自动评估添加索引、增加字段、扩容表空间等这些操作的风险,并为他们找到一个合适的时间去执行。

而在这些命令的执行过程中,监控运营平台需要在后台针对这个操作做全面的跟踪监视,一旦发现命令执行引起了一些严重的问题,就能够根据问题的种类与严重程度采取一系列的动作,包括中止操作、自动回退、向一线二线告警等。当自动化处置工作完成后,我们还需要在一定时间段内对系统的运行状态进行评估,从而确定这个操作并没有严重的副作用。如果任务完成后,数据块系统的整体逻辑读出现不合理的上升,或者和这个索引相关的SQL的执行计划出现了变化,执行开销都有明显的上升,那么这次变更可能是存在问题的,这时候,监控运营平台应该能够自动找到问题的原因,并向二线运维报警。

聊聊监控与运营平台中的一个小问题

上图是我去年为一个客户编写的自动化处置技术方案中的一个业务模型,对于一些小型的系统,这种自主化服务的风险并不大,只要流程管控的好,要实现此类操作的自助服务是十分容易做到的。对于大型企业用户的大型信息化系统,特别是核心系统,就像上面所说的,不是那么简单的。我们首先需要对信息系统进行全面的数字化建模,能够通过数字模型较为准确的反馈出系统的运行状态。这样,当大量的自动化作业执行时,其对系统的影响就能准确的反映到这些模型里,监控运营平台才能准确的掌握一切,规避各种风险。

有了准确的数字化的模型,我们就可以实现关键操作的后台自动监控,以及执行后的自动评估,并能够从模型的变化中发现系统可能存在的隐患,并在问题严重激化之前发现问题,及时解决问题。

今天说的这个小问题,实际上可能是企业级用户在大型关键性系统上构建自动化处置能力或者自助服务能力的一个必须要解决的问题。要想建设这些自动化的能力,做好运维对象的数字化画像十分重要。如果做不好这些基础的数字化工作,就像一步进入共产主义,恐怕是会吃苦头的。所以今天虽然聊的是一个小问题,其实这个问题认真起来也不小。

发表评论

登录后才能评论
联系客服
联系客服
分享本页
返回顶部