1、云与虚拟化的区别是什么？云多了什么？
【问题描述】：
1：达到什么样的硬件规模，才有上私有云的必要？
有几百上千那是上，有的10台 20台 也是上。每个企业可能衡量的标准不一样。怎么判断要不要上？
2：已有虚拟化的情况下，上云到底能带来什么样的帮助？
云比虚拟化多了什么？
解答：
多了云服务，一种基础设施封装服务模式。虚拟化提供不了SAAS，PAAS，也提供不了计费、计量、服务开发和自服务定制。
虚拟化只是一种比较方便支持云计算的一种技术手段，并不是云计算。
那么就回到问题，要不要上私有云？其实我们这里分析的是上私有云是有什么诉求，这些诉求是否值得投入，投入产出如何。
上云、云管理的诉求1：有把基础设施强烈服务化得需求，很多时候这种诉求来源于资源规模大，组织结构分工细化，基础设施部门面向多个开发环境，迫切需要通过封装自身的服务，把自身的服务能力说清，把服务运行成本、责任分清，云服务提供式一种良好的方式。诉求2：大规模资源有效利用、批量管理的需求。云计算是规模效益，规模上不去，效益体现不出来，因此，要根据自身的能力和规模，看看是否值得去上，是否能够持续投入。诉求3，也是最重点的需求，供给矛盾是否突出，决定了是否走这条道路，虚拟化环境现在管的很好，很方便，能够满足业务需求，那么，个人认为这个矛盾还没有到要改变生产力的时候，什么时候变呢？基础设施要求的速度现有手段跟不上，不能满足应用快速扩容的弹性能力，不能满足应用更高层面，比如PAASSAAS方面的需求，或者说需要通过标准手段对架构管控，海量运维。这时就是矛盾突出之时，也是入云日。
因此，在有资金和人力支持的情况下，基础设施利用现有的虚拟化进一步到云计算环境（还要考虑网络、存储、流程的投入），是可以的，但不是必须的，需要考虑自身成本、规模，量体裁衣。
2、在虚拟化建设基础之上，三个私有云建设方向如何选择？
【问题描述】：
当虚拟化的规模与日剧增，对自动化、标准化、流程化和服务质量需求的迫切性达到一定程度后，我们会选择开展企业私有云建设。
私有云建设目前大致存在三个方向：
1.在原虚拟化的基础之上，采用现成大厂商提供的各级（IAAS、PAAS、SAAS）云管理平台产品，进行虚拟化的统一接入、统一管理和统一流程。
2.在原虚拟化的基础之上，利用标准开源的框架，如openstack，Kubernetes，根据企业自身需求，量身开发属于自己的云计算需求。
3.在原虚拟化的基础之上，从基础框架到软件需求全部根据企业自身需求，量身开发，更加贴切企业实际，安全系数高，可靠性强。
对以上私有云建设三个方向有何见解？企业究竟该如何选择方向？
解答：
建议如下：
商业银行选择那个路线，还是需要看自身的战略规划和人员素质能力的。这两个路线主要区别如下：
开源私有云：代码自助可控，平台兼容性、定制化能力强，但需要具有大量的人员和财务投入，并且是持续不断的投入，人员素质和财务一定要跟上，同时，开源产品的版本迭代快，健壮性不够，方向性不明确（没准大家一股脑换了一个框架产品）,这样带来的纠错成本很高。总之，自身利用开源搭建和开发私有云，对自身能力带来的很大的挑战，要求企业能够打持久战，并能够不断的在社区中丰富和汲取养分。还有一层，就是开发、维护都有自身完成，无第三方风险转嫁。
商用软件：缺点大家很清楚，容易被厂商绑定，兼容性差，定制化差，随着规模的扩大成本增长明显，但特点是实施周期短，对于企业本身的人员素质较自开发的情况要求低很多，主要是产品经理和用户的角色。并且对于系统的维保、OLA可以通过商务的方式转嫁部分风险。比较适用于企业规模不大，求尽快上云的情况。
最后说一点的是，很多商用软件都是基于开源私有云搭建而成的，可以考虑两者优势结合，通过开源的方式增强开放性，通过商用的方式减少自身建设成本。
目标是第三点，但要求企业自身的能力加强，可以考虑基于开源的商用产品，并且要求足够开放，逐步积累经验，慢慢做到2个并存，逐步代替。
3、上私有云对企业有什么样的要求？
【问题描述】：
1：运维水平有哪些要求？或者说上了云之后需要具备的素质或努力的方向
对运维团队有哪些典型的要求？制度规范，技术水平，角色人员？
2：标准化程度要求？
制度规范，企业整体IT治理的阶段水平？
解答：
运维水平最大的要求是自动化的运维工具使用、跨领域的协同、运维组织结构调整，和运维文化的转变。
自动化运维工具应对海量运维、最基本的要求就是配置管理的准确性，要不谁敢上去自动化呢？
跨领域协同在私有云建设中很重要，在大企业中，网络、计算、存储、中间件等领域，往往都是独立的部门，有独立的变更和实施流程，但在私有云的设计、和运维上，这必须是一体的，哪怕有个虚拟团队承接。这也就是说，一般情况下，应进行组织结构的调整。
人员要具有面对海量基础设施运维的能力，要有架构团队、需求分析团队。人员要具备运维工具的开发能力，这一点建议百度一下 google的SRE团队，是一个非常好的定位。
谈起标准化，是重中之重，也是私有云最有特点和最有优势的一环，企业架构管控做的好，标准化程度高，决定了云计算的层次，SAAS服务的提供，依赖于高度的标准化。要从物理硬件层、OSNETDBSTORAGE各领域完成标准化，然后在继续规范应用的部署模式，逐步规范形成标准，有利于PAAS的提供，真对具体应用标准话，才能完成SAAS的转变。
4、企业云平台建设一共分几期？还是一步到位？
解答：
云平台很少有一步到位的，往往最开始的阶段是满足最基础的需求，例如计算虚拟化，存储虚拟化，然后网络虚拟化，然后容器，监控，大数据，编排，数据库，等等应用。其实，这个和云计算的分层也是有很大关系的。从iaas到paas，再到saas，层层递进。企业的云平台建设，往往也是遵循这个规律。在实践中，可能会有一些交集。
通常都是分几期的。第一期为试点项目，第二期根据一期结果形成规范，标准，成为新开发应用的标准平台。第三期逐渐将老应用迁移到云平台上。
5、如何在不做大改变的情况，实现私有云的升级改造？应该关注那些方面的问题？
解答：
如果把服务器作为数据中心中应用的一个点，网络、存储则往往属于面，属于底层基础设施，改造难度和风险较计算资源高。在传统行业中，没有一个新环境的契机，逐步改造，也是很难的。必然带来的网络和存储在搭建私有云中有些技术跟不上。
之前谈过私有云的理解，不一定私有云一定要去用新技术，例如SDN，存储虚拟化，私有云重点是实现面向客户服务模式的支撑，资源的弹性和快速服务能力。在这一点上，一般企业通过采用将现有的环境，向标准化配置努力，大力推动自动化能力开发和建设，使之与云平台结合，同时增强前期容量规划的方式，也可以逐步实现云环境，同时，结合新建的契机，逐步使原来的基础设施更替为更好支持云计算特点的技术及设备。
6、怎么判断某个系统是否部署在私有云上，有哪些判断指标？
解答：
最典型一个词来描述“云原生”应用。给您一个参考，敏捷开发的12原则，满足这12原则的应用，基本上在云计算的这种分布式、虚拟化的环境中可以很好的运行。这里，个人认为，最重要的是集群化、支持应用补偿机制、模块化。
7、私有云的容量如何评估？成本如何计算？如何才能做到成本和效率的平衡？
解答：
私有云的容量需要根据业务来评估：
以一般金融行业，有web区，有App，有db。需要根据运行在私有云上的业务的多少，来统计所需要的资源的多少。例如，web区，需要Nginx，需要考虑HA和LB，那么就需要2台以上；如果多个业务共享nginx，那么就需要多个nginx来分担业务压力。
成本计算：
一般私有云平台上，都有一个celimeter这个模块，专门用来计量CPU，内存，网络的使用量，可以统计出使用私有云的资源，相对传统环境节省了多少资源。
至于成本和效率的平衡，一般在私有云建设初期很难做到。设备的购置，部署，人员的配置等等都是一笔不小的开支；私有云真正的优势体现，应该在后期的使用中容量如何评估，这个肯定是没有普适标准的了。
容量通常从三方面考虑：计算能力、存储容量、网络带宽。这三方面可以说也是数据中心最基本的三大核心要素了，我们都知道，云计算是以规模取胜的，这个规模如何决定？究竟是20节点，50节点，还是100+节点，这个得根据你自己的业务需求来考虑了，在小规模情况下，为了高可用，如果可用容量评估是N，那你就按2N来计算，私有云一般不会像达到公有云那种规模，所以通常也不可能达到很多布道师口中的 虚机随便挂，真挂了你宿主机资源没有了，咋整？
至于成本，得看你的方案了，你是采用开源自建，还是与厂商合作共建，合作情况下如何分工，哪些外包出去，这个你得仔细考虑。通常，如果人力资源有限，技术实力有限，那就由承包给厂商来实施吧，不然到后面也是个烂摊子。但是，全部外部给厂商的不足也是明显的，一不小心你就被锁定，每年烧钱的跑不掉的了，尤其是项目上马后，停也停不下来了。
8、私有云环境下的统一资源纳管怎样实现？
解答：
这个重点考验的是云平台的开放度。
企业在自身选择云平台的时候要充分考虑自身的环境，有多少类型要涉及，有多少平台要纳管，是否支持异构，是否支持模块化接入。
建议将云平台纳管层面定位为工具框架，实现足够的开放性，标准化接口和统一格式接入，各个领域按标准完成自身自动化封装、自身配置采集、统一视图展示在云平台上，云平台通过流程引擎调度个领域模块，实现操作、纳管。
在实施层面，基本上则是领域负责制，每个想要被纳管的平台（计算、存储、网络等），完成自身的开发和服务的注册。
9、私有云是否需要支持多租户？多租户和单租户本质区别有哪些？
解答：
多租户的概念包含三层用户集成：
数据中心层
基础架构层
应用程序层
云计算技术设计中的重要内容是多租户的基础架构和应用程序层集成。此集成经过特别的调整，可节约成本和开发具有高度可伸缩性的 SaaS 应用程序，而这是以牺牲安全性和客户隔离需求 (segregation requirement) 为代价。很多情况下，这样的设计都是有效的，尽管可能不太适用于金融应用程序。
在数据中心租用空间并提供服务器、路由器和线缆以支持多个客户软件，这项功能自从硅谷创立初期就已经存在，因此用户对于数据中心层多租户应该并不陌生。如果正确实现此配置，则该配置能够提供最高级别的安全需求，它用防火墙和访问控制来满足业务需求，还定义了对提供 SasS 的基础架构的物理位置的安全控制。大多数情况下，可以将数据中心层多租户用作服务供应商，向公司提供场地来安置硬件、网络以及软件。
基础架构层的多租户是最简单软件栈概念，一个栈专用于一个特定客户。与数据中心层多租户相比，此配置更节约成本，因为栈是根据实际的客户账户部署的。在这种情况下，可以根据实际的服务使用来增加硬件需求。另外，基础架构层的每个用户都可以选择高可用性。每个客户都知道栈，所以软件和硬件最佳实践提供了一些实现选项。
应用程序层多租户需要在软件层和基础架构层基础上进行架构实现。需要修改现有软件架构，包括应用程序层的多租户模式。例如，多租户应用程序需要一些应用程序方法和数据表来访问和存储不同用户账户的数据，这会牺牲安全性。但如果正确实现此操作，就可以节省成本。对于小部件和简单的 Web 应用程序，应用程序层多租户是一个可行的解决方案，因为单个开发人员可以更快地开发软件，也负担得起调整规模的费用。不足之处在于更复杂的应用程序架构和实现；与基础架构处理多租户不同的是，如果基础架构发生变化，应用程序团队需要保持编程模式的可伸缩性和可靠性，而且在未来可用。
多租户服务指定从在软件应用程序中构建并直接访问的 HTTP RESTful 接口或 WSDL Web 服务终端访问。这些服务是建立多租户模式的面向服务的应用程序的关键，因为它们可重用于多种事务类型。
应用服务器是应用程序和基础架构层多租户的关键部件，因为多租户会影响安装、配置和应用程序代码。对于基础架构层，应用服务器的多租户意味着调整更快、更广，它配置了额外的服务器，其中包括应用服务器安装、配置和应用程序代码。多租户层不需要更改代码（除非应用程序设置了特别的需求），调整也很简单，一般由 IT 运营机构完成，而不是由开发人员重新设计应用程序源代码。通常，如果添加了新客户，则需要添加一个相同配置的栈，以便更轻松地满足安全需求。
10、私有云平台架构中，安全规则和方案怎么制定？
解答：
1) 云计算物理层安全
云计算物理层面临着对计算机网络与计算机系统的物理装备的威胁，是指由于周边系统环境和物理特性导致的网络安全设备和线路的不可用，从而造成所承载的网络应用不可用。主要表现在自然灾害、电磁辐射、三防（防火、防水、防尘）及恶劣的工作环境方面，而相应的防范措施包括抗干扰系统、物理隔离、防辐射系统、供电系统的冗余设计和可靠性备份，采取前后上下等多种通风方式。
2) 虚拟化资源层安全
虚拟化层是云计算代表性的属性之一，也是现阶段云计算数据中心实施最为广泛的技术，基于服务器的虚拟化技术，可以将单台物理服务器虚拟出多台虚拟机并独立安装各自的操作系统和应用程序，从而有效提升服务器本身的利用效率。但是这种虚拟化技术也带来了一些安全风险，比较典型的有基于虚拟化所衍生的一些安全漏洞，以及针对VM-VM虚拟机流量交换的安全问题。
虚拟化软件导致的安全漏洞风险：这个问题可以从2个方面来看，一方面，以虚拟化应用程序本身可能存在的安全漏洞将影响到整个物理主机的安全。黑客在利用漏洞入侵到主机系统之后，可以对整个主机上的虚拟机进行任意的配置破坏，从而导致系统不能业务，或者是将相关数据进行窃取,如果黑客侵入了虚拟机配置管理程序，则会直接影响到其管理的全部虚拟机的安全。另一方面，基于虚拟化环境开发的各种第三方应用程序的漏洞安全。这些应用程序是云服务交付的核心组成，包括Web前端的应用程序、各种中间件应用程序及数据库程序等，即使在传统网络安全环境下，他们仍然会因为编程技术的缺陷而存在多个安全漏洞，在云计算环境下，这些安全漏洞会继续存在，典型如各种WEB会话控制漏洞、会话劫持漏洞及各种注入攻击漏洞。同时为了适应或使用虚拟化环境下的各种API管理接口，也可能产生一些新的安全漏洞。
云计算虚拟机流量交换的安全新风险：在虚拟化环境下，单台物理服务器上可以虚拟化出多个完全对立的虚拟机并运行不同的操作系统和应用程序，各虚拟机之间可能存在直接的二层流量交换，而这种二层交换并不需要经过外置的二层交换机，管理员对于该部分流量既不可控也不可见，在这种情况下，管理员需要判断VM虚拟机之间的访问是否符合预定的安全策略，或者需要考虑如何设置策略以便实现对VM之间流量的访问控制。
3) 多租户IaaS服务层安全
多租户环境下的基础安全服务主要体现在IaaS服务层。IaaS作为云计算的重要组成部分，其将基础设施包括网络、存储、计算等资源进行虚拟化等处理，能够为每个用户提供相对独立的服务器计算资源、存储资源以及在承载网上设定专有的数据转发通道，这种云计算的模式已经得到IT业界的广泛认可.在本次大地保险云安全平台的建设过程中，基于IaaS模型下的各种安全服务体系的建设其是重点所在，根据现阶段的需求来看，这部分服务主要包括针对云计算防火墙服务、云计算负载均衡业务。不同的租户可以根据自身的业务需求，合理的选择部署云安全防火墙服务或者是防火墙叠加负载均衡业务。部署该安全服务后，每个租户可以获得逻辑上完全属于自己的防火墙和负载均衡。租户可以根据自身需求，设定自身的各种安全防护策略，生成自身独有的安全日志分析报告。同时对于部分需要负载均衡的业务，也可以设置独立的负载均衡的算法，以保证业务的可靠性运行。当然，考虑到应用层的安全风险一直是互联网的重点防护对象之一，各种基于web应用层的安全攻击会导致用户业务系统的权限被窃取以及关键数据的泄露，未来也可以考虑增加一些新的诸如IPS入侵检测等增值服务，用户可以根据自身业务系统的安全级别合理选择是否租用该漏洞防护服务等。这部分的内容后续将作为重点进行论述。
4) PaaS/SaaS应用层数据安全
在云安全体系的建设过程中，PaaS和SaaS的安全建设也非常重要。和IaaS的建设思路不同，PaaS的安全建设，其关键在于平台开放的思想下，开发者应用平台及数据库系统对于多开发者数据安全的适配。典型问题包括针对开发者的用户身份认证，开发者的平台和数据库的访问使用权限控制，不同开发者数据的安全隔离、及操作行为审计等内容。为此需要在数据库的开发及平台应用环境开发过程中考虑到上述安全风险的防护。而在SaaS模型下，应用系统级的多租户共享涉及到的应用层安全问题，除了多租户身份认证和权限控制及数据库安全隔离等需求外，还需要考虑针对应用环境的代码级的安全审计等问题，确保提供给租户的应用程序本身的安全具备很高的水平，不会轻易被黑客等攻击者利用其内在的各种安全漏洞。在本次的大地保险云建设过程中，这部分的安全通过合理配置数据库及应用程序来进行保证。
5) 建立安全运维体系，确保系统安全
除了前面提到的各种安全措施，还需要在运维管理方面建立相应的安全措施，形成完善的运维体系，以确保整个系统安全。
--专业安全运维团队
配备了一支高水平的专业安全运维团队,安全团队的成员都经过严格挑选，具备良好的道德修养和职业操守，同时具备极高的专业安全技术水平。安全团队有严格安全保密制度，有效的安全操作管控能力，以及长效的安全审计机制。
--日常安全流程
安全运维团队实行7X24小时安全值守服务，随时监控和处理日常安全问题。对于常见的网络攻击和入侵探测等，大多数都由云平台自动化处理，少数情况需安全人员人工判断后加以处理。同时，安全团队还及时对各系统运维人员的安全服务请求作出响应，配合各系统运维人员做好安全防范工作。
--应急响应流程
一旦发生特大的网络攻击或新类型的安全问题，安全运维团队将启动突发安全事件应急响应流程。应急响应流程将紧急调动各方资源，临时提升云平台防护门槛，组织专家会诊安全问题，制定紧急应对方案并立即实施。对于新型安全问题，将即刻启动安全防御新功能开发，并尽快上线启用，保证安全系统的及时升级和安全的长效性。
--安全消防演习
安全团队不定期会进行必要的安全消防演习，以考验各种安全流程和资源在实战状态下的有效性。消防演习一般不做事前通知，并在可控范围内发起模拟网络攻击和黑客入侵，同时记录各安全处理环境的效率和结果，最终评判整个安全体系的防卫和响应能力。
11、上云之后对IT部门的架构有什么样的影响？
解答：
云计算使传统意义上的数据中心从原来的成本中心转变成服务中心，支持向公司内部输出规范的、有质量保证的服务，降低服务成本、运营成本的同时促进IT部门运维模式发展变革，简化系统建设、运维工作，提升工作效率。
对于金融保险业，云计算有其独特的价值：
缩短上线周期：
云计算的引入能够显著缩短硬件资源、平台环境、应用系统的部署周期，支持各部门在最短时间内以“随需即取”的方式获取系统部署所需的一切服务资源，运维管理团队即可根据服务模板实现远程快速部署和动态调整，减少重复性建设工作，支撑业务的快速发展变化。
进一步实现绿色节能：
云计算构建于池化的硬件资源基础上，并进一步实现服务化封装及更高层级的细粒度服务复用，从而相应降低对数据中心机房的电力、制冷、空间消耗，实现机房绿色节能。
促进运维模式发展变革：
针对业务需求部门提供自助式服务，需求部门依据定制的云服务目录选取所需的计算资源、存储空间、网络服务、基础平台环境等服务项并提交申请，运维管理团队根据定制成型的服务模板，依靠自动化技术及云管理平台来交付规范的、有质量保证的服务，将传统运维模式转变为以服务为中心的方式，降低系统建设、运维、管理工作量。
运维人员角色的转变，image维护人员，云服务实施人员，持续运维人员，和资源管理人员，角色不通 与传统运维，日后运维多是 运维需求调研开发运维产品上线，自动业务需求梳理开发相关软件上线。
京公网安备 11010802035086号