前文中（链接：为建设四个现代化的大数据平台奋斗终身 ）我们谈到，在构建数据平台的过程中，我们要坚持四个现代化，这其中平台服务化是关键指导思想之一，而用户满意是衡量服务水平的唯一标准。
那么这篇，让我来具体谈谈如何为人民服务：）
P.S. 勘误：上图 “背篓精神” 实为 “背锅精神”之笔误，特此申明。
首先，什么是服务？我们辛辛苦苦提供了稳定的Hadoop集群给业务方用，是服务么？我们开发了高性能的ETL工具，是服务么？我们把元数据血缘关系都收集，分析，展现出来了，是服务么？我们提供了任务调度的方式手段，是服务么？
其实，这个问题，没有标准答案，是不是服务，取决于你所服务的对象。你所提供的内容，是不是对方最终想要的东西？好比我想享受一顿美食，你给我一条活蹦乱跳的澳洲龙虾，一个设备齐全的厨房，甚至还有一本澳龙烹饪指南。不是不可以，但可能并不是大多数人所期望的服务。但如果我是想学习烹饪，那这种服务就再理想不过了。
所以，要谈服务，首先得谈你怎么定位大数据平台的职能范围和服务对象。很不幸，这也不是一个有标准答案的问题。
有些公司，大数据团队只负责基础组件的开发和运维，业务方裸用系统。有些公司，基础组件之上的工具，平台等等，都由专门的工具团队负责。有些公司，不同的事业部团队会自行在基础组件之上，各自构建自己的系统。还有些公司，大数据团队从下到上，链路通吃，从集群运维一直负责到最终具体终端业务数据的产出。
但不管怎么划分，我想，相关系统所依赖的人力，资源和技能的内聚应该都是最重要的划分考量因素。对于多数公司来说，相关系统和具体的特定业务知识是否有强关联，会是一个比较合理的划分参考依据。
凡是没有业务强关联的，而对大数据相关基础知识或生态依赖又较大的系统，可能由大数据平台相关团队统一来构建会比较合适。反之，往具体终端业务产品拓展衍生的程度，就要看各公司大数据团队自己的实际情况和业务团队的能力了。
而评估数据平台的服务能力，除了客户满意这个主观标准，另一个偏客观一点的标准可以是：贯穿打通上下游和周边业务的能力，打通的越彻底，平台的服务能力基本上就越强。
比如你开发一个调度系统，系统自身的能力，大家都知道：时间／依赖触发，任务计划，执行流水，出错重试，支持的任务类型等等。
那么上下游和周边业务关系包括什么呢？比如：
后端集群流量／负载的反馈控制能力
和脚本开发环境的集成对接
和权限系统，任务，脚本订阅管理体系的连通
和元数据血缘分析管理系统的对接
和任务测试／发布环境的对接
与报警，值班，监控系统的协同
和其它非大数据类业务自己的工作流体系串联
与数据质量监控系统的协同
类似的能力，还可以列举很多，很明显，上述能力越完备，调度系统的服务水平很可能就越高。但值得注意的是，能力并不等同于服务，还要看它对用户的价值，这点我们后面再详述
下面，基于这样的定位来讨论大数据平台团队所提供的服务
所以，用户需要的是什么服务？ 按照我们服务的用户定位，用户需要的不是一个个具体的组件，用户需要的服务往简单来归纳，很明显，就是三类：
存储
计算
查询（展示）
至于为了更好的支持这三类服务，不论是存储计算的具体组件hdfs／hbase／hive／spark／storm／flink，还是你所需要工作流调度，权限管控，元数据血缘分析，质量监控等等各类支撑和监管系统，都是手段而已。并不是说他们不重要，或者用户不需要关心，而是说从用户的角度来说，并不是他们诉求的出发点。
用户需要的是稳定可靠高效的存储数据，只要满足性能指标，他们其实并想不关心底层使用的具体组件
用户关心的是高效低成本的开发业务，钻研和学习各类计算框架，并不是他们的初衷
用户在意的是方便快速的查询到想要的数据，结果便于理解和沟通，能够有效的支持业务决策。数据存储在哪里，用什么工具查询，需要做什么预处理，是否需要缓存优化，这些能不考虑最好不过
当然，从业务开发的角度来说，可能对底层系统理解得越多，开发使用起来就会越顺手，但从数据平台服务构建的目标来说，服务的价值，就在于能在多大程度上减少使用方对底层系统了解的必要性，降低业务开发的门槛。而不是仅仅提供组件或者孤立的系统，把组件选型评估，流程串接，方案构建的工作交给业务方去考虑。
如果你有无限的时间和无敌的能力，那么这个问题不是问题，大无畏的去构建就是了。
但现实情况是你的时间是有限的，你的能力和经验也是有限的，而数据平台所需要的服务，几乎是无限的。
所以，大体看来，我觉得平台服务的构建，可以分为两种方式：
第一种方式，是针对具体的业务场景，针对性的开发，一站到底式的支持
优点：
和业务结合紧密，产品逻辑可以高度定制，最大程度匹配业务需求
流程复杂度相对可控，可以尽可能屏蔽与具体业务无关的内容，确保易用性
无需太多考虑通用性问题，系统架构成型快，演进负担小
缺点：
系统专用性较强，可拓展性差。
放到多个部门，业务的维度来看，系统之间可能缺乏统筹考虑，存在大量重复建设的工作
比较典型的，如果是业务导向的部门来构建的系统，基本是这样的。比如广告部门要做数据分析业务，那他一定不会优先考虑数据模型的通用性，多租户权限管控之类的东西，高度定制化的流程及时产出正确的计费数据和投放策略才是最核心的内容。
还有一种情况，是各个集团部门间存在一些竞争关系，或者不满意基础架构团队提供的服务，所有的东西宁愿自己搞一套
第二种方式：是针对抽象通用的功能需求，分别构建独立的系统，通过各个系统的叠加配合完成对业务场景的支持
优点：
针对抽象通用的功能需求，可拓展性较好
能够减少个业务系统的重复建设
各系统设计和架构方案有机会能够做到更加深入，完善
缺点：
需要考虑通用性，设计难度较大，系统架构成型较慢
各系统之间依赖较多（相对），迭代演进负担较大
对具体业务场景定制程度较低，整体易用性相对较差，使用成本较高。
比较典型的，如果是非业务导向的部门来构建的系统，往往是这样的。还有一种情况是，基础部门没有自下而上的完整链路的掌控权，那么也可能是基于自己的业务范围，构建一些相对独立的功能模块和系统。又或者是系统的演进，是从工具向平台演变的一个过程，也很自然的是从局部向整体拓展
两种方式没有绝对对错之分，取决于各公司，团队，部门具体的实际情况
但无论使用哪种方式，都需要考虑，如何尽可能扬长避短，或者采取必要的手段去弥补缺点
比如我司之前的北京分舵，技术方案融合前，北京分舵的数据平台基本就是按照业务定制的原则来开发，在具体某类定制化的业务开发流程方面，客观的说，易用性就比我们杭州分舵的平台要好很多，用户口碑不错。但带来的问题就是，不同的业务和产品线实现类似的功能，各有一套体系，比如调度系统就有独立的三套。各类业务之间基本没有打通的可能性，维护成本也很高，技术迭代困难。
我司目前的数据平台服务，是采用第二种方式来演进的
我们的基本情况是只有最基本的功能组件，包括：定时轮询的调度系统，hive集成开发平台，定制的报表系统，简单的权限系统，使用Storm开发基本的实时计算业务等。
我们开始添加更多的功能组件，Spark计算框架的引入，元数据管理系统的开发，自定义查询系统的开发，Storm代码开始模块化构建，全站用户页面行为跟踪埋点体系的构建，以及一些底层系统整理改造工作，包括公司内部底层多个集群的整合，改造，升级。数据平台各业务后台权限管理的统一，报警服务系统的拆分构建等等
这里面有经验收获也有历史教训
教训是，整个15年，做了大量的稳定性改进，模块拆分，组件完善，集群融合，升级等工作，在一定程度上完善了数据平台的体系架构，降低了维护代价，提升了稳定性，这固然给平台发展打下了基础，但是，从业务价值产出的角度来说，并不明显，相对零散，对业务方来说，没有从数据平台的改进工作中得到显著的收益。团队的压力较大（绩效方面）
从领导和业务方的角度来说，不要跟我说你们做了什么，告诉我对公司有什么价值？
回过头来看，应该在业务导向方面，多做一些思考和工作，避免冰山下的工作不能给团队带来实际的价值回报，所以16年的工作在核心系统改造的基础上，开始加入更多的围绕终端服务价值产出的内容
开始重构部分核心组件，和推进整体平台服务化的进程，包括权限系统的服务化，构建对象存储系统，完成了核心调度系统重构，完成了数据可视化平台核心功能的构建，实时计算平台构建，数据交换链路服务化，常态化业务数据大屏构建，数据质量系统的构建，开始集群配置管控平台的构建
整体来说，一方面是内部系统的服务化，比如RBAC的权限系统，用来服务所有的业务和数据后台，比如通用对象存储服务，用来支持其它各类有通用存储需求的系统，比如简历招聘系统，小图片存储系统
另一方面是针对数据开发用户或者终端数据使用用户的服务，整体的目标是降低各项业务开发的难度，让用户能够更加独立自主的进行自我服务，减少需要平台定向支持的需求，比如通过可视化平台让用户以配置的方式完成数据图表的自主开发。
2017年目标是傻瓜化服务平台的构建，各种自助服务功能的完善，端到端整体链路服务的打通，专家系统的构建，进一步降低服务支持的代价，实现世界和平，人类大同。（哇噻，又吹牛了，臣妾做不到啊～～～淡定，只是愿景，愿景嘛。。。）
即使放在我司，回过头来看，也不能说第二种方式：通用组件->平台融合就是最合理的方案，事实上对一个特定的具体用户来说，第一种定制开发的方案可能才是他最欢迎的，毕竟，急他所急嘛，客观上来说，短期的收益也可能是最明显的。
所以，有时候，局部做一些妥协，可能也是你生存下去的合理举动。人生，不就是在各种利益抉择中度过么？
所以，这样去做就好了么？ 用户就会跪下来感谢你了么？你的工作生活从此就阳光快乐了么？Naive！
事实上，自打你心里打定主意，走上这条又红又专的服务化之路的那天起，你就走上了一条不归路。。。
很快，你就会发现：
由俭入奢易，由奢入俭难
用户对服务质量的要求，只会越来越高！
每每有其它公司数据团队告诉我，他们的用户运行任务遇到问题，都自行了断，他们都不值班，用户出问题，分析到原因才找他们时，我都会留下嫉妒而又悔恨的泪水。。。
你的服务口碑，取决于你服务最差的那个环节
可恨的水桶效应，当你尽心尽力还是被人骂的时候，有没有六月飞雪的感觉呢 ；）
不过，这也是人之常情了，就好比悲剧总是比喜剧隽永，痛苦永远比快乐来得持久。
服务越多，支持的代价越高
以我们的开发能力，做个服务，总会有BUG，总会有不够灵活的地方，可是谁让你揽过这摊事呢？
用户：既要疾如闪电，还要天长地久！
用户的需求你一定要快速响应，这个界面交互不爽，那个API不够便利，只要用户发起的变更需求，你就得赶紧搞定不是，否则不重视用户这个大棒子就砸脑门上了，赶紧赔不是去 ；）
但是你发起的变更呢，那一定是私生子啊，待遇低下，注定招人白眼。我去，这个Button昨天还在这呢，今天怎么找不到了？什么？要改API，你丫之前咋不设计好呢？！操作流程变了，咋不提前通知呢？ 啥，通知过了？没看到，这么重要咋不直接找我沟通呢？
好吧，对于这两个标准的问题，不要抵抗，都是用户对，做好心理准备，陪个笑脸，想想怎么解决具体问题，更容易一些 ；）
老板：既要马儿驼得多，还要马儿不摔倒！
老板语重心长的告诉你，要服务好客户啊！业务第一知道么？这个工作，你敢告诉我你不接，不想混了？对了，还有那个，别和他们争了，做掉就好了。。。
然后有一天，诶，怎么出了个故障？尽给我找事，能梳理一下问题，保证一下稳定性么，稳定第一你不知道么？！
后来又有一天老板问你：最近没什么故障，不错，不过，今年你们好像没有什么产品成果啊，都在做什么呢，有没有一点价值导向的思想啊？你这样不行啊。。。361绩效？本来想给1+的，看你干得辛苦，给个6-部分不满足需求鼓励一下吧。。。
：）以上情节，纯属虚构，请勿对号入座。但说实话，老板，都是对的！
用户的诉求和你的诉求，经常是冲突的，哪怕你的出发点是：你好，我好，大家好。
你要数据安全，用户想要方便：我不就查个表么，申请权限还找不到owner审批，影响效率啊！我没分析出数据，明天GMV跌了你负得起这个责任么！（用户A：我去，谁drop了我的表？？你们平台太不靠谱了，权限也不控制？）
你想提高集群服务性能，敦促大家优化脚本，用户告诉你，没空！怎么滴吧？（用户B：我去，今天跑任务怎么这么慢？让不让我干活了？）
你的时间不值钱，哪怕它本来可以用来解决更多的问题。用户的时间最值钱，哪怕花一点时间可以克服的麻烦，也会来挑战你，为什么不能做得完善一点，再完善一点，更完善一点？（用户C：诶，搞啥呢，一个功能拖那么久？信不信我告你老板去！）
最后，上述问题，基于用户满意是唯一衡量标准这条公理，最后一定可以推导出都是你的问题，谁叫你是服务提供者呢？ 有本事你去做甲方去啊 ；）没有被鞭的觉悟，就不要趟这个浑水了。挣，还是不挣，问题都在哪里，还是多花点时间想想如何更好的解决吧 ；）
所以，服务辣么苦，为什么我们还要做？是因为贱么？当然不是，是因为理想！
出来混，总是要还的。换位思考一下，我们也有当大爷，使用别人的服务时候 ；）
做为有理想的青年，为了实现在使用别人的服务时，但凡不爽，也可以抱着没有伤害就没有进步的理念，为了世界更美好的目标，以人民的名义，语重心长，理直气壮，毫无节操，无所顾忌地进行谴责和教育的崇高理想，这点苦，就当是卧薪尝胆了吧。
送给各位同行一首诗，用于自勉：
“大雪压青松，青松挺且直，要知松高洁，待到血化时 ” ：）
只谈问题，不谈方案，都是耍流氓！
虽然真的勇士，抱着“世界辣么残酷，我要血债血还”的梦想，或许可以笑对惨淡的人生。然而，毕竟，追求快乐和幸福才是这个时代的主旋律
所以，接下来，谈谈如何在服务的过程中，尽可能过得不要那么惨。。。
前面谈到，我司走的是先搭建独立的功能模块系统，然后将系统组合构建成完整的数据平台这条坎坷的路，带来的问题也很伤脑筋
所以，归根到底还是能力不够啊～～～
能力不够怎么办？那就不要不切实际，做无用功。没有目标的攻坚工作，坚决不做。目标再通用的系统，在开发之初，也需要面向一个具体的业务，上线之初（我说的是你那完美无瑕的Alpha版）就要带上这个业务（当然，想必这个小白鼠业务方内心一定是痛苦的，要找到这样的小白鼠也是蛮困难的），带着业务的痛点问题来做开发，在此基础上再考虑如何构建通用的解决方案来适配其它业务。
简单说，就是采用通用＋适度定制的方式来快速推进平台的构建，不怕做得不通用，就怕通用到没有业务可以适用 ；）
你看，好容易把各个系统拼凑起来成为一个平台，生命不息，折腾不止的你们，就忍不住就要重构升级其中的一个系统。。。
干嘛呢，干嘛呢～～～
好吧，就算你不主动重构，当你完美的通用服务平台的在遇到第二个用户的时候，也会大概率发现，我去，好像不重构一下就搞不定啊。。。
所以这个问题会永远存在，我们能做的，就是做好各个系统的模块化工作，提供所依赖功能的插件封装机制，适当考虑Fail Back的可能性，降低系统耦合度，我说的不光是代码的耦合，什么硬编码依赖系统的地址之类的无疑应该避免，但更难的是避免过度的业务逻辑流程上的耦合。
两个系统如果交叉依赖，一个流程要是你调我来我调你，循环不止，生生不息的话，你的麻烦就大了。
然后，就是尽量考虑保障系统具备灰度发布的能力，依赖多，出问题难以避免，关联系统多，系统更新可能也无法一蹴而就，那就尽可能减少变更过程的风险代价，知错就改还是好孩子，别做一锤子买卖。
说到我们的痛点了。既要马儿跑得快，又要马儿不吃草，一个通用平台，或者，不满足业务方的定制需求，让业务方抱怨流程长，操作复杂，工作各种不高效。或者，把各种需求都拼进来，但是一个不小心，一堆旨在提供便捷的功能，反而会让系统变得更加复杂，最终的结果就是导致整个系统不再便捷。所以，简单和通用往往是矛盾的。
这个问题，有时候，更多的就无关服务，而是产品问题了，所以，放下一篇文章再讨论把。不过，从路线上来说，一种可行的方式，是针对具体业务场景需求，在通用服务的基础上，二次垂直封装，适度定制和简化业务流程，从通用系统衍生出专用系统，来屏蔽和特定业务场景无关的系统复杂性，不过，代价当然也有，那就是你又多了一个系统，一层依赖关系需要维护。
技术问题，都好办，服务，更多的是针对人，而人的问题，从来不简单。下面观点，只是个人浅见，如有不妥，欢迎讨论。
一旦用户对你的定位认知是服务提供者， 那么从情感上说，用户一定会希望你的服务尽善尽美，搞定一切，从理智上来说，多数用户也能够理解服务的构建不是一蹴而就的。但人天生就有以自我为中心，高估自己的需求，低估它人的困难的本能。
所以这里关键是如何与用户的认知达成一致。
说好不打脸
你看12306那愚昧的流程和让人崩溃的图片验证机制，同样是买东西，换做我们大电商行业敢这么做，那用户转换率就不要想了，分分钟倒闭的节奏。但对于12306，能买到票就好，你应该不会奢望它提供什么车次收藏，票务购物车，路线智能推荐之类的功能吧 ；）
套个术语，这叫QOS（Quality of Service）约定，往我们的主题上靠，也可以叫用户预期管理。首先，你要明确你所提供的服务的范围定义和质量约定，然后，要尽早和用户达成一致。如果可以，对用户使用对应服务时应该承担的责任，也需要提前明确的进行沟通（好吧，我知道，做为乙方，这个有时候很难）。这么做，不是为了降低用户的期望值，而是为了统一认知。凡事不怕标准高，就怕标准不一致。
你说我的用户都是在服务推广过程中接入的，用你的服务就是看得起你，哪有机会对标期望值啊？而且系统总是迭代更新，哪有固定的标准。
说的很对，这件事情操作起来并不容易，但形式可以有很多种，我知道你没法签订一个免责协议，但比如：产品定义，路线计划，已知问题列表，最佳避坑实践，FAQ，在产品使用过程中提供即时的反馈／提示／警告信息等等，这些工作或多或少总是能做到一些的。 简单的说，明确的告知用户你能做什么，你不能做什么，你计划做什么，你希望他们注意什么，或许事情就会好办很多。
服务多了，肩挑手扛肯定不行，在实现并上线完一个服务之后，不是万事大吉了，要及时考虑如何降低维护成本。这不光是说系统自身的维护成本，还包括技术支持的成本。出了问题，用户能否自主定位和解决？
多数情况下，不是用户懒，想要躺在你身上，而是他不具备解决问题的能力，没有足够的知识储备，即使有相关知识能力，可能也因为没有明确的故障反馈，没有问题日志，没有性能数据，没有修复的手段等等而不得不依赖你来支持。
这时候，一方面你需要考虑将运维手段工具化，最佳实践文档化，另一方面，你可能需要一个专家系统来帮助用户诊断问题。
总之，服务做得多固然好，但做完一个服务，就能撒手不管一个服务才是做服务的最高目标。
这个还用说么，服务的评判标准，是用户，哪里差，哪里补，不过，注意管理好用户期望，注意引导用户，不要盲目的被用户牵着鼻子走就好了。 至于最终的口碑，由它去吧，那不在你的控制范围之类。
可能，你要说，有时候用户就是不讲理，我非圣人，我的服务好不起来啊。这是人之常情，的确当你设身其中之时，做为当事人，有时很难保持良好的心态，这时候，你需要置身事外。
我曾经一度对团队的同学说，对待用户，你们的态度一定要好，一定要热情！只管了解需求，讨论方案。做不了的事，不想做的事，人力，资源等等，都推给我，你们唱红脸，我来唱黑脸。 这还真不是我有多么高风亮节，主要是做为非一线直接开发对应项目的同学，骂在身上就没有那么切身的痛，所以心态有时可能会好一些。唱黑脸，讲道理的时候，可能稍微淡定从容一点，（当然，也不排除被用户说服了。。。）另外，从用户体验来说，更多的时候接触的还是直接负责项目开发的同学，保持这部分同学关系融洽总不是坏事。
服务的快速迭代改进和服务的稳定可靠，必然是矛盾的。这个矛盾无法解决，只能缓解。我能想到的方法也只有：
如果可能，制定班车式开发计划，按固定的周期和预定的计划更新系统，如非必要，不做火线更新.
提前沟通, 就可能影响，明确告知，宁滥勿缺，Again，这又是一个预期管理的问题。
影响面大的变更，如果必要，确保你有灰度过渡和回滚的方案。事前的沟通很多时候因为各种原因，不能触达用户（比如用户不在意，或者在没实际执行前，压根没仔细想会不会有问题等等），那么过渡和补救的手段就很重要了。
这个，向上管理？我不擅长。做好工作计划沟通吧。
然后，如果有压力，不要简单的做二传手向下传递，别把问题和责任抛给团队，把目标和方案抛给团队。
另外，遇到难题，适当反馈（老板，招不到人啊～～～）
总之，不求老板舒坦，但求问心无愧 ：）
就这一点，我很赞同一个说法：凡事可以坚持原则，但是没有必要苛求立场。
多数情况下，你和用户的诉求冲突，并不是目标，而是在实现这个目标过程中的遇到的问题。或者说，由于立场的不同，你们的侧重点是一件事的不同方面。
比如，用户在意自己的作业跑得快，而你在意它不要影响其他人，希望集群的整体效率高。用户希望便捷，你希望安全。本质上，这些都是两件独立的事情，但最终目标，其实是一致的。所以他们未必非要冲突。只是，如何兼得，有时的确很困难。
所以，怎么办？动脑筋，讲道理呗，没有必要追求大家对所有工作真心赞同，求同存异，解决核心矛盾，寻找一个双方都可以接受的妥协点就好，这个妥协点一定存在，如果没找到，要不方案不够好，要不道理没讲够 ；）
服务，从来都不是一个单向承诺的事情，选择什么样的路线，以什么样的方式对待你的用户，如何面对遇到的问题，都是有得选择的，也可以沟通的，只要你明确这么选择的理由，并且愿意承担由此带来的后果 ；）
那你问我所做的选择，后果惨不惨？咳，咳，这个，还是让我想想下一篇文章该写点什么吧。。。
常按扫描下面的二维码，关注“大数据务虚杂谈”，务虚，我是认真的 ；）
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 
