世纪互联1999年在北京成立，2011年纳斯达克上市，2012年跟微软建立合作伙伴关系，负责运营微软在中国公有云业务，就是Azure和office365。互联网比较有名的品牌公司都是世纪互联的用户。对于上海蓝云来说我们在跟微软建立战略合作伙伴关系之后，在上海成立一个世纪互联全资的子公司，由全资子公司上海蓝云负责运营微软Azure和office365所有的业务，我们今天微软公有云在中国任何用户用实际上都是通过我们上海蓝云，也就是技术支持、运维服务、以及销售、以及合同等。
接下来步入我们的正题，今天整个IT行业发生了翻天覆地的变化，由于有云的引入，由于有大数据，由于有物联网等等。所有这一切最终目的是什么？为的是实现我们IT价值，为的是为我们业务服务。既然为我们业务服务，本质上来讲云也好、大数据也好、物联网也好都是基于不同IT交互模型的变化。这个IT交互模型的变化体现在哪些地方？首先在我们传统IT领域，我们交互模型相对比较简单，我们直接自己来采购硬件网络，往上面做软件，通过我们合作伙伴把我们系统搭建起来。随后大家发现这种模型实际上往往比较费劲，因为我们作为用户来讲我不可能从网络，从数据中心到硬件到软件我都很熟，这样一种状况下我们往往请很多第三方合作伙伴帮助我们。逐渐随着业务不断的发展规模越来越大，需求越来越大，很多厂商在这里面发现我们为什么不可以把我们系统先预装进去，用户需要的话，直接把我们预装好的交付给用户，在云之前我们整个IT工业界有大量的预装系统和应用。这种极大降低了用户的部署成本，用户的构建成本。
随着社会分工不断的发展，我们越来越发现，所有这一切其实都是在做重复的劳动，我们能不能把我们整个IT基础设施当成一个服务，这是十来年前我们说整个IT工业界开始走向一个临界的转折点，整个IT工业界的变化是以IT交付模型的变化在引领我们，转变整个IT业发展的思路。
正是由于这种转变就引发了我们另外一个议题，这就是今天我们作为云服务来讲，我们边界开始变得更加模糊，这种模糊体现在哪些方面？第一个，从运维的角度发生了根本性的变化，我们拿传统IT windows为例，我们通常把我们操作系统装在一台硬件服务器上，有专家要表示有不同的看法，操作系统直接搭建在我们硬件上，统过两个操作系统通过心跳线实现，这是单服务器的运维。云环境下面，无论是公有云、私有云、混合云，实际上都变换着我们面向的运维，不是单服务器的运维，而是综合了整个风、火、水、电，到网络、机架、电源、云操作系统、虚机、虚拟化、云PaaS层面所有这一切，我们相当于把整个数据中心变成巨大的单台服务器，在这个巨大的单台服务器上我们部署了云的操作系统。云的操作系统同样像单台服务器一样我们有windowscontroller。这对我们整个运维环境和运维体系构成一个巨大的挑战，也对我们整个运维团队技术的能力有相当的要求。所以这是从运维体系方面的变迁。
我们云作为一个基础设施为的是什么？为的是我们的业务，为的是支撑我们企业的业务，支撑我们客户的业务。云基础之上有解决方案，应用系统，这些应用系统和解决方案，同样需要有方案。我们把底层、硬件、网络、电、操作系统和应用系统整合在一起，通通叫IT部门负责。随着云的引入，这一切切分开来了，通常我们现在企业IT如果用公有云的话，变成我们企业IT往往负责解决方案这一块。而云服务商就负责底层风、火、水、电系统等。这时候相当于我们云运维上又做了切分，一半是云服务商负责，私有云自有机房，另外一半私有云是我们IT部门负责，有很多不同的组合形式。这种组合形式同样因为它是跨企业的边界就会带来一定的复杂度，这就是今天为什么我们云服务商都有大量技术支持服务，云支持服务的原因，因为我们有一部分底层的运维，有我们传统企业内部的运维团队，迁移到云服务商范畴之内。
再来看看从云模型本身，云模型本身业内分得比较清晰，我们有私有云、公有云、混合云、传统IT的模式。实际上我们在当今的IT复杂的范畴之内，我们往往很难说我们就用单个公有云，我们用单个私有云。基于不同的云模型，我们到底有什么区别，有什么差异，我们怎么样选择？以及我们这些选择给我们带来什么样的优势？有什么样的不足？这边我们给大家总结一些基于传统IT、私有云、混合云、公有云的差异。
从第一条线开始看，从传统IT到私有云、混合云、公有云是灵活性的不断上升。今天我们公有云领域里面你需要用的话，今天马上申请一个账号，五分钟以后你开开虚机布应用可以提供服务了，提供了极大灵活性和便利。如果我们混合云环境下，混合云我们往往需要跟我们的自有机房连接，或者跟我们私有云去连接，这里边一定有构建的周期和成本，所以我们说它的灵活性一定会受到影响。
第二个重要考量的维度是成本。引入不同的IT环境，它的成本有差异。用传统IT成本是最高的。私有云来讲跟传统IT不一样的地方，传统IT完全自拥有，私有云一定程度上可以跨部门共享，所以节省了很多的成本。对于混合云来讲进一步的下降，通常混合云结合了私有云，以及通过私有云资源不够的时候去引入一部分的公有云，所以在capex相对低一些，同样opex也相对低一些，它是相对短期使用。对于私有云来讲完全的opex，不需要网络，不需要机房，按需使用。
另外服务等级的角度，这个也是我们另外需要考量的，通常来讲私有云和传统IT我们要搭多高就有多高，网络搭好不去动它，打好补丁，实在有问题我换一台，一台离线一台上线，我们私有云可以做到五个九，六个九，今天公有云环境下面，我们全球之内所有公有云厂商几乎很难高过三个九或者四个九，原因很简单，就是因为要开着车换轮子。
再回到混合云的模型里头。业内最常见的混合云的架构，一边是公有云，一边是私有云，以及我们还有传统的机房，或者我们自己私有的IT，现存的IT，我们现存IT里面也可以搭一个私有云。这是业内比较经典的状况。我们如何把这三块串起来？通常有两种不同的方法，业内称之为用软VPN或者硬VPN。软VPN容易丢包，因为它取决于互联网网络节点跳线次数和状况。第二种拉一根专线叫做硬VPN，就是直接一根专线进去。
接下来看一下我们容易被忽视的误区，这些误区在哪里？我们不要忘了混合云是干什么的，用来支持我们的业务的，我们要考虑业务怎么放，我们组件哪些应该搁在私有云里面，哪些应该搁在公有云里面，我们怎么串起来。我以服务形式放在自有机房里面，以网站调用服务方式搁在公有云上，还是说我全部挪到公有云上，既然它是对外的，这决定我们底层怎么搭，我们虚机是不是跨机房飘，跨机房飘虚机对我们网络构成巨大挑战。我们跨不同的机房，我们私有云机房、公有云机房、混合云机房实现我们负载均摊，我们把业务模板打在不同环境下就好了。
第二个我们现有系统怎么整合？因为我们云一定是高弹性高可用，可以随便飘移，可以随便均摊负载，我今天可以在北京上海来去分摊，我可以在我私有机房分摊，这个分摊这时候考虑怎么样整合现有的应用？以及混合云带来巨大的业务复杂度，这些复杂度怎么来去管理？此外我们说从安全的角度，我们怎么样来去确保全方位的安全性，私有云的安全要求，公有云的安全要求，自有机房的安全要求，实际上是三种不同的规范，我们如何结合这三种不同的规范，以及在不同规范之间传递信息、数据和我们安全架构，这就变得很关键。
由于时间关系我们不一一深入讨论，实际上我们在PPT列出每一个议题都可以展开讨论，因为这里面有大量的东西我们需要关注。
以及我们一些常规的运维服务，由于在三种不同的环境下我们怎么整合起来，不同云服务商之间提供的服务，不同机房服务商提供的服务，怎么无缝满足企业的SLA的要求，以及如何确保合规。我们知道国内刚刚有网络安全法，有我们管理规范等等，这些我们如何确保，我们数据存储，我们加密，我们个人信息保护，以及跨境的传递是不是合法？因为现在新的网络安全法要求，跨境传递公民个人信息超过多少条以上是需要做安全审计，需要国家相关的管理部门需要来去颁发相应的许可，所以我们说类似这样，这是从设计方面考量。
我们再来看，刚刚我们有跟各位汇报，在三种不同的机房环境下，不同云环境下，我们安全要求是不一样的，所以我们这时候整合变成一个问题，通常我们应该考虑哪些整合？首先第一个，我们要考虑功能性接口的整合。所谓功能性接口整合就是我今天发布一个服务，我这个服务是一个支付服务，这个支付服务我出口在哪，我服务依赖于另外两个服务又是在哪，假设一个在私有云一个在公有云，我们支付接口要有调用方、服务方等问题。第二个管理接口，今天我们虚机飘在哪里，我负载切到哪里去，我怎么控制我的模板，我怎么管理我的模板，这是管理性的接口。第三块业务性的接口，今天我们有很多不同的业务，我有不同的业务中心，我有不同的就像我们上京东一样，分成不同的业务中心，这些业务中心有可能部署在不同的私有云、公有云或者是自有机房怎么协同起来，这是我们三层必须要考虑的，只要我们面向业务，只要我们实现基于混合云下来传递我们的业务给我们用户的话，我们往往考虑这个问题。
同样在考虑这三种不同接口的时候，我们一定要考虑它的安全性。我们公有云下有公有云的安全性，私有云下有私有云的安全性，我们怎么保障传递数据是双向还是单向，以及是允许访问的IP，仅有专线连接还是允许公网等等，这是我们从接口和安全角度来看。
我们再来看跟现有系统对接的角度，跟现有系统对接的时候我们说数据的摆放，就是我们需要着重考虑的问题。我们有不同的数据，我们有用户的数据，我们有衍生的数据，我们有自有机房的数据，这些数据之间怎么对接切换，我们考虑灵活性部署方便，成本、位置、服务等级等等，此外要考虑从系统层级的留存整合、数据整合、展现整合等等。
通常我们做混合云的时候往往有很多比较麻烦的地方。第一个比较麻烦的地方就是混合云环境的治理。传统IT里面我们有Gartner，Hybrid IT的Gartner也是一个重大问题。由于职责模糊性带来我们未来怎么切分，就像我们所有云服务商都面临一个问题，用户打电话说我系统用不了了，云服务商第一反映我们要界定问题在哪里，我先搞清楚问题在哪，才能对症下药，这是分清边界的过程。我们看看到底问题在用户代码里头，还是云底层的代码还是网络，因为今天整个复杂度和边界极大的改变了我们传统IT模型的单一的环境，单一的边界。再次就是接口多重性，有大量管理接口、服务接口、业务接口，这些接口之间怎么调用，我们是不是通过高安全性加证书，如果换证书怎么办？等等，会带来很大麻烦，所以我们需要有接口方面整合管理、版本管理和资产管理。
混合云环境下面验证和授权，前面我们跟大家汇报到我们既然在混合云环境下，我不能只提供一个虚机用户用就好了，我们一定要通盘考量。通盘考量我们看一下我们在Azure里面的一个例子。在Azure里面基于混合云模型验证，首先公有云提供一个AAD的服务，这个AAD服务跟我们私有云环境下面，传统IT里头，自有机房里头windows环境下AD五对接起来，第三方机房，第三方应用，或者第三方的云，一个独立私有云环境我们也可以对接起来，通过AAD的模型不仅在虚机层面，也可以在我们应用层面，我们直接应用引用AAD的验证和授权中心就好了，对很多企业来讲我们不一定非要用AAD，我们自己搭一个也可以，这个并不难，这里面最核心我们如何分离验证和授权，以及如何实现先有验证中心再有授权中心。就像我们身份证一样，就像我们进到酒店的房卡一样，通过这种方式去考虑，就很容易来去实现，但是我们说混合云环境下一定要有这些东西，如果没有这个混合云几乎是用大炮去打蚊子了，因为我们架构建得很多，在上面当成单个虚机来用，没有引用到云的价值和优势。
还有隔离失效问题、合规风险问题，安全处理边界，管理接口脆弱性，以及在公有云、私有云、自有机房之间连接不可用的风险怎么考量，这种风险设计的时候一定要考虑，目前我们在所有，包括我们和用户机房之间，比如说北京、上海机房之间，都是至少双光纤备份，至少两条光纤并且通过不同的物理路由，不是逻辑路由，一条比如说走山东，一条走广东类似这样的，这是未来我们做私有云环境下一定要考虑的，一定是双线路，双路由。以及我们数据的安全和同步，数据交互怎么做？等等。
前面我们讲到它的一些架构设计的难点、运维层面的难点、安全边界的一些难点。我们再来看看对于一些企业我们做应用开发，基于混合云的应用开发，我们通常有一些简单的建议。第一个建议解耦的问题，合适的解耦。耦合程度越高的东西，往往部署在比较靠近的地方，我在北京依赖一个服务在广东，这时候首先部署有大量延迟的问题，其次任何一个网络的中断或者擅断都会给我们带来灾难性，在耦合程度上，耦合程度越高的服务应该是物理位置上部署越靠近。
我们混合云模型下我们机房有可能分散在全国各地，或者同一个城市不同的机房，这时候我们要考量我们怎么样适当的去做解耦。把耦合程度高的给解开，解耦方法有很多，这是一个系统开发层面的范畴。
其次，基于云的优化设计和应用。比如说云里面有很重要的几点，比如说我们的弹性，我们怎么样用好弹性？用好弹性一定要打模板，一定要用到我们全局负载，一定要用到我们的软负载，一定要用到我们云上共享，否则我们没有办法实现高度弹性，这些我们要考量。
其次，我们流程和数据的驱动设计。再次就是约束，网络延迟，数据的本地化，离得越近越好，性能安全，以及应用和服务的整合，以及我们应用配置和云化的一些需求。这是我们基于混合云应用开发方面我们给大家的一些建议。
混合云的应用模式，比如说集成的数据存储、全局化的数据同步、怎么样组合的应用程序，基于云的消息模式来去实现。比如说IOT领域、物联网领域用得最多的就是消息模式，我通过部署在云上的一个消息模式，我随时有IOT接起来就可以用。
我们再来看基于混合云的运维，这是我们公有云，我们云服务商领域里面我们有我们OSS、BSS。这两个不同的架构，支撑我们整个公有云的云服务体系。对于我们云的用户来讲我们有自己IT环境，有自己解决方案的运维，我们有自己的IT部门，我们怎么把这两块更好结合起来，无论对于公有云、私有云都是需要考虑的。这里面由于每一块都比较细致，时间关系我们不一一讨论了，大家知道这么一个大的范畴就好了。这里头可能有一些字比较小，大家回头有兴趣可以看一下最近上上个月信息安全杂志上有我一篇文章就是专门讲这个图的。
这是最后一个话题，就是从运维管理的角度，混合云的运维管理有三种模型。第一种是我们自有机房，云服务。我们说公有云、私有云都有自己服务管理环境有自己负载管理。在自有机房和云服务也有我们服务管理和负载管理。业务模型我们搭建的时候可以搭建一个自定义的整合服务管理的环境，这个环境可以在私有云环境下面，通过调用公有云的接口来去实现统一的管理，统一管理私有云和公有云的模型。
第二种我们完全不去用公有云的门户了，我们直接在私有云的管理模型环境下调公有云工作负载的一些接口，整合到我们私有云环境下面就好。
第三种完全自定制，我们构成双向管理环境，这个管理环境是跨边界了。不同服务商提供基于不同模型运维管理的工具和平台。由于时间关系今天给大家汇报这么多，谢谢大家。
