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