这个用堡垒机不是更好么，用ANSIBLE的确也能做，就是定期生成一些按照复杂度策略的密码，匹配不同的服务器，密码、服务器IP入数据库表，不同的表代表不同日期的密码修改记录，然后定期读取这些表，用ANSIBLE去服务器IP，执行密码修改即可。这样不同时期的服务器密码都有迹可循了。...

自动化运维节点分布式部署，统一管理。按照自动化运维场景、运维节点类型、业务类型划分出多个自动化运维节点。自动化运维系统开放接口，为不同的运维系统和平台使用，使用过程时只需要调用接口，传入参数即可。...

通常由运维部门来推动整个项目的规划和落地。采用总分的框架去建设，即统一管理，不同场景和方向细分。像自动化运维平台为最顶层，批量和定时任务调度、自动化投产、自动化运维系统为细分。当然也可以进一步细分，将自动化运维细分为巡检、软件配置和安装、配置核查、自动发现等...

最主要的还是开发上和架构上的难点，就这次ANSIBLE的使用来看，没有关注ANSIBLE本身层面的开源代码，用SHELL也好，PYTHON也好，更多的体现的是这个工具的使用上。首先是要结合企业自身的需求，量身设计不同的自动化运维场景，这点与直接采用第三方的产品有所不同，第三方是基于他们的理...

CMDB颗粒度取决于维护CMDB的人数量，维护能力越强，人数越多，可以将颗粒度提高，数据间关系可以做得越复杂。如果维护能力不足，人数不多，颗粒度尽量精简，更要通过自动发现、流程来去管控这些数据，模型搭建好，尽量减少人的作用和直接参与，人更多体现在流程的审核和管理上，让流程来驱动CM...

还是有很大区别的，互联网的自动化运维更期望的是自动化解决问题，出现了一个场景，基于判断策略，执行执行计划。而金融行业的自动化运维更期望的是批量自动化执行，有一个场景，人为判断，通过自动化运维平台手动操作，自动化批量执行。所以金融行业的期待和互联网的期待还是有所不同的...

开源底层框架 例如puppet的mco, salt的模块, ansible的简单模块上层业务和界面肯定是制定开发的,不然无法符合业务逻辑和安全审查

统一CMDB为所有系统和平台提供统一的配置基准数据，提升联动的数据质量和效果；自动化运维平台自动采集和发现价值数据和数据关联，供其他系统和平台使用，和各项资源建立自动化关联关系，提供不同自动化运维场景调用API，供其他系统和平台调用；集中监控平台对接所有监控系统和平台，实...

我们的资源监控用的是摩卡，应用监控用的是天旦，另外一家公司做的整体集成。运维一期项目主要是做到了资源的统一监控和管理，应用的监控；接着后面主要是进行CMDB、流程建设、自动化运维等；最后往智能化运维发展。...

对于该问题，从我的理解上简单谈以下两点内容：1、整体上自动化运维作为运维技术体系中的一员，其目的就是为了减轻运维成本、提升运维效率、规范运维任务、通过自动化自愈提升业务连续性等等，其重要意义不言而喻。这点从国内各类大行、股份制银行等的运维人员招聘的技术要求中，...