爬梯优化设计方案[爬梯设计要求]

　　文|飞林沙

　　这篇本应在一周前产出的年底总结被拖延症拖到了现在，上午和同事去深大校园里逛了两个小时，看着学生们悠闲地背着书包走在去往自习室、图书馆的路上，不禁感叹原来自己已经毕业了六年时间。六年来，我从最初的Web开发人员接触到一些服务端开发，然后莫名其妙成为了业界最火热的大数据工程师、数据科学家。在职责上，从单枪匹马搞定所有事儿，到带领十几人的数据团队去做一个领域的探索，再到带领几十人的部门去做实验产品尝试，再到现在作为CTO跟着百人的产品研发团队高速奔跑，看着公司一年时间完成近十倍的增长。回忆种种，恍若云烟。

　　回头看过去的2015，也许是入职了一个和之前不一样的企业，也许是接触到了与之前不同的人，也许是背负了无法与往日相比的压力。所以我尝试着将一些想法写出来，没有主题，没有主次，想到哪儿写到哪儿。

　　1.企业级服务公司的思考

　　今年最大的变化，是我第一次从一个互联网行业进入了一个企业级服务市场，经过一年的适应和思考，让我对企业级服务市场有了更多新的看法。那我就先来说下我眼中的企业级服务吧。众所周知，企业级市场与互联网公司的发展不同，他与当前创业环境、公司资金等息息相关，我们回忆一下《创业维艰》就知道在差的资本环境下，一个企业级服务公司有多难生存下去。

　　企业级服务的公司到底如何做利润，如何做大是我最近一年一直思考的问题。先从最基本说起，企业从最基本的诉求来说为什么使用云服务，例如企业为什么要使用阿里云、七牛等等，根源无外乎：1. 动态扩展能力 2. 低人员技术成本 3. 不需要去做脏活累活。归根结底的说就是企业认为做这些事情的ROI不如交给云服务公司的ROI高，例如把图片存储在我自己这儿每年需要耗费100W的机器成本+20W的人员维护成本，稳定性可以达到99.9%，那作为一个理智的技术决策者，一定会要求厂商用100W的计算解决问题，并且稳定性不可以低于99.9%。那我们这个时候把视角从客户视角切回到云服务厂商视角，那我们要如何才能赚钱呢？

　　A.寄望于客户的水平在平均线以下，例如改造XMPP，业界的平均水平是2个人月的水平，但是很多客户需要10个人月，这样相当于赚了8个人月的钱。但是这其实是一种极烂的做法。具体会在下文中有所表述。

　　B.动态扩展能力。这一点是客户使用很多云服务的理由，那么如何通过资源的合理规划在这方面去赚钱呢？我倒是有些思路，但是从目前来看还需要较长的路要去走。举个简单的例子，假设说每次某电商网站双11抢购时都需要1000台服务器才能满足需求，也就是说不采用云服务至少需要1亿左右的预算，但是其实大部分时间其实只需要10台服务器就足够了，于是想办法降低服务器闲置率就是我们可以赚的钱。但是目前的云服务厂商(我视野范围内的)还无法做到这一点。假设说淘宝、京东、唯品会同时使用了我的云服务，也就意味着我需要准备 淘宝+京东+唯品会三家的机器总和，如果他们每一家的机器闲置率是90%，那我也同样是90%。所以真正想做到这一点需要的是对客户进行明确的划分，通过不同的客户策略组合从而提高机器闲置率，例如构建淘宝(双11)+亚马逊(黑色星期五)这样的组合，把机器的闲置率从90%降低到70%。这是一个很理想的情况，在实操中会遇到很多的困难，在下文中我会再次提及。

　　C.承包脏活累活。这一点其实是国内大部分云服务厂商赚钱的主要途径，帮你把麻烦的事儿给做了，比如你懒着去做个统计后台，我帮你搞了；你懒着去搭个Docker服务，我帮你搭好；你懒着去做安全策略，我帮你做了。但是回归到我们上面说的ROI的问题，这必然会导致利润率极低，这并不符合互联网企业高利润率的模式，而基本纯粹属于外包公司了。这并不应该成本云服务厂商的立足之本。

　　D.通用方案的快速复制。这个和过去的ERP公司很类似，做出标准产品，然后去兜售给各个客户。和上面的点一样，这也是现在云服务厂商的立足之本。可是当我们回忆一下ERP时代的企业的赚钱方式，我没太听说哪一家是通过把一个通用性软件卖给客户然后就能赚到大钱的，基本赚钱的费用都是在定制化、后续维护费用。但是定制化的成本其实又回到了上文的ROI上，不再赘述。此外，还有一点ERP软件的赚钱方式，就是扎根于某一特定领域，例如用友金蝶的财务软件等，这似乎又与如今的云服务厂商发展路线相悖。所以这听上去很美，却依然是一个低利润的事情。

　　从上面四点来看，只有第二点才是值得去发展的路，先记在这里。

　　2.云服务和大数据

　　在过去一年无数次的采访和演讲中，我都努力在讲一个概念，就是云服务和大数据的结合。只有平台级产品才有大数据的理论，我也不厌其烦的反复提及。那么相比于传统“云平台”的低利润外，大数据所产生的高利润率似乎更让人幻想。相比于机器学习，数据挖掘这些技术而言，更困难的还是数据如何才能产生商业价值。在过去的一年里，我们做了各种各样的尝试，取得了一些小的成果，也对未来的方向有了一些更清晰的认识。

　　谈到数据变现时，我们需要做更多的产品和商业层面的思考，在这些上面，我走了太多的弯路：

　　A.我们更应该清晰地识别出哪些业务是需要数据的？

　　我们到底是在拿着数据去找业务，还是在用业务来倒推数据的价值。如何识别是否在拿着锤子找钉子，我有一个特别简单的方法供参考，一个方案需要Rule-based来解决问题，还是需要通过Machine Learning来解决问题。我们想下什么样的方案是没办法通过Rule-based无法解决的问题。例如Uber希望通过大量的数据行为来缓解交通堵塞，这不是rule-based可以解决的问题。抽象来说，大数据的真正价值是通过海量实时多样的数据，通过机器学习训练出最适合的模型，这个模型抽象了人类几乎不可能完成的复杂规则引擎，而深度学习在大数据时代的流行很大程度上也是因为其对大量特征的组合再加工，这也可以看做是数据多样化的必然产物。

　　B.这些数据引入前和引入后到底能产生多少额外价值？

　　因为这个取决于企业到底愿意为数据服务买多少的单。例如互联网金融公司希望利用大量的数据去做征信模型，但是当引入新的因素变量时，哪怕让准确率有1%的提升，都会产生极大的经济价值。

　　C.实时数据能产生多少的价值？

　　实时数据意味着合作的长久性，例如对于音乐推荐产品来说，如果提供的数据只是三年前的数据，那么数据效果会极差，所以这样就保证了公司必须不断使用实时的数据方案来满足需求。

　　以上几点其实决定了你要为哪些行业提供数据解决方案，最初的时候我的想法依然是停留在互联网公司上，希望能够利用平台上多样化的大数据去帮助互联网公司精细化运营，例如优化推送方案，优化推荐内容，但是现实告诉我这条路还走不通，问题就在于A和B两点，规则引擎可以解决问题&引入多样化数据后产生的经济价值略低。这也是在未来一年甚至几年内需要持续思考的问题，但是这条路是被判死刑的么？我是否认的。 另外，在上一节中，我为何说寄望于客户的水平在平均线以下去赚钱不现实，这就引出了下一个话题，关于创业。

　　3.关于创业

　　最近的一年时间里，我接触了大量的创业者，他们会咨询各种各样的问题，在这里我简单谈下我的一些看法：

　　A.世界一定在朝着好的方向发展。任何一个颠覆性的创业想法一定有着缺陷，或许是因为政策，或许是因为习惯，或许是因为大众的水平。所以在面对着很多“不靠谱”想法的时候，我更愿意去思考这个应该在什么时候去做才比较合适。例如我有个朋友，一直想做一个时尚类的APP，用他的话说，大部分中国人的审美太“淘宝”风了。我认为这个出发点是好的，并且在国外已经有很多成功的案例，我们也相信大众的审美必然从“淘宝风”转为“个性化”，只是这个时机应该是什么时候更合适的问题。所以我并不认同基于“丑陋”的一面去创业，例如在用户不知情的时候推送广告，例如所谓的“利用人性”，再例如朋友圈的小红点。

　　B.曾经我一直认为创业就是解决用户的某个痛点需求，现在我更认为创业其实是在一个大环境下基于上下文去解决一个大家尝试解决很多次的问题，说的更大一点，真正的创业解决的是补全生态链。仍然以上述的时尚类APP为例，做成一个时尚应用，要保证的是买家用户审美水平的提高，卖家设计水平的提高，供应链的资源充足，独立设计师与买家之间的纠纷解决等一系列问题。这绝不仅仅是一个APP所能解决的，这个APP的成功应该仅仅是补全其中的一环，并且在这一环做到最佳的体验。

　　那么如何去甄别呢？

　　A.对标法。这个是投资人最常用的做法：国外有没有类似的产品，国内有没有类似的产品，他们为什么没有成功，你是怎么解决这些问题的？这种方式简单粗暴，但是只能看到问题，不能解决问题，而且极容易陷入创新的死胡同。

　　B.链条整理法。既然我上文说到了创业其实是补全生态链，那么请先划出这个产品的成功需要依赖于哪些条件，也就是他的链条上下游分别是什么，例如“大众审美的提高”等。这些依赖的条件是否已经得到解决，是怎么解决的？在你的产品出现前，链条的这部分是如何被填补的，这个方案有什么瓶颈？这个瓶颈是在他的上下游还是自己本身？ 另外，因为创业产品的发展绝不仅仅是自身体验的完善，规模的扩大，更大的程度上还是取决于整个生态链的进步，所以要进一步地去问自己，这个链条上除了我的环节，其他环节发展如何，他们的增长曲线预计会是什么样？

　　更愿意从大局，而非产品本身去看待问题也许是我这一年的一个进步。

　　4.对于迭代的再次思考

　　互联网公司多年的经验，在我脑子里固化了小步快跑，敏捷迭代的思想，而这让我来到极光之后非常的不适应。强调设计，强调文档，对于质量的控制，强调稳定，这在我之前的经历里是没有的，甚至是相违背的。

　　在敏捷迭代模型中，做法是需求->设计->编码->测试->设计->编码->重构，如此往复。但是这个模型在执行过中出现了太多的问题，从客户端而言，设计的不稳定必然会导致API频繁发生变化，而且SDK的更新版本往往都是取决于开发者本身。对于一个APP而言，应用的一个Bug可能只会带一个版本，而对于SDK而言，由于多了开发者的这一环，所以这注定是无法敏捷的。从服务端而言，设计的失误会导致大批量的服务受影响，并且服务端的数据问题又将持续被困扰很久。那是不是意味着敏捷迭代注定和企业级开发无缘呢？

　　我更愿意认为企业级服务需要采取的是另外一种方式：

　　A.产品计划不能迭代。对于云服务厂商而言，产品计划最直观就是反映到API如何设计，软件如何做基本的分层架构，服务端客户端采用什么样的分工方式。

　　B.整体设计不能迭代。这里指的整体设计是说针对产品需求，需要对接下来的技术整体方案有整体的设计，大到SDK和服务端的通讯协议，服务端的整体架构方式，机架的分布，小到API的设计稳定性，这些是必须要稳定的。

　　C.设计方案需要迭代。当大的架构模式确定后，小的设计方案我个人认为是值得迭代的，例如存储方案到底使用MySQL还是PG，消息队列到底使用RabbitMQ还是Kafka，不妨上线灰度测试，然后设计方案，由于真实环境和测试环境的差异性，这里需要评估压力测试等的时间成本。

　　D.功能开发需要迭代。当我们理清上述的设计后，可以将产品和架构的设计图加以切分，根据聚类找到连通子图，拆分迭代开发，如果A的效果不好，那么B自然无需继续开发。

　　E.经常重新Review设计。人非圣贤，即便再好的技术都无法保证设计的合理性，把不合理的设计扼杀在萌芽里，而不是等着他即将爆发的那一天。

　　5.数据的未来

　　随着互联网环境的逐渐成熟，任何企业无论是管理还是产品都必然走入精细化、数字化的层面，那么如何定义自己是一家大数据公司？并不是说我自己有着很多的数据，而是由数据来驱动整个公司的发展。

　　现在我看到的大多数公司基本都是在问我，我们现在有这么多的数据，我们可以做点什么？其实这个思路也许在以后会改成我们想做这个，那么我们需要哪些数据？从产品层面，例如我们需要做征信服务，那么我们都需要哪些数据，这些数据我需要怎么样才能获得？这是数据驱动开发的思路。 从运营层面，回到我在第一点所说，如果云服务公司的一大盈利点是通过对机器闲置率的调度优化，那么是否应该利用数据对销售进行更加合理的驱动，这是数据驱动市场。从管理层面，我们如何计算一个公司需要的最佳人数，如何评估每个人的绩效，这自然是数据所决定的，这是数据驱动管理。

　　而这些，都是数据人员需要去探索和努力的路。

　　6.反思 & 提高

　　A.商业推动能力的不足。这算是我对自己最大的批评吧，在今年，其实有着太多的公司合作，但是我却并没有办法去把握利益的平衡。

　　B.行业背景知识的不足。传统企业知识的缺乏导致我没办法真正理解他们的架构和需求，更没办法对方案进行包装达到他们想要的结果。

　　C.抵御技术细节的诱惑。这是一个技术人员成长为管理人员的最大问题，抓全局而轻细节，毕竟时间和精力都有限，而回顾起来我还是浪费了太多时间。

　　希望新的一年会有所提高吧。

　　飞林沙：商品推荐算法&推荐解释

　　重磅推荐：大数据工程师飞林沙的年终总结&算法数据的思考

　　需求与匹配 从数据挖掘角度看世纪佳缘推荐系统

　　End.

标签：爬梯设计优化要求方案