在云栖大会专有云场，我介绍了大数据轻量专有云的解决方案和大数据管家这款运维产品，因为会场的时间有限，仅讲了一个大概，但实际方案到落地经历很多尝试与思考，现在整理出来，供大家参考。
现场
我在A厂一直负责大数据运维，三年前选择专有云这块新业务。当时面对的挑战非常多，也来自各个方面，简单来说，可以概括成如下一个问题，A厂的产品在自身领域里有各种能力，但如何解决输出到专有云市场依然具备相当能力的问题。要解决这个问题就不再仅仅靠产品自身的加码，还需要对专有云用户的体系架构的认知和理解能力，并做出快速的技术判断与执行，比如说灾难恢复，网络的延迟决定了灾难恢复的技术细节，在封闭的环境中，这一指标是可以定义并优化的，在专有云开放的客户环境下，这一指标是有范围并需要自身去适应的。幸运的是，运维岗位之前的知识能力储备我认为恰好符合解决这个问题的要求。
开始市场接受我们在较大规模场景下产品的技术、稳定等方案能力，慢慢提出了中等规模，甚至较小规模的需求。因此，对满足这类需求的方案调研就随之展开，目前可以分享一些过来的经验和想法。首先，怎么看待大数据轻量云的方案？有人认为大数据的平台就应该是解决大规模场景的问题，也许是，如果自身的业务规模就已经足够大且统一（比如电商、游戏等等），而在企业市场并没有具有普遍价值的大规模场景，何来解决这种场景问题的产品呢？企业大数据市场目前就像电脑城组装机的时代，从传统PC时代成长起来的人，都经历过从电脑城攒PC机，到笔记本、一体机，再到Mac一体机。在电脑城买组装机器的年代，你或许根本不会考虑Mac OS的优劣（还有一方面是价格贵），但到了一体机时代，Mac OS的优势就体现出现，从满足部分小众需求的用户到大众普及。我觉得大数据轻量云就是企业大数据市场的软硬一体化方案
其次，轻量化的用户需求处于什么阶段？一直以来在专有云市场，A厂是市场里的技术领导者，但也有竞争者采用硬件+开源体系交付试图弥补技术上的差距，并且希望借此弯道超车占据市场的先机。其实多数客户并不清楚自己的需求应该如何被满足。但是，我觉得随着技术门槛的降低和解决客户场景越来越丰富（这次参加这次云栖大会，我就有这样的体会），客户才会越来越清楚自己需要什么，最合适使用什么。而大数据轻量云是非常有机会的。第一，它代表A厂大数据软硬一体化方案的门槛，第二、随着市场上之前的需求慢慢被满足，它开始通过解决痛点的场景不断加快自身演化的速度。最终，从满足部分用户需求复制到大众客户需求，也许可能成功的不一定是大数据轻量云，但一定有其他的相似概念出现。当然，软硬一体化的方案并不是现在才有的概念，确实很多IT时代的服务公司推出过譬如一体机的方案，这里我觉得区别在于轻量云可以与广义的公有云联接，所以我提到的数据轻量云的软硬一体化方案和传统IT时代单一的一体机有区别的。总结一下，作为通用技术方案已经成熟并试点，在客户场景的推动下，随这波大数据浪潮起航。
再次，为什么大数据轻量云会成功呢？首先，从解决成熟的应用场景开始。在一开始做轻量云方案调研的时候，我们就希望从已积累的客户使用场景为需求出发，方案一定程度保留了基础产品的功能和特性，使得轻量云一样能够承载这些常见的数据业务。但在最终输出的产品组合上给予客户、合作伙伴一定的自主空间，从而降低了使用的门槛，也为了对市场需求的把握。
轻量云架构
其次，了解轻量云的内部架构，就能明白这是一个相对成熟的稳定方案。蓝色框想象成一个机柜，内外网络是隔离且独立，做到内部的流量不影响客户业务。方案内部完全拥有一套独立的基础服务设施，并且在需要的时候，可以与外部服务打通。最小十几台普通x86服务器起步，入门成本大幅度降低；拥有一键启动，优雅停机、以及服务节点、服务自恢复等便捷的运维功能，轻量云的内部任何一个关键服务做到无缝的冗余，任意一台服务器宕机不会影响业务，存储数据的节点遵循分布式系统的设计，任意两台数据节点宕机不造成数据丢失。
最后，轻量云方案集成的阿里大数据平台无论从功能、性能还有生态的丰富性都处于业界领先，详细数据和介绍可以参考 --- 参考链接
对比
总结一下，必须从设计上满足量产要求的稳定性，必须物理成本下降明显降低入门门槛，必须能够集成可复制的数据应用，轻量云都满足。所以我认为大数据轻量专有云也会如一体机一样，通过软件和硬件方案完美结合，从满足部分用户的需求复制到主流用户，逐渐占领市场的先机。
大数据管家和轻量云方案里有什么联系? 运维在专有云市场是不大不小的痛点，我们也要考虑将方案的运维能力产品化。大数据管家的定位就是解决专有云市场这个痛点问题的运维产品。
大数据管家
那么内部的运维工具很强大，是不是直接输出即可呢？我们已经尝试过了，情况并不是想的这么简单。简单来说面向的用户是不同的，内部运维更资深，更贴身，而专有云客户要么不会有专职人员，要么就更本没有相应运维，相反运维工作在专有云就是产品或者方案的一部分。这样一款产品内外相同的定位，相同的问题，但解决的方式就不同了；一方面，从2009年A厂我们开始建设大数据平台，整个团队人员负责平台的建设，从一开始我们就将满足几十W台服务器规模的自动、自助化运维作为目标，按照平台化的思路沉淀日常问题。Tesla是团队内部运维产品的名称，它意味的要完全颠覆传统人工的运维（油机），走绿色智能的数据化运维（电机）。A厂内部计算平台近年来无论机器规模、业务规模的成倍增长，借助Tesla产品的高效，加上具有产品Sense的运维开发人员（SRE）支撑，摆脱了人员数量和业务规模一起线性增长，以现在的人员规模支持今天如此庞大、复杂的业务场景是过去不曾想象的。
另一方面，大数据管家是Tesla产品对外场景的最佳实践，目标是让专有云客户同样无感的自动解决繁琐复杂的业务/基础运维问题。虽然大数据产品都是相同的（离线、在线），做到的方式是不同的，因为内部我们可以依靠那些伴随业务一起成长的SRE，而专有云市场不可能要求客户去培养这样的SRE，所以大数据管家还要再进一步的解决人的问题，简单来说，对内是复杂场景的辅助驾驶，对外就是简单场景的完全自动驾驶。
| 内部场景 | 专有云场景 | 解决之道 |
|---|---|---|
| 规模庞大，上W级 | 规模较小，K台规模 | Tesla对内，复杂道路的辅助驾驶；大数据管家对外，单一封闭道路的完全自动驾驶 |
| 使用场景复杂，包含用户需求、查询、运维操作、研发发布、调试等等 | 使用场景较为确定，要求的稳定 | Tesla对内不仅构建面向用户的最终功能，还有研发中间件体系满足系统间的相互调用和配合；大数据管家场景相对简单，对场景的运维场景能够达到自动无人干预，比如断电、断网自动恢复等。 |
总结，集团的规模、性能经验对我们开发大数据管家是有非常大的帮助，超过50%的场景和功能内部得到充分验证之后在集成到大数据管家中，最大的区别可能就是对外场景的用户体验性上面，大数据管家是最早随大数据产品进入专有云市场，随着这几年的经验积累，大数据管家这个产品我自认为非常贴近专有云市场的定位：简洁、安静地把复杂运维的事做了。首先它为期管理的产品提供统一的抽象服务层级、丰富多样的自动自助化操作、便捷的故障恢复等等功能，最重要的是它为所管理的产品提供一致性的运维体验，如何实现呢？。
入口的改进
首先大数据管家解决了怎么使用的问题，这个问题看起来很幼稚，但实际上，市面上眼花缭乱的运维定位产品并没有让使用者一上手就全部Get的酸爽感觉。大部分管控软件基本是功能驱动的，所有入口就是功能。比如说你想查看产品健康状态就得先找到和健康相关功能的按钮再做进一步的选择查看。这可能在内部通常是没问题，因为我们的用户本身就是产品的研发或者资深维护人员。而这样的入口设计在专有云场景就非常的痛苦了，使用者很难一上手就清楚每一个功能以及具体执行的结果，这就导致了使用者非常依赖手册或者培训，过分依赖手册和培训的产品一定不可能做得好。举个不恰当的例子，大家都使用手机，但有多少人会先看说明书再使用手机？如果这样的情况发生，那一定不是使用者的问题，一定是手机设计的问题。对轻量云多种产品组合的运维，我们也希望如此。这里很大的挑战就是要将不同架构设计的产品，个性化差异很大的客户使用场景，都能带来一致性的运维体验。所以大数据管家这款产品，改变了传统使用入口；将管理的产品、计算引擎服务层级化，这是兼顾物理和逻辑的抽象，例如图中一个区域和集群代表了产品所处于的物理位置，产品和服务就是它们之间的逻辑关系，无论是物理的信息，还是逻辑的信息在整个产品树的规则里就是一个对象，每个对象的图表、操作、状态都是对象的属性，只要使用者根据页面的引导和提示，就能对所管理的产品有了清晰的结构认识，对产品所需要的操作也有了基本的了解，哪怕你是第一次接触这么多不同类型的产品，也不会觉得很难上手。
自动化
其次，为了减少用户对大数据管家产品的访问次数，目的是为了让开发者专注开发。我们把百余项的健康检查、应用配置检查、日常变更检查由被动执行转向主动触发，能够做到发现问题，自动解决问题。这些信息完全不用担心是对使用者来说会不透明，一旦选择产品的服务层级的任意一个对象之后，任何相关的信息、配置信息就会自动的展现在页面上，使用者只需要按需查看，并关注我们给出的合理建议。当然也会兼顾熟悉产品运维的使用者，为这些检查和配置均加入了自动、手动切换的功能，满足高阶使用的运维需求。
第三，考虑到即使是运维的数据信息也是非常庞大的，任何一个产品服务层级、配置信息、运维操作，以及一个操作的执行，一个配置项的改动对整个产品以及整个业务链的影响可能是巨大的，而且这些信息都是实时在变化的。要求每一位使用者对所有产品的知识做到全面的掌握，显然是不现实的，特别是在关键的故障时刻，快速找到有效的将这些信息定时自动的关联起来，使用一个关键字就能够找到与之关联的产品、服务并找到相应的内容，是图谱功能尝试解决的客户运维痛点，它是一个搜索功能，但并非搜索，它的目标是所要列出和展示的是最强关联的数据。
总结，大数据管家从设计到研发过程专注在专有云市场，最终目标通过这些创新的功能和想法解决量产化的软硬一体方案的运维痛点。
罗马城不是一日建成的，大数据轻量云和大数据管家，是基础工程技术大团队从早期应用运维团队向架构/研发/产品的基础团队转型的第一步，团队不仅经历着转型的阵痛，还要探索未知的领域。在这个过程中，大家一齐心协力向前奋进，轻量云方案内部论证和验证正值中国年期间，大家依然坚守岗位；大数据管家的回炉研发让团队承担额外版本的工作量，这些困难大家都一同的抗过来。让我们欣喜的是新的时代才刚刚开启，我们的那些预言和判断要靠双手一步步的构筑起来，迫切的需要有产品Sense、对运维场景有深刻理解的人才加入我们，在这里我们大有可为。
团队岗位介绍，有兴趣微信私聊：
大数据基础工程技术团队是一只研发型团队，专注于大数据运维自动化，运营平台建设，大数据用户产品开发等，大数据对外支撑等，专注于服务于阿里云大数据业务。
1、快速学习并理解阿里云专有云的业务场景和大数据产品，能够整合业务场景和大数据产品资源，不断优化创新大数据专有云输出一体化平台的架构。
2、能够负责关键项目特定需求的技术选型和技术方案设计。
3、良好的问题/需求抽象能力，能够将新的技术方案输出并落地到研发团队中
4、使用数据分析、自动化工具等方法，分析一体化产品的稳定性（高可用、异常）、性能优化（服务节点、网络架构、调度），提高产品的可靠性，达到企业客户的要求。
5、参与大数据产品的在专有云发布、管理以及后续维护。
微信
网友评论