之前也写过一篇比较基本的文章，也算是自己对运维平台的一个基本思考。当然想法简单，而且缺乏实践，但是朝着这个方向迈进是没有错的。从我的观点来看，现在能够实现半自动化运维已经很了不得了。而且把这些工作能够落到实处，更是不易 。
比如举几个简单的例子。
比如对于数据库的数据文件添加这个功能来说，其实完全可以实现自动化扩容。但是是否完全可行呢，我觉得还有待斟酌。比如temp设置为自动增长，如果出现了sql语句导致的问题，结果导致temp被撑爆，听说过temp无限扩展达到TB级的问题，最后还是sql语句的问题导致。
那么这个数据文件是否支持扩展，怎么扩展，这个应该一方面是根据系统资源进行权衡，另一方面就得根据具体的系统情况来决定了。这也就引申出我今天想说的关于元数据的管理。
顺便讲个小段子，几个同事跑过来找我，说有一个紧急操作需要DBA配合，然后想让我去和他们开个会，我就不喜欢那种没有结果的会议讨论，从DBA的角度来说，提供完整的操作步骤，正确的脚本，你们来评估业务可行性，我们来评估从安全，性能，业务上是否需要支持和改进，当然我说的也很简单，我就是个干活的，你来提供详细的步骤和参考，我来评估和执行，会我还是不参加了吧。其实话说回来，如果我们只是简单评估和执行，那么我们工作的含金量会大大降低，外企都很强调的design，DBA也是需要加强这方面的功底的。老是搬砖，时间长了就只会搬砖了。
所以这些design的工作怎么做，不是一下子高屋建瓴，我们来想想我们能够做些什么。从整个运维系统，运维平台的角度来考虑，元数据管理还是根本，但是似乎没有什么人重视。
从我的角度来讲，我认为元数据的管理，除了资产层面的资源状态管理，从运维平台来说，还是有很多值得注意的地方。
我大体列举了一部分，从我的角度来看认为还是非常有必要去考虑的。
这些元数据看起来非常琐碎，但是一旦管理起来，作用就非常巨大了。比如给你最短的时间做资源盘点，查看当前的5000台服务器中哪些服务器是在redhat的某个子版本，简单评估是否可以升级等等。这些没有元数据管理，简直不可想象。所以我把元数据的考虑划分成了下面的几个部分，当然还需要不断完善。
系统情况，内核版本，补丁，操作系统版本。
硬件配置：基本的硬件配置情况
cpu cpu合数，物理CPU数
内存 内存大小
swap分区设置：swap分区的设置，swap的大小是否合理，如果是在有些云服务器中，默认是不开启swap的。
磁盘分区设置：磁盘分区的情况，盘数，raid级别等
crontab： 自动任务的情况，是否有ntp的自动同步，是否有定时的业务调度，是否有定时的备份和系统检查。
防火墙：防火墙开设的端口，开放的客户端
主机名：服务器的主机名管理，尤其是在很多系统迁移中，做了大量的主从切换等情况下，有时候从主机名根本分不出来一台服务器到底是主库还是备库。
ip配置 内网外网，网络ip的设置，/etc/hosts中的配置，比如在mysql中的主机名dns权限解析。如果主从切换之后，是否备库一定会有主库所拥有的权限。
主备，主从关系配置：主从切换之后，是否从库或者备库一定能够胜任，备库是否已经完全做好了时刻切换的准备。根据主库是否能够找到匹配的备库，或者根据备库关联到主库。
内核参数配置，内核参数的设置，是否初始化的时候已经合理规划还是根据感觉想到哪里做到哪里。有些内核参数设定是否是按照系统硬件资源来设定，是否考虑周全。之前就碰到过一个数据库进程数设置为150，但是资源配置非常好，但是自己申请调高process之后重启数据库的时候，发现原来的内核参数就取的默认值，所以资源好，但是软件层面的性能跑不上去。
端口配置：对于数据库来说，开放了哪些端口，哪些端口处于闲置状态
数据库参数 init.ora my.cnf，对于oracle,mysql而言，参数的管理也很有必要，如果一台服务器宕机，想找到之前的一些完整配置，不一定备库的就和主库一样，到底哪里不同，哪些参数可能设置不和规范，通过统一的参数管理就可以得到一些答案，比如对于oltp,olap来说，哪些参数需要考虑，10g，11g中的特性参数如何取舍，哪些需要统一。
外部文件挂载，系统中是否有外部的挂载点，比如nfs，其它共享存储等。
备份情况，系统的备份情况，数据的备份情况等等。
当然从数据库的层面进行更多的思考，需要做到具体的事情就更多了，我们后续再做补充。
最后说一句，圣诞快乐，其实提这个节日的人多，过节的少，该加班加班，干睡觉睡觉，生活快快乐乐，天天都是节日：）