有时候觉得我们有些矛盾，干着高科技的活，但是有时候还用着一些老土落后的思维方式，想想也还是蛮有意思。
故事来源于一次服务器信息的整理，当然之前我也写了几篇博客来说明元数据管理的重要性，不过好像没有引起多大的重视，于是我就自己做了，先满足我的需求，从实践的效果来看其实也还行，对于服务器的信息都是量身定制，所以自己用起来还算顺手。服务器多了，就想得到一个详尽的列表，看着列表就如同看着相册中的照片一般，每一处的细节都能让自己想起服务器的一些情况，但是这个过程似乎自己走得有些长，我在半年前刚开始整理的时候，基本是采用了纯手工的方式，当时接手的服务器不太多，每一台都单独连接上去跑一堆脚本，然后把结果老老实实记录下来，粘贴到excel里面，这种方式倒也着实发现了不少的问题，还清晰的记者自己当时整理这个列表的时候感觉好没有技术含量，但是又着实需要，写个脚本吧，可能明天都弄不好，今天加个班就弄好得了。于是自己说服了自己，就这么招了。
但是后面服务器越来越多，然后逐个来检查分析发现有些费劲了，而且中途有些服务器有一些变动，因为故障退还，服务器报修，扩容等等，里面的不少配置就需要手工改动，于是自己又感觉真是忙的像拖拉机一样，但是好像没有什么能拿出手的东西和经验来。
  于是后面终于忍不了了，服务器越多，发现一个地方没有检查到位，整个几十上百套环境逐个检查简直就是不可能的，而且里面的有些参数信息还是动态的(比如服务器的uptime)，所以在后面如果出现了一些故障，自己就感觉眼睁睁的看着问题发生，总是忙的晕头转向。而且发现一个问题，逐步扩展开来去查看，发现很多都是类似的问题，这个时候越发感受到了一个强有力的工具的重要性。当然自己早已走出了那个阶段，历史坑也填了不少，遗留问题也修了不少，问题没有发生之前的修复，对于外界来看似乎是可有可无的，但是这些工作又是非常必要的。
  等工作整理差不多，天天梳理环境，我都恨不得拿个梳子去梳理了。发现也着实整理出不少的问题，于是脚本+手工校验，又得到了一个改进办得服务器列表。
在这个基础上，自己感觉得到了一个秘密名单，这个列表上有最详细，自己认为最重要的服务器信息，就想读一小段故事一样，每一段服务器的配置信息总能结合业务和当前的整体环境给出一点点的评价来，比如某个服务器，内存64G，但是sga只开了2G，那么这种服务器的内存就是巨大的而浪费，某个服务器的可用空间为1.5T,但是实际的空间利用率只有20G，那么这种服务器的信息就需要一个平衡。结合起整体的环境来看，其实还能做些什么。当然这个时候，对于元数据的分析又上了一个层次，不是得到一个列表维持现状那么简单了，我们还需要计划做一些改进，这些信息就静静的摆在那里，等待我们发掘。
  然后我兴冲冲打印了几个版本的服务器信息列表，然后拿着笔在每一栏后面都加一些标注或者加圈，但是林林总总好几页的服务器信息，读了一页之后就开始招架不住了，有时候想根据数据规律得到一个自列表，然后就几页纸来回倒腾，手工画一些标记来简单标注，但是想法越多，发现在这个基础上可做的工作就越多，于是我们需要得到更多的服务子列表，有些还希望根据某些属性来排序等等，而且比较头疼的是，有些子列表之间还存在交集，在这个基础上去校验，辨识就更加困难了。这个时候发现手工校验完全跟不上节奏了，我用高大上的脚本整理出来的列表突然感觉一下子失去了强有力的掌控力，于是在挣扎中不断自己批判，发现最后还是返璞归真，还是放在了excel里面搞，排序，整理子列表，脑海中冒出的一些想法和维度总能瞬间满足，如此一来，经过这么多的折腾，我感觉这些元数据算是玩转了，很多信息只根据一些简单的标识信息就可以整理出来一系列相关的信息，比如我可以在几秒钟统计出来我接手的环境中哪些数据库在11.2.0.3,哪些在11.2.0.4，哪些还停留在10g,哪些操作系统版本还在老版本，急待升级，哪些运行时间超过了3年，服务器配置严重过旧，哪些服务器配置非常好，但是没有发挥出应有的效力，这些就属于改进的加分项。当我把这些信息通过颜色标记之后，就形成了矩阵标注，对于每台服务器的优缺点就了如指掌了。
   所以突然一回想，服务器列表的整理思路经过了下面的几个阶段。

纯手工

脚本，半自动化

脚本改进，手工校验

脚本改进，矩阵标注

这些看起来微不足道的一步一步，相信很多人都会有着类似的体会，但是有些时候是主动，有些时候是被动无奈。