1704135920
1704135921
第二个案例是“红米”。2013年7月31日，小米公司第一次发布红米手机，非常成功。但到了2014年3月16日，小米公司第二次发布红米NOTE，则“成功”地把自己的服务器拖垮。
1704135922
1704135923
帮助小米复盘之后，原因随即被发现。原来小米对于自己服务器的设计是一个无损的完美设计，其中有一点就是每个人都能随时随地查看到剩余手机数量。
1704135924
1704135925
稍做分析，不难发现，这种“完美设计”显然没有必要。当手机还剩下超过10万部时，访问量正处于高峰，而且库存相对充裕，并不需要让消费者知道剩余产品数量，那样只是徒给服务器增加压力而已。只有当库存仅余1000部甚至100部的时候，才需要让用户知道，以便刺激消费。而那时，访问量已经开始急剧下降，服务器自然就能够负担了。
1704135926
1704135927
第三个案例来自铁路购票系统12306。铁道部曾找过腾讯合作，希望其帮助解决春运时操作系统时常被“压垮”的问题。当时腾讯便提出了很简单的“有损服务”这一概念，建议铁道部不同的车次分开放票，或者不同车站错峰放票，一举解决了火车票系统瘫痪的“老大难”问题。
1704135928
1704135929
此外，如今被广泛谈论的大数据和云计算，其实都是在用柔性的有损服务来解决以前数据库所解决不了的问题。
1704135930
1704135931
动态运营
1704135932
1704135933
腾讯的互联网产品都是通过不断迭代优化成长起来的，是一个动态运营的过程，其中有一些关键的要素，例如小步快跑。
1704135934
1704135935
小步快跑包括对用户需求的快速反应，以及快速考证团队猜想是否正确。
1704135936
1704135937
微信在1.0版本的时候仅仅具备聊天功能，界面也很简陋。但随着快速迭代、快速响应用户需求，现在的微信已经成功进化为平台型产品，成为移动互联网的入口。
1704135938
1704135939
要实现小步快跑，在技术方面就要求初始设计具有可扩展、自动化部署、轻松上线以及快速沉淀的能力。
1704135940
1704135941
有了战略级别的价值观，还要有战术级别的具体意识，才能指导实际工作。腾讯在奋斗的过程中，做了这些准备：
1704135942
1704135943
1.大系统小做
1704135944
1704135945
大系统小做是指将一个大的系统尽量拆分成功能单一的模块，在架构设计上尽量使用插件式设计，高度解耦。
1704135946
1704135947
腾讯QQ乃至到后来的腾讯云都是依凭这个思想，小到代码中一个类的设计，大到涉及数个集群的云服务，都按照模块来划分。
1704135948
1704135949
2.边运营边重构边生活
1704135950
1704135951
世界上没有完美的产品，在用户使用过程中难免会出现各种各样的问题。这个时候，对于产品团队来说，最重要的是提供持续服务的能力。此外，还必须重视技术负债[1]，在研发过程中也需要不断重构。
1704135952
1704135953
3.快速沉淀
1704135954
1704135955
快速沉淀即将业务和解决方案服务化，把解决一个复杂问题的方法沉淀下来给后人使用。
1704135956
1704135957
腾讯还将业务逻辑进行服务化，比如将摇一摇、漂流瓶等都做成服务，供微信、QQ等开发团队调用。
1704135958
1704135959
4.灰度发布
1704135960
1704135961
互联网产品有一个特点，就是要不停地升级，否则就会被淘汰。
1704135962
1704135963
然而，系统升级总是伴随着风险，像是新旧版本兼容的风险、用户使用习惯被突然改变而造成用户流失的风险、系统宕机的风险等。为了避免这些风险，很多产品都采用了灰度发布的策略。
1704135964
1704135965
灰度发布指在黑与白之间，能够平滑过渡的一种发布方式。其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退。
1704135966
1704135967
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
1704135968
1704135969
ABtest就是一种灰度发布方式，即让一部分用户继续用A，另一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上来。
[
上一页 ]
[ :1.70413592e+09 ]
[
下一页 ]