腾讯云是腾讯的一个基础服务。腾讯云传统来说主要是公共服务，主要面向线上业务提供基础服务架构，其实腾讯自己对于内部的基础架构也是很早就开始，从2012年我们尝试把自己内部的基础架构从传统的ITC转向基于云技术的发展。
腾讯公司是提供互联网业务，腾讯公司自己也是个大型企业，我们自己面临的问题和所有的传统大型企业遇到的问题都是一样的。为什么要用云技术构建基础架构？理由非常简单。互联网业务是变化非常快速、种类非常繁杂的架构。腾讯在很多领域都在进行这样的运作，我们内部有着不同的团队，不同团队对于环境的要求对于环境建设、维护以及交付等等有非常不同的需求。可以说我们内部如果说有标准的话，是非常多的。我们当时最大的一个挑战是交付效率问题。
五年前，我们内部有一个辛酸的笑话，当时IT招员工要“三好”，思想好、技术好、身体好。为什么身体好？因为他要扛机器。调整太快了，甚至一星期前有这个团队，一星期后就没有了。重新搭建另外一套环境需要非常艰苦的资源调整。所以提高交付效率是最大的挑战。为了提高效率，我们优化基础架构这是必行之路。就我们自己的运营经验来讲，希望有更多机会跟其他的OpenStack运营者交流，降低运营成本并不是非常明显的目标。
腾讯基础架构选择基于OpenStack来做，理由非常简单。作为腾讯这样的大型互联网企业不可能把基础架构的命运寄托在一两个私有化公司它们的发展基础上，我必须选择一个公开的、具有发展生命力的，不被某一家公司所控制的技术平台，这对我来说非常重要。所以从一开始，我们就坚定一定要在Open Source社区环境里跟随一个稳定、优秀的平台，跟随Open Source平台的发展，我们选择了Open Source，事实上经过四五年的变化来看，当时的技术决策是正确的。
腾讯云从传统上来说是Public Service，腾讯云的产品从公有云覆盖到私有云，针对不同类型的企业提供不同的灵活的部署方式。腾讯自己就是腾讯云最大的用户之一。当然云的应用之上首先解决基础架构问题，资源问题、计算、网络、存储，其实得益于和腾讯内部许多业务的结合，我们这几年重点发展云基础上的PaaS能力。也许是腾讯自己的特点吧，我们现在内部80%以上的应用不再做PC版的，超过8成以上的应用纯粹为手机而做，For微信，或者App，或者微信公众号，或者微信的小程序。
我们私有云的一个天然有利之处就是可以总结腾讯内部许许多多的互联网产品上的优秀能力，把它转化为云平台的PaaS，进而提升到我们内部去开发应用，开发Pear领域应用的难度。比如大家耳熟能详的微信，从微信最初的公众号到现在的小程序，随着微信后续的发展，怎么样方便把企业的应用通过微信接入等等能力，数据库的能力、大数据的能力、AI的能力，基于人脸识别、语音识别，它们的服务能力通过云平台的集成、改造，让我们内部的很多管理应用能够充分地享受到互联网的最新技术的发展。这是现在云平台努力在打造的一个方面。
腾讯自己其实是腾讯云Tstack私有云这样的产品最大的用户，腾讯是中国最大规模的OpenStack在线运营系统的运营商，我们内部IT环境物理机超过6000台，上面有14000-15000个虚拟机。OpenStack的架构是双中心，我们在深圳和天津有一对一的双活数据中心，在深圳还有一个灾备中心。怎么样用云来构建自己的基础架构，我们碰见一个问题，到底是用公有云还是私有云？我们看来这个问题不应该是信仰问题，更不应该是政治考量，纯粹是用户需求的问题。公有云、私有云各自有所长。我们现在企业内部很多应用的接入点或者服务点实际上在公有云上发生。
我刚才谈过80%以上的应用纯粹已经是手机，不再有PC版本了，手机天然的服务点就是在公有云才能接入。诸如互联网已经解决的非常好的音视频的问题、内容分发CDN的问题，这些如果纯粹从搭建私有云满足需求的话，即使不是不可能，也是要花费极大的精力。所以腾讯的IT基础架构是混合云的架构，我们有一个原则，把所有需要做基于互联网访问的的接入点或者互联网访问的提供点，或者主要和Web用户访问的接入点，全部放在腾讯云通过VPC挂接。而我们内部也有的历史遗留的ERP、HR种种的，另外还有管理数据，具有私密性要求的数据，在我们的私有云上。
刚才谈到了我们怎么构建的。还有一个我们下大力气发展的是运维管理平台。上午已经有很多位嘉宾谈到他们在自己的云平台向客户提供服务的时候也充分考虑了运维的重要性。对于腾讯IT来说，我们本身是运营商，对我们来说建设好一个云固然重要，但怎么样运营好、管理好这个云，让它能够稳定发挥作用，让它能够满足内部的需求，这才是我们的生命线。所以我们花了很大力气在运营管理能力上下了很大功夫。我们不能指望我永远Higher一支具有极高IT水平的运维团队，我们一线的运维团队不可能是一支技术精英团队，很大一部分是技术蓝领工作，他们需要的不是功能复杂性、不是技术先进性，他们每天在控制台上接到用户需求，怎么样完成，怎么定位排障。在这个上面我们虽然做了很多工作，但是依然有很多缺憾。我在这里呼吁，如果OpenStack社区能够在管理性、运维性上有更多团队、有更多人关注的话，相信对于OpenStack在企业里更大范围得到应用会是极大促进。这些工作虽然很细微，但是是决定用户能够长期坚持下去的一个关键因素。
除了工具外，还有一个重要体会，管理一个云平台和管理一个传统的ITC的IT环境，这两个阶段我们都经历过，是非常不一样的经验。它们有相同之处，它们也有非常不一样的的地方。事实上，我们摸爬滚打这么多年，现在建立的三线的运营保障，包括它的工具、岗位定义、流程，可以说每一条规则都是血的教训换来的。对于有志于在OpenStack能够运用在自己企业里面，采用OpenStack做基础架构研究的企业来说，这样的一个投资，这样一个团队或者说这个方面的重视是能够用好OpenStack、能够充分体会到OpenStack强大技术的一个关键保障。
下面花点时间谈一下我们在运营这一块的情况，刚才谈到了运营的重要性，无论怎么强调都不过分。我们认为它和传统的ITC运营来比，运营OpenStack云平台有什么不一样，从互联网企业的运营经验来看，OpenStack最大的特点或者说云平台最大的特点，它是活的，它是有生命的，随着时间的发展、随着业务的发展不断地在做调整的工作。我们的平台没有一天不在做优化、没有一天不在做调整、没有一天不在做它的演进。它的演进从第一天就开始了，上面搭载的业务来说，从它的标准入云，对于云平台构建也需要合理分区，不要一味追求规模，不要一味追求技术先进性或者架构的完美。再就是柔性可用。它还是有生命力的，没有一天可以停止优化。
业务标准入云。现在建云的第一项工作是把现有的业务迁移上云。但是不是所有业务都合适迁上云呢？愿望是美好的，希望所有以往的平台和系统都能够通过努力运载在新的平台上，但从实践来看，这个目标是梦想。即使腾讯经过这么多年，我们投入这么大的精力，有自己的团队，应用也是我们自己做的，我们现在业务真正跑在云上的比例也就65%，我们内部业务，包括开发、测试、管理应用等等只有65%，再想提高是非常困难的。我们自己内部做一整套的，你能不能入云，如果入云什么样的级别能够入云，想达到更高的入云程度，需要做哪些改造，建立了一整套标准。有句话说“错误的开始绝对不会有好的结果”。我们建设云平台当然是希望它能够发挥更好的作用。如果开始就选择错了，把一些并不可能在云上运转的很好的业务引入到云平台上。最后得到的其实是你自己、你的客户对云平台本身失去信心，所以我们对一开始业务的“入云”是有非常严格的把关的。
第二是分区模型。互联网公司都想大，大家所有的通稿上都是我的用户有多少、集群有多大、支付笔数有多少、支付金额有多少等等，但实际运营来说是有最佳限制的，有一个平衡点。云看起来采购成本降低了，但实际这些成本都将转化为你技术的设计、运营上，没有任何两朵云的架构完全一样。你业务的主要特点是什么、业务模型是什么、读写模型是什么、访问模型是什么、后台压力主要来自哪里，这些不一样就带来了整体架构的不一样。腾讯内部有太多的的团队，太多对基础架构有不同要求的部门，腾讯IT云的规划设计是Set分区。计算工具、存储工具、网络控制工具，这些大致的模型是一样的。但比例怎么搭配的，在Storage Pool里采取什么配置，完全根据应用特点去规划。一旦应用的操作方式发生了改变就会有从Set之间的迁移。我们的运营团队从以前不断地搬机器，现在不断地的根据运营数据调整，从一个区调到另外一个区。
第三个经验，柔性可用。这是从我们互联网业务上来的，通常来说整个服务能力不应该是梯形结构，通常应该是矩形的，大家是等同的。柔性可用的就是你的所有应用、所有的平台服务其实不是平等的，总有它核心的东西、总有它边缘的服务，从用户角度来讲，有些服务对它而言是重要的，有些服务对它而言是不重要的，或者出了问题是感知不到的。举个例子，大多数人都在用微信。大家用的微信最多的功能只是一项，就是发文本，然后发一些表情，发一些小图片。柔性可用的概念，如果资源不够的情况下，我首先保证这些。大家会发现，有时候你发大图片、发大视频不成功，但是发小图、小视频可以，这就是柔性可用的概念。
对于平台而言，什么叫柔性可用？一个平台也分核心服务，调度服务、分配资源服务、正常运转的服务，它也有一些边缘性的为应用提供的，单个的应用级别就要降一些，还有内部管理服务，比如扫描、Retune的访问工作。对于这个服务的柔性可用的体现，我们花了很大力量去做调整，或者做应用上的调整。比如容量不够的情况下如何做智能的自动限速，我们的最高标准是平台整体可用，并不是每个应用100%可用。在平台受到压力比较大的情况下，也许我们会降低，会智能调整每个应用得到的资源服务，比如网络速度会降低，存储分配的资源会降低，比如在前端的应用排队会降低。从用户角度来讲，他感到他的应用慢了。甚至有可能有些应用会说，系统正忙稍候调用。这样的手段保证了整个平台的可用性，进而提高了这个平台在用户心中的可信度。现在OpenStack还远没有到完善的地步，我们运营当中OpenStack会出现一些不可预知的问题。任何一个技术平台都会出现一些问题，我们首先要做的，当然平台自身能力的进步绝对是第一位的，科技是生产的第一动力，但是任何阶段都不可寄希望于你用的技术或者平台绝对不出问题，或者绝对可用。作为运营者来说，因为运营质量是生命，所以运营者要更多地考虑这样一些问题。也希望能够借这样的机会向OpenStack社区呼应，在飞速引进各种各样的先进技术，飞速的推动技术发展的同时，也迫切的希望有一些力量可以关注到如何能够让OpenStack、如何能够让基于OpenStack构筑的平台更加稳定，在出现问题的时候更容易的自保，等等方面希望投入更多的力量与关注。
最后一个经验，持续优化。我们刚刚建设OpenStack的时候，怎么老是在做更新呢，还有做资源的调整。后来我们习惯了，认为这个事情是生活的一部分，你采取了OpenStack、你采取了云平台，这就变成了日常生活的一部分，不是意外而是日常。我们觉得这个原因来自于，相对于以前传统的ITC方式，以前的资源是独立的，现在我们所有的痛苦也好，或者说所有的运营压力也好，都来自于现在面对的是一个整体，以前总有办法把一个一个的应用归到一个一个单独的资源上，现在面对的物理上永远是一个整体。你怎么样使用资源的方式，就决定了你的平台应该支持它。
举个例子数据库读写比例不同的应用，应该归属在不同的集群里面。存储应该怎么配置。你主要读小文件还是主要读大文件，还是主要读视频文件。视频文件平均多长。如果大家看短视频和看电视剧，对磁盘读写的模型完全不一样。以往通过单独的资源设置来满足不同应用。在整体规模上怎么响应到这些需求。我们没有办法预料一个应用是怎么发展的。它绝对不是死的。如果应用是活的就决定我们的平台必须是活的。对于一个云平台来说，永远没有End的日子，它永远成长。
开始看似节省的采购成本，其实这些成本都将转化到这些工作当中去，你必须有一个清醒地认识，你的生活，IT的运维环境由于采用云平台，和以前发生很大的不一样，对此我们需要在上面投以技术建设同样的重视，并愿意为此投资，只有这样才能够运营好一个平台。我们跟其他企业交流合作过程中，我们看到太多在云平台上不成功的，或者不那么成功的一些反思。坦率讲，极大多数并不在于它采用了什么技术，用A公司产品还是B公司产品，很大程度在于自己的运营团队没有把这个平台运营好。用OpenStack云平台相当于你之前开帆船的，现在给了一艘航空母舰，要把一艘航空母舰的战力发挥出来，你在这上面的投入显然和以前不同。
