自动化运维架构设计选型的技术侧重点
1.anisble,puppet,saltstack ,他们优缺点很明显,但对复杂环境,支持的不好,部署极其复杂...如果要和监控系统联动起来,对于开发运维有很高的技术要求
2.是否可以支持在线更新插件,减少版本更新的难度和工作量
3.是否可以做到黑白名单?
4.误操作防范措施,是否支持预览结果的功能?
5.能否支持回退?(这个功能貌似很难实现)
3同行回答
2.是否可以支持在线更新插件,减少版本更新的难度和工作量
固定一个版本后，能不更新就不更新了，除非有天大的Bug，想想你更新的“理由”是什么，是否足够成分。
3.是否可以做到黑白名单?
黑白名单需要自己开发，主要是远程命令操作的时候要用到，我们现在基于ansible的主要方式是在sudo中控制，puppet shell插件是自己修改了shell插件来实现
4.误操作防范措施,是否支持预览结果的功能?
预览不太可能实现，不过，第一你的系统都是“标准”的系统，所以，只要第一台能够执行成功，其他的不会有问题的，第二，变更之前要测试，要测试，要测试，重要事情说三遍，第三，执行结果的收集。
5.能否支持回退?(这个功能貌似很难实现)
回退....这个功能的难于实现，主要是操作系统层的，例如，你yum update了一个包，现在突然想恢复到上一个版本。。。 但是还是有不少可以回退的，例如所有的文件类（密码、配置文件、服务状态等等），我们之前项目中，用SVN保留了类文件的向上10个版本，并且可以对比这些类之间的区别，这样你就可以用类回滚的方式来实现回退。
收起你说的这些大部分都是个性的需求，你提到的这些软件基本都是提供一个框架，个性的需求是需要自己去开发完成的，比如你说能否支持回退，我觉得这些软件是不会考虑这个，只有你自己通过设计一个可靠的流程步骤去实现。另外这些开源软件我觉得使用都很方便，并不复杂吧
收起- 1.使用的确不难,但是针对 异构系统环境复杂就不好了;比如系统有windows2003,2008,2012,AIX,5.3,6.1,7.1,solaris,hp-unix.rhel,前期部署,运维造成很大难度,(特别是许多客户的环境是分外网区和内网区的环境,很多时候不会让你连网的,而且出于安全考虑不一定会允许搭建本地源; 2.软件是不考虑,但是基于系统选型,我们只能在更多考虑可用性,稳定性前提下去选择适合的;
- 如果是你说的环境复杂，异构平台较多这种情况，我觉得选型上尽量考虑采用无agent的方式，比如通过ssh就可以解决非win的环境的所有系统，你说的网络问题这可能和规划有关系，比较合理一点一般都会划分管理网和业务网，运维的操作适合在管理网进行，本地源不允许这个不太理解，从安全上考虑应该是支持本地源啊。稳定性的话我觉得是和你受管的数量，自动化作业数相关的。