KVM虚拟化技术目前已经比较成熟，在金融行业也有比较多落地的案例；重要系统不建议采用虚拟机迁移的方式，可以采用重新部署和数据迁移的方案；2.核心业务还是建议运行在传统的SAN存储上，非核心的业务可以采用分布式存储的解决方案，两个方向都可以选择，如果是自己的研发能力比较强可...

产品选型也是考虑自身的实际需求和限制条件。比如资金投入不大，可选的产品可能就会受到限制。或者需求不一样，选择的产品侧重点也不一样。适合的就是最好的。证券公司通常体量还不是很大，所以在节点量等方面可能不会很庞大。产品适合轻量而精致。容器云产品选型首先需要考虑...

目前貌似没有资产自动发现的软件，而且这个资产的范围是比较大的，包括硬件资源、软件资产，硬件资产只能用部署在机柜中的RFID技术去获取位置，发现资产。软件资产或者操作系统配置等，可以通过自动化运维去二次开发或者用第三方的代理去抓取。...

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

笔者没有都测试过以上产品，而且每家的产品更新迭代都很快，笔者在这里分析会有失公允，所以不能进行分析。这样类似的问题在这次讨论中有些老师有提到，其实对于这个问题，笔者的建议是首先梳理清楚自己公司的具体需求和痛点，最希望超融合平台为你解决什么样的问题，把这些问题落成书...

首先否定redis，这只是一种缓存，而且数据量不能太大其次否定mongodb，因为mongodb主要还是存类json数据。gridfs只是针对小数据量的变通方案，不建议用在大量数据的情况下，否则不好维护。这种大文件、碎文件建议用以下方案：由于数据量大可能后期会用到分布式存储（块存储、对象存储...

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

楼上列举了很多底层工具，都是非常实际的，在这里我做一个整合，这个问题包含了两个方面：1、自动化运维底层工具产品是选用开源产品还是闭源产品目前来看，无论是开源还是闭源都可以满足银行的运维需求，选用开源产品无非就是银行自身的技术实力允许，有一定的开发实力，或者和第三方外...

大哥，你这是给出了问题，也给出了答案啊，哈哈！先回答第二个问题，我们没有选择Ansible和cmdBuild，我们选择了腾讯蓝鲸这套平台；我们在选择自动化运维工具时的基本思路如下：调研我们的业务系统现状，以及运维人员的需求；确定策略，我们公司目前的运维团队有自己的开发人员，未来运维也计划...

选择开源也是尝试性的选择，在一个领域如果要做好它，驾驭好它，就得亲身去尝试，那就得开源先行，自行尝试性开发，为后续积累经验，后续也可在开源基础之上进一步丰富。而开源产品选型最重要的一点原则就是对现有业务系统无侵害性，无论是CMDB还是ANSIBLE都是业界公认的、口碑很好的产...