标签：http 使用 io strong 数据 2014 问题 代码
在中国最大的CIO大会，由《商业价值》& ITValue主办的【2014 IT价值峰会】上，腾讯云CEO陈磊做了一个非常“干货”的报告。他浓缩腾讯培训新员工课程的一些内容，详细阐述了“动态运营”等经历和经验。以下是演讲全文，小标题为钛媒体所加：
我在谷歌互联网公司工作的时候，第一次听说了云计算。按照现在的概念，那时候我就在做云。今天我们谈互联网思维，大家想的更多的是思维转变，商业模式如何转变，产品如何转变。通过这些转变真正去改造一个企业，改造一个公司的运作模式，都是从技术开始的。技术是它的原动力。腾讯的产品体验就是永不掉线。腾讯的海量产品之道是：动态运营、云中成长和有损服务。
以微信为例，看如何实现动态运营
好的团队，是动态迭代成长来的，3-5个人做不好的事情，30-50人做的更烂。高举高打的失败概率非常高。动态运营关键要素：1.小步快跑——快速求证对用户猜想；2.灰度发布——在黑与白之间，能够平滑过渡的一种发布方式；3.大系统小做——分进程，尽量保证进程的功能单一；4.边运营边重构边生活——细分的实施步骤，持续的服务能力；5.干干净净——建立信心、勇于承担、边打扫边生活；6.工具齐备：自动化部署、监控、大数据分析。
腾讯微信的推出完全不是一个偶然的事情。腾讯之前做QQ的技术积累发挥了巨大的作用。微信为什么在很多的关键体验上做的很好呢？因为在做QQ的时候，这些关键技术难题就已经攻破了。2011年1月到4月微信产品上线，当时基本没有用户，我们的团队也没有硬性在用户体验上灌注用户。5月份开始了一个生死时速时期。8月份，用户就开始每天翻一番。在这样情况下如何能够保证微信的体验不变差，是腾讯当时面临的一个很大难题。
微信的动态运营以及腾讯的动态运营的产品思想在这过程中起到非常关键的作用。微信是腾讯CTO，Tony最早关注支持的产品。“产品的节奏”的把握，是最重要的，这背后是非常值得关注的一个点：不给用户他不想要的东西，一定是给用户他想要的东西。
腾讯有一套动态运营的思想跟方法论和流程，这就是动态运营、云中成长、有损服务。
其次是追求小规模团队。我来腾讯之前在谷歌，当时谷歌CEO讲，谷歌成功的产品都是两个人做出来的，比如搜索、广告、邮箱。成功之后，这个团队越来越大。所以我们在有基础的假设之后，就开始不断地尝试。先做一个很简单的产品，然后不断创新尝试。微信1.0和现在的版本差距很大，每个功能都是在不断的运营、猜想和实验的过程中做出来的。
微信团队现在每天可以发20个版本。客户端产品发布新版本其实是一件很困难的事，必须让用户下载才能完成更新。
微信团队做了很多的后台开关，“很多的功能能不能被用户用到”，或者“表现形式是什么”都有后台控制的。产品在研发过程当中根据用户的使用习惯不停的调节。
前几个版本，功能上线都是一部分用户先使用，另外一部分用户是看不见的。应用的用户效果好就放大，效果不好删除，或者将这个功能改成原来的方式。把新的功能藏起来，让用户一步一步找到，设置一个插件，一步一步深入。找到新功能的用户都是比较高端的用户，对微信有很深感情，其余绝大多数用户看不到。观察他们对新功能的反应。用的多，就往前挪，用的少，删掉。这就是动态运营。
任何一个技术产品如果不上线，它的水平一定是差的。我们要做的就是大力的缩短上线的时间。如果一个项目两个月没有上线，就会把一定功能删减，删减两个月可以上线。两个月就上线的产品，可能功能会非常的简单，但是会在上线之后不断地迭代。
腾讯搞败搜索的教训
腾讯有一个产品做的很失败——搜索。从2010年开始搜索的团队一直在做新架构。这个新架构是从头写起的，每个行代码都是新的。到2013年8月份的时候才上线，但是上线八天之后新架构彻底崩溃了。
出了问题没有办法定位，不知道怎么样把新架构修复，所以又把老架构拿出来。在此过程当中有很多不可思议的事情发生。
财付通是腾讯一个非常重要的产品，然而通过腾讯的搜索产品，大量的财富通网页无法显示。因为老架构一些技术问题，需要把一些APDS的网页放到白名单里面才能扫到。这不是缺少人员运营的问题，所以搜索应用非常失败。
腾讯的广告产品算法在行业里面是相当有口碑的，主要原因是我们每天做很多大量的实验。每个算法想出来之后，不能肯定在上线之后一定效果好，面临问题的复杂性跟用户的差异性非常大。所以我们把所有的算法都拿出来试。最后成功的留下，不成功的删掉。产品不断演进产品。
“小步快跑”为什么要这么做，这样做需要什么技术。实际上每件技术做好都需要大量的积累跟沉淀。用会务发布来讲，我们有一个比较标准的发布流程。每个功能发布的时候首先给公司员工用。公司员工用了之后提出很多的意见，哪个地方做的不好，就不断的改进。
当员工用户满意了或者问题不大的时候，会给一个核心用户群体进行用，他们觉得可以尝鲜用腾讯的产品是件很骄傲的事情。当然他们也会提很多的意见，这个群体用完了之后我们才会逐步的试。互联网差别做法就是我不懂所以我要试，这个准确率可以达到多少，如何能够让用户更满意，成功率有多少。真正的内部的测试也好，真正产品的上线可能不到30%。所以有70%的好的想法并没有被利用。
技术团队有局限，要把专业的事交给专业的人
我们认为每个团队虽然有很多的技术牛人，但是却存在一定的局限性。尽量把更多的事情交给更专业的人做，这是腾讯公司一直以来的重要理念。云计算公司有一个产品叫做微云，微云这个产品可以上传图片照片，每天上传量1700多万张，视频量也很大。我们不断的想办法压缩每天的数量增量，但是现在每天数据增量还在80多P到100P之间。
而且客户端的种类不同，微软两个版本还有安卓、苹果等等很多的版本。微云团队20个人，日活跃用户过亿的产品，怎么样能够做到这一点呢？微云使用了腾讯现有的架构，在自己的营造的云里面成长起来。
滴滴打车是腾讯跟阿里分别支持的打车软件，爆发式增长的最后关口就是技术战。2月18号的时候腾讯云团队入驻滴滴打车，2月22号的时候就把所有系统搬迁团队。嘀嘀打车用了很多开源软件，在开源软件周边做了很多的工作。我们做的事情就是迁移到现成的云服务中，这个云存储是腾讯产品里面验证的，可以撑得海量。这个事情让嘀嘀打车脱胎换骨。
云中成长还有另外的案例就是互娱DNF，这个非常成功的产品，日收入过亿。DNF原来是从韩国的游戏公司买来的产品。我们把它搬到云端，扩容能量一千台一个月，提升到一千个虚拟机一小时。DNF在腾讯的过程当中有一个非常大的高速增长的过程，云给它很大的支持。所以这是云中成长的关键要素。首先就是核心的点，我们团队关注的是最拿手的事情，让更重的事情快速的沉淀到专业的团队中。
“有损服务”是互联网的一个核心理念
有损服务，在传统行业跟互联网结合过程中，是最难让大家接受的，也是互联网最核心的一个理念。我们做的服务在正常的情况下给用户百分之百的体验，但是当我们遇到困难的时候，比如说发大水把机房淹了，导致很多设备不能用。或者用户突发的高峰的时候，该如何很好的服务用户。
用滴滴打车举例，很多产品逻辑很明显，不用做这么重，但是可以保证用户体验。比如说要不要非常准确的显示当前的位置，要不要把每个附近的出租车当前位置显示很清楚，并且可以跟踪他们的情况，然后在手机上面进行显示。这些事情的答案如果条件允许的话，用户都想知道。但是条件不允许的时候就要降级处理。两天的时间，帮助滴滴打车完成了“有损手术”，在压力过高的时候去做逻辑性处理。后端服务器压力锐减。
微信原来要做的就是把所有的消息都必须是送达，而且一定要在每个用户的手机上保持顺序的一致。后来我们说服了微信团队，其实顺序并没有那么重要。
红米案例在行业里面比较出名，我们做了两次红米的手机发布。第一次红米手机，第二次是红米NOTE。第二次做红米NOTE的时候，把小米的服务器拖垮。
我们复盘之后，发现小米的设计是一个无损的完美设计。但是这个完美设计是不是有必要？比如每个人都能看到还剩下几部手机。当你有十万部手机还要卖时，就不需要了。当你有一百部的时候，才是需要的。当你只剩下一百部的时候，访问量集聚下降，可以做到这一点，十万部的时候不需要做到这一点。
12306曾经找过我们，让我们解决现在每到春节系统被压垮的问题。他们认为腾讯在这方面做的非常的好。
第一点，可以试试我们的云，当然这个不太可能。
第二点，其实很简单你每一趟车次分开卖，车次分开卖，就可以解决很大的问题。另外早一点卖，不要非等到那个时间段。另外可以一开始悄悄卖，不同地域的票分开卖，这个想法虽然很土，但是互联网公司用很土的办法解决复杂的问题。
其实大数据和云计算，就是我们用原先的数据库解决不了现在的问题，用柔性有损的办法解决类似的问题，到最后形成了今天的互联网行业的产品。
http://mp.weixin.qq.com/s?__biz=MjM5ODIzNTc2MA==&mid=201722019&idx=1&sn=864b5400a8bfcc9b68099126e09df8e5&scene=1&from=groupmessage&isappinstalled=0&key=9467a271bcdfeb1757c9000c8dabe9e43e9fd5fa74aaee407dfe61ffb0b7ea6d6642b3bd81f424a220c1ff1c8ae9c3c8&ascene=0&uin=MjY0NTg1NjM2Mw%3D%3D&pass_ticket=CFAsU5Y%2Fktet8sYFeZXuqiGYaGXUiFx%2Bf5M0CizcQkXUoIZ%2BDmWOvB3IqhyJLjtU
腾讯陈磊讲产品：3-5个人做不好的事，30-50人做更烂,布布扣,bubuko.com
标签：http 使用 io strong 数据 2014 问题 代码
原文地址：http://www.cnblogs.com/Googler/p/3910676.html
