我的一点企业做云经验

最新推荐文章于 2024-11-15 11:54:09 发布

weixin_34355715

最新推荐文章于 2024-11-15 11:54:09 发布

阅读量195

点赞数

文章标签：运维操作系统 devops

最近，经常有朋友问我在企业做云的经验，也有人问我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。
一开始就考虑后路：想好云团队将来的出路。轰轰烈烈把内部云平台做完后，团队要干嘛去？是解散呢，还是去做外部市场呢？每种做法都需要有不同的方案，建议提前准备好。
做云是一个公司的事情，不是某个事业部的事情。要有公司层次的总体部署。