早在2011年的时候，收到一个任务，就是自研一套运维管理平台，当时基于硬件（CPU、内存、硬盘、网络）的开源运维平台业已成熟，但为什么要自研呢？
1、2010年前后已经开始了虚拟化的进程，只不过不像现在这么成熟这么多选择，当时的考虑更多的还是资源管理问题，虚拟化导致主机、虚拟机和资源之间出现了混搭状况，常用的开源运维平台已无法管理。
2、硬件设备和应用的关系随着虚拟机的出现，出现了多对多的访问关系，确定设备和应用的相互制约相互影响关系对构建快速响应机制极为重要。
3、硬件设备、应用和服务的关系，一般来说应用大于服务，服务可能是一个端口，也可能是一个或多个服务接口，虚拟化产生了分布式，分布式产生了多对多，多又对多的关系。
资源管理是运维管理的基础，为了解决上述问题，还特意看了一段时间ITIL（IT基础架构库），也做了好几版的资源管理设计文档，最后虽然不了了之，也算能够抛开繁琐的细节从总体上思考运维了。
基于运维基础做运维，通常会导致一叶障目不见泰山；脱离运维基础谈运维，会导致过度理想化，因为运维本身涉及到系统的方方面面，比如从技术上存在不同数据库、Hadoop、Redis、Kafka，没人能保证看懂所有技术，不过技术是讲分工的，每个人接触和运维一段时间，从架构角度、从运维角度去梳理各种KPI还是可行的；另一方面本人也算搞了三四年大数据了，对大数据的运维看在眼里痛在心中，有切肤之痛。
首先大数据平台的运维较以往的运维从技术上、难度上、复杂度上均提高了，这是不争事实。
其次大数据平台的运维手段还是停留在最传统的脚本角度，上百台主机即使有了一些自动化收集脚本，但整体上还处于手工作业阶段，三四个人投入运维，忙死忙活，不见成效。
再次对运维的认知上，还存在严重的不足，运维平台的建设不是为了增加运维人员的工作量，而是解放运维人员，把运维人员从繁琐的事务中解脱出来，处理更高级别和能力的事情，也可以在运维工作系统化过程中，提升自己的认知和技术能力。
最后，运维不仅仅是硬软件的监控，也包括运维工具选型，运维配套管理、运维交付物管理。运维工具选型当然重要，但却不是最重要的；尤其是配套管理，当然这里提到的更多的是数据仓库项目但也不全是，每种类型项目都需要元数据管理、主数据管理、数据质量管理、任务管理，而且更难的是把任务管理和配套管理整合在一起，这又是智能化运维管理的基石。
王老师的公众号为：追梦IT人
相关链接：
个人新书 《MySQL DBA工作笔记》
个人公众号：jianrong-notes
QQ群号：763628645
QQ群二维码如下，个人微信号：jeanron100, 添加请注明：姓名+地区+职位，否则不予通过