个人一点企业作云经验

最近，常常有朋友问我在企业作云的经验，也有人问我OpenStack二次开发项目经验。正好这方面也有点经历，那如今就把我过往有关经历整理整理，总结出几条心得体会，分享给你们。

技术：咱们OpenStack二次开发作了什么？

我以前介绍过咱们基于OpenStack二次开发作了集团的基础云平台。从环境上看，咱们作了一个小型公有云，以及一个分布在两地三中心的私有云。 

从 OpenStack角度，主要包括OpenStack底层组件的二次开发，以及CMP的研发。二者可能没法截然分开，因此我可能两个都涉及到，可是本文内容以OpenStack组件的二次开发为主。咱们主要在OpenStack Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic等组件的基础上，根据需求，作了一些二次开发。好比，咱们在Telemetry 项目上作了很多改动，团队以前有发过一篇文章 http://www.infoq.com/cn/articles/how-to-implement-cloud-monitoring-alarm-service。

技术：OpenStack二次开发的一些心得

• 若是有在利用社区代码和自研之间作取舍的话，仍是尽可能用社区开源代码吧。节省成本又省事，未来还方便升级。

• 若是要自研的话，要尽可能控制自研范围。遵循『能不改就不改，能小改不大改』原则，只有在须要的时候，才修改社区代码。

• 根据需求合理选择所须要才用的模块。在动手修改代码以前，多讨论，多思考，多测试，多对比，多比较。若是没把握，就先小动再大动，一步一步动。

• 积极贡献社区。自研部分的代码，若是能合并到社区的，鼓励贡献到社区，各个企业要积极参与开源生态。

• 团队要采用和社区一样的流程、工具和要求。

团队：产品和产品经理

OpenStack二次开发每每是以一个项目形式进行。这个项目要成功，一个好的产品经理很是重要。在咱们团队，我本身身兼产品经理这个角色。 

我以为PM这个角色须要具有如下几个条件：

• 技术 - 对OpenStack比较懂。这里的『懂』，我认为更偏重广度，而不是深度。所谓广度，就是对OpenStack的主要组件、功能、用途、适用场景、使用方式等都比较了解。

• 业务 - 懂业务需求。OpenStack平台是要支撑业务的，而业务的需求对OpenStack平台很重要。OpenStack中的组件就像积木，不一样的拼装方式，会有不一样的结果。每一个企业都有本身独特的业务场景。所以，产品经理须要充分了解这些业务场景，以及它们对OpenStack的影响和需求。

• 产品 - 具有产品经理的基本业务能力。包括但不限于，沟通能力（能说）、写做能力（会写）、各类工具使用（我当时比较土，主要就用Confluence管理文档、用Axure RP画原型，用Word/Powerpoint/一些在线网站画图，用XMind花思惟导图等）、项目管理能力、对用户体验有一些了解等。这里，我想区分一下2B产品经理和2C产品经理。我认为两种角色有比较大的差距。2C的PM不少精力须要放到产品运营、用户体验上，而2B的PM的不少精力应该是放到企业用户的需求上。

我以为，PM若是具备懂技术的解决方案架构师的背景会比较合适。 

PM的主要职责，包括但不限于：

• 产品规划。包括中长期的宏观规划，项目分几期，每期哪些功能，支持哪些业务；也包括短时间规划，一个项目内，有哪些功能，功能优先级定义，上线计划等。

• 产品设计。我当时主要的产品输出是PRD文档。咱们的主要参考对象包括青云、阿里云、腾讯云、AWS等几个公有云。

• 产品研发管理。从产品文档输出，到产品研发，到产品上线，交付运维等，PM都须要有参与和必定程度的控制。 

我作PM的一点心得：

• 产品经理是要对产品成败负责的人。

• 产品经理须要在作产品前、作产品中、产品发布后不断接触用户，不放过任何一个抱怨，不要怕被用户嘲笑甚至骂，才能真正找到改进产品的点。

• 在参考其余家产品的时候，要充分考虑到每家产品面向的客户及场景，也就是想明白他们为何会那么实现。以云弹性伸缩功能来举例子。在公有云上，它是一个挺重要的功能。可是在私有云上，一来企业应用没有多少机会须要伸缩，二来即便在某些时间要伸也通常都是提早准备好资源。所以，在私有云上，弹性伸缩并非一个关键功能。

• 作企业基础云的产品的目标之一是实现用户真正的自服务。用户根据界面上的文字和提示，必要的时候结合用户文档，能够自助顺利地使用各云产品。要尽可能减小用户找客服、运维，甚至研发的需求。

• 产品上线只是一个阶段性的里程碑，不意味着产品开发的结束。只有不断迭代，才能不断改进产品。只有达到了设计要求的产品才能上线，不然就必定不要上线。产品经理必须有在须要的时候说『NO』的勇气和决心。

• 产品经理是产品的第一个用户。在寻找用户点的时候，要抛弃一个专业人士的思惟方式，把本身当作一个小白用户，不然你永远不知道用户须要什么，用户不理解什么，用户抱怨什么。还须要摆脱本位主义，少从我的角度思考，多站在用户角度看问题。

• 产品不是了解点用户需求，能画点产品原型就能作好的。一个好的PM，会把产品装在内心，时不时拿出来琢磨琢磨，时不时跟用户聊聊他们的使用感觉和抱怨，不放过任何一个用户反馈。

• 要学会区分真需求和伪需求，强需求和弱需求，紧急需求和通常需求，大需求和小需求等；要学会作长期规划和短时间规划；要学会区分优先级。

• 产品须要象小白同样思考，不能动不动就拿技术实现说事。用户无论你是如何实现的，只管你的产品能不能用，好很差用。 

团队：技术团队

没有一个比较完整且给力的技术团队，是作不了二次开发的。咱们使用了OpenStack Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic等组件。无论每一个组件的二次开发程度如何，有我的看着确定是须要的。核心模块，好比nova，cinder，neutron，存储，网络，运维等，须要有技术能力较强的人看着，其它较小的模块，可只花一小部分时间看着。所以，技术团队的骨架很是重要，就像足球队的中轴线同样。不管成员怎么变化，只要骨架不大变，那都问题不大。 

咱们openstack团队的组织结构大概包括：产品经理、界面设计师、技术架构师、技术经理、开发、测试、镜像和部署、运维等。 

作法：作云是整个公司的事情

云不仅是一个云团队的事情。一公司作云，须要公司多个团队的参与。

• 战略团队：战略团队负责公司的作云战略，至少包括优点、劣势、机遇和挑战等四个维度的分析。这个战略会对公司作云进行顶层设计。设计好之后，就是落地的事情了。

• 云研发和运维团队：这个就再也不细说了，其职责是规划、建设、运维云平台。

• IDC团队：云平台在IDC中运行，所以确定须要IDC团队的参与。IDC作很差，云平台就不会运行得好。

• 运营团队：云搭好之后，须要运营团队来把它推广给用户。须要肯定推广策略、计费方式、回款方法等。

• 客服团队：运营团队把云推广出去后，客户就会来上云，客服团队是负责接待客户、提供方案、处理问题的。这团队要熟悉云，懂得一些云上实践，还能作好先后台的沟通。

• 应用团队：应用团队是云资源的申请者和使用者。该团队须要懂得如何在云上部署业务，如何作高可用架构，如何运维云上应用。

• 市场和销售团队：若是有云产品对外销售，那就须要这两个团队了。云产品每每须要技术型市场和销售人员，须要对云产品和方案有必定了解。

• 后台支撑团队：包括采购、人事等团队，须要考虑具体状况，对既有流程作一些调整。 

作法：按次序作事

我儿子在上课外课时，老师反复强调一个作法，就是要『有序思考』。大部分题目，经过有序思考，都能解决。回到咱们作项目，有序作事也很重要，颇有价值。我想说不要想一口吃掉大象。 

咱们作基础云，从不一样维度有序地进行：

• 先搞OpenStack一个region，到两个再到三个region。

• 先用集中式存储，再搞分布式存储，数据逐步迁移。

• 从核心功能到扩展性功能。

• 对于大的功能，须要屡次迭代，不要一上来就整大而全的。一步一步作扎实，得到用户承认，这才是王道。

• 先从外围业务上云，再到核心业务上云。

• 团队也由小而大，逐步扩张。 

这么作有几个好处，好比：

• 领导不担忧，由于你给他们看了整体规划，还有具体的实施计划，一步一个脚印，走得很踏实，领导固然放心。

• 团队不紧张，有一个成长和适应的过程，能力平稳增加，承受的压力平稳增加，内心就舒坦。

• 用户不担忧，看到前面的阶段性成果后，用户对新的功能和平台会愈来愈放心。

• 投入更合理，不须要一次性大投入。

作法：按规律作事

任何事情都有其独特的内在规律。违背了规律作事情，是要被惩罚的，只是时间问题。

• 作事情确定须要投入。搞云也不例外，甚至投入要更高。由于搞云的人的工资确实比较高，这不是负责招聘的人决定的，而是行业决定的。并且，人家还要看你的平台如何。好平台，薪水还能打个折；平台不够好，人家还要加钱。因此企业对此要有心理和财务准备，必定要提早算好，能投入多少，能投几年，投入产出好比何等，要是半途而废对你们都很差。

• 云技术真的很复杂。不要想着几我的就能搞好，是须要一个团队的，并且还要讲究搭配，看团队成员的水平。

• 云平台从规划、研发、上线、运维等是一个流程性过程，不能想着一个月招聘，再一个月写代码，而后第三个月就上线，而后还跑得又快又好。

• 作新技术的人有些不同，所以，有些管理政策需有些差异。好比，不能老想着搞云的人一天到晚写代码，人家还要学习新的技术，参加参加黑客松之类的码农聚会，平时还要时不时聚会讨论讨论技术呢。

• 云产品上线到稳定有个过程，不是上线了就稳定没有问题了。这个过程当中，须要有小白鼠来试用，不要想着放在那里几个月平台就本身好起来了。不少时候，须要有推手，让一些不那么重要的应用先在上面跑起来。发现问题，及时修改，不断迭代，才会有想要的结果。

• 云产品从研发出来到看到经济效益有个过程，还须要多种角色参与，好比运营、市场、销售等。不能以为有个好产品，很快就能卖出去回来钱。并且，这些都是必要条件，还不是充分条件。

• 开源社区、各类评奖大会、各类meetup的钱，PR的钱，该花仍是要花。这就是所谓生态，和你看得惯看不惯无关。

心得：给作云的技术人的几句话

• 给企业作云，稳定是第一位的。稳定，稳定，稳定，重要的事情说三遍！

• 云技术真的很复杂。没有金刚钻，揽不了瓷器活。好好学习每天向上是王道。若是没这心思，或者没有体力，估计就得考虑转型了。

• 除了钻研技术之外，还要看看业务。技术是为业务服务的。业务是目标，技术是实现手段。不能在产品讨论的时候一声不响，而后代码实现时候问题N多，用户来问怎么用一脸懵逼。

• 要将DevOps落到实处，不能只停留在理论和口头上。好比，产品上线后到稳定前，建议研发积极主动参与运维工做。这么作会有不少好处，好比看看本身作的东西跑得咋样，用户是怎么用的，运维都在干吗等等。

• 为用户作东西。有用户用才是王道。界面画得再好，新技术用的再多，若是没有用户用，一切就会白费了。

• 要低头作事情，抬头看榜样。除了在某几个方向有深刻钻研之外，还须要时不时看看技术发展大势。云这概念来自IBM，首先是AWS作出来的，当前公有云在引领着技术和产品发展趋势。须要常常看看公有云厂家都在玩啥新东西。

• 产品、开发、测试、运维都是一个团队，只是分工不一样。只有齐心合力，才可能给用户交付一个好的云平台。 

心得：给打算作云的企业的几句话

• 关于作云的动机：是真的须要作云吗？要作的是哪一种云？打算投多少钱？打算投几年？原本有个各类云的列表，可是后来担忧对号入座就删了。每种云都有不一样的作法，有些甚至迥乎不一样，在动手以前必定要想清楚了。

• 关于自研和购买第三方产品之间的取舍：真要搞云的话，要在本身搞云研发团队和购买第三方云产品和服务之间作出合理抉择。本身弄的话，算钱的时候要算仔细了，不能只算研发团队那点工资，还有设备、运维团队、IDC等各类费用都得算。找外部团队的话，要考虑的事情也很多，好比，如今团队会测试外面厂家的产品不？报价合理不？口碑好不？有烂尾项目历史不？是真作产品和技术的，仍是作外包的？是有真本事的，仍是动嘴皮的？团队的人都在哪里呢，是否是都扑在某个大客户那里了呢？有找三四家作下对比测试吗？

• 关于云的功能：真的要那么多云功能吗？SDN是干啥的，有哪些坑得先了解清楚；分布式文件系统是干啥的，市面上有便宜又好用的产品不？分布式存储和SAN存储啥关系，是替代呢，仍是互补呢，仍是什么都无论反正就是要用？容器云平台真的须要吗？公司如今和短时间内有几个应用能是面向容器开发的呢？研发团队玩过容器没？没的话，是培训呢，仍是换团队呢？

• 关于云的目标：公司都有哪些应用系统呢？是否是有不少windows2000上跑的应用系统啊？KVM上跑windows虚机还好使不？是否是还有不少古老的系统放在某个角落？公司业务应用研发团队主要是基于linux编程呢，仍是基于windows编程呢？

• 该请的人要请，该花的人要花，该等的时间要等。须要的话，多问问专家吧。

• 尊重规律作事，不要想一口吃个胖子，不要幻想着很快一朵成本低又稳定性能又好各类应用都能跑的云就降临IDC。

• 一开始就考虑后路：想好云团队未来的出路。轰轰烈烈把内部云平台作完后，团队要干吗去？是解散呢，仍是去作外部市场呢？每种作法都须要有不一样的方案，建议提早准备好。

• 作云是一个公司的事情，不是某个事业部的事情。要有公司层次的整体部署。 

啰嗦了这么多，有些是本身亲身经历的，有些是道听途说的，有些是拍脑壳想的。但愿作云的人，和作云用云的企业单位都好运！ 

谢谢您的阅读，也欢迎关注本人的公众号：