跪直了，别趴下！如何面对服务化过程中遇到的那些问题

只谈问题，不谈方案，都是耍流氓！

在上一篇《论“跪舔式”构建“服务化”数据平台的崇高理想》一文中，我耍流氓了，无耻的留下了一堆让致力于为人民服务的有志青年痛苦难熬的现实问题。（其实是文章篇幅太长，怕大家没耐心看，拆开两篇发）

虽然如文中最后所说，真的勇士，抱着“世界辣么残酷，我要血债血还”的梦想，或许可以笑对惨淡的人生。然而，毕竟，追求快乐和幸福才是这个时代的主旋律～

所以，这篇，我准备来谈谈如何在服务的过程中，尽可能过得不要那么惨。    

先谈路线选择带来的技术问题

前面谈到，我司（老东家“蘑菇街”）走的是先搭建独立的功能模块系统，然后将系统组合构建成完整的数据平台这条坎坷的路，带来的问题也很伤脑筋。

需要考虑通用性，设计难度较大，系统架构成型较慢，价值产出压力大。

所以，归根到底还是能力不够。

能力不够怎么办？那就不要不切实际，做无用功。没有目标的攻坚工作，坚决不做。目标再通用的系统，在开发之初，也需要面向一个具体的业务，上线之初（我说的是你那完美无瑕的Alpha版）就要带上这个业务（当然，想必这个小白鼠业务方内心一定是痛苦的，要找到这样的小白鼠也是蛮困难的），带着业务的痛点问题来做开发，在此基础上再考虑如何构建通用的解决方案来适配其它业务。

简单说，就是采用通用＋适度定制的方式来快速推进平台的构建，不怕做得不通用，就怕通用到没有业务可以适用。

各系统之间依赖较多（相对），迭代演进负担较大。

你看，好容易把各个系统拼凑起来成为一个平台，生命不息，折腾不止的你们，就忍不住就要重构升级其中的一个系统......

干嘛呢，干嘛呢～～～

好吧，就算你不主动重构，当你完美的通用服务平台在遇到第二个用户的时候，也会大概率发现，我去，好像不重构一下就搞不定啊......

所以这个问题会永远存在，我们能做的，就是做好各个系统的模块化工作，提供所依赖功能的插件封装机制，适当考虑Fail Back的可能性，降低系统耦合度，我说的不光是代码的耦合，什么硬编码依赖系统的地址之类的无疑应该避免，但更难的是避免过度的业务逻辑流程上的耦合。

两个系统如果交叉依赖，一个流程要是你调我来我调你，循环不止，生生不息的话，你的麻烦就大了。

然后，就是尽量考虑保障系统具备灰度发布的能力，依赖多，出问题难以避免，关联系统多，系统更新可能也无法一蹴而就，那就尽可能减少变更过程的风险代价，知错就改还是好孩子，别做一锤子买卖。

对具体业务场景定制程度较低，整体易用性相对较差，使用成本较高。

说到我们的痛点了。既要马儿跑得快，又要马儿不吃草，一个通用平台，或者，不满足业务方的定制需求，让业务方抱怨流程长，操作复杂，工作各种不高效。或者，把各种需求都拼进来，但是一个不小心，一堆旨在提供便捷的功能，反而会让系统变得更加复杂，最终的结果就是导致整个系统不再便捷。所以，简单和通用往往是矛盾的。

这个问题有时候更多的就无关服务，而是产品问题了，所以，放在另一篇文章再讨论吧。不过，从路线上来说，有一种可行的方式，是针对具体业务场景需求，在通用服务的基础上二次垂直封装，适度定制和简化业务流程，从通用系统衍生出专用系统，来屏蔽和特定业务场景无关的系统复杂性，不过，代价当然也有，那就是你又多了一个系统，一层依赖关系需要维护。

接下来谈谈服务自身的问题

技术问题，都好办，服务，更多的是针对人，而人的问题，从来不简单。下面观点，只是个人浅见，如有不妥，欢迎讨论～

由俭入奢易，由奢入俭难。

一旦用户对你的定位认知是服务提供者，那么从情感上说，用户一定会希望你的服务尽善尽美，搞定一切；从理智上来说，多数用户也能够理解服务的构建不是一蹴而就的。但人天生就有以自我为中心，高估自己的需求，低估他人的困难的本能。

所以这里的关键是如何与用户的认知达成一致。

你看12306那愚昧的流程和让人崩溃的图片验证机制，同样是买东西，换做我们大电商行业敢这么做，那用户转换率就不要想了，分分钟倒闭的节奏。但对于12306，能买到票就好，你应该不会奢望它提供什么车次收藏，票务购物车，路线智能推荐之类的功能吧。

套个术语，这叫QOS（Quality of Service）约定，往我们的主题上靠，也可以叫用户预期管理。首先，你要明确你所提供的服务的范围定义和质量约定，然后，要尽早和用户达成一致。如果可以，对用户使用对应服务时应该承担的责任，也需要提前明确的进行沟通（好吧，我知道，做为乙方，这个有时候很难）。这么做，不是为了降低用户的期望值，而是为了统一认知。凡事不怕标准高，就怕标准不一致。

你说我的用户都是在服务推广过程中接入的，用你的服务就是看得起你，哪有机会对标期望值啊？而且系统总是迭代更新，哪有固定的标准。

说得很对，这件事情操作起来并不容易，但形式可以有很多种，我知道你没法签订一个免责协议，但比如：产品定义，路线计划，已知问题列表，最佳避坑实践，FAQ，在产品使用过程中提供即时的反馈／提示／警告信息等等，这些工作或多或少总是能做到一些的。简单的说，明确地告知用户你能做什么，你不能做什么，你计划做什么，你希望他们注意什么，或许事情就会好办很多。

服务越多，支持的代价越高！

服务多了，肩挑手扛肯定不行，在实现并上线完一个服务之后，不是万事大吉了，要及时考虑如何降低维护成本。这不光是说系统自身的维护成本，还包括技术支持的成本。出了问题，用户能否自主定位和解决？

多数情况下不是用户懒，想要躺在你身上，而是他不具备解决问题的能力，没有足够的知识储备，即使有相关知识能力，可能也因为没有明确的故障反馈，没有问题日志，没有性能数据，没有修复的手段等等而不得不依赖你来支持。

这时候，一方面你需要考虑将运维手段工具化，最佳实践文档化，另一方面，你可能需要一个专家系统来帮助用户诊断问题。

总之，服务做得多固然好，但做完一个服务，就能撒手不管一个服务才是做服务的最高目标。

你的服务口碑，取决于你服务最差的那个环节。

这个还用说么，服务的评判标准，是用户，哪里差，哪里补，不过，注意管理好用户期望，注意引导用户，不要盲目的被用户牵着鼻子走就好了。至于最终的口碑，由它去吧，那不在你的控制范围之内。

可能，你要说，有时候用户就是不讲理，我非圣人，我的服务好不起来啊。这是人之常情，的确当你设身其中之时，做为当事人，有时很难保持良好的心态，这时候，你需要置身事外。

我曾经一度对团队的同学说，对待用户，你们的态度一定要好，一定要热情！只管了解需求，讨论方案。做不了的事，不想做的事，人力，资源等等，都推给我，你们唱红脸，我来唱黑脸。这还真不是我有多么高风亮节，主要是做为非一线直接开发对应项目的同学，骂在身上就没有那么切身的痛，所以心态有时可能会好一些。唱黑脸，讲道理的时候，可能稍微淡定从容一点，（当然，也不排除被用户说服了......）另外，从用户体验来说，更多的时候接触的还是直接负责项目开发的同学，保持这部分同学关系融洽总不是坏事。

用户：既要疾如闪电，还要天长地久！

服务的快速迭代改进和服务的稳定可靠，必然是矛盾的。这个矛盾无法解决，只能缓解。我能想到的方法也只有：

• 如果可能，制定班车式开发计划，按固定的周期和预定的计划更新系统，如非必要，不做火线更新。

• 提前沟通，就可能影响，明确告知，宁滥勿缺，Again，这又是一个预期管理的问题。

• 影响面大的变更，如果必要，最好确保你有灰度过渡和回滚的方案。事前的沟通很多时候因为各种原因，不能触达用户（比如用户不在意，或者在没实际执行前，压根没仔细想会不会有问题等等），那么过渡和补救的手段就很重要了。

老板：既要马儿驼得多，还要马儿不摔倒！

这个，向上管理？我不擅长。还是做好工作计划的沟通吧。

然后，如果有压力，不要简单的做二传手向下传递，别把问题和责任抛给团队，把目标和方案抛给团队。

另外，遇到难题，适当反馈。（老板，招不到人啊～～～）

总之，不求老板舒坦，但求问心无愧。

用户的诉求和你的诉求，经常是冲突的，哪怕你的出发点是：你好，我好，大家好。

就这一点，我很赞同一个说法：凡事可以坚持原则，但是没有必要苛求立场。

多数情况下，你和用户的诉求冲突，并不是目标，而是在实现这个目标过程中遇到的问题。或者说，由于立场的不同，你们的侧重点是一件事的不同方面。

比如，用户在意的是自己的作业跑得快，而你在意它不要影响其他人，希望集群的整体效率高。用户希望便捷，你希望安全。本质上，这些都是两件独立的事情，但最终目标，其实是一致的。所以未必非要冲突。只是，如何兼得，有时的确很困难。

所以怎么办？动脑筋，讲道理呗！没有必要追求大家对所有工作真心赞同，求同存异，解决核心矛盾，寻找一个双方都可以接受的妥协点就好，这个妥协点一定存在，如果没找到，要不方案不够好，要不道理没讲够。

小结

服务，从来都不是一个单向承诺的事情，选择什么样的路线，以什么样的方式对待你的用户，如何面对遇到的问题，都是有得选择的，也可以沟通的，只要你明确这么选择的理由，并且愿意承担由此带来的后果。