一、IaaS, PaaS和SaaS是云计算的三种服务模式
1.SaaS：Software-as-a-Service（软件即服务）提供给客户的服务是运营商运行在云计算基础设施上的应用程序，用户可以在各种设备上通过客户端界面访问，如浏览器。消费者不需要管理或控制任何云计算基础设施，包括网络、服务器、操作系统、存储等等；SaaS 是软件的开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来即用。普通用户接触到的互联网服务，几乎都是 SaaS。
——可以直接使用
客户管理服务 Salesforce
团队协同服务 Google Apps
储存服务 Box/ Dropbox
社交服务 Facebook / Twitter / Instagram
2.PaaS：Platform-as-a-Service（平台即服务）提供给消费者的服务是把客户采用提供的开发语言和工具（例如Java，python, .Net等）开发的或收购的应用程序部署到供应商的云计算基础设施上去。客户不需要管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储等，但客户能控制部署的应用程序，也可能控制运行应用程序的托管环境配置；PaaS 提供软件部署平台（runtime），抽象掉了硬件和操作系统细节，可以无缝地扩展（scaling）。开发者只需要关注自己的业务逻辑，不需要关注底层。下面这些都属于 PaaS。
——需要自己开发
Heroku
Google App Engine
OpenShift
3. IaaS： Infrastructure-as-a-Service（基础设施即服务）提供给消费者的服务是对所有计算基础设施的利用，包括处理CPU、内存、存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。
消费者不管理或控制任何云计算基础设施，但能控制操作系统的选择、存储空间、部署的应用，也有可能获得有限制的网络组件（例如路由器，防火墙，负载均衡器等）的控制。
IaaS 是云服务的最底层，主要提供一些基础资源。它与 PaaS 的区别是，用户需要自己控制底层，实现基础设施的使用逻辑。下面这些都属于 IaaS。
——连资源都可以自己分配
Amazon EC2
Digital Ocean
RackSpace Cloud
参考链接
https://zhidao.baidu.com/question/584394281.html
二、toB /toC/toVC
B：business （企业）
C：customer（消费者）
VC：Venture Capital（风险投资）
起先的To b，他们并不了解客户需求，只知道做一个产品，卖出去，至于客户体验与我无关。
时代在进步，随后出现了To c，先做好客户体验，了解客户最想要的，在做产品，这样更有利销售。To VC，这也是这几年最为流行的，因为无论是B还是C都是需要资金才能做的。
to B产品是根据公司战略或工作需要，构建生态体系，或者推动将流程系统化，提高效率。
to C产品是发现用户需求，定义用户价值，并准确的推动项目组达成这一目标。
而to VC是为风投做产品，得到认可，拿到资金，再研发直到销售。
VC/PE们也发现了这一个问题，不再按照自己的喜好去改变、建议产品，而是详细的去了解这个产品对社会、对消费者的价值。
三、如何做IT项目PoC测试
POC测试，即Proof of Concept，是业界流行的针对客户具体应用的验证性测试，根据用户对采用系统提出的性能要求和扩展需求的指标，在选用服务器上进行真实数据的运行，对承载用户数据量和运行时间进行实际测算，并根据用户未来业务扩展的需求加大数据量以验证系统和平台的承载能力和性能变化。
特别是在应用系统选型阶段，一些大型企业的业务流程比较复杂，并非单一的功能性演示就能覆盖现实的业务需求，这时候需要事先划定一个小范围的实验对象（但是业务逻辑的复杂性要有典型性，有代表性），通过小范围的项目导入与实施，从真实业务的实践到战略意图的实现，来验证系统方案是否能满足用户的需求，从而作出更客观更准确的判断。
PoC测试工作准备前提
1、前期调研充分，并已经对产品或供应商有了较深入的沟通了解；
2、企业对自己的产品需求比较清晰。
PoC测试工作参与者
使用用户代表、业务负责人、项目负责人、技术架构师、测试工程师、商务经理等
PoC测试工作准备文档
1、PoC测试工作说明文档。内容包括测试内容、测试要求（如私有化部署）、测试标准、时间安排等。
2、功能测试用例。主要确认功能可靠性，准确性。内容包括功能名称、功能描述等。
3、场景测试用例。主要测试企业团队实施响应速度、实施能力、集成能力。这部分通常按照企业需求而定，不建议太复杂，毕竟需要供应商实施干活儿的嘛，拖得太长企业耐性受到影响，时间也会拉长。
4、技术测评方案。主要验证产品的性能、功能覆盖情况 、集成效率、技术文档的质量。
4、商务测评方案。主要包括企业实力、企业技术人才能力、版权验证、市场背景、产品报价等。
PoC测试工作
第一阶段 工作启动
由商务或者对外代表对供应商发布正式邀请并附PoC测试工作说明。
建立PoC协同群。以满足快速沟通，应答。
涉及到私有化部署的，需要收集供应商部署环境要求，并与供应商一起进行部署工作，同时企业参与人员对部署工作情况做好记录。
第二阶段 产品宣讲及现场集中测试
供应商根据企业提供的PoC测试工作说明及相应测试模块的用例或方案进行产品现场测试论证。企业参与人员参与功能测试，并填写记录和意见。此阶段供应商往往需进行现场操作指导。
第三阶段 技术测评
供应商根据企业提供的技术要求给出相关支持文档，企业进行现场比对，根据实际情况进行统计记录。并保留供应商提供的资料和对比记录。
涉及到场景demo设计的，建议企业对实施人员能力、实施时长、实施准确性进行比对。
第四阶段 间歇性测试工作
该阶段是在第一阶段启动时，就可以开始了。测试功能外，还包括关键用户使用的体验心得、易用性评价。该部分允许企业用户主观评价，建议可以扩大范围组织间歇性测试，并做好测试用户记录。间歇时间1天或者多天根据实际情况安排。
第五阶段 商务验证
供应商根据企业提供的商务测评方案，积极配合工作。涉及到客户核实的，还需要企业进行考证。该部分工作也是从第一阶段启动时，就可以开始了。
第六阶段 背书归档、分析总结
每个阶段的工作都需要记录好参与人、时间、工作说明，并将测试过程中企业的、供应商的文档分类归档。
验证目的和内容包括
1、产品的功能。产品功能由企业提供，企业可以根据自己的需求提供功能清单，也可以通过与多家供应商交流后，列出自己所需要的功能；
2、产品的性能。性能指标也是由企业提供，并建议提供具体性能指标所应用的环境及硬件设备等测试环境要求；
3、产品的API适用性；
4、产品相关技术文档的规范性、完整性；
5、涉及到自定义功能研发的，还需验证API开放性，供应商实施能力；
6、企业资质规模及企业实施案例等。
验证内容归根结底，就是证明企业选择的产品或供应商能够满足需求，并且提供的信息准确可靠。
验证内容归根结底，就是证明企业选择的产品或供应商能够满足需求，并且提供的信息准确可靠。——类似于提前让用户感受当前的使用，了解当前的内容是不是满足客户想要的需求
评价和验证过程就是寻求风险承担者通过POC和备案设计文档的反馈。通过POC评价，风险承担者可能提出调整规格和设计的要求。
有时，由于设计存在的缺陷或不适当的地方，设计团队就可能只好到绘图板。客户可能决定停止设计或寻找其他团队，这是因为设计没有足够地关注客户和使用者的需求，或者是因为客户需求的不稳定性。
有时这种改变是由客户组织或者项目决策者所引起的。通常，在评价和验证过程结束时，有关设计的承诺、大家都认可的意见都将记录在备案的设计文档中。
这往往是产品开发的生命周期中一个重要的里程碑。在结束评价和验证之后，POC就可继续发展。
四、DevOps
DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
DevOps来自于 Development 和 Operations 的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps 其实包含了三个部分：开发、测试和运维。换句话 DevOps 希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。DevOps是指“开发运维一体化”，即通过工具辅助开发完成运维的部分工作，减少成本。
为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 DevOps 的范畴。
比如 Google 提出的 5 个 DevOps 原则，这套原则中必须依赖于工具辅助的部分只有后两点，更多的则是对于开发组织形式的内省：
- 精简组织架构；
- 愿意承担一部分试错带来的损失；
- 分阶段地一小步一小步地进行转型；
- 最大化地利用工具和自动化流程；
- 对所有的过程和结果进行记录和分析。
DevOps平台的搭建可通过如下工具进行实现，具体安装步骤可参考链接：王教授-DevOps平台
项目管理（PM）：Jira
代码管理：GitLab
持续集成（CI）：GitLab CI
镜像仓库：VMware Harbor
容器：Docker
容器平台： Rancher
镜像扫描：Clairctl
编排：Kubernetes
服务注册与发现：etcd
脚本语言：python
日志管理：EFK
系统监控：prometheus
Web服务器：Nginx
数据库：MySQL redis
