一个成熟的自动化运维系统应具备的功能
以下是一些高人的回答,非常具有参考价值.
结合现在云计算和DevOps的发展趋势，我觉得一个成熟的自动化运维平台应该包括以下的特性：
一、支持混合云的CMDB
现在越来越多的服务器都转到了云上，而主流的公有云、私有云平台都拥有比较完备的资源管理的API，
这些API也就是构建一个自动化CMDB的基础。
新一代自动化运维平台应该是能基于这些API自动维护和管理服务器、存储、网络、负载均衡的资源的。
通过API对资源的操作都应该被作为操作日志记录下来，以备作为后续操作审计的基础数据。
CMDB这个东西听上去是老生常谈，但这个确实是所有运维工具的基础设施。
而基于开源工具做运维平台最大的麻烦，就是如何在各个工具之间把CMDB统一起来。
CMDB不统一起来，就意味着一旦要增加一台服务器，可能要在各个运维工具里面都要同步一下，
这个还是非常折腾滴。。。
二、比较完备的监控+应用性能分析（APM）
能支持对平台的可用性、服务器的性能、各种服务（web服务、应用服务、数据库服务）的性能进行监控。
做的好一些应该能进行更深入、或者关联性的性能分析。
现在市面上一般都会将资源性能监控和应用性能监控（APM）混合着讲，这里面的产品确实也有很多都是
重叠的，两方面都会涉及到。
开源的性能监控系统主流有的Zabbix、纳吉奥斯，国产的开源监控平台有小米OpenFalcon，但这些基本都只
是做基本的资源监控（服务器，磁盘、网络等）和简单的服务软件的性能监控（中间件，数据库等）。
而市面上的APM系统更主打的功能是应用性能分析，比如能精确定位到某个应用的URL的访问速度快慢，
某些SQL执行速度的快慢，这些对于开发人员和运维人员快速定位问题还是很有帮助的。
APM这方面的商业工具，国外比较主流的有New Reclic、Dynatrace，国内的也就是透视宝、单机、
听云等，他们也提供了API进行集成。
APM这方面的开源工具有pinpoint（一个韩国团队开源的），zipkin（twitter开源），cat（大众点评开源）。
三、有一个还不错UI的批量运维工具
在业务发展比较快的情况下，从几台服务器，到几十台服务器，再到几百台服务器，批量运维的需求很自然
就产生了，老板也希望越少的人干越多的活。
现在也有不少开源的批量运维工具，也都比较成熟了，比如puppet、厨师、能听懂的、盐堆。
puppet和chef都是ruby做的，实话实说，ruby的熟手市面上很少，比python不是难招一点。
我个人比较推荐使用ansible或者saltstack，这两个系统都是python写的，代码质量和社区活跃度都挺不错的。
ansible有官方的web ui—Tower，但实话实说不好用，所以我们也在重新做一套自己用起来更顺手的WEB UI。
四、日志集中分析工具
线上系统最常规的问题定位方式，就是日志分析了。
随着服务器的增多，日志的分析定位也成为一个难点和痛点（想象一下，系统出故障之后，要去几十甚至
数百个节点去上去查日志，是有多折腾）。
国内有一家叫日志易的公司，是专门做日志分析方面的运维工具的。
另外还有一家log insight，也是做这个领域，但产品好像还处于beta阶段。
日志分析这个领域现在是一个热点，现在的开源方案也比较多了，比如著名的ELKStack，
还有Flume+Kafka+Storm的体系。
上面这两个方案相对重一些，部署比较复杂，网上介绍的文章也不少。
比较轻量级的开源日志集中采集方案有python做的Sentry，他是通过改造各种语言的日志采集框架来实现日志
的集中采集，各种主流的开发语言的日志框架都支持得很完整了，比如java的log4j和logpack。
Sentry的官网在此：
哨兵 – 使用 JavaScript 的现代错误日志跟踪异常, Python, 红宝石, 爪哇, 和 Node.js
五、持续集成和发布工具
这方面其实比较难有统一的需求，很多公司集成发布的做法都差异挺大的。
持续集成方面，一般用jekins的比较多，这方面网上介绍的文章也很多。
而如何把打好的包发布至各台服务器，则可以通过批量运维工具或者脚本来完成了。
版本发布的过程涉及到很多细节，包括了版本文件的上传、分发、版本管理、回滚等各种操作。
对于一般不太复杂的项目，我比较推荐的做法是把打包好的文件上传到svn上，然后通过脚本在各台服务器上
进行发布操作就行了，这样其实是利用了SVN来完成文件的上传、分发、版本管理、回滚等各种操作。
六、安全漏洞扫描工具
现在一个稍微有点知名度的系统，都会遭受各种各样的安全攻击的折磨。
一般的公司不太可能请得起专职的安全工程师，所以运维工程师最好能自己借助一些安全扫描工具来发现
自己系统的漏洞。
安全工具方面我了解不多，不太熟这个领域的开源工具。
之前乌云网推出过一个SaaS化的漏扫平台—唐朝巡航，有对外提供漏洞扫描的API，不过最近一直在升级，
所以也就暂时无法调用了。
个人觉得，如果上述功能都有了，基本上大部分中小规模企业的日常运维工作的高频操作都覆盖到了。
- 机房设备数据系统 (电子商务数据库)
- 录入机房服务器和网络设备的各种信息，比如机器型号，硬盘大小，OS类型，所属应用，运行状态，机房名称，所在房间，机架，位置等等各种信息，这是一个最基础的数据库，最主要的目的是给每个机器从多个维度统一打上各种标签，方便其他系统的使用。
- 提供各种查询API接口，并做好权限控制。目的是能够被上层的各种系统调用，一般是rest接口，xml接口。然后基于各种语言做相应的封装库。
- 应用监控系统(应用监视器)
- 一个统一的数据采集模块，用于采集设备运行信息，包括磁盘IO，网络流量，CPU利用率，网络设备的Session数，缴费灵。这个采集模块在网络设备上一般可以通过snmp来实现，在服务器上一般通过一个定制化的Agent来实现，这个Agent最基础的能力是采集服务器运行数据，最重要的是能执行各种脚本语言并通过脚本语言实现对服务器的各种操作(如更改配置，分析应用日志并输出结果)。
- 监控数据存储与可视化，数据采集模块采集到各种数据会很多，但对事务性没啥要求，可以用各种NoSQL数据库如Hbase,Cassandra等来实现。数据的可视化是一个可以做的很深且偏应用层面的东西，一般在监控系统上只实现最基本的曲线图展示，提供按时段选择和对比的功能，其他复杂的可视化操作通过各种API来实现。
- 监控项添加和报警通知，监控项是一种层次结构，而不是列表结构。上层节点的配置能够被下层节点的配置覆盖掉。对网络设备来说监控项就是一些不同的oid。借助于底层的数据采集模块，对服务器来说监控项基本上就是一个脚本。可以分为标准监控项和自定义监控项，标准监控项最大化的通用，实现cpu,内存，磁盘，网络等信息的监控。自定义监控项可以用多种系统管理脚本语言(贝壳,蟒蛇,perl)等实现，脚本的输出符合一定规范即可,一般采用行结构或json串。每个监控项设定warn,crit报警阈值和若干报警联系人，阈值一般是数值型，特殊的可以是字符串。超过阈值的监控项会发送报警给联系人，报警可以通过短信，邮件，IM软件发出。报警发送要支持合并报警，频率控制，关闭报警。要不然可能一次小故障就能发出成千上万条报警，报警就失去效果了。
- 监控Api接口，并做好权限控制。做法和目的与EMDB一样。开放监控数据获取，报警消息发送，配置推送的接口。主要目的是让监控系统里面的数据能够被外界利用，可以在这些数据基础上做更加绚丽复杂的数据可视化工作，或者做一些更加个性化的监控和报警。次要目的是支持对服务器的统一操作，比如公司所有机器统一升级系统软件的版本。建议统一操作的API接口仅对少数几个人开放，并且权限严格控制。
- 发布和线上配置管理系统(发布经理)
- 应用发布和依赖库版本管理，应用发布是运维与开发对接的重要环节，一般发布系统会和svn系统紧密结合，svn系统里面会有线上应用的列表，EMDB里面会有各个机器所属的应用。发布系统会用到这些数据，将svn系统里面生成的应用包及其依赖包发布到线上，并且自身对这些应用包和依赖包进行版本管理和控制，在应用发布出现问题时可以回滚到上一个版本。
- 线上配置管理，类似于linux下puppet的功能，主要用于应用服务器上关键配置文件的版本控制，分发，一致性维护工作。大应用一般是若干台服务器组成集群提供服务，要求这若干台服务器的应用配置是一致的，但有时候又存在应用的灰度发布操作，或者某人误更改配置。线上配置管理系统要求提供统一的配置修改入口，对灰度发布提供支持，同时对于误更改配置情况进行纠正。执行操作可以借助于Appmonitor的接口。