在我的理解运维工作量大更适合于自动化来解决。ai是解决分析决策效率问题，自动化是解决操作效率问题。aiops应该基于数据，发掘数据，发掘数据价值。手眼心脑，数据是心脏供血，监控是眼发现问题，ai是脑分析决策发指令，自动化是手做事。...

      存量的问题一定是要分步解决，如果想一蹴而就很可能最终导致项目失败。       建议先针对生产中主推的服务器操作系统版本实现自动化纳管等操作，先解决见效大的问题，在第一步成功后既减少了日常大部分运维的工作量又有了后续继续推进的动力，然后分析剩余服务器...

个人建议专业的人做专业的事，能够各个专业领域通达兼济是难得的。从传统企业来说，自动化运维的建设需要一个团队或者多个团队协作，而且也应该将各方面力量拉拢一起做这件事。从自己熟悉的专业领域做起，了解日常工作中重复事项哪些可以由机器替代，可以采用什么技术替代。在开发...

个人浅见，技术发展过程中必然会有一些先驱探索，智能运维、自动化运维、传统运维之间并无很明显的界限划分。就我们情况而言，自动化运维并未发展到完全成熟的阶段，也已经在监控领域探索一些智能化的衍进，比如对于海量告警的压缩提取有效告警、告警的根因分析、利用大数据拟合动...

自动化发布的目标是将应用服务按需求正确部署，传统情况下我们都是通过登录主机操作，能实时查看到输出结果，这样的操作有既视感，让操作人员心安。而自动化后怎么监控的问题会在初期困扰运维人员，我们通过将日志准实时采集展示在自动化平台上实现对后台运行情况的监控。同时也在...

开源工具或者第三方闭源与瓶颈不是必然的关系，无论是开源还是闭源。合理的部署架构可以解决大规模环境下，自动化运维的瓶颈，可以采用分布式自动化运维管理节点部署，每个管理节点管一片或者一类运维节点，通过统一的管理平台进行对接。...

从我们目前的实施应用情况来看，自动化运维工作在基础平台搭建完成后，更多的是脚本开发能力，从初期来看需要关注各类脚本的编写能力。同时，自动化运维后需要运维人员对方案制定与评估更为审慎，那么对业务系统架构与关联分析要更严谨。因此建议传统运维人员在脚本开发能力（shell...

从自身需求出发，从最繁琐最没有价值重复性最高的工作出发，这些就是你的需求。考虑选择一些技术来实现最基本的自动化，或者称为脚本化，不管是使用shell还是python还是ansible这些技术。在有了最基本的自动化能力后，可以考虑自动化平台的建设，自动化平台的建设就需要从“监”、“...

这是违规行为！严重的会追究法律责任！

厂商平台是产品方式开发, 如果想适用于大型数据中心都需要进行定制开发,可更加ansilbe的api接口进行二次开发, 或者通过tower的api进行开发cli也可封装成rest 的api 进行接口开发