运维平台的建设思考-元数据管理(五)

  1. 云栖社区>
  2. 博客>
  3. 正文

运维平台的建设思考-元数据管理(五)

jeanron100 2016-06-26 23:14:55 浏览449
展开阅读全文
关于运维平台的建设,元数据一直是一个很重要的环节,之前在听了ITIL方面的一些讲解之后,发现其实早已经是体系之中的,想必是很多公司很多人还没有重视起来而已。
而要说运维平台和元数据,其实我也一直比较纠结,因为我不是专业的,只是在工作中越来越意识到它的重要性,很多时候不是口上说说,提提而已,而要落到实处,更不能图形式。
    我们先来说说工作之中的沟通,其实我有时候也蛮偷懒的。用一个基本的沟通方式来说,能当面就不电话,能电话就不用lync,能用lync就不用邮件。这个是一个方向,实际做起来就很难,我之前的公司的很多领导都会这么提倡,也是提高工作效率的一种方式,相比于现在的敏捷运维而言,不就是类似的思路方法嘛。
工作之中的邮件本身只是一种工作形式,我们无法根据邮件数来考核KPI,无法根据邮件的回复情况来判断每个人工作的情况,我也看到过很多工作中邮件踢皮球,邮件中的办公室政治(有时候都分不清情况,不好站队),邮件中的各种推诿。算了先不提这些,我们要说的是,邮件也可以提高工作效率,就是一种正式的,信息量比较多的时候,前提还是要通过基本的沟通清楚明白了之后。
    就比如我们处理日常工单,有些工单开发同学都不用发邮件,电话,lync告诉我,我一看到工单就知道他要做什么,在什么环境等等,都一目了然。而有些同学开的工单就让人比较纠结。我看了工单看不明白,里面也没有任何环境描述,每次发邮件回复就非常费劲,来来回回可能一上午就过去了。而且不一定马上能得到我希望的结果。有时候在lync上能几句话说清楚的,也还好,不过我就想为啥一次不说清楚呢。那些邮件,lync都搞不定的,赶紧电话吧,很多时候问题听起来很紧急,很严重,其实明白了问题就很容易处理了。比如之前有个开发同学联系我,说有个问题非常紧急,但是工单里也没有提供环境,没有更多的辅助信息。最后确认发现他所说的环境就不是我负责的。还有个开发同学在我坐地铁的时候打电话,说有个任务非常紧急,希望马上处理,当时信号不好,大体听明白了问题,其实就不是数据库的问题;还有些问题听起来很紧急,好像是交到我手上开始就很紧急,结果一看工单,又是个三无工单(没有环境,没有描述,描述脚本),你说让我怎么快速处理,好容易要来脚本,发现脚本又有问题,我这个时候就会认真的告诉他们,这是线上环境,这一点上标准和规范优先级要更高。
    所以我引申出一个观点,制度和规范也是元数据的一部分。
    就拿最近的一件事情为例。我们有一个基本的退换服务器的流程,群发邮件大家都收到了。但是后面应该是发现直接关闭防火墙有一些风险,所以又收到了一封邮件,里面的描述就是这个流程中需要注意,不要直接关闭防火墙。而我在处理这个问题的时候,邮件实在太多了,于是就搜索关键字,找到的邮件就是第一封,因为里面的步骤最全,而且其中就有一条是可以添加主机信任,或者直接关闭防火墙,我也是为了图省事,直接就关闭了防火墙,做了服务器退还,当然退还之前我在现有系统做了屏蔽和注销,所以我们没有收到任何的异常报警,但是系统组反馈说他们收到了大量的报警短信,于是这个问题就最终变为了开通防火墙的事情了。然后又收到一封邮件,如果退还服务器关闭防火墙算是人为故障,你说这种事情你找谁说去。当然我选择了沉默,这种事情纠缠起来也很费劲,但是我的总结如下。第一个是报警的划分,如果不是具体负责的同事和组,报警信息都他们是无效的,发与不发有什么意义,这个需要明辨,而一种方式就是在资产和监控系统对接起来。第二个就是规章制度类的信息也是元数据,这类信息很重要,通过邮件又很容易出现信息不同步不一致的情况,为何不通过统一的portal或者公共页来显示,如果有什么变更情况,也很容易同步过来,新来的同事可以马上了解到这个流程。就可以避免更多的问题,信息不共享,不同步是主要根源,而不是通过加重惩罚力度来实现。
    所以元数据的责任还是意义重大,我们希望更加这些信息来组织得到一个完整全面的信息链,这个意义更为重大。

网友评论

登录后评论
0/500
评论
jeanron100
+ 关注