大型私有云运维实践

大家下午好！我要分享的题目是国家级私有云的实践。分享的内容有三部分：

　　第一部分为什么要建设云？云建设的目标是什么？

　　第二部分介绍一些云技术发展的趋势，有些技术也好几年了，但是最近也遇到一些变化；

　　第三，自己在私有云运维方面的实践。

　　

　　先简单介绍一下自己，我目前在新钛云服工作，工作有19 年了，1999 年参加工作，马上 20 年了。在盛大游戏待了八年，2013 年到珠海金山西山居工作了三年，到 2016 年时到北京中联润通工作，主要做私有云，做了一些国家级的项目。

　　2015年5月份出版了一本书叫《深度实践KVM》，我是第一作者，还是《运维前线》这本书的策划人。

　　也参与翻译了几本书，已经出版的有《云原生基础架构》、《Ceph Cool Book》，还有一本《OpenDayLight宝典》预计快要出版了。

　　

　　1. 云建设目标

　　为什么要建设云？这里有个人的思考，也许不对，拿出来跟大家探讨。我总结的云建设的火箭模型，云建设的目标是要实现云原生，它有什么特点呢？弹性、持续发布、多租户、与基础架构无关、无状态、充分冗余、自动化、模块化、微服务。因为要把业务拆微服务实现云原生，首先要实现基础架构云原生，要实现虚拟机、物理机、容器的管理API化，方便上层调用。

　　

　　当然这是目标，怎么实现云原生呢？对于创业公司来说首选基于云的无服务器计算，一步可以实现云原生，好处是学习成本低，不好的地方就是要使用公有云，要持续产生成本，每个厂商的接口不一样，一旦基于某个厂商建设起来很容易被绑定。

　　第二种方式我们就使用公有云的容器服务，公有云的容器服务相对比较成熟，它会产生费用，而且也很容易产生绑定，容器现在也有通用的接口。

　　当然还可以自建私有云，再其之上构建云原生的环境，这个缺点是什么？要从构建云的基础环境开始，周期非常长，要求也非常高。

　　已有的业务我们要做云原生怎么办？我们要重构这个业务。当然可以搞双模IT，旧的不管，新的方面来建设云原生。

　　

　　现在云原生现状怎么样呢？真正实现云原生的企业并不多，就是头部的企业像BAT这类的，国外的是像谷歌、Facebook。

　　大部分组织或者有些组织只是实现了使用云主机或者虚拟机，离真正的云原生差距还是很大，还有很多的组织只能叫虚拟化，云可能都谈不上。原因是什么？第一个云原生要重构业务，觉得不划算，没这方面动力去做改变。

　　还有就是人才方面的制约，这方面的人要招、培训都有过程，管理层决心也非常重要，不管实现云原生还是DevOps的决心非常重要，中间会碰到任何问题，没有管理层的支持很难推进下去。竞争对手如果没有搞云原生，没有竞争压力也就没有没有推行云原生的决心，所以目前这个现状还要维持很长时间。

　　

　　2. 最近几个云技术发展趋势

　　首先是裸金属，裸金属云也喊了很长时间了，这有一份数据，来自于中国移动研究院，腾讯云推出“黑石”物理服务器，还有Oracle、IBM、华为、阿里云、微软都有裸金属服务器。这是一个趋势，裸金属云发展还是比较快的，到2020年有90亿美金的市场份额。

　　

　　裸金属云有什么特点？它的计算能力比较强，其实就是物理机。可以做到物理层面的隔离。快速交付，实际上是把物理机API化了。还有一个好处是可以和云产品打透，比如说和对象存储、VPC都打通，整个云融合在一起。

　　

　　完全像使用云主机一样使用裸金属还是有些困难，比如说云主机有远程的VNC，有远程的界面可以看到，但是目前这些公有云提供的裸金属服务还有没有远程桌面的服务，技术上还是有好多需要克服的地方。

　　

　　哪些场景可以用裸金属？一是性能要求比较高的，比如说大型在线游戏、基因测序，这种对计算要求比较高的业务，还有一些传统行业，想核心数据库，SAP HANA这些。

　　裸金属对传统行业是比较好的，SAP要云化放在云主机上不太现实，现在有一种方式直接可以搬到物理机上，并且放在云上，这是非常有吸引力的解决方案。还有大数据的分析，它的压力比较高，对压力、网络要求比较高，裸金属也很适合。还有用裸金属搭建私有容器云，这也是比较灵活的解决方案。

　　

　　另外就是超融合，超融合喊了好多年了，目前国内很多厂商都在做超融合，看起来也是一种发展趋势，并且发展比较快。

　　这是中国超融合2016年的市场数据，每年有20%的增长。超融合好处是开箱即用，缺点是比较贵，不适合大型场景，中小企业比较适合，规模比较大的公司一方面成本比较高，一方面要定制化非常麻烦。

　　有没有接口，能不能跟现有的各种系统打通，能否跟流程、认证打通？还有超融合是一体化的，要扩容什么必须按比例扩容。

　　

　　云方面还有一个技术 SDN，SDN实际就是把控制层面和转发层面分离。最近几年有一种声音，就是智能化的网络，我理解就是SDN+AI的解决方案，这个是思科网站的图，学习各种场景然后智能化。Ganter总结基于意图的网络有四个特征：

　　第一个就是转移和验证，将网络工程的命令转换为执行的操作能力，当管理者想要验证策略时，基于意图的网络系统会验证策略是否可以执行。

　　自动实施，软件自动执行网络管理员定义的策略。

　　网络状态感知，收集数据以持续监控网络操作。
保障和动态优化补救，机器学习可以确定保障策略的实施和纠正措施的自动化。

　　如果真的基于智能化的网络做的比较好，以后可能就是通过语音或者图拖拽两下就可以成功了。现在厂商各种产品都能看到智能，这个也是后面网络发展的方向。

　　

　　再就是多云和混合云，混合云也喊了好几年了，多云就是使用多个公有云，像国内的公有云、阿里云、腾讯云。混合云就同时使用多云和私有云，还有异构，既使用小型机，也使用X86物理机。

　　

　　这里也有私有云的数据，其实私有云里OpenStack国内用的比较多，但是国内外使用的多的还是VMware，昨天有一篇文章叫OpenStack的八年之痒，是非常yip有深度的文章，推荐大家看看。

　　

　　接下来是云网融合，把自己的私有云和公有云打通，这样可以保证网络的稳定和数据安全，所以云网融合也是比较热的一方面。

　　

　　云对IT团队也提到了比较高的要求，IT团队要转换到云上面，如何把云用好，如何专注云、控制云的成本？

　　

　　在云时代运维的价值是什么？用云是必须的，用云的过程中要持续优化成本，云原生是持续的追求目标。

　　3.私有云运维方面的经验

　　在规模比较大的私有云里，还是比较讲究用传统的解决方案，像PDCA、ITIL。大型企业里ITIL是深入到IT内部的，必须要用ITIL语言进行沟通。

　　

　　我简单用一个项目的实施周期给大家介绍一下如何运行的。首先就是大型项目里合规是红线，必须要过三级等保，我们也有合规方面的专家。然后要有大量的基于ITIL的制度、流程等方面的储备。

　　

　　再简单介绍一下人员组织的演进，我们原来分为四块，系统方面包括系统方面的部署和实施，系统之上的云平台实施，网络方面专门做网络方面的实施，支持呢方面主要是ITIL的工作台工作，有24小时值班，还有工单系统、工单流转、任务追踪的支持，现场方面主要做物理服务器上架。

　　后来我们组织方面做了变革，分成架构组，主要做架构方面的设计还有方案的验证，和疑难杂症的处理；实施组，要有搭建云的能力，包括机房现场上架不线、服务器OS运维、网络设备之安全设备、分布式存储、云平台，然后内部还有考核，考核完了才具备实施组的资格，支持组做的事情和原来差不多。

　　

　　架构组要有方案的能力和云平台的搭建能力，还要完整的云运维能力，还要脚本以及编程能力。每碰到一个新项目来的时候我们生成虚拟项目组，这个项目会有唯一的运维内部的owner，从项目开始到项目结束，他是唯一的责任人，也包括跟客户和公司技术人员对接。这个项目出了问题这个owner必须要负责，觉得容量不够了就要申请资源，客户有需求也会跟客户约谈，他知道这是责任是他的，他也跑不掉。

　　

　　这就是我们人员组织方面的经验。然后就进入项目立项阶段，我们会指定Owner，然后制定实施方案，主要就是WBS的形式，WBS就是三个字母的缩写，Work、Breakdown、Structure，它是按照一定的结构模式去组织的。

　　

　　举个例子，比如说包饺子有很多人包过，没包过也看到过，可以分解为准备饺子馅、饺子皮等，就不详细介绍了。

　　

　　

　　这一块插播一下七大人生工具，SWOT分析PDCA循环、6W2H法、SMART原则、时间管理、WBS、八二原则，比如说WBS我开始看起来也非常有道理，但是做的时候发现有好多细节上的东西，真正实践的时候，尤其做项目的时候怎么样分解，是按照时间线分解还是按照任务分解呢？关于各种人生方法有好多书大家有兴趣也可以研究一下。

　　

　　做项目实施的时候反而简单了，按照自己的WBS做，做了哪些？哪些没做？为什么有偏差？

　　

　　然后进入项目运维阶段。首先够是ITIL方面的流程，我们使用了大量的开源工具。

　　工单方面我们用的OTRS，OTRS是非常重的工具，但是功能比较多一点，大家可以看一下。有的客户还需要大屏，当然如果要求比较高的话也会定制化开发大屏，国内有好多公司专门做大屏也能生存，最后就是专家，要有对疑难杂症比较熟悉的专家。

　　

　　总结一下吧，有个故事，有一位将军射箭时围了一群人，每次射箭都能射到红点上，周围人都叫好，旁边有一个卖油翁说“无他但手熟尔”，将军很生气，卖油翁说：“以我酌油知之”，然后取一枚铜钱放到装油的葫芦上，拿瓢从很高的地方倒油，油细线一样进入到葫芦中，至始至终铜钱没有沾到一滴油，周围人都很叹服。

　　其实做运维也是这样的，不容有任何的纰漏和偏差，然后也要依靠经验、平台、流程和Checklist和核查机制，长期不断地尝试、修整、积累。我分享就这么多，谢谢大家。

　　

来源：高效运维