网站icp备案号怎么查,北京 网站建设 SEO,wordpress imgedit,网站产品介绍页面的布局方案最近#xff0c;经常有朋友问我在企业做云的经验#xff0c;也有人问我OpenStack二次开发项目经验。正好这方面也有点经历#xff0c;那现在就把我过往有关经历整理整理#xff0c;总结出几条心得体会#xff0c;分享给大家。 技术#xff1a;我们OpenStack二次开发做了什…最近经常有朋友问我在企业做云的经验也有人问我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等组件。不管每个组件的二次开发程度如何有个人看着肯定是需要的。核心模块比如novacinderneutron存储网络运维等需要有技术能力较强的人看着其它较小的模块可只花一小部分时间看着。因此技术团队的骨架非常重要就像足球队的中轴线一样。无论成员怎么变化只要骨架不大变那都问题不大。 我们openstack团队的组织结构大概包括产品经理、界面设计师、技术架构师、技术经理、开发、测试、镜像和部署、运维等。 做法做云是整个公司的事情 云不只是一个云团队的事情。一公司做云需要公司多个团队的参与。 战略团队战略团队负责公司的做云战略至少包括优势、劣势、机遇和挑战等四个维度的分析。这个战略会对公司做云进行顶层设计。设计好以后就是落地的事情了。 云研发和运维团队这个就不再细说了其职责是规划、建设、运维云平台。 IDC团队云平台在IDC中运行因此肯定需要IDC团队的参与。IDC做不好云平台就不会运行得好。 运营团队云搭好以后需要运营团队来把它推广给用户。需要确定推广策略、计费方式、回款方法等。 客服团队运营团队把云推广出去后客户就会来上云客服团队是负责接待客户、提供方案、处理问题的。这团队要熟悉云懂得一些云上实践还能做好前后台的沟通。 应用团队应用团队是云资源的申请者和使用者。该团队需要懂得如何在云上部署业务如何做高可用架构如何运维云上应用。 市场和销售团队如果有云产品对外销售那就需要这两个团队了。云产品往往需要技术型市场和销售人员需要对云产品和方案有一定了解。 后台支撑团队包括采购、人事等团队需要考虑具体情况对既有流程做一些调整。 做法按次序做事 我儿子在上课外课时老师反复强调一个做法就是要『有序思考』。大部分题目通过有序思考都能解决。回到我们做项目有序做事也很重要很有价值。我想说不要想一口吃掉大象。 我们做基础云从不同维度有序地进行 先搞OpenStack一个region到两个再到三个region。 先用集中式存储再搞分布式存储数据逐步迁移。 从核心功能到扩展性功能。 对于大的功能需要多次迭代不要一上来就整大而全的。一步一步做扎实获得用户认可这才是王道。 先从外围业务上云再到核心业务上云。 团队也由小而大逐步扩张。 这么做有几个好处比如 领导不担心因为你给他们看了总体规划还有具体的实施计划一步一个脚印走得很踏实领导当然放心。 团队不紧张有一个成长和适应的过程能力平稳增长承受的压力平稳增长心里就舒坦。 用户不担心看到前面的阶段性成果后用户对新的功能和平台会越来越放心。 投入更合理不需要一次性大投入。 做法按规律做事 任何事情都有其独特的内在规律。违背了规律做事情是要被惩罚的只是时间问题。 做事情肯定需要投入。搞云也不例外甚至投入要更高。因为搞云的人的工资确实比较高这不是负责招聘的人决定的而是行业决定的。而且人家还要看你的平台如何。好平台薪水还能打个折平台不够好人家还要加钱。所以企业对此要有心理和财务准备一定要提前算好能投入多少能投几年投入产出比如何等要是半途而废对大家都不好。 云技术真的很复杂。不要想着几个人就能搞好是需要一个团队的而且还要讲究搭配看团队成员的水平。 云平台从规划、研发、上线、运维等是一个流程性过程不能想着一个月招聘再一个月写代码然后第三个月就上线然后还跑得又快又好。 做新技术的人有些不一样因此有些管理政策需有些差别。比如不能老想着搞云的人一天到晚写代码人家还要学习新的技术参加参加黑客松之类的码农聚会平时还要时不时聚会讨论讨论技术呢。 云产品上线到稳定有个过程不是上线了就稳定没有问题了。这个过程中需要有小白鼠来试用不要想着放在那里几个月平台就自己好起来了。很多时候需要有推手让一些不那么重要的应用先在上面跑起来。发现问题及时修改不断迭代才会有想要的结果。 云产品从研发出来到看到经济效益有个过程还需要多种角色参与比如运营、市场、销售等。不能觉得有个好产品很快就能卖出去回来钱。而且这些都是必要条件还不是充分条件。 开源社区、各种评奖大会、各种meetup的钱PR的钱该花还是要花。这就是所谓生态和你看得惯看不惯无关。 心得给做云的技术人的几句话 给企业做云稳定是第一位的。稳定稳定稳定重要的事情说三遍 云技术真的很复杂。没有金刚钻揽不了瓷器活。好好学习天天向上是王道。如果没这心思或者没有体力估计就得考虑转型了。 除了钻研技术以外还要看看业务。技术是为业务服务的。业务是目标技术是实现手段。不能在产品讨论的时候一言不发然后代码实现时候问题N多用户来问怎么用一脸懵逼。 要将DevOps落到实处不能只停留在理论和口头上。比如产品上线后到稳定前建议研发积极主动参与运维工作。这么做会有很多好处比如看看自己做的东西跑得咋样用户是怎么用的运维都在干嘛等等。 为用户做东西。有用户用才是王道。界面画得再好新技术用的再多如果没有用户用一切就会白费了。 要低头做事情抬头看榜样。除了在某几个方向有深入钻研以外还需要时不时看看技术发展大势。云这概念来自IBM首先是AWS做出来的当前公有云在引领着技术和产品发展趋势。需要经常看看公有云厂家都在玩啥新东西。 产品、开发、测试、运维都是一个团队只是分工不同。只有齐心协力才可能给用户交付一个好的云平台。 心得给打算做云的企业的几句话 关于做云的动机是真的需要做云吗要做的是哪种云打算投多少钱打算投几年本来有个各种云的列表但是后来担心对号入座就删了。每种云都有不同的做法有些甚至迥乎不同在动手之前一定要想清楚了。 关于自研和购买第三方产品之间的取舍真要搞云的话要在自己搞云研发团队和购买第三方云产品和服务之间做出合理抉择。自己弄的话算钱的时候要算仔细了不能只算研发团队那点工资还有设备、运维团队、IDC等各种费用都得算。找外部团队的话要考虑的事情也不少比如现在团队会测试外面厂家的产品不报价合理不口碑好不有烂尾项目历史不是真做产品和技术的还是做外包的是有真本事的还是动嘴皮的团队的人都在哪里呢是不是都扑在某个大客户那里了呢有找三四家做下对比测试吗 关于云的功能真的要那么多云功能吗SDN是干啥的有哪些坑得先了解清楚分布式文件系统是干啥的市面上有便宜又好用的产品不分布式存储和SAN存储啥关系是替代呢还是互补呢还是什么都不管反正就是要用容器云平台真的需要吗公司现在和短期内有几个应用能是面向容器开发的呢研发团队玩过容器没没的话是培训呢还是换团队呢 关于云的目标公司都有哪些应用系统呢是不是有很多windows2000上跑的应用系统啊KVM上跑windows虚机还好使不是不是还有很多古老的系统放在某个角落公司业务应用研发团队主要是基于linux编程呢还是基于windows编程呢 该请的人要请该花的人要花该等的时间要等。需要的话多问问专家吧。 尊重规律做事不要想一口吃个胖子不要幻想着很快一朵成本低又稳定性能又好各种应用都能跑的云就降临IDC。 一开始就考虑后路想好云团队将来的出路。轰轰烈烈把内部云平台做完后团队要干嘛去是解散呢还是去做外部市场呢每种做法都需要有不同的方案建议提前准备好。 做云是一个公司的事情不是某个事业部的事情。要有公司层次的总体部署。 啰嗦了这么多有些是自己亲身经历的有些是道听途说的有些是拍脑袋想的。希望做云的人和做云用云的企业单位都好运 谢谢您的阅读也欢迎关注本人的公众号
