IT瘾故事推荐

ChatGPT 和 Bing Chat 为何擅长捏造故事？

Fri, 07 Apr 2023 21:33:47 CST

法学教授 Jonathan Turley 发现自己被 ChatGPT 列入了性骚扰名单，澳大利亚一位市长发现 ChatGPT 声称他有贿赂罪被判处监禁，为什么 AI 聊天机器人 ChatGPT 和 Bing Chat 擅长捏造故事？AI 研究人员通常将此类错误称为“幻觉（hallucinations）”，一部分人认为这个形容词太拟人化了，暗示了它们能自己做决定。商业大语言模型的创造者可能会以此为借口将错误输出归罪于模型本身而不是他们自己。“虚构”可能是更恰当的比喻。在人类心理学中，记忆出现空白，在无意欺骗他人时大脑会虚构出空白部分。ChatGPT 与人脑的工作原理不同，但虚构是更合适的比喻。ChatGPT 事实上已经比它的前辈能更有效的抑制虚构了。这种虚构能力与大语言模型的工作方式相关。ChatGPT 等模型是根据统计概率挑选出一个适合上下文的词，当它寻找其数据集中不存在的信息时，它会用看似合理的词贴补空白。它是使用海量的数据集训练的，编造虚构故事对其而言就是信手拈来，它还能根据上下文让虚构的故事看起来逼真。AI 研究人员使用名叫 temperature（温度）的属性去控制模型的这种胡编乱造的“创造性”。如果它的值设置过低的话准确度会提高但会变得不太有趣。平衡创造性和准确度是微调 ChatGPT 之类模型的一大挑战。AI 公司 Hugging Face 的首席伦理科学家 Margaret Mitchel 说，ChatGPT 不是构建去实事求是，因此也不会实事求是。就是这么简单。

GitHub 和 GitLab 的故事

Tue, 11 Jan 2022 23:30:00 CST

引子

2005年，因为 Linux 社区被商业公司撤回了免费试用源码配置管理工具的权利，Linus Torvalds 一怒之下自己花了十天时间开发并发布了分布式源码配置管理工具Git, 虽然当时 Linus 只是想着给 Linux 社区小伙伴们开发个顺手的协作工具，但没想到这款工具将席卷全球，并改变了软件世界。关于 Git 的诞生和源码分析参见拙作《改变世界的一次代码提交》。我在该文的最后写道：

在 Git 诞生后两年，旧金山的一个小酒馆里坐着三位年轻的程序员，决定要用 Git 做点什么，几个月后，GitHub 上线。

原本是打算紧接着写一写 GitHub 的历史的，但拖延症犯了，一拖就是一年多。等到 GitLab 上市了，才想起来应该写点东西了。周末回顾了下 GitHub 和 GitLab 的历史，来聊一聊这两个产品的故事。

GitHub 的故事

2007年，Tom Preston-Werner 刚刚卖掉上一个创业项目 Gravatar, 开始构建新的想法。他的新项目叫 Grit，这是一个使用 Ruby 语言开发的 Git 组件库，通过 Ruby 封装操作 Git 仓库的接口。那个时候 Ruby 以及 Ruby on Rails 在硅谷很流行，很多前卫的创业公司都会选择 Ruby。Tom 在酒吧里碰到了 Chris Wanstrath 和 PJ Hyett，向他们推销自己的想法并拉他们一起入伙。这便是 GitHub 的开始，而 Tom Preston-Werner, Chris Wanstrath 和 PJ Hyett 也成了 GitHub 的三位创始人。后来他们又找了一名程序员，名叫 Scott Chacon, 负责 Git 接口开发。这哥们很长一段时间一直在简介中写着：第一位 GitHub 员工。是的，GitHub 的初始创业团队里，就是三个老板和一个员工。

GitHub三位创始人(左一: Chris Wanstrath; 左二: Tom Preston-Werner; 右一: PJ Hyett)和第一个员工(右二: Scott Chacon)

不过 GitHub 的三位创始人都是程序员出身，所以老板和员工的区别不大，一起撸代码。Tom Preston-Werner 更是一名极客，GitHub 技术栈上的核心组件基本都是他捣鼓出来的，他还创造了静态博客框架 jekyll，也就是 GitHub Pages 默认的博客框架；以及 Toml(即 Tom’s Language)配置语言，成为了 Rust 语言包 Cargo 的官方配置脚本语言。不过后来 Tom 牵涉进了办公室性别歧视事件，辞去了 GitHub CEO 的职位。Tom辞职后，Chris Wanstrath 接任了 CEO，一直到2018年微软收购 GitHub。

Tom Preston-Werner 回忆他第一次创业，他躺在学校宿舍的床上绞尽脑汁去想有什么创业的机会，但好像互联网上点子都被人实现了。于是又去想有哪些服务可以提供公共 SaaS 服务，比如提供评论服务的 disqus. 他想到每次在网站上注册账号时都要上传头像，于是就做了头像服务 Gravatar，用户只要在 Gravatar 上传头像，那么支持 Gravatar 的网站便可以直接显示用户的头像。但这个服务赚不到钱，一直到卖给 WordPress 后 Tom 才还清了自己的贷款。等到创立 GitHub 时，Tom 就认定首先要把商业模式想清楚，因而 GitHub 在一开始就是提供私有仓库收费服务的。从2008年创立到2012年的四年间，GitHub 从未融过资，在它的官网介绍页面一直自豪的写着0融资。2012年，GitHub 接受了 a16z 的1亿美元投资，2015年再次接受红杉资本2.5亿美元投资，此时估值已达20亿美元。2018年6月，微软宣布以75亿美元收购 GitHub.

微软收购 GitHub 后三位大佬的合影(左: 收购前 GitHub CEO Chris Wanstrath; 中: 微软 CEO Satya Nadella; 右: 收购后 GitHub CEO Nat Friedman)

微软收购 GitHub 可谓是捡了个大便宜，2016年微软收购 Linkedin 时就花了262亿，GitHub 吃亏在被投资界认定为是开发者的 Linkedin. 这是大大低估了GitHub的价值。从可替代性上看，Linkedin 是可以被替代的，而 GitHub 不可替代。从 Linkedin 进入中国（领英）去年又退出可以看出，Linkedin 并没有优势（至少在中国没有优势）；但 GitHub 则不同，GitHub 的不可替代性太强了。扯远了，GitHub 已经成为了全球最大的开发者社区、代码中心和开源软件平台，软件在我们的生活中越来越重要，GitHub 也只会越来越重要。不仅是 Git 成就了 GitHub（Git是GitHub的技术基础），更是 GitHub 让 Git 成为了版本控制管理工具的事实标准。

GitHub 最初的 Slogan 是 “Social coding”(后来改为 Build software better, together, 现在是 Where the world builds software)，因此也认为是程序员版的 Facebook. 在 GitHub 之前，全球最大的开源项目平台是SourceForge, 任何人都可以在上面创建并发布开源软件，但它侧重于开源软件的展示和发布，没有考虑开发者的社交活动。而 GitHub 在面世时就突出开发者社交，最亮点的特性有三个：开发者社交功能、”Fork+Pull Request”、Explore 页面。

GitHub最初的 Slogan: Social coding 以及GitHub的著名Logo章鱼猫 octocat

社交功能主要体现在登录用户的首页和用户 Profile 页面。登录用户首页上以 timeline 状态流的方式呈现与用户关注的用户和项目的动态，感觉就像刷社交媒体一样爽 GitHub。GitHub 的用户 Profile 页面在2012年做过重大调整，这种风格基本保持到了现在。Profile 页面上展示用户的项目和 follow 及被 follow 的数量；后来加上了贡献图，就是那些绿色小格子的日历图，每个勤奋的程序员都想点亮它们。这就成了程序员的最真实的个人名片，因此早在2009年就有人在 Twitter 上提出：对程序员来说，GitHub 比简历和 Linkedin 重要的多。GitHub 非常注重它的社交属性，这是它成功的最主要原因。

早在2009年，Twitter 上就有网友提出 GitHub 比简历更重要

GitHub 第二个亮点特性是“Fork+Pull Request(简称 PR)”，这种开源协作模式充分利用了 Git 的分布式特性。在以往的开源协作模式中，程序员们主要通过邮件+patch的方式来交换代码。而 GitHub 提供的 PR 机制，让程序员在 GitHub 上可以一键 Fork 仓库到自己名下，然后通过提交 PR 来将自己的共享合回社区（或原项目所有者），基于 PR 公开讨论，并决定是否合入主干。这种社区协作的方式让大家觉得很酷，很快 GitHub 就在硅谷的黑客圈子里流行了起来。最开始是 Ruby 社区（因为 GitHub 本身也是用 Ruby on Rails 写的），Ruby on Rails 的创始人 DHH 开始注意到了它，并将 Ruby on Rails 源码托管迁移到了 GitHub。在2014年前的几年里，Ruby 一直是 GitHub 上排名第一的语言。接着，是更多的社区、企业和个人将自己的代码迁移到 GitHub. 当然，不是每个人都喜欢 PR，最大的反对声音来自于 Git 的创始人 Linus Torvalds。Linus 曾直言不讳的批评 GitHub PR 制造了“一堆毫无用处的垃圾合并”。

Linus 在邮件列表中痛批 GitHub PR

而 Explore 页面稍晚一些，在2010年推出。在拥有了一定数量的用户和项目仓库后，GitHub 开始通过 Explore 页面推荐一些热点(Trending)项目仓库，排名靠前的项目是那些近期 Star 数量飙升的项目。程序员们乐意给中意的项目加”Star”，而被 Star 的项目也有更高的权重被更多的人所知道，这样就让整个 GitHub 社区活跃了起来。如果说 Facebook 的标志性操作是”Like”的话，那么 GitHub 一定非”Star”莫属了。网络的价值，在于网络中连接节点的数量。GitHub 网络中的连接节点就是用户和项目仓库代码，当这种连接数量越来越多时，就会产生规模效应，越来越多的用户加入 GitHub，越来越多的代码被上传。而后 GitHub 又推出了marketplace (原名Integrations), 将第三方软件厂商提供的服务也连接到节点中，GitHub 成了一个连接了全球开发者、代码和服务的社交网络。

虽然 GitHub 后来又增加了项目管理的 Project 功能、CI/CD 功能(GitHub Actions)，看上去似乎是在向 DevOps 平台发展；但本质上，GitHub 仍然是一个社区，并且也在着重打造社区。GitHub 提供更多更全面的服务，也是为了让社区里的用户体验更好。根据 GitHub 发布的报告，GitHub 上已经有7300万开发者用户，其中2021年新增了1600万；托管代码仓超过2亿，仅2021年新增代码仓6100万。

GitHub 首页上的地球动图，当该地区有人提交代码到 GitHub，地球动图的该位置就会被点亮

GitLab 的故事

GitHub 创始人 Tom Preston-Werner 曾在2011年时写过一篇博文 Open Source (Almost) Everything, 他的观点是尽可能多的开源，因为开源可以带来的好处很多，如广告效应、使用社区力量（更多的用户带来更多的应用场景和促进高质量代码）、吸引人才、选拔人才、留住人才、模块化软件架构、减少代码重复等，而且开源本身也是回馈社区的行为。但他认为有些代码是不能开源的，比如那些具有核心商业价值的代码组件。GitHub 在创始人的驱动下，开源了一些组件，如 grit、resque、jekyll、gollum、hubot 等，这让 GitHub 获得了开发者特别是 Ruby 开发者的好感，当时，GitHub 也是最酷的技术公司之一。顺便说一句, Tom 在文章中提到唯一正确的 License(One True License)是 MIT，这也是 GitHub 上创建仓库长期以来默认的 License，以至于MIT很快取代了老牌的 GPL 和 Apache License, 成为了开源社区最为流行的 License.

几年后，GitLab 也在官网上发布的一篇博客，名为 Almost Everything We Do Will Be Open, 在文章中，GitLab 宣称他们将公开所有能公开的东西，包括源码、文档、工作手册、工作讨论交流等，除了涉及隐私或安全相关的内容，能公开的都会公开。虽然 GitHub 开源了很多组件，但他们核心的产品 GitHub 本身是闭源的。而GitLab是完全开源的，用他们自己的话说，这是 Open Core, 即核心开放，这是开源的一种商业模式，产品的核心是开源的，而提供商业收费的增值或附加特性。

The Org 曾发表过一篇专题报道“全世界最透明的公司”( GitLab: The World’s Most Transparent Company)，介绍了 GitLab 的公司运作。GitLab 全球1400名员工，分布在全球65个国家，因此远程(Remote)是 GitLab 的基本工作方式。GitLab 按照他们所声称的那样公开了几乎所有的东西，最著名的是他们的员工手册(handbook)，涵盖了公司价值观、内部沟通、开发流程、公司运作，以及如何请假、如何报销等方方面面。这份员工手册如果打印成纸质文档的话，会超过8000页。并不是每位新进 GitLab 的员工都能理解这种透明的文化，刚开始他们会很不习惯被“暴露”在公开社区的工作方式。但很快员工就会习惯，因为透明和开放让协作变得更简单。而透明也有利于流程和效率改进，比如员工手册，一直在持续优化更新。

这种近乎偏执的透明文化让 GitLab 持续保持着创业公司的特质，当然这与公司创始人的黑客风格也是密不可分的。2011年，乌克兰的两个程序员 Dmitriy Zaporozhets 和 Valery Sizov 想做一个能帮助他们团队协作的工具，于是就开发了 GitLab。2011年10月9日，GitLab 发布了第一版并开源了源码，而后，每个月他们都会发布新版本。2012年，荷兰程序员 Sid Sijbrandij 发现了 GitLab，正好他手中握有 GitLab.com 这个域名（Dmitriy发布GitLab时用的是 gitlabhq.com），于是 Sid 和 Dmitriy 一拍即合，决定成立公司来全职投入GitLab。

GitLab 的两位创始人（左: Sid Sijbrandij; 右: Dmitriy Zaporozhets）在去年 NASDAQ 上市时的合影

最初，GitLab 是定位为开源的 GitHub（确切的说，是 GitHub Enterprise，也就是可在企业内私有部署的 GitHub 版本）。当时 GitHub Enterprise 的一个License 大约是500美元每人年。因此，功能接近 GitHub 而又开源的 GitLab 开始被越来越多的公司和个人所采用。我在2012年5月在公司搭建了第一个 GitLab 服务，好像是2.5版本，后来几乎每个月我都会升级，因为每个月都能感受到 GitLab 日新月异的变化。从最初仅仅是Git仓库托管，到项目管理功能(issues, milestone)，到借鉴与 GitHub PR 的 Merge Request。实际上，Merge Request 还是有很大的流程性创新的，在 GitLab 的 MR 流程中，无需 Fork 仓库，而是创建分支提交MR，这其实比 GitHub PR 更适合项目内协作。GitHub 后来也将这种无需 Fork 创建分支提 PR 的功能也实现了，可谓是学生教了老师。而 GitLab 的更新迭代非常快，他们也非常积极听取用户特别是企业用户的意见。记得应该是在2013年左右，我发了封邮件(也许是issue)给 GitLab，很快就收到了 Sid 的回复，并约我和 Dmitriy 一起开了个电话会议，我还记得 Sid 在电话会议快结束时说我们三个非英语国家的人分别在三个时区完成了对 GitLab 发展很重要的交流，这是互联网带来的奇迹（我脑洞一下，莫不是从那次会议起 Sid 动了 Remote 工作的念头^_^）。GitLab持续加强企业代码托管及开发协作所需的特性和服务，在 GitLab 之外还发布了持续集成服务 GitLab CI.

2015年初，GitLab 申请成为 Y Combinator 孵化器成员并获得通过。Y Combiantor 是 Paul Graham（即《黑客与画家》的作者）创办的风险投资结构，对投资项目要求极为严格。GitLab 获得 Y Combiantor 投资后整个团队（包括两创始人在内也就5个人）便搬到了硅谷。GitLab 也有了更为清晰的商业路线，加快了扩张，从最初的能装在一辆SUV的团队扩张到了140人。

GitLab 搬到硅谷初期的时候的团队，他们将这辆能塞下整个团队的车称为 Boat

GitLab 发现如果单纯做开源版的 GitHub Enterprise，商业变现比较困难，虽然GitLab 提供了收费的 GitLab EE 版本，但营收一直不是很理想。因为小企业其实部署开源免费的 GitLab CE 版本就够了，而大企业也会优先选择在 GitLab CE 版本上做二次开发和功能增强。因此 GitLab 在加入 Y Combinator 孵化器后，在商业策略上也开始调整，着重打造 GitLab.com SaaS 服务，将 GitLab CI 合入到 GitLab 中，并增加项目管理、CICD、性能安全检测等全链路的DevOps功能。对比 GitLab 和 GitHub 的订阅费可以看出，GitLab 的 Premium 版本每用户每月收费19美元，Ultimate 版本每用户每月 99美元；相对应的 GitHub 的两档收费版本 Team 和 Enterprise 分别是每用户每月 4美元和 21美元。可以说，GitLab 的收费远远高于 GitHub. 而 GitLab之所以有这样的底气，是因为它能给客户提供比 GitHub 更多功能特性的产品，用 GitLab 自己的话说，他们是（唯一的） DevOps 平台(The DevOps Platform, 注意这个 “The”)。当然，这个唯一是GitLab 自己声称的，其实各大云厂商都有自己的DevOps平台。不过仅就比较GitHub而言，确实 GitLab 在 DevOps 能力方面更胜一筹，GitLab 在官网也有与其他工具对比：GitLab = JIRA + GitHub + Jenkis + JFrog + 性能监控 + 安全检查。

GitLab 官网上将自己与其他工具对比

2020年，新冠疫情席卷全球，而提供企业 DevOps 服务的 GitLab 获得了快速发展的机会，成员也增长到了1200人，GitLab 获得了2亿6千万美元的风投，而 GitLab 也开启了它的上市计划。2021年，在 GitLab 创立10周年之际，GitLab 在纳斯达克(NASDAQ)上市，开盘市值冲到150亿美元（目前市值 100亿美元 10.24B）。

从2011年9月在 GitHub 上发布第一个版本，GitLab 每个月都会发布一个新版本，而且基本上都在每月的22日，前后相差不过一两天。十多年如一日，即使 GitLab 体量已经非常大了，还保持着最初版本一样的敏捷迭代效率，真的是令人佩服。而这体现了 GitLab 良好的构架守护。GitLab 最初采用 Ruby on Rails 框架编写，一直是学习 Ruby on Rails 的最好实例样板，代码非常干净整洁，测试用例也很齐全。而后关键性能组件用 Go 重写，前后端分离前端使用 VUE 重构。GitLab 一直采用合适的新技术来保持架构的弹性。

GitLab 代码量增长曲线

除了透明和敏捷，GitLab 的联合创始人及 CEO Sid Sijbrandij 总结了 GitLab的文化，将它归纳为 CREDIT: 及 Collaboration(开放协作), Results(结果导向), Efficiency(效率优先), Diversity Inclusion and Belonging(多样性、包容及归属感), Iteration(敏捷迭代), Transparency(透明)。从最初的两个创始人到目前全球分布的1400多员工，从最初的一次开源代码提交到现在市值160亿美元的上市企业，GitLab 的故事激励着初创企业和开源社区。可以说，GitLab 是将开源软件的开放与透明文化与商业模式结合最为成功的案例之一。

启示

GitHub 和 GitLab 的故事带给我的启发大概有如下几点：

文化是公司或团队最重要的东西。任总说过：“只有文化才能生生不息。”很多组织的文化是在组织创立后逐渐形成的。一个积极而正向的文化能将优秀的人聚集在一起，所谓物以类聚，人以群分。GitHub 的黑客文化，GitLab 的透明开放文化，都将一批有同样理想和追求的人聚集在了一起，从而创造出优秀的产品。
解决自己遇到的问题，这往往是做好产品的前提。如果别人也有这个问题，那么商业模式就有了。如果这是个普遍存在的问题，那么这将是个很好的商业模式。GitHub 和 GitLab 在创立初期都是为了解决自己遇到的问题，吃狗粮(eating dog food)，直到发现更广阔的用户场景。
持续迭代，持续演进，持续更新。GitLab 可以说将迭代做到了极致，而 GitHub 的更新迭代也是很快的。与之形成对比的是 Gitorious，作为 Git 托管平台，Gitorious 很早就开源了，它的诞生不仅比 GitLab 早，甚至比 GitHub 还早。但 Gitorious 基本上是对标 SourceForge 做的，后期也不怎么更新，最终被 GitLab 所收购。产品如果不及时更新，很快就会被用户所遗忘。
后发产品要想实现超越必须要探索出一条新路，沿着领先竞争对手的路去走只能是跟随。GitLab 初期是以开源可私有部署的 GitHub 方式而深入人心，因此得到了很多期望以更低成本私有化部署 GitHub 的用户的青睐。后来 GitLab 做代码托管 SaaS 服务 GitLab.com, 曾想以免费私有仓的差异化来获取用户，但在产品路线上并没有与 GitHub 形成太大差异，因此效果并不理想，而等到微软收购 GitHub 宣布免费创建私有仓后，这点唯一的优势也就没有了。因此 GitLab 后来将重点放到了支持企业级 DevOps 上，全力打造 DevOps 能力，探索出另一条新路，也使得自己的估值指数级上升，获得了市场认可。

如果你有任何想法和建议，欢迎与我交流或联系。

参考

电瓶车自燃事故频发，电动车电池还有前景吗？

Mon, 17 May 2021 11:31:00 CST

近日,成都某小区一电动车在电梯内突然自燃起火,现场浓烟滚滚伴随火光爆闪,致电梯内6名乘客烧伤,包括一名襁褓中的婴儿,电瓶车失火问题需要认真防范。

电瓶车自燃事件频发

近年来我国电瓶车自燃事件举不胜举,根据每日安全生产资料显示,一辆电瓶车从起火到完全燃烧仅需要三分半,温度高达1200度,电瓶车自燃问题需要引起足够重视。

治标:倒逼物业管理服务升级

尽管国家一再出台政策整治电动自行车“进楼入户”、“人车同屋”、“飞线充电”等突出问题,但执行效果并不如意。一方面,物业监管力度不够,对电动车进电梯缺乏监管;另一方面公共区域充电设施不完善,居民在楼道和家里充电是被逼无奈的选择。

从加强电动车进电梯监管方面入手,为防止电瓶车爆燃事故发生,多地小区采取技术手段禁止电车进入电梯楼道。例如近日山东济南、潍坊等地安装电动车禁入电梯智慧管控装置,禁止电动车乘电梯上楼充电,避免电动车爆燃事故发生。当有电动自行车进入电梯轿厢内,系统会自动抓拍图片并现场联动语音报警,同时输出信号到电梯主板,控制电梯停止运行。

电梯智慧管控属于社区智能安防的细分产品,此外智能安防系统还包括智能防盗报警、智能视频监控、智能楼宇对讲、智能防爆安检、智能门禁控制等子系统。

近年来,我国智能安防系统市场规模持续增长,2020年我国智能安防市场规模约为576亿元。随着数字化、网络化的发展,智能安防市场规模未来将持续增长。

在解决解决公共区域充电设施方面,为遏制电动自行车火灾多发势头,2020年柳州进行电动自行车智能充电桩建设试点工作,并鼓励不是试点的小区通过自筹资金、商业运营的模式自行开展建设。随着各地公共区域充电设施建设的开展,电动自行车智能充电桩市场将得到发展。

结合智能充电桩行业公司叮叮智能发展情况来看,根据叮叮智能消息,目前其充电业务已覆盖200多座城市,服务用户数近百万人,预估2020年其市场占有率达16%。

不论是电车进电梯物业监管失责,还是电车公共充电设施提供不完善,都显示出物业管理的失责,需要进一步加强物业管理服务。2021年5月11日,成都市物业管理协会发布《关于进一步加强物业服务区域电动车停放充电管理的紧急通知》,进一步加强物业服务区域电动车停放充电管理。

随着云计算、大数据等技术的发展,物业管理行业迎来新的发展机遇,通过物业管理智慧化升级可提升对电动车停放充电管理的效率,保障小区居民的权益。

治本:电池问题值得关注

2019年新标准《电动自行车安全技术规范》的出台,对电动自行车整车重量提出了新的要求,推动了锂电池电动自行车的发展。根据中关村在线数据显示,2019年我国锂电池市场份额达到13．2%,较2018年增长1．8个百分点,预计2020年锂电池的市场份额将会扩大到20%左右。

但是锂电池也存在一定的隐患。锂电池由于其活泼的化学属性,起火爆炸的风险要比铅酸电池高很多。

其实不论是锂电池和铅酸电池,正规厂家生产的电池都符合安全技术标准,能够充分保证用户的使用安全。但由于电动车领域准入门槛较低,市面上很多小厂家生产销售质量较差的锂电池,相对更容易发生事故。并且市场上充斥着违规改装电池的现象,形成了灰色产业链。根据新华社消息,在几大主流电商平台上,均有多款不合规电瓶在售卖,价格在几百元至上千元不等。

除了电池本身质量问题之外,电池使用时间过长、电池过多充电、电源线路老化破损等原因也会导致电车自燃。因此,用户需要加强电瓶车自燃预防意识,减少电车自燃发生条件。

来源:前瞻产业研究院

重大事故！IO问题引发线上20台机器同时崩溃

Tue, 22 Sep 2020 05:21:05 CST

几年前的一个下午，公司里码农们正在安静地敲着代码，突然很多人的手机同时“哔哔”地响了起来。本来以为发工资了，都挺高兴！打开一看，原来是告警短信

故障回顾

告警提示“线程数过多，超出阈值”，“CPU空闲率太低”。打开监控系统一看，订单服务所有20个服务节点都不行了，服务没响应。

每个springboot节点线程数全都达到了最大值。但是JVM堆内存和GC没有明显异常。CPU 空闲率基本都是0%，但是CPU使用率并不高，反而IO等待却非常高。下面是执行top命令查看CPU状况的截图：

从上图，我们可以看到:

CPU空闲率是0%（上图中红框id）

CPU使用率是22%（上图中红框 us 13% 加上 sy 9%，us可以理解成用户进程占用的CPU，sy可以理解成系统进程占用的CPU）

CPU 在等待磁盘IO操作上花费的时间占比是76.6% （上图中红框 wa）

到现在可以确定，问题肯定发生在IO等待上。利用监控系统和jstack命令，最终定位问题发生在文件写入上。大量的磁盘读写导致了JVM线程资源耗尽（注意，不代表系统CPU耗尽）。最终导致订单服务无法响应上游服务的请求。

IO，你不知道的那些事儿

既然IO对系统性能和稳定性影响这么大，我们就来深入探究一下。

所谓的I/O（Input/Output）操作实际上就是输入输出的数据传输行为。程序员最关注的主要是磁盘IO和网络IO，因为这两个IO操作和应用程序的关系最直接最紧密。

磁盘IO：磁盘的输入输出，比如磁盘和内存之间的数据传输。

网络IO：不同系统间跨网络的数据传输，比如两个系统间的远程接口调用。

下面这张图展示了应用程序中发生IO的具体场景：

通过上图，我们可以了解到IO操作发生的具体场景。一个请求过程可能会发生很多次的IO操作：

页面请求到服务器会发生网络IO
服务之间远程调用会发生网络IO
应用程序访问数据库会发生网络IO
数据库查询或者写入数据会发生磁盘IO

IO和CPU的关系

不少攻城狮会这样理解，如果CPU空闲率是0%，就代表CPU已经在满负荷工作，没精力再处理其他任务了。真是这样的吗？

我们先看一下计算机是怎么管理磁盘IO操作的。计算机发展早期，磁盘和内存的数据传输是由CPU控制的，也就是说从磁盘读取数据到内存中，是需要CPU存储和转发的，期间CPU一直会被占用。我们知道磁盘的读写速度远远比不上CPU的运转速度。这样在传输数据时就会占用大量CPU资源，造成CPU资源严重浪费。

后来有人设计了一个IO控制器，专门控制磁盘IO。当发生磁盘和内存间的数据传输前，CPU会给IO控制器发送指令，让IO控制器负责数据传输操作，数据传输完IO控制器再通知CPU。因此，从磁盘读取数据到内存的过程就不再需要CPU参与了，CPU可以空出来处理其他事情，大大提高了CPU利用率。这个IO控制器就是“DMA”，即直接内存访问，Direct Memory Access。现在的计算机基本都采用这种DMA模式进行数据传输。

通过上面内容我们了解到，IO数据传输时，是不占用CPU的。当应用进程或线程发生IO等待时，CPU会及时释放相应的时间片资源并把时间片分配给其他进程或线程使用，从而使CPU资源得到充分利用。所以，假如CPU大部分消耗在IO等待（wa）上时，即便CPU空闲率（id）是0%，也并不意味着CPU资源完全耗尽了，如果有新的任务来了，CPU仍然有精力执行任务。如下图：

在DMA模式下执行IO操作是不占用CPU的，所以CPU IO等待（上图的wa）实际上属于CPU空闲率的一部分。所以我们执行top命令时，除了要关注CPU空闲率，CPU使用率（us，sy），还要关注IO Wait（wa）。注意，wa只代表磁盘IO Wait，不包括网络IO Wait。

Java中线程状态和IO的关系

当我们用jstack查看Java线程状态时，会看到各种线程状态。当发生IO等待时（比如远程调用时），线程是什么状态呢，Blocked还是Waiting？

答案是Runnable状态，是不是有些出乎意料！实际上，在操作系统层面Java的Runnable状态除了包括Running状态，还包括Ready（就绪状态，等待CPU调度）和IO Wait等状态。

如上图，Runnable状态的注解明确说明了，在JVM层面执行的线程，在操作系统层面可能在等待其他资源。如果等待的资源是CPU，在操作系统层面线程就是等待被CPU调度的Ready状态；如果等待的资源是磁盘网卡等IO资源，在操作系统层面线程就是等待IO操作完成的IO Wait状态。

有人可能会问，为什么Java线程没有专门的Running状态呢？

目前绝大部分主流操作系统都是以时间分片的方式对任务进行轮询调度，时间片通常很短，大概几十毫秒，也就是说一个线程每次在cpu上只能执行几十毫秒，然后就会被CPU调度出来变成Ready状态，等待再一次被CPU执行，线程在Ready和Running两个状态间快速切换。通常情况，JVM线程状态主要为了监控使用，是给人看的。当你看到线程状态是Running的一瞬间，线程状态早已经切换N次了。所以，再给线程专门加一个Running状态也就没什么意义了。

深入理解网络IO模型

5种Linux网络IO模型包括：同步阻塞IO、同步非阻塞IO、多路复用IO、信号驱动IO和异步IO。

写在前面

为了更好地理解网络IO模型，我们先了解几个基本概念。

Socket（套接字）：Socket可以理解成，在两个应用程序进行网络通信时，分别在两个应用程序中的通信端点。通信时，一个应用程序将数据写入Socket，然后通过网卡把数据发送到另外一个应用程序的Socket中。我们平常所说的HTTP和TCP协议的远程通信，底层都是基于Socket实现的。5种网络IO模型也都要基于Socket实现网络通信。

阻塞与非阻塞：所谓阻塞，就是发出一个请求不能立刻返回响应，要等所有的逻辑全处理完才能返回响应。非阻塞反之，发出一个请求立刻返回应答，不用等处理完所有逻辑。

内核空间与用户空间：在Linux中，应用程序稳定性远远比不上操作系统程序，为了保证操作系统的稳定性，Linux区分了内核空间和用户空间。可以这样理解，内核空间运行操作系统程序和驱动程序，用户空间运行应用程序。Linux以这种方式隔离了操作系统程序和应用程序，避免了应用程序影响到操作系统自身的稳定性。这也是Linux系统超级稳定的主要原因。所有的系统资源操作都在内核空间进行，比如读写磁盘文件，内存分配和回收，网络接口调用等。所以在一次网络IO读取过程中，数据并不是直接从网卡读取到用户空间中的应用程序缓冲区，而是先从网卡拷贝到内核空间缓冲区，然后再从内核拷贝到用户空间中的应用程序缓冲区。对于网络IO写入过程，过程则相反，先将数据从用户空间中的应用程序缓冲区拷贝到内核缓冲区，再从内核缓冲区把数据通过网卡发送出去。

同步阻塞IO

我们先看一下传统阻塞IO。在Linux中，默认情况下所有socket都是阻塞模式的。当用户线程调用系统函数read()，内核开始准备数据（从网络接收数据），内核准备数据完成后，数据从内核拷贝到用户空间的应用程序缓冲区，数据拷贝完成后，请求才返回。从发起read请求到最终完成内核到应用程序的拷贝，整个过程都是阻塞的。为了提高性能，可以为每个连接都分配一个线程。因此，在大量连接的场景下就需要大量的线程，会造成巨大的性能损耗，这也是传统阻塞IO的最大缺陷。

同步非阻塞IO

用户线程在发起Read请求后立即返回，不用等待内核准备数据的过程。如果Read请求没读取到数据，用户线程会不断轮询发起Read请求，直到数据到达（内核准备好数据）后才停止轮询。非阻塞IO模型虽然避免了由于线程阻塞问题带来的大量线程消耗，但是频繁的重复轮询大大增加了请求次数，对CPU消耗也比较明显。这种模型在实际应用中很少使用。

多路复用IO模型

多路复用IO模型，建立在多路事件分离函数select，poll，epoll之上。在发起read请求前，先更新select的socket监控列表，然后等待select函数返回（此过程是阻塞的，所以说多路复用IO也是阻塞IO模型）。当某个socket有数据到达时，select函数返回。此时用户线程才正式发起read请求，读取并处理数据。这种模式用一个专门的监视线程去检查多个socket，如果某个socket有数据到达就交给工作线程处理。由于等待Socket数据到达过程非常耗时，所以这种方式解决了阻塞IO模型一个Socket连接就需要一个线程的问题，也不存在非阻塞IO模型忙轮询带来的CPU性能损耗的问题。多路复用IO模型的实际应用场景很多，比如大家耳熟能详的Java NIO，Redis以及Dubbo采用的通信框架Netty都采用了这种模型。

下图是基于select函数Socket编程的详细流程。

信号驱动IO模型

信号驱动IO模型，应用进程使用sigaction函数，内核会立即返回，也就是说内核准备数据的阶段应用进程是非阻塞的。内核准备好数据后向应用进程发送SIGIO信号，接到信号后数据被复制到应用程序进程。

采用这种方式，CPU的利用率很高。不过这种模式下，在大量IO操作的情况下可能造成信号队列溢出导致信号丢失，造成灾难性后果。

异步IO模型

异步IO模型的基本机制是，应用进程告诉内核启动某个操作，内核操作完成后再通知应用进程。在多路复用IO模型中，socket状态事件到达，得到通知后，应用进程才开始自行读取并处理数据。在异步IO模型中，应用进程得到通知时，内核已经读取完数据并把数据放到了应用进程的缓冲区中，此时应用进程直接使用数据即可。

很明显，异步IO模型性能很高。不过到目前为止，异步IO和信号驱动IO模型应用并不多见，传统阻塞IO和多路复用IO模型还是目前应用的主流。Linux2.6版本后才引入异步IO模型，目前很多系统对异步IO模型支持尚不成熟。很多应用场景采用多路复用IO替代异步IO模型。

如何避免IO问题带来的系统故障

对于磁盘文件访问的操作，可以采用线程池方式，并设置线程上线，从而避免整个JVM线程池污染，进而导致线程和CPU资源耗尽。

对于网络间远程调用。为了避免服务间调用的全链路故障，要设置合理的TImeout值，高并发场景下可以采用熔断机制。在同一JVM内部采用线程隔离机制，把线程分为若干组，不同的线程组分别服务于不同的类和方法，避免因为一个小功能点的故障，导致JVM内部所有线程受到影响。

此外，完善的运维监控（磁盘IO，网络IO）和APM（全链路性能监控）也非常重要，能及时预警，防患于未然，在故障发生时也能帮助我们快速定位问题。

看完三件事❤️

如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：

点赞，转发，有你们的『点赞和评论』，才是我创造的动力。
关注公众号『 java烂猪皮 』，不定期分享原创知识。
同时可以期待后续文章ing

本文作者：冯涛来自公众号：架构师进阶之路

“刘家老大刘江伟平时搬水泥为生，刘江伟搬一袋水泥，赚2毛5分钱。一袋儿水泥是50公斤，搬够一吨水泥是5块钱，一天要搬够20吨水泥能才挣够100块钱。”在《山东商报》的报道《独家探访“土方4名儿童被埋”家庭》里看到这样一段文字，刘江伟是这次事故中一位死亡儿童的父亲……

Mon, 20 Apr 2020 19:13:18 CST

“刘家老大刘江伟平时搬水泥为生，刘江伟搬一袋水泥，赚2毛5分钱。一袋儿水泥是50公斤，搬够一吨水泥是5块钱，一天要搬够20吨水泥能才挣够100块钱。”在《山东商报》的报道《独家探访“土方4名儿童被埋”家庭》里看到这样一段文字，刘江伟是这次事故中一位死亡儿童的父亲……

又一批长事务，P0 故障谁来背锅？

Fri, 17 Apr 2020 00:00:00 CST

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

最近几周，发生过多起因为事务问题引起的服务报错。现象为数据库连接池连接占满，数据库连接长时间等待，最终导致请求线程hang住，服务大面积报错。这个时候，服务资源、数据库资源大量空闲，但就是进行不下去，影响是比较恶劣的。

谁来背锅？当然是架构师。因为这次所有的服务都活着，没运维什么事。

面试时，大家可能都会碰到关于事务相关的问题，升级版的可能是分布式事务的问题。在互联网行业中，一句马马虎虎的补偿事务就能蒙混过关，毕竟都是些短小精悍的接口。

但在很多企业级应用中，这行不通。我们必须直面惨淡的现实。

为什么要用长事务?

在许多业务非常复杂的后台系统，经常频繁操作DB，为了保证数据的 一致性，能够在出错时回滚数据，通常会使用事务。

就拿最简单的单机数据库事务来说。

在事务操作期间，如果持续时间过长，只有等事务结束之后，DB连接才会释放，此类长时间占用DB连接的事务操作，称为长事务。一旦外部有大量请求，并发调用此操作，那么将会有大量的DB连接被持有而没有被释放掉，直到连接池爆满。

这个时候，如果有其他请求到来，那十有八九是以失败告终。

也就是说，连接资源被少数长事务操作占用。在这种情况下，即使是最简单接口查询，都不能够正常进行。

几粒老鼠屎，坏了一锅粥。

一些魔幻的反应

当你去排查这种问题的时候，可能会陷入僵局。jstack显示，多数请求其实是阻塞在tomcat的线程池上，而且是一些访问速度非常快的请求被阻塞。

比如，tomcat的200个线程，有180个阻塞在耗时不到1ms的 /status接口上。

很多人就一脸懵逼。经验失灵。

jstack此时的输出结果，欺骗了我们。真正造成阻塞的，是那额外的20多个线程。

有哪些改善?

保证事务的短小是一个基本要求，包括但不限于：

应控制慢查询的调用频率，尽量减少慢查询。很多情况下，这条规则是自欺欺人的，需要业务做一些妥协。

事务内不应包含任何RPC调用，减少事务的粒度。通常，一些RPC调用，包括其他非事务资源的调用，耗时非常不可控。如果把它们也纳入事务的范围之内，势必会加剧资源的占用。事务内不应包含其他容易超时或者长时间阻塞的服务，如HTTP调用、IO操作。

次优先级服务如消息队列，不应该放在事务内，避免因为消息队列不可用引起的服务不可用。给类似消息队列的组件，设置一个合理的超时时间的非常有必要的，否则它就会一直等在那里。但即使是这样，也尽量不要把它们纳入到事务操作之内。

跨库、跨类型（如Redis），不应该放在同一事务中，可避免交叉影响。

你可以看到上面的这些描述，有些和我们所追求的数据一致性是相悖的。这不奇怪，依然是CAP原理的权衡。有些业务选择的是宁可卡死不再响应，也不能进入异常数据；有些则首先让业务运行下去，脏数据会通过补偿事务进行修正。

一切看你的选择。

设计总有人背锅，补偿总有人做出牺牲。

解决方式

那么如何来 快速解决大事务造成的服务不可用问题呢？

除了扩容，其实是无解。重启大法也不见得好用。因为被阻断的请求，会以更凶猛的态势再次来袭。

你可能会想到调大连接池的大小。但在实践中得知，也不好用，大事务请求会迅速将连接池占满。

但我们可以提前进行防御。

以Spring为例，事务的使用方式大多数是使用@Transactional注解来控制的，或者是声明式事务方式。我建议以以下方式进行预防和发现：

1) 重新扫描或者Review业务代码，排查事务中是否有以上提到的各种情况。然后将除DB操作外的其他操作移动到事务之外。

2) 每个事务操作都给予足够重视，对于执行复杂度和时间复杂度不确定的事务，添加超时报警，及时发现引起的原因。

同时，还需要加强监控，辅助进行问题排查。

1) 业务可以考虑定时将数据库连接池的信息进行打印，通过看日志的方式进行初步排查。

2) 使用jstack查询执行栈，找出阻塞的点。

3) 排查并联系下游服务，找出主要原因

xjjdog倾向于使用监控快速发现问题。如图，通过连接池监控，可以看到数据库连接池连接数长时间保持在高位不释放，同时等待的线程数急剧增加。发生此种现象多数可以考虑是否是以上原因引起。

发生问题时，应及时（多次）使用jstack定位到线程的阻塞位置，然后排查下游服务是否有问题，或者是否存在慢查询。

最好的情况是服务已经进行了对代码的梳理，那么引起的原因大概率只剩下了慢查询。针对慢查询，druid数据库连接池，提供了sql的聚合，能够查看是每一类查询语句的具体执行情况。如图，短时间内SQL请求飙升，最大执行时长上升，连接池占满：

具体是哪一句SQL所引起的，一目了然。

End

长事务问题的危险级别属于高危型，通常会造成严重的后果，可以通过观察监控，防范于未然。

最优的解决方式，当然是业务模型的改进。但这东西第一涉及到开发成本，第二涉及到跨部门协作。

出钱的老板，无法听懂你这些梦话。

在一些公司内部，这两者都是让人抓狂的事情，还不如痛痛快快背个锅，来得实在。

近期热门文章

《 996的乐趣，你是无法想象的》
魔幻现实主义，关爱神经衰弱

《一切荒诞的傲慢，皆来源于认知》
不要被标题给骗了，画面感十足的消遣文章

《必看！java后端，亮剑诛仙》
后端技术索引，中肯火爆。全网转载上百次。

《学完这100多技术，能当架构师么？（非广告）》
精准点评100多框架，帮你选型

作者简介： 小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流

独家深访：腾讯变革150天全记录 | 故事硬核

Sat, 09 Mar 2019 13:16:58 CST

点击 故事硬核关注我们，加星标以防走失⭐️

在2018年的危机当中，20岁的腾讯自上而下开启了一场前所未有的变革，投身未来20年产业互联网的新战场。

作为一家拥有国民级应用的企业，腾讯每一次变革，都令公众与业界瞩目。为此，故事硬核采访了马化腾和他数十位同事，深度还原他们处理危机、调整架构、推翻自我、深入战场的全历程。

撰文 | 林珊珊李炫特

“是时候变革了”

马化腾快步走进北京西三环的一间会议室，没有停顿，开始接受故事硬核的采访。这是2018年12月18日下午，4小时前，他还坐在人民大会堂主席台第二排，在军乐声里接过奖牌，获得了“改革开放四十周年先锋人物”的称号。

马化腾已经想的很清楚了。他会礼貌地倾听我们插入的问题，简洁答完，又迅速回到自己的思路上。他不怎么表露情绪，也很少展开身体语言，但态度直接，甚至于坦白。

很难说这是他人生中第几个高峰，在改革开放40周年、腾讯公司20年的历史节点，提到即将逝去的2018，马化腾说，“（这是）危机感很强的一年。”

马化腾有种天生的理性。腾讯高级顾问杨国安说，听到不同意见，马化腾的典型反应是“也有道理”。当他表达不满，通常会说“还行”，说“不太好吧”已经算非常严厉。共事十多年的总办成员们也说，很少见他情绪波动。

然而在刚刚过去的2018年，几位伙伴都提到感受到了马化腾的压力。

剧烈变动从年初就开始了。1月以来，腾讯股价下跌40%，市值蒸发万亿；政策方面，游戏版号停发，行业一片哀嚎；不利舆情顺势扑来，蔓延进4万员工的内网，引发了对于公司战略的困惑：腾讯究竟有没有梦想？

做一家受人尊敬的公司是腾讯最大的愿景。但外部批评在内部轻易引发了员工的共鸣，让腾讯高层意外。“我们对内、对外沟通都存在问题。”一位腾讯高管说，过去这一年，“压力慢慢、慢慢蓄积起来”。

腾讯的危机究竟是哪一种？问题传递到公司总办（腾讯的最高管理层），总办成员们激烈讨论，“到底我们现在是伤风感冒了，还是一个比较严重的病？”杨国安在腾讯滨海大厦办公室里回忆。他组织一连串会议，一个月后得出诊断结果：不是伤风感冒，而是真正的、重大的危机。

杨国安找到腾讯集团总裁刘炽平，关于危机应对的讨论最终聚焦到一个问题上：是时候架构变革了吗？

巨头公司一旦变革总是需要大决心、伴随大风险，好比疾驰中的重卡换引擎，换的过程还不许减速。在腾讯20年的历史上，总共只进行过三次组织架构调整，上一次还是在3Q大战之后，以一系列自省动作及一场架构调整，将自己推上了移动互联网的浪潮之巅。

“我们经历了一段很好的时间。”回忆那个节点，刘炽平说。而眼下，他感觉，“这个好日子有点被打破了。”

他感慨道，“大家一起打江山的时候，凝聚力相当强的。到后面好像大局已定，江山已稳了，反而凝聚力是有所下降的。”他的结论是，公司管理需要升级，团队心态需要提升。

刘炽平对杨国安说，“是时候了。”

谈话到了马化腾那里，他意识到，4万员工渴望变革，期待公司“有一个求变的心态，而不是听着外面指责，无动于衷”。

架构调整的想法他已经酝酿了一年，“是时候了。”他说。

△ 2018年12月18日下午，马化腾接受故事硬核的采访。摄影 | 吴家翔

在香港餐厅的小包厢

十多年来，腾讯最高决策机构“总办”，保持着隔周周二开例会的传统。2018年9月第二周，总办会却被转移到香港一家餐厅的小包厢。

对开会选址，马化腾进门时有些迷惑。然后他被没收了手机。其他人也是。包厢只有一张圆桌，为了全员上桌，十几位总办高管只好依次卡进座位，“胳膊肘挨着胳膊肘”，团成一个圈。

但全新的会议制度立刻使他们忘了这些。设计议程的是杨国安，他准备了一枝仪式感小花，按次序推向桌沿。收花人被要求诊断腾讯——“你现在就是CEO了”——必须正面回答公司面临什么真问题，应该如何解决。

首轮小花发给了马化腾。“他先讲困扰，要打开尺度，”回忆时杨国安眨眨眼睛，“这样大家就知道能够讲到多深。”

马化腾一口气讲了数个真问题，其一如战略问题，云到底是不是腾讯最重要的、一定要做的？其二如组织架构问题，确实需要调整——他停住，提问，“腾讯一两千个总监级干部里，30岁以下的有多少？”

答案是不到十人。

“这事儿对Pony（马化腾）、对我们刺激都很大。”腾讯的与会高级副总裁郭凯天回忆，“你想想当时创办腾讯的时候几位创始人多大呢？”——回到深圳后，每位总办成员都接到了裁撤中干、为年轻人腾位置的任务。

在腾讯公司20周年的会议上，刘炽平表态，在未来一年内，有10%不再胜任的管理干部要退。“尤其在中干这个领域，”他态度坚决，“我们几个月之内很快地会完成10%的目标。”他希望公司能真正形成“能上能下”的新文化。

像杨国安希望的那样，领到小花的每个人都“讲了心里话”，有很多问题很尖锐。比如一个以社交为优势的公司竟出现了沟通障碍。

总办成员们困扰于员工心态“脆弱”。这种脆弱是，内部不能很好地理解公司真正的战略和意图，业务一旦不顺利，士气就开始波动。管理方式是时候改变了。

尺度前所未有。午餐被拖到3点，晚餐则是9点。那种感染力是真实可触的，在场的每个人都知道，有些内核的东西从此刻起不同以往了。“所有这些事儿汇集到一起，你会觉得历史时期变了。”一位腾讯高管说，“就是要变革的时间点到了。”

△ 腾讯总办成员在组织架构调整后的合影。

腾讯史上最重要的战略

在香港会议上，当马化腾问云是不是腾讯一定要做的，他心中早有答案。如果过去还要犹豫争吵，现在则是十几位总办成员都达成高度共识：互联网已经进入TO B 下半场，云是最重要的战略工具。

只是还有一个问题要想清楚，腾讯人能否适应新战场？

在腾讯，高管们喜欢拿战争做比喻。TO C部队是空军，做个爆款产品，一呼百应，“炸弹一投，整个地盘都是你的，你是很舒服”。

“你不可能只做空军了，”马化腾很坚决，“做TO B压力还是蛮大的。苦活、脏活嘛，连车都没有了。但你没办法，而且我们的步兵还是有优势的，就是C TO B。我们还是有空军支援步兵。”

地面战争，腾讯志在必得。国家在发生深刻转型，全面的数字化、智能化的时代已经来临，每个产业都在拥抱云、大数据与人工智能，“跟以前拥抱电一样”。不及时跟进，腾讯也要变成“传统互联网了”。离腾讯战略提出互联网+已经过去5年。几年间，各部门按着各自生存优势开拓了地面战场——交通、安全、医疗AI 、智慧零售……打造着各自的“陆军战队”。

而今复盘，如果说腾讯错过了什么，也许是没有更早对云重兵投入。但马化腾运气一直不错，极少失手，在云战略上也维持了好运——云自己悄悄长出来了。

云，被称为“信息能源发动机”，为各行业提供动力与能源。

作为腾讯史上最重要的战略之一，云的故事最初也是一个宅男/程序员故事：一款偷菜小游戏的副产品。2009年夏天，全年龄段QQ用户几乎都在“农场”里疯狂“偷菜”。

“不断加服务器，一个月内要加4000台”，汤道生回忆时，脸上有种程序员们能心领神会的快乐。他是QQ前掌门人、现在的腾讯云与智慧产业事业群掌舵人。

“偷菜”成功让QQ引进了更多外部游戏，催生了开放平台。云正是在对外开放流量和计算能力中诞生的。“我觉得腾讯做事儿有时候好像是被大的时代推着，你不做不行。”汤道生说。

那时，马化腾还没看清云业务的方向。但他对暂时看不清的东西，会默许它存在，不轻易表态。腾讯的许多产品都不是在计划之内的，而是生长于这种包容。后来，马化腾把它称为“管理的灰度”。

云业务的诞生被默许，但云业务的发展得靠自己。很长时间里，云业务看不清前景，汤道生能调动的资源只有“人品”。“我很幸运，人缘不错，攒了一些人品，给团队画饼……放心放心，我觉得这个事儿还是有的做的，你相信Dowson（注，公司内习惯叫汤道生的英文名）。”

卖云毛利低，投入高，有规模效应前要亏非常久。服务器成本过高，资金投入就会显得小心谨慎（为了节省成本，2009年后汤道生和小伙伴们直接采购回CPU、内存、硬盘，自己设计、自己组装服务器）。与此同时，阿里云高举高打，已经收割了移动互联网第一波爆发的红利。

那段时光非常难熬。汤道生说，“很多是早期做QQ秀的，在腾讯打过仗蛮久，刚好云（出现），有四五年大家赌在上面，最终机会就是给那些愿意预先投入、在前景不明时就去闯的人。”

那时留下来的，都是跟了汤道生多年的铁杆。现在腾讯云的总裁邱跃鹏，在那时是帮汤道生做运维的业务负责人，现在腾讯云副总裁王慧星，那时是QQ秀的骨干。

从开放平台到孵化出一个公有云原型花了快十年。王慧星2014年底加入云时，部门只有三百多人——之后四年里这个数字增长了10倍——加入不久，亚马逊公司的云AWS正式发财报宣布盈利，净利率达到20%。“Pony会发现，这个东西原来还是挺有前景，规模很大。”

马化腾有一种天然的温和，你不会害怕挑战他。在云这件事上也是。“他知道你在做，他未必完全认同然后马上给你很多资源，但他也不会按住你说你不要做。”汤道生说。

先行者带动了国内的云竞争，除了腾讯，阿里、百度、Ucloud、金山等公司全部发力，加大投入。

云的重要性在国家层面也越来越清楚，“互联网+”“数字中国”成了国家战略，云是数字化的基础。来敲门的还有腾讯投资的公司们，他们需要云，需要数据安全有可靠保障的云。时机变化，汤道生开始鼓励团队主动汇报，申请资源，甚至必要时，“跟老板吵吵架”。

2016年腾讯云峰会，马化腾出现在会场，给云站台——他的鲜明风格之一就是不给腾讯任何产品站台——一个例行邀请，“竟然来了”，汤道生回忆，云团队像过节一样开心，“关键他不仅仅是给云的团队看，他出来是给整个行业看”。

那天的演讲中，马化腾明确说，“互联网+基础设施的第一要素，就是云”。

具备了人工智能、安全、大数据处理这些能力后，云不再是一个独立业务，“而是作为整个平台战略来考虑”。

腾讯集团总裁刘炽平在一次和员工的沟通会上说，腾讯云是“非常重要的、一定要攻上去的战略高地”，态度上非“长期吃定”不可，“一定要把云的业务看成是我们一个生死存亡的业务来做，全公司一起去联动”。

刘炽平是一个乐观的人。他分析美国亚马逊公司的云业务AWS，画它的增长图，“要说什么是一个最美好的商业模式，画出来的就是AWS”——规模大、增长快（每年稳定增长40%-50%）。这给他注入了信心，不止在一处场合，他把那条美好的曲线打到PPT上，让同事们一起欣赏。

腾讯要把失去的时间追回来。云团队一路狂飙。2016年腾讯云收入比上一年增长逾两倍，2017年同比增长一倍多，2018年Q3财报显示，又同比增长逾一倍，前三季度收入逾60亿。居国内云市场第二。

但地面战场形势险峻，将各分散的“陆战队”和云合并，齐心作战，已是必选之举。

最终，“香港共识”达成了最重要的几项：一、进行组织架构调整，成立云与智慧产业事业群（CSIG），主攻产业互联网。二、从TO C 到 TO B，继续巩固消费互联网，重兵投入产业互联网。

汤道生被推举为云与智慧产业事业群的掌舵人。结果是自然而然的，他所负责的社交网络事业部拆解，QQ业务交给新成立的平台与内容事业群。没有讨价还价，没有争论抵抗，全桌达成共识，所有TO B业务整理、合并、打包，全体移交给他。

技术工程事业群总裁卢山说：“要往死里帮（产业互联网）”。

刘炽平不止一次强调对于这个新部门寄予的厚望。有时是开玩笑式的。他与马化腾、汤道生等人花了好多个晚上，为新事业部起名儿。他笑道，“CSIG是公司唯一一个有四个英文字母的BG（Business Group，事业群）。四个英文字母代表了一个很特殊的地位。”

汤道生却过分安静，到最后，他干脆沉默了。

△ 马化腾在2018年度员工大会上。

汤道生准备好了吗？

汤道生的办公室曾摆着很有年轻人气质的钢铁侠和美国队长等漫威公仔（如今又改成了由云与智慧产业事业群自研的产品智能音箱腾讯叮当）。8年前，微信横空出世，QQ跌至谷底，这名斯坦福电子工程系毕业的香港籍高管作为救火队长空降，自学内地年轻用户的穿衣风格，追他们追的网剧（“看《花千骨》时自己也能跟着爽一把”），从自我减龄开始帮QQ年轻化。很快，手机QQ活跃用户达到7亿。

采访这天他穿着墨绿色夹克、牛仔裤和黑色休闲鞋，看上去从容有活力，的确比实际年龄年轻许多。汤道生属于“解决问题使我快乐”的那类人，他总是兴致盎然，提到腾讯课堂的“母羊如何顺产课”时简直乐不可支。共事多年，杨国安没见过“想不通”的汤道生——除了香港会议结束后那半个小时。

对新任务汤道生欣然领命，但直到香港会议，他才知道自己经营多年的QQ业务将剥离出去。他非常不舍。会上发言像一个新时代里不合时宜的怀旧者那样，讲了他与QQ的往事。

最后那半小时，人走光了，汤道生留下来问杨国安，为什么做出了这样的安排。

连续三天汤道生在脑子里推演怎么让马化腾理解他对QQ的感情。太太理解他，允许他在想通前“不承担一些家务”。脑中演习进行到第四天中午，汤道生约了马化腾午餐。

汤道生记得，他第一次跟马化腾“争论”发生在刚进腾讯几个月时。马化腾担心韩国一个叫Cyworld的社交网站会给QQ空间带来威胁，建议增加部分功能应对。汤道生不能共情马化腾的焦虑，走进办公室，告诉他这么做意义不大。马化腾不置可否，但没有勉强他。

2010年3Q大战发生时，汤道生还没进入总办，他在一旁看着每个人都像被什么巨大的着了火的东西砸中了，而整个过程中他“完全能感受到Pony是所有总办里最焦虑、最敏感的”。像游戏里切换视角，他忽然能够理解，过度反应源自责任带来的恐惧。

马化腾曾有这样一句话来表达危机感，“巨人倒下的时候，身体还是温的”。3Q大战已经过去8年，腾讯仍然视安全为命脉，“虽然巨大的投入之下看不到它能变现，但要有一个很强的团队去保护我们，它就像腾讯的‘国防工程’那样重要”——如果是你要为四万人的职业梦想与生计负责，所有人随时都会问你“接下来有何打算”时，这种反应过度就没那么令人费解了。

采访中，在腾讯超过十年的员工几乎都主动提起了3Q大战。也许是因为，人们再一次被巨大的着了火的东西砸中了。有一位腾讯高管说，他看着马化腾这一年，虽然“没有特别的语言”，但顶着这么多事，这么大的压力，“还依然在水里”。

回想时汤道生才发现，这是近期他和马化腾唯一一次单独吃饭。

演习了几个昼夜，但从进门的一刻起，马化腾根本没给他开口的机会，“他不断跟我讲新的事儿应该怎么做……我看他是很兴奋、很激动，对新的TO B、TO G有很多想法。”汤道生感到意外。

像不少接近马化腾的高管所认为的，马化腾是特别灵敏的人，照顾他人感受几乎是他的本能。

他从来不是一个自负的管理者。不是那种疯子式的天才——他不赞成甚至明确地反感“传奇叙事”，尽量回避接受采访，能做事就不想说话，公司文化也是“反drama”的。采访中，人们谈起腾讯风格和这位创始人性格时经常使用同一个词：淡淡的。

很少有人见到马化腾沉浸自我的时刻。那是一次有点儿魔力的午餐。汤道生自始至终没有提他的演习。他只是听着，听着，甚至有点儿开心——朋友式的。而马化腾饭也顾不上吃，“就不停地跟你讲，应该怎么做，应该和哪些部门合力……”汤道生说，那个画面也给了他信心：“他真对那件事是很在意的”。

这一切都在说，马化腾已经准备好了，以改革的方式带领伙伴们去新的战场。他希望汤道生也准备好了。

就在那一刻，汤道生觉得原本想说的话已经没必要再说。

他准备好了。

△ 汤道生在腾讯新成立的CSIG 2018年度员工大会上。

改革历程

改革的部队继续向前推进。想来有些矛盾，腾讯没有一个强势的主宰人物——一位腾讯高管回忆和马化腾共事十余年，即使在争得面红耳赤的时候，也没听马化腾说过一句，“听我的，就这么办”——但如此重大的改革却很顺利。也许是温和开放的氛围聚合了志趣相投的人，在总办形成了一种群策群力的文化。他们年纪相仿，大多四十多岁，从某些角度看上去，竟有着相似的纯真气息。

这种纯真气息，有时让“总办”们自己都觉得不可思议。

一次总办会议散会后，临出门，一位总办高管忽然问高级副总裁郭凯天：“我感觉咱们这么大的公司，在高管里没有政治斗争。是真的没有，还是我被排除到了政治斗争之外？”郭凯天愣住了，回家细想，越想越困惑，高管们会吵架，会为部门争夺资源，但从未在暗地里互相搞破坏。被这么一问，他也琢磨，“难道我也被排除在了斗争之外？”他思考良久，终于很高兴地确认：应该真没有。

香港会议后，总办成员带着共识返回深圳，第二天，40个副总裁参与的扩大会议已经组织起来。目标非常明确：围绕TO B业务，调整公司管理。

“我先问大家一个问题。”腾讯集团总裁刘炽平开门见山，“觉得云的业务对公司未来发展非常重要，公司一定要去做的，请举手。”

40只手全部举了起来。

“好，你们说的，这都是你们说的，你们支持的。”刘炽平笑了。刘炽平在公司有着“超人”的名声，脸上总挂着一种亲和的微笑。在这家以务实平淡文化著称的公司里，他通常是最有激情，最带动氛围的那个人。

会议往后进行，副总裁们才明白过来为什么刘炽平设计了这么一个表态环节：这是一个“缴枪”大会。

“这个事他也搞得比较戏剧性，”一位在现场的高管笑着说，预料到“缴枪”可能遭遇到抵抗，来这么个环节，就是要告诉众人没有讨价还价的空间。“该从哪个部门收走，合到云（CSIG事业群），都不要讲条件。”

“公司的挑战是什么”“为什么会产生这个问题”“怎么改善”……问题抛向了副总裁们。9月20日、21日，在“战略管理大会”，问题又抛给了腾讯的几百位中层干部。

中干们挨个发言后，总办点评：不够尖锐、不够尖锐、不够尖锐。会议氛围越来越激烈。有人开始挑战马化腾。一位员工说，“Pony（马化腾），整天在外面站台，为什么不多点时间在公司内部?”

“时间我自己管理。不用你担心。”马化腾反驳。他的时间管理可能是腾讯公司最大的谜团之一。

过去几年，他给TO B和TO G业务不断站台，一天辗转多个城市，与各地官员、合作伙伴会面（具有产品经理气质的马化腾，过去是不爱露脸甚至容易脸红的人）。新产品他也关注，产品经理会收到他关于字号大小之类的反馈；公司推出《如懿传》后，他竟看完了，完了还给高管们推荐，分享自己的领悟。

马化腾“电话、短信、微信，任何界面，全部及时回复”，总办成员都很困惑，他通常在夜里12点后下班，但员工经常在夜里两三点收到他的邮件；每周末他都去爬山，出差就在城市周边爬。“一看他朋友圈两万多步数，就知道肯定又去爬山了。”

全面TO B后，连效率超人的时间管理也遇到了挑战。一位中干甚至严肃地建议设立一个机制，解决处处都期待马化腾站台的问题。

一个月来，马化腾和总办成员花了更多时间开会和动员。

腾讯开始启动公司史上第三次架构调整。这是历次改革以来，动作最大、最艰难的一次。

9月29日，马化腾、刘炽平等总办们，加了一晚上的班，准备了员工公开信、新闻稿。等到写完已是日出时间。

9月30日6点14分，腾讯正式对外公布了架构调整的消息。6点40分，一封署名“Pony、Martin &全体总办”的邮件送达4万员工的邮箱。七大事业群调整为六大，新成立云与智慧产业事业群（CSIG）、平台与内容事业群（PCG）的同时，腾讯还成立技术委员会，打造具有腾讯特色的技术中台。

CSIG亮相了，现在全世界都知道了腾讯TO B 的决心。但一个广为流传的观点是：作为一家成功的TO C 公司，腾讯没有TO B基因。

△ 2018年底，深圳腾讯员工大会，刘炽平上台讲话。摄影 | 吴家翔

腾讯想通了

“跟基因没有关系。”马化腾不掩饰对那个广为流传观点的不屑。

恰恰相反，他相信腾讯在TO B上有先天优势。“有些工作不难，就像施工队，谁都能施工，质量也不会差到哪去，但问题是：施工完有人用吗？做出来的东西跟消费者是不是连接？而我们能连接好用户。我有很多用户群跟你合作来连接，有巨大的优势。”

早在2013年底，马化腾就提出互联网+的概念。他去国家发改委演讲，向主任、各司局局长、处长将近600人，讲用互联网去“+”传统的各行各业。两场重要演讲之后，这个概念流行开来。

2015年两会前，马化腾受邀向政府智库提交了“互联网+”的意见。这个概念被写入了政府工作报告。那正是互联网+如日中天的时候，互联网+打车颠覆出行，互联网外卖改写餐饮，互联网支付入侵金融……一时间互联网人都在说赋能、颠覆，仿佛新的大革命已然来临，正大刀阔斧重组人类社会的命运。

腾讯业务团队很快听到相反的声音。互联网当主角，传统行业不服气，说“我+你还差不多” 。他们的忧虑在于，一旦开门欢迎互联网，下场会不会是把自个儿颠覆了。

行至深水区，“+”的对象变成了那些有着高高壁垒的行业——教育、医疗、能源、制造业……前方团队突然发现“+”不了了，许多产业的核心技术互联网公司不懂，人家也不可能把自己的命脉交到别人手上。

僵局之中，马化腾捕捉到一个奇特的变化信号。2016年两会期间，他去拜访链家CEO左晖，了解到了全新的故事样本：一个线下传统中介机构不仅没有被互联网企业入侵、颠覆，还倒攻线上，成功逆袭，“最终成了老大”。

这次拜访给马化腾带来了很多启发，他渐渐想通了，面对更为复杂的产业格局，腾讯应该把自己定位为助手，给产业补充能力。

刘炽平也在上海分公司的恳谈会上反思，过去一整年几乎所有科技公司都在被社会舆论挑战，要怪就怪“颠覆”，“颠覆了很多行业，让很多人没饭吃了”，这既不对，也不是腾讯真正的机会，不管在医疗、教育、汽车、工业、零售上，腾讯的机会恰恰在颠覆的反面——“把技术分享出来，让所有伙伴参与”，“好的科技公司要为科技平民化做更多贡献”。

一旦转变思路，马化腾发现机会四处涌动。过去各行各业警惕着互联网巨头，而今也“逐渐想通”，医疗、制造、汽车、旅行、零售……纷纷敞开大门：让互联网企业进来，但自己仍是主角，借助互联网工具，期待重新崛起。

随着局面打开，腾讯将战略从互联网+逐步升级到“产业互联网”。如今复盘，马化腾想起了改革开放的历程，摸着石头过河，“很多东西是倒逼的”。

腾讯智慧零售部门的成立，就是需求倒逼的一个结果。

2017年11月，中国最大的超市品牌大润发被阿里收购。“战胜了所有对手，却输给了时代”——大润发创始人离开时的悲伤情绪迅速在业界传染开来——龙头已被降伏，其他企业命运将会如何？

面对强势渠道，品牌商们期待一个解决方案，于是纷纷找到腾讯，喊救命、要投资。

其中的代表是万达。王健林犹豫了很久，最终选择了腾讯。

令王健林意外的是，腾讯在合作条件中，没有要求万达排除其他支付工具。腾讯的解释是，一切为了用户，把选择权交到用户手上。

但另一方面，腾讯也意识到，品牌商、商场，是它不能丢失的支付场景。有资深的观察者甚至认为，当时马化腾若再不落子，可能满盘皆输。

腾讯迅速招兵买马，成立零售部门，回应了万达，跟京东、苏宁、融创一起入股万达，做数字化升级。

新建立的智慧零售部门设了5个头部标杆应用，优衣库、百丽鞋业、都市丽人、海澜之家、绫致，为零售业探索智慧解决方案。

△ 摄影 | 吴家翔

全赛道绿灯

薄硕桐是零售部门最早三个员工之一，从微信战略部门加入到真正的地面战场，他终于体会到战火之猛烈，非得一周工作上百小时，才能勉力应对。深入超市，争抢客户，必要时还得肉搏，但他没想到，战火持续蔓延，竟烧到了内部战场——“一个零售业老板要见（腾讯）七波人，七波人对外互相竞价，规则不统一。内部竞争的结果是，这个零售老板反而可以渔翁得利。”

马化腾断断续续听到反馈，“他们觉得很累”。之所以累，是因为，业务需要调用大量技术能力，比如安全、人脸识别、小程序、企业微信、地图等等，它们分散在各个事业群，而各部门各有利益、各有难处，协调起来难度不小。

应该力出一孔，而不是各自为战。智慧零售的战争，最终成了腾讯“总办”们下定决心作架构调整的契机。

2018年10月，产业相关部门无条件并入CSIG，内部全赛道绿灯。合并同类项带来秩序。马化腾喜欢新格局，“原来（分散时）我想打屁股都不知道打谁，现在清楚了”。

“拥抱产业互联网”的醒目标识即刻出现在年会表演、滨海大厦电梯间广告和几乎每一次公开活动中。拥抱是真金白银的。2019年1月9日，腾讯云在“微信公开课”上发布10亿元扶持计划，帮助100万个中小微企业开发小程序，快速上云。有媒体评论，这是“一个自己为自己制造机会的漂亮动作”，“强化了腾讯的赛道优势”。

即刻提速的还有新上任的CSIG总裁汤道生的时间表，“开好多会，见好多人，比以前差不多多三倍”。他在与传统产业老板们洽谈合作时，谦逊到了让人不好意思的地步，希望消除他们对互联网巨头的刻板印象，“我说我是来抱在座各位的大腿的”。

两个月来，马化腾感觉效率提高了，但依然赶不上业务需求增长的速度，“连内衣企业都找来了” 。他笑了起来，“机会超多，就是发愁我们的人接不下来。能接的话，我天天去找单，甩下去”。

在腾讯总办们关于未来C TO B的设想里，不仅CSIG，微信也是产业互联网版图里的重要一块——由CSIG对接产业需求，平台提供支持。

“做TO B的时候，你还要发挥腾讯的C端优势与‘连接一切’的能力，这是最大的法宝和最大的吸引力。”谈起未来马化腾很兴奋，即使还有许多难题要克服，还有很多组织架构手术要进行，但正如他说的，“打完仗再说”，毕竟战争的号角早已吹响了。

△ 2018年腾讯员工大会摄影 | 吴家翔

渐次清晰的版图

工号117的老将陈广域听到了清晰的号角声。他2007年就做了总经理，行政、游戏、渠道、基建都干过，是唯一一个从业务线去到职能线，又返回业务一线的中干。但这些事都是他挑的，如今，TO B的仗也是他要去打的。“最后都是要老去的”，工作第17年，陈广域高兴还有新的仗可打。

陈广域有一种非常坦率明快的风格，底气是老练。所有抛向他的问题都像是直接掉进了他的口袋。他是TO B战场的战将，早于集团两年进入战场。

2015年，他看到“老板在外面辛苦”，但没有团队对TO B的事情全面负责，觉得自己“应该去搞互联网+”。“Pony很希望有这么一个部门，我们又愿意跳出来承担一些有挑战但是未来不确定的事情，公司当然很高兴。”两周后，“互联网+”部门成立了。陈广域带领一百多位员工开进TO B正面战场，战场广阔，他选择的方向是医疗。

几年后，先驱部队腾讯医疗的版图已然成型，陈广域是最知道它是如何从零开辟、一小块一小块铺就的，从“电子社保卡”起步，像推土机一般，在全国60个城市打通了电子支付和社保系统，实现在微信上挂号、缴费、社保报销，使腾讯能力在医疗上落地生根。

随着战事演进、时间推移，产业互联网的声量愈发强大，云计算、人工智能、大数据渗透到方方面面，互联网公司激烈角逐，火光四起，腾讯大厦里更多人坐不住了，跃跃欲试地加入了TO B新战场。

智慧零售部门在2017年末才刚成立，可以看到海景的办公室却总空空荡荡，总经理田江雪的前驱部队奔赴全国各地：香奈儿柜台上，女队员不停把香水往自己身上喷，设法找到让人在线下为香水买单的诀窍；在东莞，那支主要由男同事组成的队伍，连续数月蹲守在“都市丽人”内衣连锁店里，揣摩内衣穿搭。在一些运营群里，他们既要当管理员，又要扮演顾客，推广“明日特价小黄鱼”。新出现的岗位还包括“大妈鼓励师”，主妇们被鼓励着买菜、翻着花样做菜、再分享菜。

事情是琐碎的，战略却是宏大的：提供大场景、大数据、AI技术支持，依靠腾讯全产品线，量身定做解决方案，实现线下门店的数据化、智能化。微信公众号、微信支付、小程序、腾讯云等七大工具整合起来，为零售商升级换代。

其他战线也纷纷开辟，在政府合作上，腾讯云渗入城市服务的方方面面；在安全方面，程序员们从“保安”转型成“保镖”，七大实验室将自我守卫能力拓展到了各行各业……

从2018年9月30日开始架构调整，至2019年3月初，已历150余天。腾讯的产业互联网版图渐次清晰：构成了支持各网络公司云端计算的泛互联网板块，支持实体企业效率提升与数字化的泛企业板块，支持政府的信息化与数字化的泛政府板块。

多年来，这家科技公司容纳了也许是中国最多的宅男程序员，他们多数不擅社交，不喜欢面对人群，在虚拟世界感到自由快乐。

而这次改革却把他们一次性丢进了真实世界——去超市收银台、内衣店、社区门诊楼、地方政府办公室、工厂流水线，腾讯高管们称这场转型为“空军落地”。

150天的地面战，日日夜夜，感觉如何？步行、负重、在泥巴里滚，跟对手肉搏，至少在一开始，每个人遭遇了重重困难。

困难比想象的大十倍不止

对地面战场，马化腾对“拥抱产业互联网”有一番低调务实的表达：做各行各业的“数字化助手”。这个“助手”，是通过腾讯的技术能力与连接能力，帮助各行业提升效率、降低成本。

但实战中，无论哪条战线，都会看到人们因为不适应而步履艰难。从“用户至上”到“客户至上”，从“产品思维”到“服务至上”，从“分兵”到“合击”，这种蜕变事实上非常痛苦。

政府合作战线的困难超出了“数字广东”项目负责人刘若潇的想象。他穿着剪裁合体的浅色衬衫和深色西裤，看起来更像是一名有行政级别的国企干部而非腾讯云的副总裁。这么塑造自己的外在形象，严格来说，也是他工作的一部分。

“数字广东”是2018年度腾讯的“1号工程”，配合广东省政府利用互联网技术改革政府治理。“实际困难比之前想象的大十倍不止。”刘若潇感叹。他每天工作14个小时，全年几乎无休，靠喝功能饮料提神，夜里常常失眠，“这辈子就没这么累过”。员工更是如此，一个孩子写信给爸爸，“（爸爸）为什么不需要睡觉吃饭”。

一家互联网公司深度卷入政府改革是史无前例的。省长不光自己来腾讯考察了3遍，30天接待80位市长级别官员的感受谁干谁知道。互联网公司强调快速迭代，要求效率。而政府则很在意政策的稳妥。刘若潇理解政府也很矛盾，“他又希望互联网公司的活力带来动力，但是确实看着我们这些做法，实在心里毛毛的”。

“大家被批评惨了。”刘若潇说起了不少沟通误区。他们需要重新学习，甚至自发上起了夜校，第一课叫“如何与政府沟通”，从称呼改起：“同学”变成了“同志”。

刘若潇迎来的第一个改革任务是“粤省事”小程序的上线。上线时间死死定在5月21日0点。这个小程序的目标繁杂远大：要用最清晰的流程、最方便的操作、最少的证件要求，把人们最常办理的一百多个政务事项全部实现。

马化腾每两周参与一次讨论，光是字号就提了5次意见。

在安全战线，痛苦是更加肉眼可见的。半年过去，桌面安全产品部负责人方斌才刚刚认识客户，“会很慌”，客户听他讲完安全形势有多么严峻，总是反问，“那又怎样呢？”——2018年初方斌曾认为“都不用干就能躺着完成KPI”，团队凭借手游模拟器技术，拿下了“吃鸡”游戏十分之一用户，结果先是版号政策，用户无法变现，地面战争启动后，游戏部分干脆从团队剥离了——如今他要帮客户一一去分析它们被黑客盗取的数据（比如大量妇幼医院产检母亲的数据，国内多数连锁酒店很全的开房数据），以证明安全问题不是想象、编造的。

方法笨拙，收效甚微。“过程来来回回，相当、相当的痛苦。团队的角色也一下多了很多，前端的BD、销售、售前、交付、售后……”方斌的焦虑程度到达了十四年来的峰值。“突然找不到方向，找不到目标，找不到你的客户了。”方斌说，“真的很撕裂。”

除此之外，还有一些隐形痛苦是由不理解带来的。智慧零售部门总经理田江雪给人一种很柔和、知性的印象，说话温声细语，思索时拧起眉心。她没有化妆，头发也随意地扎起，在自己办公室的停留显得很临时——实际上也是，一年大概有300天，她四处奔波，早晚身处不同的城市，每天见一个零售企业老板。

有的零售商对腾讯能力的想象远离实际，比如要求在微信上单开一个入口，比如说能不能把微信开机页面的地球换成一个月饼。田江雪得一一耐心解释。

而投身漫长医疗战线的郑冶枫博士相信，组织的决心是最重要的。他有一双科学家的干净、专注的眼睛。连续3个月，他在美国搜索马化腾的新闻，“他每次对外讲话我都有研究”，腾讯得到科技部认证让他稍感放心，“变成国家队，那不能说今天做明天不做了吧”，最终决定前，又与汤道生视频谈了45分钟。这位前西门子医学影像AI科学家在美国生活了17年，他遥遥观望，像猫鼬一样小心，反复确认一家中国互联网公司在医疗上的决心。

然而决心是一回事，环境是另一回事。2018年初，郑冶枫离开家人，独自回国加入腾讯优图实验室，带领一支13人的核心算法团队，负责训练AI识别癌症影像。可首先让他吃惊的是国内医院的信息化孤岛程度。合作的三甲医院科室间传图像，“需要派个学生拿U盘物理地拷来拷去”。训练AI认识一种癌症至少需要四五千份标注图像。每份图像两到三个医生一起标，“每个人理解不一样，你从哪个医学院毕业的，不同医生标出来的差距比较大”。

方差过大，机器没法学。“一会儿告诉机器是A，下一个同样图像又告诉它是B……机器就乱掉了。”训练崩溃。AI学坏了。

郑冶枫要去解决这些他没预料到的难题。

△ “云上科技共建数字广东”启动仪式。

冠军之心

尽管困难重重，各条战线的队员在不懈地推进、探路，慢慢培养着对新业务的感觉，各自摸索出打法、探出路径来。

在安全战线，方斌一直在寻求突破口。后来，万豪酒店用户信息泄露事件引起业界震动，大企业的危机提示了方斌，他带领团队专攻企业信息安全产品，针对云场景设计安全服务。

团队将目标聚焦到构建整个行业的安全态势上。站得更高、视野更大地做产品。他们推出了“安脉”，一个三甲医院安全排名产品，实时更新医院数据安全指数。在手机上，客户就可以清晰看到主机被恶意攻击多少次，数据是否已在暗网上泄露等。

方斌专门预订了楼里最大的会议室，庆祝他们拿到第一个“大单”——虽然在过去“躺赢”时代是可以抹掉的零头——振奋人心的100万。他给大家发现金，把调门抬得高高的， “我们迈出了很坚实的一步”，同时也纾解了自己的情绪。得了奖金的同事上台讲心路历程，“都憋着很大的一股劲儿”。信心重新回到了方斌的团队。只要局面打开，他们引以为傲的看家本领迅速向B端延伸。

如今大家都意识到了，TO B是一场漫长而煎熬的战争，决定成败的因素很多，信念必不可少。

陈广域毫不讳言，“我们是典型有梦想的人”。他总是跟团队说，“我们做的事情不是挣快钱，我们干的是这个行业的最基础、最有长远价值的事。”

可是信念不会凭空冒出来，也不会仅仅因为一番鼓劲就自然生长。

陈广域记得，2018年7月医疗健康事业部成立不久，他带队向刘炽平作第一次汇报，本以为业务太复杂、太专业，可能得先跟老板做做“知识普及”。但没想到，刘炽平对智慧医疗的关键点了如指掌，一个小时里给了他不少启发。

Martin（刘炽平）怎么这么懂？陈广域有些迷惑，后来才想明白，“互联网+”战略执行了这么多年，刘炽平带着团队全方面扫描医疗行业，前后投资了丁香园、微医、卓健科技等一批独角兽，当中的门槛、风险，当然还有巨大的机遇，全都摸过一遍，刘炽平对此有理解、有信心，自然明白医疗和健康事业巨大的公共和商业价值。

汇报之后的一个多月，刘炽平甚至协调，拉来微信的核心资源支持医疗团队，陈广域形容自己感到“狂喜”，有了这一层支持，团队就有了更强大的信念。

“一刻不停地做选择”，陈广域处在明显的战时兴奋中，他教育团队，要时刻记得，自己是腾讯人，要有战略眼光。到了没人摘过的田野，先捡西瓜，再捡苹果，不要事情做完“发现它只是一个枣”。

他判断医疗AI是个冠军瓜。腾讯有人工智能算法，有技术，有数据，还有微信场景，做医疗AI志在必得。这个战略的第一个果实是在2017年8月发布的“腾讯觅影”，一款可以提升癌症早期筛查精准度的AI医学影像产品。以食管癌筛查为例，觅影最多花上4秒，就能做出判断，准确率达到90%。

马化腾在朋友圈转发了“觅影”发布的消息，评论：一小步，有希望。3个月后，腾讯入选科技部首批国家人工智能开放创新平台名单，“觅影”不仅跑出赛道，还把腾讯带入了“国家队”。

对信念的坚持也给郑冶枫带来了好消息。一个月前他在公司附近社区医院留了一台AI眼底相机。他花半小时培训了社区年轻人：按按钮，自动对焦，扫描眼睛图像上传云端。一个月过去，AI从社区100名糖尿病患者中筛查出25名左右有眼底并发症。这是郑冶枫从美国回来一年来最兴奋的时刻：“我们的AI，达到顶尖医生的水平，落地到基层（帮助患者）。”

陈广域的新老板汤道生对医疗超级上心，问题细如蛛丝，他问的越细，陈广域就越开心，他暗搓搓地希望一遍遍答下来，能“把老板培养成我们一样的人”——这样，打起仗来上下一致。他语速极快，不由人打断。“你知道，有两类人不怕死，”他说，“年轻人不怕死，他们是初生牛犊；第二个，老人家不怕死，是因为没有名利的负担。”

对公司而言，“这（医疗TO B）是一个长期的战争”。对不怕死的老人家陈广域而言，这个仗打完后他就“不遗憾了”。

△ 腾讯滨海大厦。

地面战的感觉

在政府合作战线上，刘若潇和同事打着争分夺秒的仗。他们夜以继日地加班。

0点，“粤省事”准时上线，系统瞬间崩溃。项目经理腿软了。8小时后是政府新闻发布会。他们把人挨个从被窝里拖出来。抢修持续到天亮。总算有惊无险地通过了。

一年下来，数字广东实施项目超过30个。“今年总算扛过来了。”刘若潇露出一个有些疲惫的微笑。“数字广东”最终成了一个典范，得到的评价是，“支撑起了广东省今年数字政府改革”

他提到广东省政府门口那座写着“为人民服务”大字的照壁。如果粤省事这样的小程序真的利民惠民，“那我们也确实为人民服务了，我们在这份工作中找到了意义感”。

反诈骗实验室是接入政府服务中特色的一环，随着合作深入，李旭阳也体会到前所未有的快乐：一种除暴安良的成就感。他们现在更多精力花在解决社会问题上，李旭阳说，“先看看社会问题哪个比较严重，筛选出来，匹配我们的能力，找相应监管单位推。我们就是帮国家做一个雷达。”看似跟机器打交道，实际上是与十万黑产过招。追击之下，黑产者四处逃窜。

最初想给他的安全神兽们起名“复仇者联盟”。联盟不断壮大，包括“鹰眼”反电话诈骗系统、“麒麟”伪基站实时定位系统、“神荼”反钓鱼系统、“神侦”资金流查控系统，还有“神羊”“灵鲲”“神鸮”。

他们将算法模型布到运营商和相关部门机房里，希望通过预测犯罪阻止犯罪发生。“鹰眼”部署在北京公安后诈骗经济损失环比两年前降低了67.7%，微信支付接入反诈骗实验室后，色情支付成功率干脆变成了0。

随着“数字广东”成为标杆，“反诈骗”等服务的展开，政府合作业务不断深入，汇聚于“云”。这是腾讯云战略最为重要的板块之一，也是巨头公司竞争最为激烈的战场，考量着一家公司自上而下的决心。

这几年公共事务部总经理沈丹常陪马化腾开拓政府业务。马化腾的时间表十分紧凑，“有的都不歇一晚，当天飞到、沟通、签约，或者再有一个晚宴，然后接着赶路”。沈丹也不愿老板如此密集“站台”，2018年下半年，她有意识地保护马化腾的时间。虽然她承认，很多时候老板不仅仅是“出现”，很多眼看着丢了机会的时刻，“马总亲自带队汇报”，紧要关头翻盘、逆转。“他真的会去抓住任何有可能的机会。”沈丹说。

智慧零售战场上，田江雪渐渐生出了一种直觉，“其实我们是责无旁贷的。”这同时也增长了她的信念。她一直在寻找互联网如何让社会更美好的答案。这也许解释了她团队的热情。

有一次，为了争夺智慧零售的同一家服饰行业的服务商，薄硕桐和队友们与作风强悍的友军在走廊上正面相遇了。客户轮番进入双方房间谈判，拉锯了8个小时。

最终，那位客户要求跟公司高层对话。当时已经是晚上11点了，薄觉得不可能，“那家服务商在腾讯体量小到不能再小”。但立刻，副总裁Davis、集团总裁刘炽平都在电话那头了。“我看到了公司的决心。”薄硕桐说。他们赢得了那场谈判。

田江雪和她的队伍越来越了解“地面战的感觉”了。以前做TO C，产品出来就像空军扔炸弹，第一时间就有反馈，成败清晰。“TO B 却是小火慢慢炖。”她说。炖的过程漫长，要调节火候，加料、减料。心态上也要调到TO B的频道，“以别人的成功为成功”。

永辉超市率先收到了腾讯集结全公司能力定制的智慧解决方案包——以选址为例，不再凭经验，而是在腾讯云预测销量前提下科学布局。市场占有率前十的超市品牌5家变成了腾讯的盟友。

不只是智慧零售，各行各业的盟友越来越多。智慧业务与腾讯云融成一体。腾讯云开始在游戏类、电商类、资讯社交、交通出行等多个细分市场冲入第一。腾讯云总裁邱跃鹏对此的理解是：“产业互联网，是一个我们和合作伙伴、和客户一起打造的时代。”

田江雪相信“第一”的故事是这样来的：开头没人相信人类能在4分钟内跑完一英里，但当第一个跑进4分钟的人出现，接下来一年能有15个人同样做到。这是关于信念的故事。她认为腾讯这群人，就是在干这样的事。

尾声

新战场的故事仍在激烈地发生着。这些故事让人想起腾讯的一次团建，高管们一起徒步戈壁，一天走完痛苦不堪，26公里之后，有两位不肯走了，但马化腾和刘炽平非走完不可，还戏剧性地任命其中以风格率性著称的高管为纪律委员，最后所有人一起走到了终点。某种程度上，腾讯产业互联网的变革就像一次漫长的徒步，一旦达成共同信念，一切也就高速地运转起来。

多年以后，回想起2018年腾讯的危机与变革，故事也许会有不同版本。譬如外人掀开屋顶，好奇里面发生了什么，但有些内心感受只属于屋子里的人。比如那次午餐中，汤道生曾欲言又止；比如，香港会议中，马化腾苦思突围：“苦不是人怕的东西，人只怕没事儿干。你也许败，你也许胜，但是你总有一个地方可以去争取。要有战场，要有能胜利的地方。”

END

点击图片阅读更多硬核故事

「樹莓派」的故事：一款35美元的電腦是如何改變世界的？

Sat, 09 Feb 2019 15:30:00 CST

這是一個見證「Nothing is Impossible」或者「Impossible is Nothing」的故事。受困於申請學電腦的人數日益減少，劍橋大學教學主管Eben Upton決心用一種激發自己兒時學習編寫程式興趣的小玩意兒重新點燃下一代對電腦的好奇心。為此，這個東西必須能植入到各種常見的東西裡面，並且價格要足夠的親民。BBC的報導引發了大量的公眾關注，騎虎難下的他們從此開始了一段唐吉訶德式的努力。儘管遇到了種種複雜挑戰，但Upton和他的樹莓派基金會團隊最終還是克服了困難，讓這種信用卡大小的單板電腦成為全球第三大暢銷的電腦。在被問到樹莓派能成功的原因時，Upton說，也許正是無知者無畏讓我們做成了一件不可能的事。

那天早上想要集中精神的感覺簡直就像被上絞刑一樣。

Eben Upton說的是2011年5月，當他與人聯合開發的35美元樹莓派開發板在網上被披露後，自己肩上感受到的公眾期望的份量。

經過5年相對隱匿的情況下折騰這塊板的設計後，突然之間意識到這個項目存在的人數出現了爆發式增長，僅僅2天之內早期樹莓派的影片瀏覽量就達到了60萬。

一開始Upton對BBC技術通訊記者Rory Cellan-Jones報導引起的興趣感到很高興，並且跟妻子Liz描述了一番，後者用嚴酷的現實給他的熱情澆了一通冷水：

她對我說，「你知道現在你得完成這件事了，對吧？」

那是個艱難時刻，意識到我們其實已經告訴大家我們正在做這件事了，我們已經騎虎難下。如果不是為了Rory的話，我們本來可以就這麼玩玩的。

今天，樹莓派已經變成一種現象，是全球第三大暢銷的通用電腦。如果你對電腦感興趣的話，很有可能你已經上手了一塊這種英國製造的板子插在什麼地方。它已經植入到筆記型電腦、平板電腦和機器人裡面；它已經跑到國際太空站上做實驗；它甚至進入到主流媒體，在《機器人先生》這樣的電視節目以及《超能陸戰隊》這樣的電影裡面亮相。我們還沒有提到它在商業當中扮演的角色，從精簡客戶端到工控系統，樹莓派幾乎無所不能。

但是這種成功絕不是打了包票的。樹莓派從某種唐吉訶德式的努力開始，旨在一代人沉浸於技術但對其機制卻毫不關心的氛圍下重新點燃對計算的好奇心。對於Upton來說，這顆種子在2006年已經種下，那時候他是英國劍橋大學的一名教學主管，正在為申請學電腦科學的人數至少感到撓頭。

數字太糟糕了，簡直是一落千丈。世紀之交的適合我們從80、90個地方有600個申請降到了只有250個人。

面對著這麼不感興趣的情況，Upton不禁發問「那些申請者都去哪兒了？」以及「怎麼才能把他們爭取回來？」

▲ Eben Upton，照片攝於2016年女王壽辰授勳儀式上被封為爵士（CBE）之後。圖片：樹莓派基金會

他說：「我們當時沒有意識到，1980年代方便編寫程式的家用電腦成為了我們的一個非常重要的人才來源。」

「隨著那些機器在1990年代消失，可以借此學習編寫程式的孩子也沒了，然後10年後我們醒來才發現沒人申請我們的課程了。」

「所以其實樹莓派是對此的回應。這是一次非常刻意的嘗試，目的是想重啟那種我小時候就有的機器。」

Upton跟他的同齡人成長於1980年代，那時候像英國BBC Micro和美國Commodore 64這樣的電腦正在設法進入家庭。對於普通的現代電腦使用者來說，BBC Micro似乎很嚇人：一台棕色的厚板機器啟動後即只有一個閃爍的光標，上面沒有任何解釋下一步要幹什麼。

但對於Upton和許多1980年代的孩子來說，那個出現在幾乎空白螢幕上的閃爍光標就是一次讓他們填補空白的邀請，邀請他們輸入BASIC編寫程式語言，讓BBC Micro用聲音和顏色變得鮮活起來。

不過，時間快進20年，在市場占主導地位的電腦——遊戲機和後來的平板電腦和智慧型手機——不再邀請他們去創造，而是慫恿他們消費。

Upton記得，2007年，在一次篝火晚會上，有一位11歲的男孩告訴他自己想當一位電子工程師，但是他卻失望地發現，當時已經沒有可供這位孩子上手編寫程式的電腦。

「我說，『哦？你用的是什麼電腦啊？』他說，『我有一部任天堂Wii』。這讓我感覺很尷尬，這個孩子是那麼的興奮，對我們的職業表現出了那麼濃厚的興趣，但卻沒有一台可以編寫程式的電腦，任何形式的電腦都沒有。他只是有一台遊戲機。」

那時候Upton正在Broadcom當晶片設計師，設計一種晶片系統架構，他意識到自己有阻止這種不鼓勵使用者編碼電腦的趨勢所需的技能。

他說：「作為愛好我開發小電腦已經有很長一段時間了。所以，開發小電腦的能力，再加上意識到小電腦的匱乏是個問題，樹莓派其實是這兩樣東西碰撞出來的火花。」

為什麼樹莓派只需要35美元

其想法是創造一台不僅便宜，而且幾乎可以隨便處置的電腦，價格低到孩子不怕帶在身上或者將它跟其他硬體連在一起去開發自己的電子產品。

Upton說：「要做一台可以隨便破壞的電腦，這個想法對我們來說很重要。」

「價格應該低到給它連接線纜的時候你不會覺得會有毀滅世界的風險。」

但是價格定得那麼低會帶來挑戰。在2000年代中期，35美元的電腦其實並不存在，Upton剛開始做出來的東西跟最後樹莓派的樣子幾乎一點都不像。

2006年他首次嘗試的樹莓派相對於6年後發布的開發板來說實在是太簡單了，以至於只用手就可以組裝起來，用的是現成晶片和零組件，還有一塊烙鐵。

處理器和電阻過大的原型看起來就像是過去時代的遺蹟——從某種程度上來說，這是在複製1980年代Upton剛懂事時推出來的BBC Micro的能力。

▲ 第一代樹莓派原型，由Eben Upton在2006年手工製作出來的，這個東西跟2012年推出的電腦有很大的不同。圖片：樹莓派基金會

「我做的第一個你可以叫做樹莓派的東西是在Atmel微控製器的基礎上開發的，它可以算繪一點3D圖形；其能力大概跟BBC Micro相當，但是你自己用一塊烙鐵就能做了。它的好處就在這裡，後來的樹莓派都沒法做到這一點。」

Upton並沒有往這條設計道路走下去，因為覺得不夠強大，可用性也不好。不過他並沒有失去設法重新點燃對電腦科學興趣的動力，繼續跟工程師同事和學者討論解決方案。2008年整件事情到達了一個關鍵點，Upton跟劍橋大學教授Alan Mycroft、電子工程師Pete Lomas以及好幾個人一起坐了下來，開始構思為孩子們量身定做的廉價電腦的藍圖。

Lomas是電子設計諮詢機構Norcott Technologies的創始人，他設計了第一代樹莓派的印刷電路板（PCB）。他把10月份那次會議形容為樹莓派誕生的決定性時刻。

Lomas說：「我們很多人都有類似的想法。只是需要那場會議作為讓此事發生的催化劑。」

他說，他們的願景是製造這麼一台機器，可以提供一個窗口，讓使用者窺探電腦是如何工作的——不是一個封得嚴嚴實實的黑箱，它就是一塊開發板，孩子們可以學習每一個零組件，能夠在它工作的適合感受到處理器變熱，並且鑽研板塊運行的開源軟體的程式碼。

樹莓派的名字由來

2008年我們將見證Upton創造的原型機第一次被叫做了樹莓派。

儘管這第二個原型要比第一個手工製作的更強大，但是2008年的這台機器還不是像樹莓派那樣成熟的電腦，只是跑在Broadcom的圖形處理單元（GPU）和向量處理單元（VPU）上——這些晶片同樣是更大的電腦系統的一部分，Upton稱之為「在Broadcom開發板基礎上拼湊起來的東西。」

再次地，那個原型令人想起了Upton成長時一直在用的BBC Micro。儘管比1980年代的那台機器強大了很多，這台原型機也是直接啟動到閃爍光標，只不過這次跑的是Python程式碼。

Upton說：「就像BBC Micro啟動進入到BASIC一樣，這個啟動後進入的是某個版本的Python。」他說機器取名叫Pi（派）就是這麼來的。

至於樹莓這個詞，一方面是他很想學學蘋果、Apricot Computers以及Acorn（晶片製造商Arm與BBC Micro製造商的前身）的水果傳統，同時也是半開玩笑地點一下當時項目玩票的性質。

Upton說：「有很多以水果名字命名的公司，而且『blowing a raspberry』這樣的東西也是故意的。（放屁的意思， raspberry tart（樹莓餡餅）跟fart（屁）諧音）」

次年初，Upton、Lomas、Mycroft、Elite創造者David Braben以及劍橋大學講師Jack Lang和Rob Mullins創辦了Raspberry Pi Foundation（樹莓派基金會），這是一個專注於向全世界傳授創建電腦軟體與硬體所需知識和工具的慈善組織。

▲ 2012年一場董事會上的受託人：從左到右：財務總監Martin Cartwright，教授Alan Mycroft，Pete Lomas，David Braben，Eben Upton與Jack Lang。還有一位同樣在圖右的是Alex Bradbury，當時是基金會的首席Linux開發者。圖片：樹莓派基金會

不過即便名字和基金會都已經就位了，但電腦的設計卻開始難產了。這麼低的價格Upton和Lomas沒法找到合適需求的處理器，而且設計樹莓派還遇到了各種障礙。

Lomas說：「2009年我們想圍繞著另一款處理器進行重新設計。但是由於沒法做下去而導致大家意志消沉。」

「零組件太多了，PCB又太大，消耗電力過多，各種各樣的東西都出來問題。」

儘管如此，Lomas說大家都不願突破35美元的價格點。

他說：「當我們首次宣佈價格時，大家以為我們瘋了。我們也曾一度認為自己瘋了，但我們的動力是如果能夠實現的話，那就能吸引很多的孩子。」

與此同時，Upton要在Broadcom的全職工作，完成MBA學業，以及攻關樹莓派這些事情間輾轉騰挪。

他說：「2011年以前很多時候似乎這件事都做成不了，就因為我太忙了。我要做別的事情，這件事不是我的首要事項。」

直到2011年初情況仍進展緩慢，但此時一個機會擺在了Upton和Lomas面前，他的僱主Broadcom設計出來了一款低成本晶片，正好可以成為其人人買得起的電腦的完美基礎。

Upton和Lomas用了一個通常裝在電氣設備和數位標牌內部的處理器，然後把它當作了一台廉價電腦的平台。

這款新的晶片有望撐起一台堪比1990年代末高階機器的電腦——大概相當於300MHz的英特爾奔騰2。當然這不是那種好到讓人興奮的性能，但卻足以提供一台能用的35美元以下成本的機器。

關鍵是，這個基於ARM的Broadcom BCM2835片上系統可以讓樹莓派變得不僅僅只是玩具或者閹割版的電子產品。

Upton說：「這是一大突破，我們有了ARM處理器，ARM 11。」

「不用太多錢我們就有了一個ARM的處理器以及一個能力非常強的圖形處理核心。」

由於跑的是完整的基於Linux的作業系統，樹莓派可以啟動進入到一個窗口式的桌面，典型使用者會把它看成是一台電腦。

Lomas說：「你有一個完整的作業系統，然後你可以把所有免費的軟體開發工具納入其中，那些東西在Linux環境下已經做了好幾年了。」

Lomas說這讓他們有了勝利的感覺，「Broadcom製造的晶片有很多功能正是我們需要的。」Upton和Lomas的樹莓派現在有了必要的「大晶片」（比如記憶體和網路控製器）作為平台保障，更重要的是價格都是平民化的。然而，戰鬥還沒有結束，他們對低價的堅持仍將繼續給基金會帶來巨大壓力。

Upton說：「定價在25美元到35美元之間的依據是那些大的零組件的價格點，然後認為『剩下的不可能會太貴』。當然，這種想法是錯誤的。」

「我們的一大教訓是幹掉你的是那些小東西，而不會大東西。大量10美分左右的東西，而不是若干幾美元的東西會擴大設備的成本。」

▲ 樹莓派Alpha版開發板，2011年首次投產。圖片：樹莓派基金會

這還不算，Upton和Lomas很快馬上自己又給自己徒增了壓力。BBC對樹莓派拇指儲存器大小的原型的報導在2011年5月被人瘋傳——報導稱樹莓派將在1年內推出。

Upton說：「報導把我們的形象非常堅定地展示到了公眾面前，我們已經沒有退路，只能設法把它變成事實。」

「所以，2011年整個夏天和秋天我和Pete都待在一起，想方設法要把產品的成本降下來。比如們考慮哪些功能可以不要，找出實現某些功能更廉價的手段等。」

基金會面臨著一場硬仗。創始人們為基金會已經貸款了幾十萬美元，足以將樹莓派的產量從當初的3000提高到10000塊板左右。然而，在電子製造上著仍然是相對較低的量，而這會導致零組件成本的上升。

到了8月份，基金會有了一份樹莓派的參考設計，Broadcom給他們造出了50塊Alpha板。這種板跟5月份展示的拇指儲存器大小的原型很不一樣，支援了很多後來的樹莓派所具備的功能——比如幾個USB 2.0端口，100M的乙太網連接埠，microSD儲存卡讀卡器，HDMI，以及啟動後進入Linux Debian命令行方式。它甚至還能玩一點第一人稱設計遊戲《雷神之錘III》。問題是它在成本上離需要的低點還有不少距離，而且比他們想要的信用卡大小還稍微大了一點。

Lomas說道：「接下來的問題就是怎麼把這頭110美元的怪獸變成35美元的實用解決方案。」他和Upton從8月份到12月份都在琢磨著如何辦到這一點。

將110美元的怪獸變成樹莓派的戰鬥

這塊小板的每一個零組件都有自己的一席之地，Lomas回憶到在權衡每一個零組件的相對優點時不得不面臨十分艱難的抉擇。

舉個例子，比如他們曾遇到如何將樹莓派連上顯示器的問題。他們希望樹莓派品質要夠好，能跟新一點的電視和顯示器協同工作，後者一般都要求HDMI連接埠，但他們也希望舊的CRT顯示器也能用，而這個又要求VGA連接埠，甚至老一點的電視也能連，那種連接埠是復合影片連接埠。最終Lomas說VGA占用晶片的串行連接埠針腳數太多了，這會導致能夠支援的其他功能數量減少，所以他們就選了HDMI和復合影片連接埠。

Lomas說：「我們付出了艱苦的努力。實際上我們放棄了好幾樣東西。我們對I/O進行了合理化，去掉了一些不需要的東西。然後進行了重新組織，返璞歸真。他們給我起了個外號，叫做『職業殺手』。」

那場戰鬥在每一個部分都展開了全面廝殺。每一個零組件都得在成本、品質以及可用性上進行微妙的權衡。

Upton說：「實現3點中的1、2點相對容易，但是要想把3點都做到就非常非常的難，所以引起了很多這類的爭吵。」

一些情況下，Upton和Lomas採用了聰明的規避手段來推動成本下降。原先設計中的一塊專用音訊晶片被6個寄存器和電容以及一個透過脈衝寬度調製產生音訊的軟體取代。在別的地方，他們會先降低規範要求，然後等到後面推出的板子再考慮改進某些缺陷，比方說，一開始給樹莓派選擇了線性電源，這玩意兒在Upton看來是「非常低效」的，但隨後將會被「勞斯萊斯級的開關電源設計」取代。

並不是全都是削減。在Lomas的要求下後來的板子pin數（通用輸入/輸出端口）從26針增加到了40針，使得電腦能夠利用樹莓派控制燈光、開關、馬達，並且跟其他開發板互動。儘管這是一項後面才增加的特性，但據Lomas說它是「樹莓派的很多一部分」，因為促進了大量樹莓派驅動機器人的誕生。Upton同意這種說法：「今天你去問問那些劍橋大學的申請者『你是怎麼想到要學電腦的？』他們會說，『樹莓派和機器人。』」

到了這個階段Upton的工作強度已經達到每週80小時，晚上、週末、在飛機上、火車上，只要工作允許的時候都在弄樹莓派。他回憶起有一次甚至在希斯羅機場登機的適合還在打電話給Lomas，「讓他給我發BOM（材料清單），好讓我在飛機上還能工作，」這話讓他身邊的部分乘客感到緊張。（編者註：也許是BOM的發音跟炸彈相像）

在他們共同努力的這段時間內，並沒有其他的團隊成員或者足夠的基礎設施來支援Upton和Lomas——只有少數志願者到他們家中來幫忙。

Lomas說：「我們起步就只有6個人，沒有辦公室，只有幾部電話，我們做的一切都是透過電子郵件和Google進行的。但是大家的決心都很大，一定要把它做成。」

到了12月，樹莓派的設計終於達到預想的樣子，聖誕節前一週，Lomas在柴郡的Norcott Technologies工廠做了20塊內部測試用的板子。

那天傍晚，也就是距離聖誕節還有3天的時候，Lomas記得自己接通了第一塊剛下線的板子，然後得到了一個不令人愉快的驚訝。

他說：「當我們在板凳上接通第一塊板子的電源時，心都快跳出來了，但是板子什麼反應都沒有。」

「後來才發現我們看錯了部分文件。文件其實經過審核了，但沒人發現。」

幸運的是，問題的解決只需要相對簡單的手工銲接即可——就是電壓軌斷了。

同一天晚上，當Upton抵達工廠時，Lomas還在修最後一塊測試板。在連續6個月不斷工作之後，Upton和他的妻子，基金會的媒體總監Liz，剛剛從康沃爾驅車度假回來。

Upton說：「等我們趕到柴郡時已經很晚了。」

「我把其中一塊插上電，那是一種很奇怪的體驗，因為這是一台我知道可以用25塊錢做出來的機器，但是功能比我小時候的任何機器都要強大得多，比我喜歡的Amiga都要強大得多。」

這塊beta版的板子就是第一代的樹莓派，Pi 1 Model B（2012年2月29日正式發佈）的第一批開發板。Upton和Lomas把這塊35美元的板子功能削減到2個USB孔，100Mbps的乙太網，HDMI 1.3,26針腳的GPIO，還有一塊700MHz的單核處理器和VideoCore IV GPU，可處理100p影片重播的硬體加速。為了堅守基金會的教育使命以及對透明性的承諾，每一塊板都提供了各種基於Linux的作業系統以及一套編寫程式工具。

應付成功

然而，基金會現在遇到了一個新問題——它成為了自身成功的受害者。Upton和這塊板的聯合創造者一開始對Pi的考慮並沒有太多，認為能賣出的數量不會超過1,000。即便Pi的公開亮相在2天內就在YouTube上達到60萬的瀏覽量，板子背後的團隊仍然很謹慎。

他說：「儘管看到大家興趣很濃，但我們仍然認為實際上想要掏錢去買的人會少很多。」解釋為什麼基金會只是把當初的產量略微提高到10,000。

但是火箭式的需求增長並沒有減弱，基金會的產能相對而言似乎杯水車薪，2月29日樹莓派正式開售時訂單已經達到了10萬。

基金會的製造模式是批量加工，加工量是每次10,000件，一個批次的銷售所得用於下一批的製造，這種速度遠遠滿足不了需求的增長。

供應鏈方面的考慮以及消費稅與製造成本令情況變得更加複雜，迫使基金會把生產放到了中國。

Upton和他的同事意識到基金會在方法上需要做出改變。

Upton說：「我們發現產品有大量需求，需求大到我們手頭的資金沒法滿足的地步。」

「於是我們換成了這種授權模式，把設計授權給RS Components和Premier Farnell。」

▲ Eben Upton在南威爾士的索尼工廠，樹莓派的生產地。

按照這筆交易，Farnell和RS Components負責樹莓派板子的生產和分銷，把生產分包給第三方——一開始是分包給中國的一家工廠，不過自從2012年底以來就轉給了英國南威爾士的一家索尼工廠。

現在回想起來，Upton認為這個授權模式是幫助樹莓派取得今日成功的關鍵決定——這讓基金會極大地擴大了樹莓派的生產規模，並且利用了那些公司全球的分銷網路。

他說：「我至今仍感到最自豪的就是那一變化，因為這是這件事情把價值釋放了。正是它讓我們發展起來了。」

3月初，隨著10萬訂單的累積，網上的大規模炒作，以及新得到的批量製造板子的能力，Upton說他開始意識到樹莓派吸引力的規模。

他回憶起了拿到首批待售樹莓派開發板的情形。

「我記得自己從頂部拿起了一塊樹莓派的開發板，托板上一共壘了50個箱子。」

他說：「我從最上面的箱子拿出來一塊板，然後跑到（基金會創始人）Jack Lang的客廳，接上他的電視，板子能用了。我們又從最底下抽出了一塊，中間隨機又抽出一塊，以防他們把能用的放在最上面。後來再插上電，啟動成功，當時我們的感覺是，『哇，這東西看來要發了。』然後我們在想也許我們能賣出50萬套。」

▲ 第一批的樹莓派 1 Model B產自中國。

自從2012年樹莓派 1推出以來，這股勢頭就沒有放緩的跡象。201年，全球售出的樹莓派開發板超過了2200萬，迄今已經發佈了3代，最近的是樹莓派 3 Model A+，這款25美元的板子相對於2012年推出的機器已經有了大規模的升級。這種成功為一項廣泛的教育拓展計畫提供了資金，2017年該計畫透過編碼俱樂部的形式為超過15萬兒童傳授了一週的編寫程式知識，並且透過該基金會的網上項目令超過850萬人受到了教育。

從6個人起步的基金會現在已經發展成一家國際性的組織，在英國和美國軍設有辦事處，他們還開設了一個分支機構，Raspberry Pi Trading，來處理工程和交易活動方面的事務。甚至還有個小時候後倒騰樹莓派的人現在也加入了他們的硬體團隊工作了。

對於Upton來說，樹莓派成功的證據不僅僅是賣出去的數千萬塊板子，而且也在於它讓新一代的人也擁有他當年用BBC Micro編寫遊戲時感覺到的那種興奮感的能力。

他說：「甚至很早你就開始能看到那些孩子們趴在客廳地板，看著街上樹莓派的電視的圖片，就跟我們過去一樣。」

數年後，那些孩子紛紛進入大學，而申請劍橋大學電腦科學的數量再度開始攀升。

「我們現在人數已經漲到1000人了——你開始看到一切都變得不一樣。」

Upton不斷強調樹莓派不是一個人的創造，從早期就是一群軟硬體、營銷、案例設計等方面專家的集體產物。這一點在今天更是如此。

他說：「我們喜歡對賈伯斯的那種敘事手法，對Woz的那種敘事手法。但是當你開發的是像樹莓派那麼複雜的東西時，故事就不是那麼講的了。」

有個例子很能說明問題。那就是基金會是如何建立起這個龐大的樹莓派會員社群的。這幫人經常相互幫助並且分享自己項目。這種強大的社群感很大程度上是由Liz Upton（現為基金會媒體總監）促成的，2011年她從一名自由職業記者轉為自願為基金會全職工作，Eben說她「發明了很多我們仍然用來跟社群互動的技巧」。

回顧過去，儘管Upton對基金會在2012年推出樹莓派 1的成就感到自豪，但他說2014年的樹莓派 1 Model B+才算是他們打算要做的電腦的樣子。

他說：「如果你看看Pi 1 B+的話，你會發現那就是我們希望在2012年時能做出來的東西，但是必須做出犧牲。」

「之後我們得以增加更多的GPIO，形態因子也更加合理了，USB孔增加了，能效也更高了。」

該電腦的成功讓實現樹莓派原先的願景變得可能。這款電腦推出的第二年，技術愛好者購入了超過250萬台樹莓派，原先開發板數量少的挑戰沒有了。

下一個要推出的版本將是樹莓派 4，不過Upton預計這款可能會跟之前的有很大的不同，需要遷移到一種全新的片上系統，從而支援更快更高效的處理器。這將是自樹莓派 2以來的最大挑戰，Upton說他們雄心勃勃的打算是在2020—2021時間窗內推出這塊開發板。

單板電腦在今天不值錢，而且對於冒充成樹莓派那樣的小東西——不管是香蕉派、橙子派還是草莓派，你也不能提什麼要求。但是如果樹莓派沒有被做出來的話，世界會有什麼不同呢？

Upton說：「這是個很吸引人的問題——但是沒人知道答案，對吧？」

他猜想也許Arduino會從製作微控製器開發板延伸到製造低成本的SBC（單板電腦）或者BeagleBoards的SBC也會降到樹莓派的價格。也許他和樹莓派的創造者們只是運氣好點罷了。

「也許這只是一個時機剛好成熟的想法，而我們正好從中插了一腳。」

Upton說，從某些方面來說，樹莓派的誕生需要一定程度的缺乏經驗。如果他和他的同事一開始對所面臨的挑戰更清楚一點的話，他們也許就永遠都不會著手去幹這件事了。

他說：「知道嗎，我認為我們就是太幼稚了。」

「一邊是知之甚少，不足以讓你為大膽的事情做好準備；另一邊是懂得足夠多，足以讓你整合一直團隊的力量。這兩者之間有著微妙的界限。」

「從某種程度來說，缺乏知識於我們而言是一種恩惠。我們不知道什麼是不可能的，所以我們做成了一件不可能的事。」

資料來源： Inside the Raspberry Pi: The story of the $35 computer that changed the world 作者：Nick Heath
本文授權轉載自 36Kr

加入T客邦Facebook粉絲團

小米财报业绩超预期，但互联网+IOT 的故事还是没讲好

Mon, 19 Nov 2018 21:14:50 CST

11 月 19 日，小米股票迎来久违的大涨，当天报收于 13.6 港元，涨幅超过 5%，显示了市场对小米第三季财报的信心。

不出所料，盘后小米交出了一份成绩颇为亮眼的财报。当季小米营收 508 亿元人民币，同比上涨 49.1%，调整后净利润 28.85 亿元人民币，同比增长 17.3%，超出市场预期。

不过，从几大业务的贡献来看，小米仍未扭转硬件公司的形象。

手机营收占比仍过大

小米第三季度手机出货量达到 3330 万部，在销量和平均售价上涨的带动下，手机营收同比增长 36.1%，录得 350 亿元，营收占比 68.8%，甚至略高于上一季度的 67.4%。考虑到小米手机利润不高，手机的增长对公司整体利润的贡献相对有限，也不符合其互联网公司的定位。

小米 8 等中高端手机拉高了小米的平均售价，但均价提高也只是相对而言，第三季度小米智能手机平均售价为 1052 元，上季度为 952.3 元，同比增长仅 4%，第三季度售价 2000 元以上的手机贡献了小米智能手机收入的 31%，产品结构有所改善，仍未摆脱「千元机」主导的现状。

小米手机的另一部分增长来自海外市场。IDC 的数据显示，小米第三季度在全球的市场份额增长至 9.7%，达到历史新高。除了继续在海外主力市场印度保持市场份额第一外，小米也在开拓西班牙等西欧市场，第三季度其西欧出货量同比增长 386%，但比起上一季 2700% 的增幅已是大为放缓，而高增速亦与其尚在起步阶段有关。

互联网服务略有起色

互联网服务和 IOT 是撑起小米估值的关键，但前者尚未显示出能成为营收支柱的迹象。本季度小米互联网服务营收 47 亿元，占总收入 9.25%，仍不到 10%，同比增长 85.5%，也就是说，手机和 IOT 智能硬件占比依旧超过九成。

小米的互联网服务收入主要来自广告、游戏、互联网金融和电商。

6 月份小米的广告出现「P2P 爆雷」事件，为平息争议，小米随后将所有 P2P 广告下架，但从财报来看，这并未影响其广告收入。当季小米广告收入 32 亿，暴涨 109.8%。

反倒是另一个营收大头游戏业务出现了下滑，同比增长 12% 至 6.525 亿，低于上一季的 7.04 亿和 25% 的增幅。今年国内游戏行业整体日子都不好过，没有产品和渠道优势的小米想在网易和腾讯这两大巨头中突围的难度非常大。

MIUI 月活用户达到 2.244 亿，平均每个用户贡献的收入增至 21.1 元。

财报中特别提到了小米已开始海外互联网服务的尝试且初见成效，第三季度海外业务营收占互联网服务总收入 4.4%。

IOT 稳中有降

IOT 是小米上一期财报的最大亮点，但本期财报表现大不如前。

第三季度 IOT 与生活消费品收入 108 亿，仅比上季度多了 4 亿，89.8% 的同比增长低于上季度的 104.3%，对总收入的贡献也由 23% 下降至 21.3%。

小米 IOT 主要包括智能电视、笔记本电脑、小米手环和米家电动滑板等产品，财报特别强调了 2 类产品的增长：智能电视和笔记本同比增长超过 100%，达到 42 亿元，智能电视同比增长 198.5%，前 9 个月销量达到 520 万台。

然而，对比第二季度智能电视 350% 的同比增幅，第三季度的速度无疑是大幅放缓了。不过在国内的智能电视市场，小米已经遥遥领先于其他对手，未来仍大有可为。

但在其他智能硬件方面，小米想与老牌厂商争抢份额恐怕没那么容易，小米 7 月推出的米家空调，暂未显露「爆款」的潜质。

还有一组数字值得关注：截至第三季度末，拥有 5 台以上小米 IOT 设备（不包括笔记本和智能手机）的用户近 198 万，上一季度这一数字是 170 万，环比增长 16.5%。

财报发布的同时，小米还宣布与美国公司达成战略合作，将负责未来美图手机（V7 除外）的设计、研发、生产、运营、销售和推广，还获得美图一系列智能硬件的品牌授权。

总体来看，小米仍是一家以硬件为主导的公司，互联网服务略有起色但仍难担大任，「互联网+IOT」的故事看来并不好讲。

题图来自：视觉中国

吴羚

和有情人，做多情事

邮箱 3

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

微博这个励志故事

Thu, 11 Aug 2016 10:14:55 CST

微博发布2016年二季度财报，业绩相当亮眼，利润同比大涨5倍有余。

在中国互联网这二十多年的发展历史上，微博算是一个另类。它的独特点在于，很少有像它这样被舆论一致看好然后又一致看衰却又在看衰中崛起的产品。

2011年，微博在舆论看多中走到顶峰，一度有所谓“微博改变中国”的说法。

2012年，微博开始走上下坡路，一个很有趣的现象就是，从“每天都要刷微博”到“现在还有什么人在用微博？”

2014年，微博上市，国内舆论依然不是太过看好，一个很重要的原因在于，微信及其公众账号平台吸引了太多的目光。

2016年，微博强势崛起，到8月份为止，股价已经连拉六个月的阳线。当下股价创下历史新高，突破40美元。

一

股价的上涨，背后是业绩。打2014年上市之后，微博的业绩的确让人满意。

微博的总营收盘子、广告收入盘子，每个季度的同比增幅都在40-50%之间，它的利润增幅真得可以用“瞠目结舌”来形容。打从2015第一季度开始，微博利润的同比增长，都是用倍数来形容的——当然，基数不大是蛮重要的原因。14年四个季度中有三个季度是亏损状态，15年到了Q2才算是正式步入持续性盈利阶段。

阿里巴巴于2013年4月入股微博，并为后者提供三年的业绩支持。一开始微博的收入的确得益阿里淘系甚多，不过时至今日，微博对阿里的依赖度并不高。

当下，微博宣称自己平台上的广告主数量达到100万。2015年Q3的时候，只有这个数字的一半：50万。微博营收上的长尾化已经很充分。

二

作为一个居住在上海，而且经常跑跑北广深杭的人，我的确高频听到这样的话语：我已经不用微博了，我身边也很少人用啊。

我自己用的也少。我甚至在我的手机只有16G的内存时，一直没有安装微博客户端。

但微博的DAU和MAU，都是以每季度30%左右的同比速率在上升。

我检讨了一下我不太用微博的原因：这个APP相当复杂，有一次我为了想找到我那点可怜的广告分成，找了半天。我不禁抱怨：是哪个产品经理搞那么复杂。

但完全可能存在另外一批人，他们只用微博的几个功能，其它功能毫不在意。也有可能存在一批人，每一次微博迭代都在使用，对他们来说，长期的使用已经让他们觉得并不难找子功能。

有点类似的情况是，我至今搞不明白windows系统上那个庞杂无比的QQ（mac上倒是简洁得很）以至于我很少用QQ，但这只是我的情况。

有一批人，QQ只是用来聊天或传输文件，再庞杂和他们无关。还有批人，QQ每次加一个功能出一个新版本，都在使用，当然不会像我这种猛然拿起就有一头雾水的感觉。

三

微博的老师：Twitter这两年相当不顺。

股价走势截然不同。

Twitter一直处于亏损状态，近日有媒体爆料说，它计划将旧金山总部的1.7万平方米空间对外转租，算是开源节流。

与微博每个季度大致都有30%以上的MAU同比增幅相比，Twitter的用户活跃度在变差。到了2016年Q2，它的MAU同比增幅进入了负数区。

Twitter经常换CEO，以至于我的朋友开玩笑说，这家公司，已经有了一股雅虎的气质。

这是为什么？

四

Twitter长期利润为负，我发现了一个小小的原因：它的开支，与微博相比，有过高之感。

研发费用和销售、管理及行政费用这两项，在Twitter和微博的收益表里，都是重要的开支。

主要体现在销售、管理及行政费用这一项中。Twitter这一块开支连续两年都占据了营收的一半，而微博则较为克制。

这可能是影响利润的因素之一。说白了，Twitter的人员开支占比比较大。

但这似乎很难去解释为什么Twitter的活跃用户量一直得不到快速的增长。

把Facebook的MAU季同比增长数据加入后，可以得到如下这张图：

灰色线是Facebook的，这个同比增长数字一直很稳健，保持在近15%的规模。考虑到Facebook的基数从2014年Q1就达到12.8亿（微博同期为1.438亿，Twitter同期为2.55亿），这个增幅是可以令人满意的。

同为社交应用，对于Twitter来说，Facebook是一个巨大的阴影。

而Facebook和Twitter其实有一点非常大的区别：Facebook重、复杂，Twitter轻、简洁。

看来，轻、简洁，并不见得有多讨好用户。QQ、微信，一点也不轻也谈不上什么简洁。

所以，我一直很怀疑“少即是多”这貌似充斥着哲理的话。

如果是产品早期，少即是多可能作为一种切入战术还是可行的。但到了中后期，至少在社交领域中，我们看到的，都是相当复杂的一站式的集成式的服务胜出。

五

现在来看看微博到底干了些什么，让它在微信的阴影中，依然做得可谓风生水起。

毫无疑问的一点是，微博和微信依然有其差别。

假设普通人张三因为一句“洪荒之力”而粉上了傅园慧，但他很难在微信上成为傅姑娘的“朋友”，从而几乎没有可能去看看这位“泥石流”运动员在朋友圈里究竟说了些什么。

当然，他可以通过关注傅园慧的公号（假设有）来完成follow这个动作。不过，微信公号是一个横跨PC端和移动端的产品。内容生产者需要借助PC，而内容获取者则在移动端。微信公号并不是一个纯移动的产品（微信公号倒是在小范围测试一个移动端的生产型APP）。

我们观察傅园慧过去的微博可以发现，她的言论、照片，很难套到微信公号的情境中。虽然都好像是一套CMS（内容发布管理系统），但微博和微信公号，差别是非常大的。

这就意味着，即便在微信如日中天的巨大阴影下，微博理论上依然有其存在的空间，而不是死路一条。

无非就是看微博到底怎么做。

微博的方式是：下沉。

六

下沉的手段分为三个路径。

第一是向三四线城市乃至五六线城市的渗透。这是所谓用户社会属性的下沉。

第二是大V策略向中小V策略转化，微博称之为“垂直细分”，因为中小V一般都是垂直细分的，而不是公共型的。这是内容的下沉。

第三则是调性的下沉。与早期“微博改变中国”那种宏大调性所不同的是，微博上现在大量的内容都是吃喝拉撒式的。

一个很好的例子是国内一个网红孵化器如涵，旗下三十多名网红清一色全部在微博上拓展业务而不是微信。其中最有名的一位网红叫张大奕，在2015年双十一一个晚上，销售业绩超过6000万。她目前在微博上有400余万粉丝。

当你去观察张大奕的微博时，也会有这样一种感觉：这些内容，和微信公号那个情境，实在不太搭：一般都是很简短的文本，然后要么就是配好几张照片，要么就是一段视频，最后很直接地导流到淘系上进行购物。

对于很多电商为收入模式的微博经营者来说，微信和淘系之间的互封，使得他们很难在微信公号上开展业务。

七

很有意思的一点是，曹国伟治下的新浪系，对视频类项目一向独有情钟。2012年，我一个在职读研的学生，当时也是新浪的员工，就和我私下里提到，老曹非常看好短视频。就在当年，新浪投资了视频秀场9158，后者于香港上市。

微博目前可以利用新浪系视频工具有秒拍和一直播，前者大抵上属于录播类，也就是拍完了上传。后者则属于直播类，可以基于视频进行实时互动。

随着网速的提升和带宽价格的下降，视频很明显将得到极大的追捧。微博押注无论是短视频还是直播类视频，方向并没有问题。

如果说微信公号带动的是一大波内容创业的话，微博可能会带动网红创业——或者，按照如涵创始人冯敏对网红的不接受，可以称之为达人创业。

八

虽然微博已经走出它的低谷，也书写了一个极其励志的故事：被全面看衰之下依然翻盘，但我并没有这个意思说，微博将回到它最鼎盛时期以至于腾讯都有一丝QQ即将受到威胁的状态。事实上，微博对微信的威胁并不大。

作为一个社交类应用的微博，说到底是兴趣图谱：关心发生了什么、看看有什么达人给我推荐，这当然是一种刚需，但恐怕没有微信这种完成人际通讯的刚需那么“刚”。

微博在用户属性的下沉上很努力，不过根据摩根斯坦利的估计，微博的的MAU在二线城市，以及三线及以下城市分别为微信的41%和27%。你可以认为微博依然有上升空间（比如借助视频类服务），但要想超越微信，可能性非常小。

微博的DAU与MAU之比，14年以来一直处于45%上下的水平。目前并不清楚微信这个衡量用户参与度的指标，但Facebook的数据是66%（亚洲地区58%）。

这可能和微博产品线的庞杂有关。

前文提到，社交领域的平台级产品都需要复杂的功能，而不是轻、简洁。但功能复杂并不等同于无序。微博诸项子功能从产品设计角度，有庞杂之感。

九

最后谈谈微博未来的商业化之路。

这张图反映的是每MAU的广告营收，今年一季度，微博达到0.38美元，二季度达到0.45美元。摩根斯坦利对亚洲同类公司这个指标给出的数据是：0.76美元（一季度）。Facebook在亚洲，这个数字是1.5美元（一季度）。

众所周知的是，新浪拥有可能是中国最好的互联网广告销售队伍。在诸家门户中，它单个流量所能带来的广告销售，即便面对中国流量排名第二的腾讯QQ.com，也丝毫不落下风。

但微博的广告销售效率并不高。

2016年一季度，微博的CPM价格为15元人民币，而微信朋友圈广告的CPM价格达到60元人民币，今日头条为40-50元人民币。

微博背后是100万广告主，长尾效应的确和朋友圈广告、头条广告不同。微博CPM价格较低，对广告主诚然是好消息，但对微博，可谓效率还有待提高。

这些数字当然可以说明微博并没有走到已无上升空间的境地，但同时，也可以说明，未来微博的主要重点是：打磨产品以提高DAU与MAU之比，提升效率以提高CPM价格。

这是微博三季度、四季度财报发布后，应该关注的重点指标。

—— 腾讯科技首发 ——

作者执教于上海交通大学媒体与设计学院，天奇阿米巴创投基金投资合伙人

微博这个励志故事，首发于扯氮集。

携程网宕机事故深度剖析

Wed, 03 Jun 2015 19:40:08 CST

2015年5月28日上午11时许,携程旅行网官方网站突然陷入瘫痪,打开主页后点击时均显示“Service Unavailable”,经过12小时的紧急抢修后，携程网终于恢复，可正常访问。
虽然事情已经过去几天了，但通过网上的各种传言，到处都透露出携程网在网站建设中的种种不专业行为，有些传言甚至让人匪夷所思，典型的就是所有数据库数据都被物理删除，无法恢复这一条，容后表述。
下面列出一些携程网显然做的不足的方面，以资讨论。
1.运维工程师，开发工程师，测试人员等各角色的职责和权限必须定义清晰
互联网站建设的几个重要环节，基本是产品->开发->测试->运维这样一个流程。让我们根据这个流程看一下，究竟是哪个环节出问题了呢？毫无疑问是运维这部分。
出问题的可能性大致推测如下：
运维工程师不小心删除了根目录下的全部文件；
运维人员水平所限，没有搭建灾备系统；
公司管理混乱，不该具备操作权限的非运维人员也有权进入生产环境的主服务器进行操作；
外部黑客攻击网站。

根据上面的推断，基本可以发现，运维人员的水平高低，往往是决定网站能否正常运行的关键环节。而携程网显然在运维这一环节关键时刻掉链子，才造成了网站大面积宕机的惨剧。
无法想象在今天的互联网时代，一个大中型网站竟然没有灾备系统或者集群，网络拓扑结构等的配置。携程网的运维部门，必然不合格。
时至今日，在网站建设中的各个角色的定义已经相当清晰，一般来说，只有运维部门有权在生产服务器上进行发布新版等操作，如果这一点尚存疑问，携程网确实需要好好补课才行。

2.灾备系统的重要性
根据官方统计，携程网在12个小时内，网站所有功能都陷于瘫痪。说明此网站完全没有进行灾难备份。在当今一些要求比较高的应用，例如银行，金融业等，必须要求7*24小时不宕机，在这种情况下，往往至少会在生产环境发布两套系统，一旦主服务器出现异常，马上可以切换到备份服务器。另外，使用nginx的权重分配等方法也可以完成类似操作。携程网的系统架构师和运维人员显然不具备这种灾难恢复意识。

网上甚至一度盛传所有数据库数据都被物理删除，无法恢复。在实际应用中，大型网站的数据库几乎都是主从（master-slave）数据库，每隔半小时，1或2小时就会对数据库做一次备份，备份还分为冷备和热备。怎么还会出现这种问题，最多也就是丢失1至2小时的数据而已。携程网的说法实在是让人诧异不已。

3.java的安全性能相对较高，.net程序则一般运行在IIS的windows机器上，权限控制太弱
事发后，大家才获知携程网至今仍然使用的是.net进行的网站建设，那么它的全部代码理应跑在windows系统的IIS web服务器下。众所周知windows系统几乎对系统安全性不做限制，那么随便一个内部人员几乎都可以上去增删代码；而linux系统对权限的控制就严格的多。
另外，还有一说，是遭到了外部攻击造成系统瘫痪。目测时至今日，大的正规网站基本都使用了Java,php等编程语言来进行网站建设（.net基本已经被大家遗弃，不是没有理由的）。Java系统天生安全性能就较高，可以较好的抵御外部入侵。

4.系统架构的重要性
携程网瘫痪了12个小时，只有主页可以浏览，其他所有功能都陷于瘫痪。官方解释是遭到了外部攻击造成系统瘫痪。这从另一个方面说明，该网站的各个功能模块互相依赖，耦合性太强。一旦受到外部攻击，整个系统的自洽性极低，崩溃会迅速从点蔓延到面，造成整个网站瘫痪。
对大中型网站建设来说，用户系统，购物系统，订单系统，客服系统。。。甚至缓存系统，数据库集群等等，基本都是独立出来为整站提供服务。例如，客服系统受到攻击，其他系统基本不受影响。而携程网则非常诡异的全站瘫痪，实在是闻所未闻。
一种传言是有人将主服务器根目录下的所有文件都删除了。但是依我的经验，对一个大中型网站来说，通常都使用网络拓扑加服务器集群（主备或者权重）的方式来发布，删除所有服务器上的运行程序，几乎是不可能发生的事情。
从系统架构的角度来看，这是一个极其不合格的系统。一个好的系统，应该尽量降低模块间的耦合性，分散到多个服务器上发布。这样不但可以提高开发测试等工作效率，方便模块发布，也有利于系统拆分及升级扩容，显然携程网的架构师离这一要求还相去甚远。

5.公司企业文化的重要性
最后来阐述一下，公司处于稳定发展期后，企业文化对公司持续良好发展的重要影响。
根据不少使用过携程网的用户反应，此网站经常搞一些小动作，注册用户在退票时各种推诿，不能爽快的退还应付款项。感觉上是公司为了营收，经常对用户进行无理由克扣款项，肆意践踏网站自己制定的客户须知等内容，毫无企业诚信可言。

从这个现象可窥豹一斑，此公司的企业文化就是比较鸡贼，擅搞小动作。而有一种网上传闻则是，携程网的运维总监和运维部L员工的女友上床，招致该员工报复性的删除了主服务器上根目录下的全部数据，看看外界对携程网的认知和评价，马上就让人觉得这样的事情发生在携程网不足为奇了。
什么样的企业文化，培养出什么样的员工，纯粹是no zuo no die.

已有 2 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

怎样训练写故事的能力？

Wed, 03 Jun 2015 23:00:00 CST

介是个好问题，又到了半夜写知乎的时间啦～
——————————

我的以下答案，都是基于如何训练 戏剧性故事创作，用戏剧创作的方法和经验来谈一谈故事创作，希望可以给题主一些帮助。

首先要说一说，戏剧性，啥叫戏剧性呢？抛开资料论述，我个人最喜欢的一个解读为——
情理之中，意料之外。
那为什么要强调故事创作的戏剧性呢？因为戏剧性满足了人自身对故事的渴望和期待习惯。

我们看古希腊，俄狄浦斯王弑父娶母，看似是不可能的预言，是戏剧安排一步步完成宿命。
我们看莎士比亚，罗密欧以为朱丽叶的假死是真死所以自杀，这就是戏剧化的逻辑。
然而，现在的故事和几百年前有啥不一样吗？
我们看赵本山，让没事的范伟生生买拐，也是看似是不可能的啊，
我们看小时代，让杨幂去以为那个谁谁谁死了可实际人家也没死，这不还照样拍了三部么…
故事的素材各有不同，但是讲故事的路子千百年实际并没啥变化。

下面，为了方便大家的阅读时间，我来放个mv，为了有助于我全文举例说明的……
很早的韩国广告，《因为是女子》，相信大家都听过这个，这个mv的故事吧，就很戏剧性，但是也很狗血，据说很多韩剧的故事模式都是在这个mv后出现的….
大家真的不要耻笑我，创作这事儿就是要用最简单最有力的方式给说明白…
也可以一边点开听歌一边看我的后文..
Kiss - 因为是女子韩国天后流行音乐天籁
接下来步入正题
－－－－－－－－－－－－－－

在这之前，请看我曾经的一个回答：

如何果断地写剧本的第一笔？ - 曹效聪的回答

好了，有了第一笔，我们可以继续了，
根据我个人受到的戏剧教学学习和实践，我认为故事创作可以总结为六个元素。

一人物

1 人物塑造
大家都在谈我们缺好故事，本质上是缺一个好人物。
好人物在我看来就是有血有肉，生动鲜活。不假，不标签，不脸谱。
人不就是个复杂的动物吗，一定要让你的人物保持 ‘可爱’。最坏的坏蛋也有可爱的一面，这个可爱就是，我们可以理解这个人物，可以感受到这个人物。
一个杀手不抽烟不喝酒就爱样花喝牛奶奇怪吗？

举例说
这个mv里的俩人物，男主摄影师，帅气，敬业，单身，还有条狗！
女主，理发店洗头老妹，漂亮，清新，有礼貌，笨手笨脚。
这个设定就很容易让他们产生接下来要说的人物关系。
2 人物关系的塑造， 发展和 转变
在这一点一定要明确循序渐进，是有层次有逻辑的。
相知，相识，相认，就是这样一个过程。
但是在人物关系的设定上，重点在巧。
这mv里，
两个人相识，洗发老妹无意闯进了摄影师的镜头留下一张照片。
这个既合情，又合理，还有点小清新呢…
而且后面这张照片有很强大的物件作用呢。
人物关系塑造后，开始进入发展，
摄影师来洗头，老妹儿支开别人，自己给他慢慢的洗，不小心擦到了摄影师的脸，被经理骂了。摄影师笑笑，老妹儿心理这个美啊。
这不就是人物关系到发展吗！而且完全用的是戏剧性的动作。
谁都能看出来，俩人互相看对眼了啊，然后他俩的人物关系就转变了——
毫无悬念的在一起了。。。。

二情景/环境

情景绝不仅是故事创作的背景环境，更多的设定在于， 情景可以为矛盾的产生提供合情合理的必要条件。
俩人谈恋爱，船撞冰山了，这就是情景。
俩人谈恋爱，战争爆发了，这就是情景。
俩人谈恋爱，天要下雨/娘不同意/前任骚扰/房价压力/异地分局/劈腿小三….
这些都是情景。
只有选择合适的情景，才能让故事发展更为流畅自然。

接下来在插一个我的问答话剧应该如何压缩故事情节以适应场幕的限制？ - 曹效聪的回答

这个问答在此题的意义在于如何为情景选择场景。

然后我们看mv，俩人在谈恋爱后，有个重要的情景安排就是暗房。
表面看，摄影师在这里洗照片看老妹儿秀恩爱，可洗着洗着，一拿药水，完了，眼睛瞎了。
于是整个故事的矛盾开始了，也就是，事件存在了。

三事件

在任何故事，无论是大故事还是小故事，无论是大片还是微电影，大戏还是小品，都自始至终的有一个 核心事件。这个事件决定着人物在情景要干嘛。
《教父》，教父死了，咋办？
《肖申克的救赎》，瑞德入狱了，咋办？
《大逃杀》，熊孩子被关进岛里了，咋办？
……
再看这个mv，正是因为摄影师眼睛瞎了，构成了一个事件，所以观众才期待后面的发生。

些故事经常容易发生的一个情况就是，故事并没有多大，事件一大堆。
相信我， 大多数的故事，设定并完善好一个事件的处理就足够了。

四任务/行动

当发生一件事的时候，一个人一定要有所作为，这就是行动，而他的一系列行动，都是奔着明确的目的，这就是任务。
mv里摄影师疯狂飙车，然后把自己的东西给了朋友，这是他的行动。
而他的任务就是，把自己的眼睛换给老妹儿。
故事是这样，没啥意思，可这不意味着， 讲故事的方式要按照故事来！
mv里摄影师走了，没说干嘛去了，紧接女主出院。

所以这是这个mv在讲故事方式上巧妙的地方，留下悬念。但这点后文在表。
在这一点我要说的是，完善故事/矛盾的解决办法，但是我们可以先让观众猜怎么做。先给予一个结果。所以很多人都觉着戏剧和电影没啥关系，可电影是剪辑的艺术，剪辑和编剧有着直接的联系，而编剧那不就是戏剧叙事吗…….好吧我承认我说的有些绝对，但道理绝对是绝对的。

说回来，其实故事中的任务和游戏设定很像。
游戏里我们就有一个任务，而且会赋予行动。打怪干boss闯关就是任务和行动。
在任务中，还存在 最高任务。相当于人物的终极目的，在这一点超级英雄类电影的故事更佳明显。总之，作为创作者，要时刻记住人物的任务，因为这直接会决定上述一切元素的存在和发展。

五悬念

观众看一个电影，都想知道最后主人公是咋地了，
观众看一个节目，都想知道哪个歌手赢了，
观众看一个热闹，都想知道最后怎么解决问题，
这就是悬念。
悬念首先需要前面一系列的铺垫才会有效，设置悬念并不难，难得是如何 渲染悬念感。
在这个mv里，悬念就是男主干嘛去了？
后来女主各种找，然后最后通过最初的一条狗，发现，啊，男主瞎了。原来，人家把自己眼睛给老妹儿了。
这其实就是故事悬念的本身，只不过加上音乐，加上视听语言，就显得煽情好多。
抛开外化条件，悬念其实是故事已经完结后的一个解释。
最典型的例子是《迷雾》，最后一分钟救援来了，悬念揭开。
很多人说这是影史最佳的反转结局………..

可是这个片子重点讲的是这一分钟之前的故事啊！！！！！

还有这个被无数解读的小玩意……….被解读为各种开放式结局….

可是诺兰在这之前已经把故事讲完了啊！！！！！

所以看到有些动不动就说自己这个故事是开放式的朋友…..
编不下去不要找别的理由好吗…….

说到这点，还有一个些故事经常出现的现象——
啊，原来一切，都是我的一场梦。
…...
你要是把前文这些元素都做好，这梦还值。啥啥没逻辑，没感情，没理由，那您还是继续睡吧...

－－－－－－－－－－－－－－－－－－－－－－－－

以上，为我的自己一些总结，虽然我尽量朝着干货努力，但还是理论成分较多，相信题主你要是有心买几本编剧书，人家都比我说的好得多得多。
而我之所以要写这些，主要是因为我很热爱创作，在这个过程里我会很满足。
各路大神勿喷勿装， 学术交流，欢迎指教，若遇装x，我绝较劲。

而楼主，我衷心希望我的回答可以有所帮助你。
此外，不说我想你也知道，创作这个东西，没有什么捷径，就是——

多看，多学，多听，多写多写多写多写多写多写多写多写…
继续看，继续学，继续听，继续写写写写写写写写写写写写….

来源：知乎 www.zhihu.com
作者：曹效聪

【知乎日报】千万用户的选择，做朋友圈里的新鲜事分享大牛。点击下载

此问题还有 2 个回答，查看全部。
延伸阅读：
如何写好一个故事？
如何写好故事墙？

一种快速估算故事点的方法

Mon, 25 May 2015 22:20:31 CST

英文原文： A Fast Story Point Estimation Process

估算故事点是一个令人乏味的过程。正是这样的乏味过程使得一些团队放弃了有助于预测速率的估算点。何不放手这种有效的方式来预测未来的工作，而找一种更快的估算过程？不仅是快，而且有趣！是的，估算和有趣可以同时进行！

我们曾面临过这种情况，我们必须知道是否可以在确定的发行日期之前推出新的网站，该网站涉及到全新的创意、基于服务的架构方法，并且与后端系统有交互影响。有几个敏捷团队（内部和外部）是该项目的部分团队，并且需要知道是否可以按期推出。我们必须决定是否可以在可用时间内及时地完成剩余的工作，或者必须缩小工作范围以满足推出日期的要求。我们把团队都聚到一块，也包括主要的经理们（一共有 15 个人），尽快地弄清楚是否可承诺完成。我们提前修整了超过 125 个用户故事，并且可以在 15 分钟左右的时间内估算完这些用户故事。最后的时候，我们确定需要缩减范围以便满足日期要求，并且由业务人员决定缩减哪些内容可以争取一些时间。

如果你有一个同地协作的团队，这有种方法可以快速地估算多达 100 个用户故事。当团队需要提供一个可靠的时间表、什么时候可以完成用户故事的开发和测试，由此可以计划主要的项目发布，这个过程方法则使用得很成功。并且它可以替代像计划扑克那样耗时的方法。

所以不要因为耗时就停止了估算，而要用不同的方式！这种新方法的风险是微不足道的，这也是敏捷，并且支持大胆前行并需要紧迫交付可工作软件的项目。

假设条件

要有待办列表修整会议并且团队成员理解大多数用户故事的要点
同地协作的团队
有一面墙或者会议室可以让团队使用
每个用户故事被独立打印，必须在估算过程之前准备，并且提前贴在墙上。
在墙上写下斐波那契数列：1-2-3-5-8-13-31 并且加上一列“？”

过程

团队人员排成一排
要求第一名成员把一个用户故事放到他认为可以正确反应故事点值的那一列上
第一名成员做完后排团队成员的最后一个位置
下一个团队成员可以挪动已经摆好的用户故事，也可以选择另外的用户故事，把它挪到他认为可以正确反应故事点值的那一列
继续这个过程，直到所有用户故事都摆放完毕。
在此循环过程中，会有用户故事在不同的估值点列中来回挪动，引导师可以把这些用户故事挪到列表的上方，用于最后的时候讨论。

当大多数的故事都摆放好后，让团队成员投票选择这个“问题”故事属于哪一列。
如果无法达成一致，把这个故事放到最高值的一列。

也会有一些故事需要更多的信息，把他们放到“？”一列
把“?”一列的故事降到最低
如果这样的故事太多了，也许再需要一个列表修整会议，可以让团队成员很清晰地了解故事细节。
放置故事以及讨论协商的整个过程会很快

团队在整个放置故事的过程中都感觉到很有趣

一旦团队成员对放置的故事都满意，计算每一列故事的个数，并且乘以故事点，从而得到所有的故事点。
这也有助于团队基于当前的速率估算剩余的迭代。
注意，可能会有一些高优先级的故事已经在迭代中——这个练习是专注于弄清楚列表中有多少剩余的工作。。

快试一试吧！如果你现在还没有修整列表，可以考虑把它作为一个例子，让团队看看怎么进行的。例如，如果你有一个名为“摊煎饼”的项目，可以创建例如这样的用户故事，“定义煎饼类型”、“创建购物清单，因此我不会忘记”、“去商店购买需要的所有材料”、“把材料组合起来，检查是否准备就绪”、“开始烹调”、“招待”等等。这些故事很容易理解。只要团队有足够的故事可以很好地演示整个过程就可以了。

关于作者

Mary Ann Michaels 具有多年的大规模零售系统实现的项目领导经验。她是敏捷的忠实粉丝，在工作中学会使用一些工具，以及从 MBA 和各种培训课程中了解敏捷方法论如何让团队快速地交付可工作的软件。它曾就职于多个大型公司，包括沃尔玛、Levi Strauss & Co、Williams Sonoma 以及 Coldwater Creek。并且同时拥有技术与业务能力，管理应用开发并支持团队和配送中心。她拥有密歇根州立大学的数学/法语学士学位，以及佩珀代因大学的 MBA 学位。

本文链接

Spotify推荐引擎Discover Weekly的故事

Wed, 07 Sep 2016 20:31:27 CST

Spotify的软件工程师Edward Newett说，赋权自下而上的创新，奇迹将会发生。他在上周举行的@Scale 会议上分享了开发Discover Weekly推荐引擎的故事。Discover Weekly设计帮助用户发现他们从未听过的新音乐，于一年前上线，至今已积累了4000多万的用户。Newett最初的工作是开发个性化网页，其中包含了向用户推荐他们可能感兴趣的专辑的系统。但这个推荐功能没什么人用。他推测原因可能是过于繁琐，认为可以找到更好的方法。2014年他和同事开发了Discover Weekly的原型，设计根据用户的音乐品味个性化新音乐播放列表。

在LinkedIn做面试官的故事

Mon, 27 Apr 2015 16:07:00 CST

　　问题：硅谷公司的招人的渠道有哪些，跟国内有何不同？

　　一般公司都有自己的Refer和面试系统，HR人员寻找候选人，在LinkedIn上就有丰富全面的简历库，通过对毕业学校，就职公司的过滤去挖掘潜在员工。还有一些高水平的学术会议，工业界愿意支持和参与，像SIGMOD，VLDB顶级数据库大会；也喜欢举办公开技术讲座，邀请社会各界参加，注册时留下联系方式。或者写一些技术博客，开源产品，通过他们做的有意思的项目来间接吸引人才。有时也举办一些hackathon比赛，24小时做出一个小产品原型，欢迎各类技术人才挑战。当时我也参加LinkedIn的编程马拉松，每人发一件T-shirt，写着 Eat, Code, No Sleep。我记得内部统计表示，2/3的人都是通过内部推荐进来的。

　　其实国内的思路更厉害，比如最近雅虎北京一裁员，忙坏了各路IT公司，某创业公司也凑热闹一起去抢人，派出2个高级工程师去面试，结果，负责面试的2个员工都被人挖走。还有一些无节操HR，伪装成下面这个，我接触过的妹子不多，你们不要骗我。

　　问题：硅谷公司招聘流程是什么，跟国内有和不同？

　　我刚好在国内外都工作过，我可以做个对比。

　　国内：如果是在校生，一般都要有个笔试，通过率也不高，可能就百分之几，然后在校园里面试3轮左右，分别对技术，基本功，价值观的考察。然后就会大规模发offer，一些大公司如百度，阿里一年招上千人是很常见的。

　　硅谷公司：一般是没有笔试。如果HR发现简历的一些关键字和背景符合职位需求，简单介绍公司，安排1，2轮电面，如果通过，邀请onsite面试，里面会有4－7轮，里面涉及到不少白板编程，虽然很多人争议，参见附录，但目前为止还是有些无奈的选拔手段。

How to Conduct a Better Coding Interview « Eric Elliott

　　LinkedIn会花很大代价去组织，包括报销来回机票，吃穿住行，赠送小礼物，给候选人一种非常受尊重的感觉。比如附带礼物中有一个inMap, 把你在LinkedIn上面的联系人聚类可视化呈现出来。非常酷。

　　这里面成功率非常低，真的是千里挑一，虽然代价很大，但很多公司都是强调人才是第一位的，在宣传企业文化和价值上也是起到积极作用。然后就是收集反馈，一般是2个面试官back to back同时给出评价，按1-4打分，最后取平均分， Yes = 3.0 ; Very Yes = 3.5 ; No = 2.5 招聘委员会通过投票和辩论来确定是否发放Offer。

　　上图是LinkedIn内部招聘流程图
　　我记得印象深刻的面试：面试者岁数大些，当时我面的时候也没出众，我准备给他一个一般的分，但他回去马上给我写了一篇长信，解释当时我问的问题，给出详细参考，我对他的回答非常佩服，至少态度很积极，也许是当场没有发挥好，我立马改变了印象，给他很高评价，但其中有个初级面试官居然给他1分，什么概念（if you hire him, I will go), 这样就把他平均分给拉下来，我觉得这样不公正，就在招聘会议上为他说话，最后他也拿到Offer顺利来到公司，事实证明这是一个挺优秀的技术人员。

　　问题：简历怎么写才能规范并吸引人呢？

　　怎样写好求职简历？ - 董飞的回答

　　下面这个是很有趣的程序员是如何读简历的：

　　问题：硅谷公司是如何选拔技术人才的？

　　硅谷公司对基础架构很重视，注重基本功，员工素质和价值观认可。技术人员还是需要关注生产力的，其实也很难短时间考察，公司也考虑过是否通过一些做小项目，直接上机模拟真实环境来评价。但真正实施又难度很大，LinkedIn 有个专门负责招聘Staff Engineer Jacob Kessler写过文章阐述面试理念： Interviews are not Exams 主要是想保持自然，一起应对一天工作中场景。

　　我总结成3C (Culture, Communication, Curiosity)，下面也展开一些重点。

　　技术：平常扎实的技术积累，包括系统知识点，不同编程语言，开源工具，团队合作工具，比如, Restful架构有哪些特点，动态语言的优劣。我在知乎上也给出了硅谷跳槽工具箱指南

　　基本功：代码简洁优美没有bug，常见算法的应用，优化技巧，比如如何把一个O(n^2)的算法优化成线性。好的编程习惯一定要坚持，格式：缩进可以良好排版，括号要对齐，变量名起的有意义。边界检查，参数检查，异常处理，单元测试。主动写出合理的Test case，一些常见的null检查。不管你之前做过多少年，只要申请工程师职位都要经历过编程的基本考核。

　　交流：实技术人员用到的英文都比较浅显，听和读应该问题不大，但最好在说和写方面下大功夫，这能突破一些天花板，更多融入团队交流。

　　系统设计：包括设计大型系统的架构选型，各种不同组件的tradeoff，数据库系统，网络系统，分布式系统。比如什么时候适合用NoSQL，如何做一个推送系统，缓存系统如何搭建。

　　问题：您在面试中会重点考察面试者除了技能之外的哪些点？面试者身上哪些特点往往会是各公司认为不能接受的？

　　首先，看背景是否 符合职位的需求，比如做分布式计算的工程师，对系统底层，大数据架构就要有一些涉猎。

　　第二，聪明，如果我交流的时候发现他们能很快意识到我说的意思甚至补充我心里想的，这种人非常讨喜。如思路异与常人，很快给出最优解，能挑战一些难度大的问题。

　　第三， 好奇和热情，如果面试者说不清为啥要申请，或者没啥主动提问的，我会觉得对公司兴趣不大，没有好好做功课，态度上不够积极，而就算最后技术很出色，在评价上也是要打折扣。另外如果他技术面很狭隘，技术兴趣不广泛，可能也要考虑是否能胜任创业公司不断变化的环境。

　　不能接受的

　　不愿意学习，对他说的或者写的很自大，但却不虚心接受其他人指出的问题和建议。

　　企业文化不合，对公司的使命和价值观有一些偏差，这个比技术功底更致命，主要是找志同道合的。

　　给大家附录中推荐的，Coursera的CPO分享的 “像谈恋爱那样去招人”说的很有启发。

　　问题：对于初级程序员的面试，最难的部分可能就是所谓的设计题。这部分是什么流程？

　　设计题可以分成两个部分，系统架构设计和利用面向对象编程原理进行程序设计。前者所涉及的技术往往包括数据库，并发处理和分布式系统等等，对于经验要求和知识要求比较高。系统面试的流程如下:

　　1. 题目描述

　　往往非常简单，如：设计一个XX系统。或者：你有没有用过XXX，给你看一下什么界面和功能，你来设计一个。

　　2. 阐述题意

　　面试者需向面试官询问系统的具体要求。如，需要什么功能，需要承受的流量大小，是否需要考虑可靠性，容错性等等。

　　3. 面试者提供一个初步的系统设计

　　4. 面试官这对初步的系统中提出一些Follow-Up的问题：如果要加某个功能怎么办，如果流量大了怎么办，如何考虑Consistent怎么办，如果机器挂了怎么办。

　　5. 面试者根据面试官的Follow Up逐个解决问题

　　总体特点是以交流为主，画图和代码为辅。

　　问题：从面试官的角度给出一些系统设计上的考量标准是什么？

　　我先给一个内部培训面试官的方法，大致说了考量环节。根据我的经验，也列出一些关注点

Adapt to the changing requirements （适应变化的需求）
Produce a system that is clean, elegant, well thought （设计干净，优美，考虑周到的系统）
Explain why you choose this implementation （解释为何这么实现）
Be familiar with your experience level to make decisions （对自己的能力水平很熟练）
Answer in high level of scale and complexity （在一些高层结构和复杂性方面有设计）

　　其实大家大可不必追求完美，在真正的面试中，没有人能对答如流，往往面试官也会给出善意的提示，就算你没回答某个子问题，在面试后的评价中也会综合衡量，跟其他的面试者比较，最终打出一个分数。很多人在2到3分左右，目标是尽量在3分以上。

　　问题：我不是算法大牛，不是ACM队员，听说Google，Facebook有很多牛人才能进，那我怎么能拿到好Offer？

　　首先要是要有信心，算法不是想象那么难。

　　第一：因为面试常见的算法就那么几种。只有你努力去总结归类相似题目，才能只做很少的题就可以会很多的题。不要盲目关注数字。做题质量非常重要。标准是：你做过的题目，让你再做一次，你就能“完美解决”。

　　第二：即使你知道一题的解法，你未必能写好。因为你可能每次写出来的程序都很随性，这样会漏洞百出。程序员是一个非常讲究严谨性的职业，如果你在总结题目的时候能够找到这些题目的模板，你把模板提炼好，碰到类似的题目，可以一边写模板，一边想想怎么在模板上做一点简单的改动。这样节省时间又保证不会出错。

　　问题：如果本科不是学计算机的，又想转行该怎么准备？

　　1. 让自己更Professional。比如你的简历只能放和计算机有关的东西，其他东西再牛也不能发挥用处（比如学生会主席）如果Resume还是很空，就多去做项目。在Github上面多去follow项目，然后参与到感兴趣的当中。

　　2. 在某一方面达到工程师实力。临时转行时间短，找一个容易入手的准备，如果你以前做的事情跟数据有关，就申请Data Analyst。本来就会一些基本技术的，可以做前端，JavaScript, HTML, CSS，去真正做一个自己博客。如果对产品感兴趣，就玩Django, ROR这样的网站框架，了解一个网站是怎么搭建起来的。如果对Mobile感兴趣，就用IOS或者Android写2个APP。这样做的好处是，简历不空，如果问到，可以驾轻就熟。如果不相关，坦诚相见，说由于我是转行的我这方面不熟悉，可以尝试猜猜看。也可以直接告诉面试官，我是转行的，我对计算机很感兴趣，做了这么这么几个项目。于是面试官不会问你难题。结果你早就准备好了，超出面试官预期，就是一个高分!

　　问题：面试时候如何表现自己体现沟通能力？

　　首先你要站在面试官的角度，面试官招你进去当同事，他希望同事怎么样的人就决定了他的立场。学会换位思考。

　　让面试官时刻明白你的意图，不要闭着眼睛不停写。对于面试官来说，他根本不知道你的解题进行到哪一步了。你可以反复和面试官交流自己的想法，得到面试官认可以后再动手写。可以讲讲你怎样想到这个思路的。记住，你并不是要说服他接受你的想法，而是要把你的想法解释给他听。面试官提出质疑的时候，第一，不要觉得面试官什么都不懂，怎么这都不知道（其实他只是看一下你是否真的懂），第二，面试官比你经验丰富得多，很有可能就是你犯错了，赶紧想想是不是真的有问题。

　　问题：面试中出了Bug怎么办？

　　BUG Free很重要，这个需要我们平时不断的练习，按照我们方法的准备，还是可以避免一些坑。但碰巧你可能不在状态，写出了BUG被面试官指出，是不是就挂了呢？

　　别担心，出BUG很正常，也许面试官来面你之前正在DEBUG:( 衡量一个程序员能力的标准，并不是他能想出多牛的算法（那为什么还要面算法题？）而是当遇到问题的时候，程序员去分析和解决问题的能力。而出BUG的时候，正是展现你是否是一个合格程序员的时候。

DEBUG流程：

　　1. 通过TEST CASE定位BUG所在位置

　　2. 不要立即修改代码，重新梳理逻辑。因为很有可能还有其他BUG。

　　3. 走完所有逻辑之后，心里有数怎么改了，再动手开始改

　　4. 用TEST CASE再走一次新的代码。

　　5. 在整个过程中，不停的告诉面试官你在干嘛（在不影响正常写程序的情况下）

　　这样，成功排解BUG，不但不会减分，还会因为你优秀的DEBUG能力和与此同时展现出来的沟通能力而加分。

　　问题：面试中不同人考察的内容都有哪些？

　　给一张表大家可以了解：

　　最后希望大家在找工作方面能有所收获，不用多久，就会升职加薪，当上总经理，出任CEO，迎娶白富美，走上人生巅峰～想想还有点小激动呢，嘿嘿~~ 同学，梦醒了么，该去搬砖了。

　　参考资料

　　 How to Conduct a Better Coding Interview « Eric Elliott

　　 In Defense of Whiteboard Coding

　　像谈恋爱那样去招顶级程序员吧！

　　劲爆！萌萌哒华为校招视频——值得HR借鉴

　　当面试官问「你有什么要问我的吗」时，应该问什么？

线上事故分析

Tue, 03 Mar 2015 14:10:45 CST

事故现象

线上服务不定点的不能使用，查日志发现resin服务正在重启。由于resin所在的服务有web监控，如果web服务没有相应，则会重启resin服务。那到底是什么导致了无法请求到web服务呢（60秒没有相应）

故障定位

1, 首先查看相应的日志：
/data/logs/chewenwww/stdout.log   正常信息日志
/data/logs/chewenwww/stderr.log   异常信息日志
/data/server/resin/log/jvm-default.log resin的日志
查看resin的日志发现在车resin重启之前有如下日志：
java.util.concurrent.TimeoutException: Timed out(1000) waiting for operation
        at net.rubyeye.xmemcached.XMemcachedClient.latchWait(XMemcachedClient.java:2230)
        at net.rubyeye.xmemcached.XMemcachedClient.fetch0(XMemcachedClient.java:513)
        at net.rubyeye.xmemcached.XMemcachedClient.get0(XMemcachedClient.java:879)
        at net.rubyeye.xmemcached.XMemcachedClient.get(XMemcachedClient.java:837)
        at net.rubyeye.xmemcached.XMemcachedClient.get(XMemcachedClient.java:848)
        at net.rubyeye.xmemcached.XMemcachedClient.get(XMemcachedClient.java:870)
        at jp.gummy.service.cache.MemCacheManager.get(MemCacheManager.java:88)
        at jp.gummy.tools.common.cache.MCache.get(MCache.java:304)

查看stdout.log 也发现有 zookeeper 重新链接的日志
[03 04:17:02,860 INFO ] [main-SendThread(10.3.63.205:2181)] zookeeper.ClientCnxn - Client session timed out,
have not heard from server in 21688ms for sessionid 0x2441aa450100345, closing socket connection and attempting reconnect

就此认为是网络的问题。

后经过排查，发现网络也没有什么大的问题。

2，查看慢查询日志

经过查询慢查询日志，发现有一条根据手机号码查询user对象的语句
    @SQL("select "+ALL_FIELD+" from " + TABLE_NAME
            + " where phoneNum = :1 ")
    public CwUser getCWUserByPhoneNum(String phoneNum);
经过客户端查询分析，此语句查询很慢。

这个时候以为大概就找到原因了，可不太明白为什么一条慢查询怎么就导致了服务的变慢，而且查询
日志发现这条语句的执行频率也不是太高。

故障重现分析

1, 将线上的206web服务拿下来，模拟用户点击使用手机号登录，模拟慢查询的操作。点击两三次以后发现， 206的web服务不在相应。
2, 增加gc的日志记录, 在/data/server/resin/conf/resin.conf 配置文件中增加gc的日志。如下
      <jvm-arg>-Xms4096m</jvm-arg>
      <jvm-arg>-Xmx4096m</jvm-arg>
      <jvm-arg>-Xdebug</jvm-arg>
      <jvm-arg>-Xss512k</jvm-arg>
      <jvm-arg>-XX:PermSize=256M</jvm-arg>
      <jvm-arg>-XX:MaxPermSize=512m</jvm-arg>
      <jvm-arg>-XX:+PrintGCDetails</jvm-arg>
      <jvm-arg>-XX:+PrintGCTimeStamps</jvm-arg>
      <jvm-arg>-Xloggc:./log/gc.log</jvm-arg>

3，查看gc的log发现，在点击完登录以后(手机号为：abc，密码为：123456)。jvm模型中的年老代持续增加。
   gc日志路径 /data/server/resin/log/gc.log
310.815: [GC [PSYoungGen: 838342K->12272K(1100672K)] 1214764K->406864K(3896896K), 0.0308350 secs] [Times: user=0.09 sys=0.02, real=0.03 secs]
23268.488: [GC [PSYoungGen: 821872K->16666K(1119360K)] 1216464K->412505K(3915584K), 0.0302600 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
24054.566: [GC [PSYoungGen: 849818K->18987K(1111872K)] 1245657K->420547K(3908096K), 0.0275740 secs] [Times: user=0.14 sys=0.01, real=0.03 secs]
24251.516: [GC [PSYoungGen: 852139K->269605K(735744K)] 1253699K->1161827K(3531968K), 0.4672150 secs] [Times: user=4.31 sys=0.35, real=0.47 secs]
24254.009: [GC [PSYoungGen: 735717K->460824K(932096K)] 1627939K->1618868K(3728320K), 0.4211430 secs] [Times: user=4.06 sys=0.15, real=0.42 secs]
24255.917: [GC [PSYoungGen: 926936K->463479K(932096K)] 2084980K->2083985K(3728320K), 0.5223580 secs] [Times: user=4.91 sys=0.28, real=0.52 secs]
24258.026: [GC [PSYoungGen: 929591K->465319K(932096K)] 2550097K->2549705K(3728320K), 0.5334350 secs] [Times: user=4.93 sys=0.35, real=0.53 secs]
24260.064: [GC [PSYoungGen: 931431K->465972K(932096K)] 3015817K->3015163K(3728320K), 0.5280580 secs] [Times: user=4.89 sys=0.36, real=0.53 secs]
24260.592: [Full GC [PSYoungGen: 465972K->217778K(932096K)] [PSOldGen: 2549191K->2796224K(2796224K)] 3015163K->3014002K(3728320K) [PSPermGen: 127322K->127322K(264832K)], 4.9594160 secs] [Times: user=4.88 sys=0.08, real=4.95 secs]
24266.419: [Full GC [PSYoungGen: 466112K->466112K(932096K)] [PSOldGen: 2796224K->2796224K(2796224K)] 3262336K->3262336K(3728320K) [PSPermGen: 127322K->127322K(262144K)], 4.8840250 secs] [Times: user=4.87 sys=0.01, real=4.88 secs]
24271.304: [Full GC [PSYoungGen: 466112K->340903K(932096K)] [PSOldGen: 2796224K->2796223K(2796224K)] 3262336K->3137127K(3728320K) [PSPermGen: 127322K->125606K(262144K)], 6.4299960 secs] [Times: user=6.42 sys=0.01, real=6.43 secs]
24278.162: [Full GC [PSYoungGen: 466112K->466112K(932096K)] [PSOldGen: 2796223K->2796223K(2796224K)] 3262335K->3262335K(3728320K) [PSPermGen: 125607K->125607K(262144K)], 4.9364420 secs] [Times: user=4.93 sys=0.01, real=4.94 secs]
24283.109: [Full GC [PSYoungGen: 466112K->466112K(932096K)] [PSOldGen: 2796224K->2796224K(2796224K)] 3262336K->3262336K(3728320K) [PSPermGen: 125607K->125607K(262144K)], 4.9332780 secs] [Times: user=4.93 sys=0.01, real=4.93 secs]
24288.042: [Full GC [PSYoungGen: 466112K->449133K(932096K)] [PSOldGen: 2796224K->2796223K(2796224K)] 3262336K->3245357K(3728320K) [PSPermGen: 125607K->125606K(262144K)], 6.4916020 secs] [Times: user=6.48 sys=0.01, real=6.49 secs]
24294.579: [Full GC [PSYoungGen: 466112K->461216K(932096K)] [PSOldGen: 2796223K->2796223K(2796224K)] 3262335K->3257440K(3728320K) [PSPermGen: 125617K->125617K(262144K)], 6.5066020 secs] [Times: user=6.50 sys=0.01, real=6.50 secs]
24301.100: [Full GC [PSYoungGen: 466112K->466112K(932096K)] [PSOldGen: 2796223K->2796223K(2796224K)] 3262335K->3262335K(3728320K) [PSPermGen: 125617K->125617K(262144K)], 4.9549900 secs] [Times: user=4.94 sys=0.01, real=4.95 secs]
24306.056: [Full GC [PSYoungGen: 466112K->466112K(932096K)] [PSOldGen: 2796223K->2796223K(2796224K)] 3262335K->3262335K(3728320K) [PSPermGen: 125617K->125617K(262144K)], 4.9524090 secs] [Times: user=4.94 sys=0.01, real=4.95 secs]
24311.013: [Full GC [PSYoungGen: 466112K->466112K(932096K)] [PSOldGen: 2796223K->2796223K(2796224K)] 3262335K->3262335K(3728320K) [PSPermGen: 125617K->125617K(262144K)], 4.9518770 secs] [Times: user=4.94 sys=0.02, real=4.95 secs]

发现年老代的占用空间几乎达到 100%， PSOldGen: 2796223K->2796223K(2796224K)]。这个很让人费解
日志格式说明参考: gc.jpeg 和 fgc.jpeg

4，再次模拟上述测试环境，在 stderr.log中发现如下：

Caused by: java.lang.OutOfMemoryError: Java heap space
    at com.mysql.jdbc.MysqlIO.nextRowFast(MysqlIO.java:1632)
    at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1409)
    at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:2886)
    at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:476)
    at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2581)
    at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1757)
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2171)
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2568)
    at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2113)
    at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2275)
    at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
    at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
    at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:648)
    at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:591)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:641)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:670)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:678)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:710)
    at net.paoding.rose.jade.provider.jdbc.JdbcImpl.query(JdbcImpl.java:67)
    at net.paoding.rose.jade.provider.jdbc.JdbcDataAccess.select(JdbcDataAccess.java:79)
    at net.paoding.rose.jade.core.SQLThreadLocalWrapper.select(SQLThreadLocalWrapper.java:48)
    at net.paoding.rose.jade.core.SelectOperation.execute(SelectOperation.java:66)
    at net.paoding.rose.jade.core.JadeDaoInvocationHandler.invoke(JadeDaoInvocationHandler.java:128)
    at $Proxy35.getCWUserByPhoneNum(Unknown Source)
    at com.chewen.chewen_user.biz.impl.CwUserBizImpl.getByPhoneNum(CwUserBizImpl.java:68)

由此猜测是否是查询的结果是很多条记录？？？？？？？导致堆栈溢出呢

故障推论验证

1, 通过mysql客户端发现，查询
mysql> select count(*) from user where phoneNum="abc" ;
+----------+
| count(*) |
+----------+
| 5115771 |
+----------+

有大概五百多万条记录，将查询条件更改为其他字符时，发现结果一样
mysql> select count(*) from user where phoneNum="abcdef" ;
+----------+
| count(*) |
+----------+
| 5115771 |
+----------+

推测，难道是mysql查询时将字符串转为Bigint格式的时候转为0了？
mysql> select count(*) from user where phoneNum=0;
+----------+
| count(*) |
+----------+
| 5115771 |
+----------+

结果一样。

到此，真相大白了，因为数据表结构中phoneNum是Bigint类型的，而查询的时候如果是字符串则将
字符串转化为了Bigint格式，转为0了。导致了上百万条记录的返回，导致jvm堆栈溢出。

jvm gc format: http://blog.csdn.net/lxb_champagne/article/details/9006593

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

Scrum敏捷实践之旅系列（一）用户故事概念 - 敏捷达人

Sun, 19 Jul 2015 10:34:00 CST

敏捷开发对需求规划的要求是很高的，首先需求是打散的，一个大的项目需求会拆分成很多小的功能完整的需求，以便排定优先级去逐个实现，敏捷开发提升了开发效率，但是对需求规划的要求更高了，就是对产品的需求规划能力提出了更高的要求，必须有清晰的思路，很强的需求规划能力才行，这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计。

敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的。

一、什么是用户故事？

用户故事就是定义用户所需功能的文字描述，简单说就是用户的需求。一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

二、用户故事的描述

建议采用两种方式来进行用户故事的描述，用户可以任选一种：

作为<用户角色>，我需要<功能>，以实现<业务价值>
为实现<业务价值>，作为<用户角色>，我需要<功能>

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

注意事项：

用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

三、用户故事与任务、测试等对象的关联

每个用户故事与多个开发任务、变更、缺陷（Bug）、测试用例和测试历史相关联。

1、与任务的关联

用户故事通过任务来实现。实际开发工作比用户故事更琐碎。实际上，每个故事都是多项任务的集合。把故事分解成多个任务，安排到人，完成了所有的任务，就意味着实现了用户故事。

2、与变更的关联

敏捷开发就是鼓励大家“拥抱变化”，每次用户故事变更都做记录，与相应的用户故事相关联，这样方便整个团队了解用户故事的来龙去脉，减少重复劳动。

3、与测试用例的关联

每个用户故事开发完成需要进行测试，测试工程师应当为用户故事编写一个或多个测试用例。

4、与测试历史的关联

记录用户故事经历了哪些测试，测试的结果和处理情况如何。

5、与缺陷（Bug）的关联

记录用户故事发生的缺陷，查看缺陷的处理情况。

这篇就先写到这里，下一篇继续用户故事的验收标准和用户故事编写原则的撰写，初学乍练欢迎大家前来拍砖。

（注：部分图片来自www.ScrumArts.com ，可随意传播）

本文链接： Scrum敏捷实践之旅系列（一）用户故事概念，转载请注明。

从解决Redis访问超时的问题谈起——故事比结果要精彩

Sat, 17 Jan 2015 15:50:31 CST

这周终于解决了Redis访问经常超时的问题，终于可以踏实睡觉了。从上周就开始纠结在这个问题上，可以用寝食难安来形容，感觉这个问题就像个定时炸弹一样，虽然根据手搜的访问量，极少的Timeout Error对用户基本不会造成影响，但是这种问题如果不及时遏制导致Redis整体被拖慢造成的危害是相当严重滴！毕竟在手搜的架构中，Redis是极其重要的一环。

先来讲个故事（说说问题上下文），有兴趣来手搜工作的Python程序员认真听：

前段时间我们新上了个业务，为了满足需求我们对进程级的cache做了些改动，根据业务对cache key进行了拆分，导致的情况是同一份数据会被缓存多份，只因为展示类型不同（可简单理解为不同的展示用的key不同，数据相同）。有经验的同学应该能够想到这么做的结果会是怎么样的——同一份数据会请求两次Redis（因为cache key不同）。(可以看的出来，对于多种展示需求的业务在展示层做cache并不合适）功能测试没问题，so，上线。晚高峰来了。运维同学和值班同学被报警短信“轰炸”了，大量应用服务器端口访问超时（Nagios监控）。因为那天只有我们的改动上线了，所以可以定位为我们代码的问题。遂，备机上。次日看日志发现大量的Redis的Timeout Error（timeout=1s），虽然日志中在我们这个系统上线之前就已经存在很多这种日志，显然我们这次改动的上线加剧了这一状况。

从直观的感觉上，我们的功能导致Redis请求增多，因此这时就聚焦在如何较少Redis的请求上。在分析了一个页面的加载到底会请求多少次Redis之后发现一个很大的问题，因为针对具体业务的设计，一个页面在加载时访问Redis的次数跟页面上展示的内容成正比。因此页面上的内容越多，对Redis的请求会越频繁，因此一次正常的页面访问很可能会产生100次甚至更多的Redis请求。问题已经很明显了，因为这种设计，必须完全依赖本地缓存，无缓存情况访问页面的速度是不可接受的。

知道问题在哪就好办了，经过不断的思考和尝试，找到一种方案。减少页面上的内容肯定是不行的，那么就只能合并请求了。

说了一大堆，其实问题的本质在于要把之前串行的Redis请求换成并行。另外值得一说的是Redis本身的响应是非常快的，另外还有一些时间消耗在网络上。串行换成并行的方案可以简单理解为把之前的: GET 1, GET 2 换成: MGET 1 2 这样。改完之后在无缓存的情况下页面加载时间几乎提升了一倍。 OK，既然可行，那就测试，在测试，上线。Yeah！没人被短信轰炸。

你以为故事到这里就结束了，那就太Naive了。Nagios监控只是用来看端口访问是否符合预期的（1s内响应），并不能发现所有的问题。

上线几天之后发现状态码为500的情况增多了，且波动很大。So，继续看日志（有人问，你们不是用Sentry吗？为毛看日志？呃，内个，内个，业务调整...)。咱们还是来看日志吧，依然是大量的Timeout Error，还是Redis的问题。依据上面的方案我们已经完全减少了Redis请求次数，为何还是慢。

有兴趣的同学可以思考下，为何还是慢？之前的方案会造成哪种影响。

喝口水，继续讲故事：（终于明白知乎上为何经常有人讲故事了，讲故事原来比写正经文章要容易）

为何还是慢呢？之前的改动相当于是把100次请求合并成1次，造成的影响是，虽然减少了网络上的耗时，但是会增加Redis的耗时。假设之前每次请求读10个key（mget），合并成1次请求就变成一次读取1000个key。这块可能是问题原因，那么继续定位吧。要怎么确定呢？Redis并不熟，但是MySQL有Slowlog，Redis应该也有。于是找到了几个命令:
CONFIG GET slowlog-log-slower-than  (10000us,Redis中的执行单位是微秒，相当于10ms）
CONFIG GET slowlog-max-len  （最多存储128条慢日志，应该是默认的吧？）
SLOWLOG LEN   (128, 靠，存满了）
SLOWLOG GET   (默认去10条)
然后看到了慢日志出现的频率非常高！并且MGET命令中key的数量相当大——1w多（不是上面那个方案导致的），执行耗时在50ms左右。好了，再次Get到问题所在，解决吧。然后发现无法从这个日志上去找是哪个项目产生的，因为Redis不记录这个日志产生的client ip。现在回忆知道是哪台服务器发的请求也定位不到。因为这种错误的产生就不是正常业务逻辑代码产生的。

具体调试过程简单概括为：在所有可能产生巨量MGET请求前添加判断，打印log到sentry（没错，我们又上了Sentry服务），主要还是在获取列表的部分（其实最后查到问题的根源完全跟列表没关系），依然没有捕获到任何日志。于是开始到Redis服务器tcpdump所有请求，定位到一台服务器，至少知道了是哪个项目产生的。然后就是运气了，不断的查看正常访问日志。终于发现了问题。太TMD走运了，那一刻都要哭了。这个结果完全不在所有的预料情况之中。

从MGET的key上可以发现所有的新闻都是属于某一个频道，所以我们的预期是这些请求一定是在访问这些新闻所属频道列表页面时产生的。最终发现跟列表页面没半毛钱关系。

看吧，这就是“大型”系统了，充满了不可预测。这样真的不好！

这个问题产生的原因是某个页面中有一部分内容是可以指定获取某频道数据的，但是这部分内容又是存在Redis中的。好吧，之前完全没考虑到会有这种间接的请求。

知道具体问题了，顺藤摸瓜，找到了对应的存在Redis中的内容，奇怪的是这部分内容没有设置要从某个频道获取多少条数据。这个内容的模型大致是这样的:
class Content:
    channel = int()
    data_size = int()
设置了频道，没设置要获取的数量，默认是0。

故事结束，来看代码。

假设我的这个blog系统用的是Redis，那么怎么处理某个频道的分页呢？因为是非关系型数据库。因此在存储数据的时候，我得这样:

import redis

cache = redis.StrictRedis(host='localhost', port=6379)

for post in posts:
    cache.set('blog:post:%s:title' % post.id, post.title)

    cache.zadd('blog:channel:1'，time.time(), post.id)

这样存下去如果我要从这个频道（假设id为1）下获取十条数据:

start = 0
count = 10
post_ids = cache.zrange('blog:channel:1', start, start + count - 1)
post_tiltes = cache.mget(map(labda _id: 'blog:post:%s:title' % _id, post_ids))

这样的代码有问题吗？

咋看之下没有问题，因为redis的zset是从0开始计数的，获取10个元素，那就是0到9。那么看下这个描述:

Both start and stop are zero-based indexes, where 0 is the first element, 1 is the next element and so on. They can also be negative numbers indicating offsets from the end of the sorted set, with -1 being the last element of the sorted set, -2 the penultimate element and so on.

大意是，索引从0开始，-1表示最后的一个位置。因此如果你想获取某个频道（id为1）的所有文章id就是这样:

post_ids = cache.zrange('blog:channel:1', 0, -1)

因为-1表示最后一个元素的位置。

再回到上面故事的结尾，那块内容要获取的频道新闻数量为0，而我们的代码和我写的类似，没对这种-1可能性做判断，因此一次就取出来频道下的所有新闻，so，产生了那个结果。

总结时间

在复杂的业务下的复杂的系统结构中，要找到一个隐藏的问题确实不容易，因为写代码的人不断的变化，负责业务的人也在不断变化，最后都不知道这个业务为何存在，是否还在使用，也不知道这段代码是否正常，毕竟每个人还在负责新的业务，不断的添加新的代码。这样的结果就是系统进一步复杂，这样下去的结果就是再经过几年人员的变迁之后，任何一个人想要理解这个系统（这些系统）中的业务逻辑，代码逻辑都将变的十分困难。

代码应该是历史的结果，不应该把历史平铺到代码中，git log才是历史应该存在的地方。说人话就是:业务的增加不仅仅是增加代码，有时也是要对现有结构进行抽象和重构。

故事点估算，这真的是问题吗？

Mon, 26 Jan 2015 22:48:35 CST

用户故事的估算总是不准确的，这是估算的第一要义。正因为此，我们才不能在故事估算上耗费太多时间。估算不应该由个人来进行，团队的 Planning Game 不可缺少。在估算用户故事时，不应该估算时间，而应该估算用户故事的规模。同时，在团队进行估算时，团队应对“Done”的定义达成一致。

我把这称为用户故事估算的四要素。——然而，即便你掌握了估算的要素与原则，掌握了正确的估算方法，就一定能解决故事估算的问题么？

“故事的估算是按照时间来的，这是一个大问题！”我的一名咨询客户有些心急火燎，迫不及待想要我帮助她解决这个麻烦。可在我看来，这根本不是什么问题。即便是按照时间进行估算，只要团队成员足够了解用户故事，并以团队形式开展估算，得出的工作量仍然可行。在“估算总是不准确的”大前提下，我们只需要让计划时间更接近实际工作时间即可。方法有很多，例如可以通过历史数据对估算进行调整，以及事先识别可能存在的风险等多种措施来做到这一点。

但是客户并不这样认为。——好吧，我需要实地调研。

问题是起点，如果你只看表面，绕了一圈，你还是会回到起点；只有深度挖掘背后的起因，你才能走到问题解决的终点。

当我看到用户故事

当我拿到客户编写的用户故事时，我忽然明白问题所在了。用户故事的编写显然是照猫画虎描出来的。用户故事的所有要素它都具备了，然而却只得其形，却未得其神。用户故事如下：

as 一名顾客

I want to 进入商品清单后

So that 进行查询

-

Given 顾客

When 进入商品查询页面

Then 系统执行查询

  用户故事的末尾，则是一大段针对界面操作流程的描述。

“知其然而不知其所以然”，对于许多敏捷实践，我们就这般浑浑噩噩地推行着，以为这是更好的方法，却从未有人去质问“为什么”。当问题暴露时，常常是头痛医头，脚痛医脚，直至病入膏肓，尚且不知病因究竟出在哪儿？

软件开发本身就是一个生态系统，诸多方法与实践其实并不能孤立去看待。这个系统的任何动作与活动，就像是蝴蝶扇动翅膀，飘飏起南美热带森林的季风，殊不知它却掀起了印度洋的飓风。

为什么是用户故事？

在传统的软件开发过程中，我们称需求为功能点，而 Jacobsen 则将需求提炼为用例（Use Case），在 FDD（特性驱动开发）方法中，又将功能点称为 Feature，至于 Scrum，则干瘪瘪地将其命名为 Backlog。但我，更喜欢以用户故事名之。

描述需求就像讲述故事一般的明白晓畅，甚至做到让故事的读者能够身临其境。虽然不要求将软件需求写得像古龙小说般精彩，但最好也要能做到像白居易诗一样童叟可读。其实简单说来，就是要让需求能够让人读得懂，

讲故事需要哪些基本要素？答案是 6W，即 Who、What、Why、When、Where 和 hoW。具备这六个要素，就能讲述出一个活灵活现的故事了。6W 撑起了一个场景。戏台的布景装饰出景色，演员们身着戏服演绎着春秋，演绎着人生百态与喜怒哀愁。

写用户故事当然不能天马行空。要学会取舍。高手当然可以信手拈来，若未深得其中精髓，就该退而求其次，遵循普遍被认可的模式为好，例如 as...I want to ... so that，又例如 given...when...then。

模式或许限制了你的自由发挥，但它的引导价值却可以让你快速上手。但首先你得明白这样的模式背后隐藏的道理。之所以明确提出 as...I want to...so that... 就是希望需求分析师在分析用户故事时，要思考功能的使用者是谁，要做什么，价值又是什么？这恰好对应了 6W 的 Who、What 和 Why。就像拍电影一样，我们总是要从人的角度去讲故事，去观察世界，体察人与人之间的关系。而在最后的制作阶段，则要从整部电影的风格、价值观、故事着手对内容进行裁剪。即使部分拍摄片段唯美而精彩，演员表演也极到位，若与整部电影发生冲突，导演也要忍痛割爱。需求分析师也需要站在用户的角度去体验需求，寻找业务的价值。

Given...When...Then 的驱动力

许多敏捷实践其实是诸多工程师千锤百炼得来的体验。这些体验如智者，一言一行，都别有深意。采用 Given...When...Then 模式，实则代表了接口设计的驱动力。这正是 ATDD 以及 TDD 的惯用手法。

Given 是什么？就像契约式设计一般，它等同于前置条件。从接口角度讲，就是输入数据。当满足这些条件（无论是数据，还是状态）后，就可以执行动作了。When 就是这个动作，其实就是我们需要开发的功能，又或者说，正是我们要驱动出来的接口。至于 Then，就是后置条件，也即是我们所谓的验证。这就很好地与测试结合起来了。

在编写 Given...When...Then 时，我们要注意，只有 Given 与 Then 可以通过 and 连接更多的内容。 When 只能是一句话！

为什么？——让我们回到场景。在编写用户故事时，需要从用户角度出发，驱动出故事发生的场景。如果说故事是整部话剧，场景就应该是话剧的一个相对完整的片段。在用户故事级别，场景应尽可能保持小。就像 SRP（单一职责原则）讲的那样，最好一个场景只做一件事情。一旦发现在编写 When 时，无法用一句话表达，就应该思考，是否需要对该场景进行进一步拆分。

场景又可分为正常场景与异常场景，正如 Use Case 中提出的正常流程与异常流程。例如，以查询来说，正常场景就是查询获得了符合给定条件的记录。异常场景则可能包括两个。第一个是没有符合条件的记录；第二个则是查询过程发生异常，从而导致查询失败。

场景还可分为主要场景与扩展场景，可以对应 Use Case 中的用例与扩展用例。还是以查询为例，主要场景就是查询获得符合给定条件的记录；扩展场景则是查询结果默认以名称进行升序排列，并允许用户对指定字段重新进行排序。

用户故事的 INVEST 原则

当我们按照场景去编写用户故事时，我们会自然而然地去思考故事的拆分。有些场景可能确乎属于同一个故事，但当你发现一个故事包含了太多的场景时，就可以考虑把这些场景分开。例如把正常场景与异常场景分开，把主要场景与扩展场景分开，皆可。那么，我们该怎么对用户故事进行拆分？这就需要运用 INVEST 原则了。

只要了解用户故事，多数人都知道 INVEST 原则，可惜却没能将这个原则用好。如下是 INVEST 原则的说明：

I——Independent
N——Negotiable
V——Valuable
E——Estimable
S——Small
T——Testable

我个人的理解是将这些原则分为几个层次。首先是 Valuable，即判断一个用户故事是否为好的故事，关键在于它是否提供了价值。这个价值指的是业务价值。若一个用户故事没有业务价值，要么需要删掉，要么就说明它不是故事，而应该是任务（Task）。

在满足了V原则后，就需要判断I。I是判断用户故事的独立性。理想的故事拆分应保证故事之间不存在依赖。如果存在依赖，就需要去识别产生依赖的原因。多数情况下，都是由于支撑性功能带来的依赖。例如两个用户故事都需要发送邮件通知客户。若完成了其中一个用户故事，则另一个用户故事就不必重复开发邮件通知功能了。此时，我们可以考虑将邮件通知（可能还包括邮件模板）拆分为单独的故事或任务。我们要尽量地保证用户故事的独立性，只有在无法继续拆分以隔离依赖的情况下，我们才能选择妥协。

接下来再考虑N。我们希望用户故事是描述清楚的，可以促进客户与团队以及团队成员之间的沟通。故事描述最好没有歧义。有时候，为了更好地说明故事，可以引入实例或者 UI 原型。基于这些故事，我们需要更好地与客户协作，明确满足客户的需求。

有了明白晓畅的故事描述，再来判断这个故事是否可测。故事是可测的，就意味着它定义了验收标准。只有通过了验收标准，故事才可以被标记为“Done”。若故事不具备可测试性，则用户故事不过就是平铺直叙的故事描述而已。毕竟，用户故事不是小说。

最后，我们应该合起来看待E和S。因为一个用户故事到底小不小，最直观的判断就是看它能不能被估算。如果很难估算，要么是故事没有描述清楚，要么是这个故事太大。太大的故事总是很难掌控，而功能点的叠加并不只是一加一那么简单。无论何时，分而治之都是软件开发的“不二法门”。

与其说 INVEST 是用户故事的拆分原则，不如说它是衡量一个用户故事好坏的验收准则。

验收条件（Acceptance Criteria）

在提及用户故事的 Testable 原则时，我其实有些意犹未尽。这未尽的内容就是验收条件。很多需求分析师都把它忽略了，又或者散乱地将这些验收条件分散到需求描述中。其实，在传统的制造行业，在软件开发的测试环节，我们一直都遵照着验收条件来办事。但是，对于多数需求分析师而言，他或者她可能更关注用户体验，功能细节，或者业务目标与范围，却往往缺乏逆向的思维去思考验收条件。这也是为什么我们提倡 BA 与 QA 结对编写用户故事的初衷。

验收条件可以说是沟通的“契约”，使得我们的用户故事能够成为一个“闭环”。验收条件意味着“照单验收，立此存照。”

我们可以为用户故事的每个场景编写各自的验收条件，也可以为整个用户故事编写一个整体的验收条件。验收条件必须简单清楚，每条内容都应该是可验证的。例如针对查询功能而言，我们可以写出如下验收条件：

查询结果默认以名称升序排列；

当查询结果超过 20 条时，应进行分页考虑；

分页条数的阈值可以进行设置；

如果没有查询结果，应提示“无满足条件的结果集”。

如果查询失败，应弹出“查询失败”的错误框，并在错误框中给出错误原因。

……

只有编写出好的符合 INVEST 原则的用户故事，才谈得上对用户故事进行估算。估算并不能帮助你提升团队的生产效率，更不能以估算的点作为团队及团队成员的量化指标。估算是天气预报，它唯一的作用就是提醒你明日出行带伞还是不带伞。如果带了伞，却没有雨，你也不必抱怨；如果没带伞，却下了雨，那就慢慢享受雨水的清凉吧。当然，若遇上大雨倾盆，那就找个地儿歇歇吧。你总不能因为天气预报让你饱受了淋漓之苦，而视天气预报为仇寇吧。

本文链接

技术合伙人的故事

Thu, 26 Mar 2015 11:50:38 CST

很多人说百姓网的技术很牛，其实我不觉得牛在哪里，不过有一件事情我自己一直引以为傲，那就是在我们技术团队中诞生了5个以上的技术合伙人，还有更多的人加入了其他创业公司成为了骨干。记得以前有位资深的管理者跟我说，不要总是和下面的人谈创业，谈了他们出去了怎么办？一开始我还真的犹豫了一下，但是后来我想明白了，首先不是你不说了他就不会去创业，愚民政策是没有用的。其次是有人出去了，他说你这里好，才会有更多的好人来。再说一个十年的公司，怎么可以没有人走出去呢？最重要的是，我们需要的是一个人的心，而不是一个人的手，人需要把公司的事情当作自己的事情来做，这个就叫“创业”。

今天我就来谈谈作为一个技术合伙人，经历的3个故事。

迷你朝歌

一个小时内写出一个分类广告网站？这似乎是一个不可能完成的任务吧。但是只要接受我们的training，你肯定可以在一个小时内写出来，当然你要花1天？2天？3天？还是以上呢？按照我们的测试成绩，如果能够在1天内完成，你必然是技术的绝顶高手，百姓网只有1个人达到这样的素质，一般在2天之内写出来的同学，已经算得上是技术不错的同学了。3天是及格线，如果超过3天了，那么基本上可以被淘汰了。没错，基本上，我们最核心的十几名技术人员，全是这样被train出来的。

说起这个迷你朝歌的来历，还要说到我和ceo的代码pk，没错，我们的ceo是写代码的，而且悲剧的事情是他写得还比我好。我从05年加入百姓网的时候，主要任务是招聘人员，然后项目控制，但是随着各种需求的堆积，代码越来越烂，当时最差的时候，几个人看见一段代码谁都不敢下手。由于我之前的工作经历都是在外包公司的，相信的是按部就班的开发步骤，所以ceo说1小时内开发出来，我是不相信的。然后我们两个pk一下哪个代码更快更好，经过一个多星期的pk，最后我发现他的代码真的比我的要好，这是对我的世界观的颠覆。建硕的那句话叫做：你用的是微软的开发方式，而谁都知道微软在互联网时代的处境，这就是用一种落后的思维来做一个新的东西，怎么能够赢呢？

感想：
技术合伙人的技术很重要，但是他的思路不能老，用软件思路做互联网，或者用互联网思路做移动互联网，最后只能把团队带到沟里面。

一封邮件

有一段时间工作特别忙，天天都是12点以后走的，最主要是忙得还没有成就感，而且还看不到头。我相信任何一个技术人员都会经历这样的过程，当时我记得做了一件傻事，就是我发了一封邮件给ceo，意思就是说，你看工作这么多，这么累，大家都这么苦，这么勤奋，可是我不是很开心，和女朋友的关系也不是很好，身体也不是很好，吧啦吧啦。现在想想都觉得好笑，但是就是这么发了。

接下来ceo又来找我了，把我骂了一顿，说你这个叫naiive，当时我懵了，我想我说的都是事实啊，可是我忘了一件事情，我没有给出解决方案。所谓的正能量和负能量最大的区别就是有没有解决方案。愤怒是无能的表现。现在看来的话，这个问题很简单，工作量太大，首先是产能是否足够？产能分成人数和生产效率，如果人数不够就要招人，如果效率下降就要提升效率，调整团队结构，做team building，或者项目攻关等很多种方式。其次是否有很多不需要做的工作，没有成就感的工作，是不是所有的工作都要做，是不是需要进行协调？技术合伙人之所以是合伙人，和其他团队的沟通协作是重要的部分，甚至可以占到一半以上。

感想：
愤怒是无能的表现，无能是因为有框，打破了框框之后就有解了。明确别人的期待，千万不要活在自己的假设之中，对于技术合伙人来说，不是管理好团队就好了，更重要的角色是业务中的技术视角。

天生要快

2011年在qcon上做了一次关于百姓网速度优化的演讲，反响很热烈。这中间背后最主要的原因是我们确实花了1年多的时间进行了速度上的很多工作，取得的效果也是非常显著的，由于在这个上面尝到了甜头，所以我们就持续做这个事情，甚至做到了一些非常之极端的做法，速度是我们的重要考核指标，以至于我们网站上出了用户发的照片以外，没有一张的图片，连我们的logo都改成了文字，后来从alexa上的监控看，我们的速度比google，baidu都要快，唯一还没有赶上的就是craigslist。

可是后来我们发现就算我们再继续努力，能够优化的空间变小了，同时取得的效果也不那么明显了。试想已经几百毫秒了，用户已经几乎分不清楚差别了，很多的优化都有一个临界点，这个临界点就是触发用户感觉的地方，也就是很多事情只要做到足够好就行了，不一定要做到极致的。还有一个因素是，当年南北互通问题是大家都非常头痛的问题，可是随着互联网基础设施建设的提升，大家的带宽越来越大，这个问题就慢慢不是问题了。倒是现在的移动互联网的h5页面速度可能还是问题。

技术在现在大多数创业公司里面的角色还基本上都是支持的角色，真正能够让技术变成业务推动力的情况是很少的。对于百姓网，我看到的少有的能够以技术称为巨大推动力的，一个就是网速称为瓶颈的时代，但是随着时代的变迁，他也变的不是了。另外一个领域就是antispam领域，这个地方好玩的就是因为你是和人在斗，你的对手永远都在升级，防作弊是一个道高一尺魔高一丈的过程，这个时候技术就会变得很重要了。

今天的bing的技术可能已经和google的差不多了，但是大部分人还是习惯用google。当大家都缺少搜索的时候，google领先了那么几年的技术，那就占据了人的内心的那个位置了，接下来喝google做的一样已经没有机会了，除非你要好10倍，那就是革命性的。

感想：
能够找准并且做出技术上的那个重要引擎是技术合伙人一直考虑的事情。

总结

三个故事讲完了，如果硬要讲一个中心思想的话，那就是要不断地突破自己思维上的框框。如果讲顺序的话，要先把自己的事情做好，然后帮别人一起把事情做好，最后要能够带领大家把事情做好，找技术即业务的那个结合点。

【创业有道】：3个小故事彻底激发你的商业思维

Tue, 02 Sep 2014 16:26:35 CST

平凡的生活中也不乏寓意深刻的小故事，对于创业者来讲，能够细微体会其中的深刻含义，及时评鉴背后的商业机会就是一门必修的功课。今天的三个小故事就是这样的商业锻炼。

故事一：“给我”还是“拿去”？

有一朋友，做人特别吝啬，从来不会把东西送给别人。他最不喜欢听到的一句话就是：把东西给……！有一天，他不小心掉到河里去了。他的朋友在岸边立即喊到：把手给我，把手给我，我拉你上来！这个人始终不肯把手给他的朋友。他的朋友急了，又接连喊到：把手给我。他情愿挣扎，也不肯把手给出去。他的朋友知道这个人的习惯，灵机一动喊到：把我的手拿去，把我的手拿去。这个人立马伸出手，握住了他的朋友的手。

启发思考：

“给我”还是“拿去”？我们在经营事业的过程中，是不是一直在向客户表达着“把你的钱给我”，客户就象上面那个吝啬的人，情愿在痛苦与不满足中挣扎，也不愿意把钱给我们。如果我们对客户说的是：把我的产品拿去，是否会更好一些呢？客户会更情愿地去体验你的产品，购买你的产品。“给我”还是“拿去”？这是一个问题，也是一个精明的商家是否能从客户的角度去设计成交，设计商业模式的问题。换一个角度，事业就豁然开然。

故事二：“便捷”还是“诱惑”？

我们旅行到乡间，看到一位老农把喂牛的草料铲到一间小茅屋的屋檐上，不免感到希奇，于是就问道：“老公公，你为什么不把喂牛的草放在地上，让它吃？”老农说：“这种草草质不好，我要是放在地上它就不屑一顾；但是我放到让它勉强可够得着的屋檐上，它会努力去吃，直到把全部草料吃个精光。

启发思考：

看完这个故事，你大脑里想起的一个产品会是什么？小米手机！没错，雷军就是那个老农夫，把小米手机放在屋檐上，让你勉强可以够得着，让你欲罢不能地想去够着。容易得到的，也会随手扔掉。太难得到的，有些人争取一会儿就放弃了。只有勉强得到的，意外得到的，人们就会感到惊喜，倍感珍惜。

这让我又想起一件事情。我的一个客户，经营服装店，开业的时候做出了很多代金券，到处免费发放，结果发现转化率出奇的低，来的人寥寥无几。她怎么也想不明白，自己请了一个团队专门发传单，结果却不佳。我告诉她：轻易得到的，人们就不会珍惜。于是，我们一起想了一个办法，把这些代金券不再送了，而是卖出去。天啦，我们要卖代金券？太搞笑了！但是事实证明我们对了！

怎么卖呢？我们找到小区的便利超市，找到美容会所，找到美发店，找到各种各样能接触到年轻女性的店。告诉他们的店员，我们的优惠券让她们来卖， 卖来所得的钱，全部归她们所有。通过卖优惠券的形式，我们发现，人们来店里的概率大大增加。也许人们只是花5元钱买了一张100元的代金券，但这5元钱会促使他来店里消费。

想让客户记得你？你可以变着法子让客户为你付出一些，轻松付出一些。客户会惦记着自己的付出，从而惦记着你！“便捷”还是“诱惑”，艺术地使用吧！

故事三：他真正想要什么？

有一个富翁，一个人住着一栋豪宅。年纪大了，想回到老家居住，与其他老人一起打打牌，下下棋，心灵上有个伴。于是他想把这栋豪宅卖掉。很多有钱人都看上了这栋豪宅，来看的，报价的络绎不绝。有一天，一个年轻人来看房，看完房子后连连称赞。富翁问他：你决定要购买吗？你想出多少价钱？

年轻人对老人家说：是的，我很想购买，但是我只有1000英磅。富翁心想：那我怎么可能卖给你？年轻人思考了一会儿，跟富翁说：我真的决定要购买。我们能商量另一个购买方案吗？富翁说：你说说你的方案。年轻人说：我愿意把我的1000英磅都给你。你把房子卖给我。同时，我想邀请你一起居住在这个房子里。你不需要搬出去。而我，会把你当爷爷一样看待，照顾你，陪伴你。

年轻人接着说：你把房子卖给其他人，你得到的只是一些钱，而钱对你来说已经可有可无，你足够富有。你把房子卖给我，你将收获的是愉悦的晚年，一个孝顺的孙子，一家人其乐融融的温情。将来我还要你见证我的婚礼，见证我的宝宝出生，让他陪着你，逗着你笑。

你可以选择获得一些可有可无的钱，也可以选择获得一个温情无比的家，一个快乐的晚年。富翁静静地听着他讲述，眼前的这个小伙子如此真诚，目光坚定，他在等待着自己做出选择。钱，他这辈子赚够了，追逐金钱也让他疲惫了，快乐才是他想要的。

3天后，富翁把房子卖给了这个年轻人，他们快乐地生活在一起！

启发思考：

这位富翁真正想要的是什么？你的客户真正想要的是什么呢？读懂客户的内心，你才能走近客户。用心与客户交往，与客户成为“知音”，你才能轻松与客户保持关系，客户也愿意在你这里消费！

当然，这个故事里也可以看到，这个小伙子非常善于利用自己独有的价值——陪伴，你是否发现，原本你认为自己一无所有，平凡普通的你，只要懂得挖掘自己的价值，善用自己的优点，一样可以在梦想的豪宅里生活！

英特尔和Linux不得不说的故事

Fri, 17 Oct 2014 23:06:50 CST

近期，Linux 宣布无人机开源软件平台项目 Dronecode。而在这个项目中，非常卖力的一员就是英特尔，另外一个是中国的百度。

虽然 Wintel 联盟是业界津津乐道的一对组合，但其实英特尔除了和微软合作以外，一直大力投入 Linux，英特尔一直是 Linux 基金会的白金级会员。

英特尔是 Linux 基金会全球第二大赞助商，同时早在 2009 年英特尔就以 6.9% 贡献份额成为 Linux 内核代码第二大提供者，英特尔更是在去年年底公布了多达 5000 页的 Haswell 文档。《开源图形程序员参考手册》涉及了 2013 Haswell HD Graphics、Iris Graphics 和 Iris Pro Graphics，其内容覆盖模式设置到 3D 引擎和 GPGPU，到性能加速器和视频加速。

英特尔为什么要大局投资 Linux 呢？因为 Linux 是一个非常重要的操作系统，它对英特尔的芯片销售起着至关重要的作用。

Linux 操作系统是 UNIX 操作系统的一种克隆系统，Linux 系统诞生于 1991 年的 10 月 5 日（这是第一次正式向外公布的时间）。以后借助于 Internet 网络，并通过全世界各地计算机爱好者的共同努力，已成为今天世界上使用最多的一种 UNIX 类操作系统，并且使用人数还在迅猛增长。

Linux 系统开源的，是由全世界各地的成千上万的程序员设计和实现的。

Linux 以它的高效性和灵活性著称，Linux 模块化的设计结构，使得它既能在价格昂贵的工作站上运行，也能够在廉价的 pc 机上实现全部的 Unix 特性，具有多任务、多用户的能力。正因为他的这些特性，尽管很多个人电脑还是 windows 系统，但 Linux 已经环绕我们周边。

1、Android 手机

现下火到爆的 Android 手机系统就是以 Linux 为基础，每天有 550000 部 Android 手机激活。550000 部有木有！光鲜的 Android 背后铁定有一个小黑影在嗤嗤偷乐！

虽然大部分手机都是基于 ARM 构架的，但由于对 Linux 和安卓的长期投入，现在英特尔的 X86 构架基本上已经可以完美的运行安卓系统。除了少数针对平台优化的游戏以外，不会有太大问题。

虽然英特尔目前移动市场份额非常小，2013 年 1 月高通 CEO 保罗·雅各布在中国接受媒体专访时表示，英特尔是个很强劲的竞争对手，其中的原因之一就是英特尔对安卓的兼容正越来越好，和谷歌的合作也越来越密切。

2、Linux 支撑着世界上大多数的超级计算机

在科学计算领域，Linux 占据着绝对重要的地位，而这些超级计算机都是 CPU 大户。我国产的超级计算机天河二号公配备 32000 颗英特尔的 Ivy Bridge 处理器和 48000 颗 Xeon Phi 协处理器。

天极网的资料显示在今年 Linux 企业级终端用户峰会上最新一期的世界最快超级计算机排行榜出炉，在世界最快超级计算机 500 强排行中，Linux 不仅占据主导地位，且将对手远远甩在身后。在世界上 500 台最快的计算机里，强劲的开源操作系统 Linux 占了其中的 485 个位子。剩下的 15 台计算机里有 13 台运行 Unix 系统。

这些高端处理器对英特尔来说都是金主，得伺候好了，所以优化 Linux 让开发超算更容易也成了英特尔份内的事。

3、Linux 支撑着大多数的 WEB 应用、数据中心

得益于云计算、大数据，英特尔的数据中心业务这些年蒸蒸日上，而大多数的数据中心使用 Linux 作为其支撑操作系统。

谷歌、Facebook、亚马逊、中国的 BAT，几乎所有的互联网公司的服务器都大量使用 Linux。

和 Linux 配套个各种工具和软件提供了我们在互联网上享受的各种服务：包括搜索、购物、数据存储、数据挖掘等等。

和这些 Linux 软件配合最好的硬件就是英特尔制造的处理器，为了让数据中心尽量不使用其他家的产品，英特尔必须让自己的硬件在 Linux 下得到最好的优化。

4、Linux 已经可以说是无处不在

除了以上这些领域，Linux 还在其他很多地方得到应用。

大多数航空交通控制系统采用的也是 Linux 系统，确保航行安全。大多数的证券交易系统基于 Linux。

2011 年 7 月，世界最大车厂丰田公司加入到 Linux 基金会，丰田汽车的车载信息娱乐系统和通信系统采用 Linux，现在路上跑的汽车里面都载着 Linux。

Linux 是如此重要，以至于当你的硬件无法和它好好配合时，可能你的产品就卖不出去了，所以英特尔会大力投资 Linux。

随着物联网时代的到来，英特尔为了不再犯像错失移动市场先机那样的错误，已经开始投资物联网领域的 Linux。

除了研发了夸克微 PC 这样的硬件产品，Linux 平台的先机也不能失去，这也是英特尔会联合 Linux 基金会投入无人机开源软件平台项目 Dronecode 的原因。

本文链接

我所经历的“余额宝”的那些故事

Mon, 02 Jun 2014 19:37:13 CST

　　一年前的现在，在杭州支付宝大楼里有个叫“春秋书院”的闭关室，里面一群紧张而兴奋的年轻人在忙碌着。项目室巨大的落地窗前，站着一个面色凝重的人，他就是天弘基金创新事业部技术负责人樊振华，一个在金融IT领域有着丰富经验的老兵。他看着窗外川流不息的汽车，深深地吸了一口气。

　　这是一个只有代号但没有名字的保密项目，内部称之为“2号项目”，2号项目的旺旺交流群的签名上写着“2013支付宝秘密武器”，足可见这个项目的重要性。

　　截止到今天，中国近亿人因为这个项目受益，改变了自己的理财习惯。这个神秘的项目，就是余额宝。那么余额宝的初期业务背景是什么呢？由此引发出对IT系统建设的需求又是什么？

　　 余额宝业务背景

　　在支付宝上卖基金的想法，在天弘基金电商负责人周晓明心中经过多次的思考和锤炼，已逐渐清晰。他在向阿里小微金服集团国内事业群总裁樊治铭介绍余额宝模式的雏形时，准备了5分钟内容，但只讲1分钟后，双方即达成一致意见可以做、快速做，并期望余额宝能在6月上线运营。

　　双方随即行动起来，进行了简单的分工，支付宝负责余额宝在支付宝端的建设工作，而基金公司端负责与支付宝对接的直销和清算系统的建设重任，就落到了樊振华头上。

　　这是一个从来没有人做过，也没有人知道该如何做的创新业务，面对支付宝巨大的用户群体，在仅不足3个月的时间内，该如何设计基金的清算和直销系统，成为了樊振华面临的头号难题。

　　2013年3月，樊振华一行与支付宝技术方进行整体架构沟通，这是传统金融行业建设思路与互联网技术路线的第一次冲突，双方在闭关室足足讨论了4天，确定下来一期系统的建设目标和要解决的问题。

　　当时主要面临以下难点。

　　1. 要能支持“千万级”用户的系统容量。

　　（1）传统的基金销售系统主要是和第三方销售机构，如银行理财专柜、网上银行进行合作销售。直销系统能够处理每天几万到几十万个用户的开户就完全够用了。但“余额宝”面对的是数以亿计的支付宝用户，用户的开户数量和并发量与传统业务有数量级的差异。

　　（2）传统基金的TA系统面对的用户是以理财为目的的申购和赎回，因此每天清算的交易笔数要求也只有几万到几十万即可满足。但余额宝的业务模式里，支付宝用户的每一笔消费，都会转化为一次基金赎回，又加上海量潜在用户群，每日清算笔数将会是传统模式的百倍甚至是千倍。

　　2. 直销系统和TA系统的融合。

　　传统的直销和TA是分别独立的系统，但对于接入支付宝这种入口交易空前频繁、数据量极为庞大的需求而言，传统的分离式文件交互方式不能满足效率和优化利用资源的要求。因此，项目组提出了功能整合、功能简化、当前库和历史库分离的技术结构。让直销和清算系统使用同一套数据库，来避免数据拷贝带来的业务时延。

　　3. 7×24小时的基金直销系统。

　　由于渠道的原因，传统基金直销系统的大多数开户出现在银行的工作日。因此系统能做到5×8小时即可满足大部分客户的需求。但互联网的属性是7×24小时，因此系统也应具备7×24小时不间断的服务能力。

　　4. 支付宝与天弘基金双方的数据传输与系统交互。

　　余额宝的直销和清算系统会部署于天弘基金在天津的数据中心，而支付宝的“余额宝”系统部署在杭州，双方之间的通信协议，远距离数据传输面临很大的挑战。

　　这样，根据早期建设需求，余额宝一期系统的架构和系统容量规划展开了序幕。

　　 一期系统建设

　　距离上线时间只有不足3个月，樊振华和系统开发商金证科技的技术人员进行了紧张的架构工作。经过数次讨论，双方有了初步的统一意见，并形成了建设目标。

　　1. 基于传统的IOE基础架构。

　　在如此短的时间内，有很多功能优化、业务流程更改等开发工作，再配合相关的测试，控制改动的范围。因此基础架构决定采用传统的HP/IBM/Oracle/EMC方案，靠使用高端硬件设备的方式，提高一期系统的整体容量和性能。

　　2. 直销和TA的系统整合。

　　（1）为减少直销系统和TA的数据传输延迟，决定两个系统使用同一套数据库架构。

　　（2）为避免单点故障引起的业务中断，应用层的直销和TA平均分布在每台服务器上，确保每个应用服务器的角色具备可替代性。

　　3. 跨省的MSTP专线链路。

　　天弘基金清算和交易中心在天津数据机房，通过架设两条4M的MSTP专线，连接到支付宝杭州数据机房。两条专线之间互为备份，确保通信链路安全。

　　一期系统的架构如图1所示。从中可见，支付宝实时开户、申购和赎回等实时请求，与每天的离线对账文件，都通过MSTP专线与一期系统进行通信。其中实时请求通过RADWARE硬件负载均衡分发到两台前置机，前置机在做完报文解析后，将请求发送到XP的消息队列。然后由BP以主动负载均衡的机制，从XP中取出相应请求进行处理，处理结果保存到后端数据库中。

图1 一期系统构架图

　　 幸福的烦恼

　　然而，在一期系统上线以后，面对业务量暴增的情况，系统遇到了瓶颈同时也出现了新的问题。

　　2013年6月13日，一期系统如期上线，业务量远超预期，给系统来了一个“下马威”。上线后数分钟内就达到了18万的用户。在2013年6月18日晚上，余额宝的用户量已突破了100万。2013年6月30日，余额宝用户数达到251.56万。

　　在如此高速的业务增长压力之下，一期系统开始面对前所未有的直销和清算压力的冲击。这个新建的系统，是否能支撑起如此大的容量冲击？什么时候系统会达到瓶颈？这些问题，悬而未解，让樊振华陷入了深深的危机感中。经过了数个失眠之夜后，他还没找到解决问题的办法，但他清楚地知道，再这样下去，一期系统将会很快面临瓶颈，成为业务增长的绊脚石。

　　樊振华的担忧很快变成了现实，随着用户量的暴增，数据库的负荷越来越高，实时请求的响应时间开始变缓。清算时间由最初的半个小时慢慢地变成一个小时、两个小时、四个小时……清算系统每天会在凌晨收到支付宝最后一笔确认文件后开始清算，天弘基金的后台运营人员会等候清算出结果以后，发送给监管行和支付宝。随着这些人回家的时间越来越晚，抱怨声开始出现，樊振华的压力也随之增大。

　　系统的扩容势在必行。然而，当樊振华收到金证科技发来报价表，打开第一页时，他惊呆了。如果依然使用IBM/Oracle/EMC的传统架构进行扩容，要达到预定目标，仅仅硬件设备采购及中间件的Licence费用就达到了数千万元人民币。这个数字对于樊振华来讲，甚至对于天弘基金这家公司来讲，是一个天文数字，超过了这家公司以往所有对于IT投资的总和。并且设备采购到货就要一个月以上，想在一期系统瓶颈出现前完成扩容几乎不可能实现。

　　传统的路线走不通，就要找新的方法。当他得知阿里云计算作为一家云计算服务提供商，使用云计算支撑了海量的互联网企业及阿里集团自身业务时，樊振华开始和阿里云计算进行接触。2013年7月，樊振华组织阿里云、支付宝、金证科技的人一起探求解决方案。最终经过慎重思考，樊振华心一横，说了句：“不要再讨论了，上云，上阿里云！”

　　 上云吧，腾飞

　　 上云之路，困难重重，举步维艰。

　　上云并非一句话那么简单，使用云计算支撑当时国内最大的基金直销和清算系统，前无古人，但开弓没有回头箭。樊振华召集了支付宝、阿里云、金证科技的人一起，启动将直销和清算系统整体迁移到云计算架构的二期系统。

　　阿里金融云为二期系统提供了的云计算服务有ECS（弹性计算服务）、RDS（关系型数据库服务）和SLB（负载均衡服务）。这三个服务分别对应于一期系统中的HP和IBM服务器、Oracle数据库和硬件负载均衡设备，但这三种服务的单个实例的性能和容量，都比相应的物理设备小上一大截。如何用单机性能更小的云计算服务来支撑那些单机性能更强都难以支撑的系统呢？经过深入的了解，樊振华在心中已有了答案：“蚁群战术”。

　　俗话说“三个臭皮匠，顶个诸葛亮”。“蚁群战术”就是要充分利用云计算服务的快速部署能力（5分钟内可以创建数百台ECS）、弹性伸缩能力和安全稳定等特性，使用水平拆分算法将应用系统水平拆分为数十组甚至上百组平行运行的小系统，这些小系统组合起来可以支撑起海量的请求和超高的性能。

　　此时已进入到2013年7月中旬。按照对一期系统运行状况趋势的评估，一期系统的容量在没有任何运营推广活动的情况下，只能支撑到9月份便会面临瓶颈。在理清楚二期系统的性能和容量设计目标时，樊振华又接到了新的压力：天弘基金和支付宝管理层已决定余额宝要参加阿里“双十一”购物狂欢节，这对于支撑后台的技术人员来讲，绝对是一场恶战。很快，传来了支付宝对天弘提出的双十一支撑要求：

实时请求的响应要超过1000笔每秒；
清算系统要支持单日3亿笔交易清算，清算时间不得超过150分钟；
2013年10月份支付宝会展开相关运营活动，系统必须在10月份前上线。

　　面对这样严酷的要求，且只有两个月的系统改造时间，项目组遇到了巨大的困难。

　　1. 如何进行系统水平拆分？

　　按照“蚁群战术”，需要将原有系统的业务逻辑水平拆分成多组小系统。而如何才能保证拆分尽可能平均和拆分后的扩展性是绕不过去的难点。水平拆分依据哪个字段来拆分，需要根据业务特性慎重考虑。一个细节考虑不到会导致全盘皆输。

　　2. 将Oracle替换为MySQL。

　　无论是单机性能还是功能，MySQL都无法与单机的Oracle匹敌。使用MySQL代替Oracle，原有的存储过程该怎么办呢？一些涉及多表join的操作在MySQL下执行效率较低该如何解决？工作量有多大？没人清楚这一系列问题的答案。

　　3. 数据迁移工程浩大，难度极高。

　　一期系统部署在天弘基金在天津的数据中心，而二期系统却部署在阿里云在杭州的节点，如何做到无缝割接？并且考虑到互联网用户的用户体验，一期系统和二期系统在上线期间，不允许出现业务中断，项目组必须在大数据量、异构环境、远程迁移等复杂环境下，实现无缝迁移。做到上线过程最终客户无感知。

　　4. 直销和TA系统的资源争抢问题。

　　一期方案将直销和TA进行了融合，来解决数据交互问题。但由于传统的TA与实时请求在不同时段运行，所以采用了主动争抢机制的负载均衡及贪婪式的CPU占用，以保证充分利用硬件资源完成业务清算。这在传统模式下没有问题，但一期系统进行合并以后，TA和实时请求的应用系统部署在同一组服务器上，每次TA系统启动清算的时间段，会严重影响实时请求的响应时间，甚至造成响应失败。

　　5. 整个架构保持两年以上系统扩容能力。

　　上云后的系统必须能够满足业务量飞速高涨的情况下，可以根据业务量的大小做到无缝升级。两年之内，不能因为扩容而改变系统架构。在保证扩容性的前提下，经济和投入必须控制在合理范围内。

　　这些问题，不管是樊振华，还是金证科技，在分布式系统和云计算这个领域，虽然了解很多，但真正动刀枪，还是第一次。即使阿里云和支付宝的技术人员，在这么短的时间内，要解决这么多难题，也都不禁捏一把汗。

　　 走投无路，背水一战

　　樊振华清楚自己已没有退路，只有往前走才是出路。他召集阿里云、天弘基金、金证科技和支付宝的技术人员在闭关室进行封闭式开发，一场艰苦的战役就此打响。

　　“管不了那么多，这些问题只能一个一个解决。”樊振华每次面对棘手的困难时总会说这么一句。最终困难都被解决了。

　　1. 系统水平拆分。系统水平拆分的基本原理很简单，就是按一个业务字段，如支付宝协议号作为拆分依据。对字段取哈希值以后根据拆分虚节点的个数进行求模。这样就可以简单地将所有请求拆分成多份。

　　在二期系统的拆分过程中，经过测算，需要使用50组业务节点，但在拆分时，考虑到扩展性，并未简单地拆分成50份，而是拆分成1000份，然后每个节点处理20份数据。这样做的好处是将来如果系统遇到瓶颈，需要扩容时，不需要对拆分算法进行修改，而且数据平均迁移时只需要以库为级别进行，从而避免了拆表。

　　2. 去Oracle。首先是将存储过程等MySQL不支持或支持不好的数据库逻辑上移到应用中。

　　其次要将复杂度比较高的SQL语句进行拆分，变成多条简单的SQL语句，从而提高MySQL的执行效率。

　　阿里云的RDS提供的慢SQL查询功能，可以将整个系统执行效率比较慢的SQL呈现给用户，帮助用户优化SQL语句。

　　3. 数据迁移。数据迁移是这个项目的重头戏，迁移过程中使用全量+增量+数据订正+并行运行检查等几个阶段完成。

　　二期系统在生产环境部署完成后，将在天津的一期系统的全量数据打包，按照指定拆分算法拆成1000份以后，通过专线导入到二期系统中。导入以后，将天津的一期系统前置机转发服务打开，将所有实时请求转发到二期系统，这样两个系统同时处理请求。然后，在交易日之后，以一期系统为准，将二期系统中的数据进行订正和补全。这些所有的操作必须在24小时内完成是迁移成功的必要条件。

　　数据迁移成功之后，两个系统实际上在并行运行。需要使用脚本每天对比两个系统中的数据，连续2周数据对比无误以后，由支付宝将请求地址从一期系统切换到二期系统，整个迁移才算完成。

　　4. 直销和TA的再次分离。借助云计算快速灵活的机制，将直销系统和TA系统的应用逻辑层进行完全分开，分开后的直销和TA系统分别运行在一组ECS中，两套系统后端连接同一套的RDS数据库服务。这样既能保证TA和直销系统在应用性能上不会发生争抢，又不会发生数据传递问题。

　　5. 扩容性保证。除了在水平拆分算法时就采用双重映射的机制来保证架构本身的扩容性，还充分利用了阿里云云服务可以无缝升级的特性，来进行容量保证。

　　以RDS数据库为例，阿里云提供了新1型到新7型等7个型号，性能逐渐增强。最终选择了新5型作为数据库服务器，并没有一步到位采用最高型号。这样当系统出现瓶颈时，就可以通过将所有RDS从新5型升级到更高型号来将系统容量翻倍。

图2 二期系统构架图

　　这种架构（图2）将清算和直销的集群分为两组独立的集群，但使用相同的RDS数据库服务，既避免了在应用层面的资源争抢，又可以做到数据的共享。其中，实时请求会先到达4个互为冗余备份的SLB（负载均衡），避免SLB单点故障。SLB将请求转发给5台前置机，前置机会按照拆分算法，将该请求路由到相应的节点进行处理，该节点处理完毕后，数据保存到改组对应的RDS数据库。而每天的对账文件则通过文件服务器进行拆分，然后清算系统的每个节点主动取出自己处理的文件进行清算处理，再保存到数据库。

　　 历尽磨难，涅槃重生

　　经过两个多月的封闭式开发，在上线之前，二期系统进行了严格的压力测试，测试结果让樊振华悬着的心终于放下了。

　　TA系统，可以在6400秒内完成3亿笔订单的清算并将清算结果返回给支付宝，完全符合清算时间不得超过150分钟的要求。对开户的实时请求，项目目标要求达到1000笔/秒。压测的数据轻松达到5000笔/秒，并且具备11000笔/秒的储备能力随时可放开。

　　二期系统终于在2013年9月26日上午正式上线成功。在上线的前一天，一期系统每天完成清算需要8个小时，而上线当天，二期系统完成了第一次清算，只用了不到30分钟。这个结果让那些经历多个不眠之夜的后台运营人员眉开眼笑，终于可以晚上回家睡觉了。

图3 实时请求的响应时间

　　实时请求的响应时间老系统为180ms，上云以后，平均130ms，效果十分明显，如图3所示。

　　万事俱备，只欠东风，只有经过“双十一”海量交易量的摧残，才能验证系统是符合设计要求的。

　　2013年11月11日，余额宝首次参加“双十一”大促，完成1679万笔赎回，1288万笔申购的清算工作，成功为639万用户正确分配收益。当天处理了61.25亿元的消费赎回，119.97亿元的转入申购。完成这些所有的清算工作，系统只用了46分钟。

　　 云计算是万能的吗？

　　这一路走来，直销和TA系统经历了分开、合并、再分开的演进路线，让樊振华想起一句话“天下之势，分久必合，合久必分”。过去这么多年，以IOE为主的集中式计算已告一段落，在这个互联网的时代，云计算和分布式的结合代替集中式计算已深深植入他的脑海之中。

　　此时的樊振华，已和一年前的他截然不同——一年前，他还在为各种硬件选型、采购流程而忙碌。但一年后，他更喜欢在人们面前谈起的是云计算、大数据、分布式、用户体验、互联网的IT架构等名词。

　　具备强大水平扩容能力的二期系统，足以让这个饱经历练的老兵高枕无忧，休息一阵子，再也不用担心系统容量和高并发的问题。但有一颗种子，在樊振华的心目中开始发芽：如今这个二期系统已不是简单的直销和清算系统，每天沉淀在50个数据库里的海量用户和交易的数据量在暴涨，如何存储这些数据？如何使用这些数据？该如何才能产生最大的价值？

　　 未来如何发展

　　有了这颗种子，樊振华休了个短假，他又开始了新的征程，投入了大数据的怀抱，这一次，他选择了阿里云提供的ODPS（开放数据处理服务）来作为自己的大数据平台。ODPS目前是阿里集团进行离线数据处理的平台，支撑了阿里金融、淘宝等多家BU的大数据业务。有了这个平台作为后盾，樊振华清晰了很多，他脑海中复现了一幅画面：在不久的将来，通过对目前沉淀的海量数据的分析，可以把握上亿用户的理财需求及不同的风险接受能力。而天弘基金，根据这些客户的情况，提供更多更丰富的理财产品。或许到那一天，让天下所有的人享受到符合自己的理财服务真不是梦想了。

　　作者白培新，阿里金融云服务业务架构师，负责金融云总体架构设计与规划。先后供职于电信、公有云服务、金融云服务等领域，“余额宝”上云过程的阿里云侧负责人。

遇到交通事故要自行拍照有哪些需要注意的地方？

Tue, 04 Nov 2014 14:00:00 CST

车险事故定损时对于车辆定损拍照是有要求的。第一是照片需要反映出事故的前因后果，车险现场车辆位置，第二是损毁细节必须注重到，第三是如果有时间参照物最好能拿出来（譬如当天报纸）。
目前国内大一点的城市交通运输部门和保监局都会与保险公司商量出一个《轻微道路事故快速处理办法》，要求各地保险公司对于不涉及人伤，损失金额10000元以下的事故快速处理，比如北京就是拍完照车往路边停等待处理。保险公司定损以交警部门或车主拍照为准。根据不同事故类型，拍照技巧如下：
1、追尾事故，变道碰擦事故。这类型的事故需要至少拍三张照片，一张车头，一张车尾，一张碰撞处局部照片，车头的那张需要把两车全貌，车辆牌照之类的拍好，地上的交通线都拍出来（用以界定责任），车尾一样。
2、发生在十字路口，转盘，高架之类的需要最少拍五张照片，分别是第1点中的三张加上路口两车的位置情况四个方向拍上几张，如果来得及，能把红绿灯情况能涵盖进去最好。
大致如上，现在都是数码照片，手机拍的，就不要吝啬多卡擦几张吧，当然按照上面的要求拍，主要是通过照片能反映出责任在谁就好了！
对了，先报交警和保险公司，然后拍照！如果交警要求拖到旁边，保险公司查勘没有到的情况下，给保险公司电话，告知交警现在拖车，现场无法保留，责任以交警界定为准，照片只能以咱们手里的为准！
好了，妥妥的了！
安全驾驶第一，买保险只是预防万一，不要因为有保险就不顾交通规则，拿自己生命开玩笑，切记切记！

来源：知乎 www.zhihu.com
作者：小方方

【知乎日报】千万用户的选择，做朋友圈里的新鲜事分享大牛。点击下载

此问题还有 6 个回答，查看全部。

微博春晚背后的技术故事

Wed, 12 Mar 2014 23:05:21 CST

前言

一年一度的春晚再次落下帷幕，而微博也顺利地陪伴大家度过除夕之夜。

谈及马年春晚，人们首先想到的不是春晚上精彩的节目，而是微博上的吐槽，边看春晚，边刷微博，边吐槽，已经成了国人的习惯。看春晚不再是为了看节目，而是为了能够在微博上吐槽，知道大家在吐槽什么，更有人戏称不是春晚成就了微博，而是微博拯救了春晚。

马年春晚又格外引人注目，不仅仅是因为冯小刚亲自坐镇，担当总导演，更值得一提的是本届春晚首次将社交平台作为其与观众互动的主要途径，而新浪微博更是成为官方二维码独家合作方。在节目播出时，用户通用手机客户端，扫描屏幕右下角的官方二维码，即可参与春晚的话题讨论。不仅如此，参与讨论的观众，还可以免费获得微博红包，抽大奖的机会。如此一来，大大的提升了微博的活跃度瞬间提升，同时在线人数翻了几倍，给微博系统带来前所未有的访问压力。

根据以往统计的数据，春晚期间微博的访问量将激增到日常水平的数倍之多，而瞬时发表量更是飙升数十倍，如此场景丝毫不亚于淘宝双 11 和 12306 抢票时的”盛况”。

而最后的统计数据结果表明，马年春晚直播期间，微博的访问量和发表量都再创新高，而我们系统也自始至终平稳运行，经受住了此次高峰的考验。这成功的背后，是我们的工程师将近一个月的努力。其间面临了哪些问题，又是如何解决的呢？下面，我们一一为大家揭秘。

挑战1：如何应对数倍于日常访问量的压力？

每年春运抢票时，12306 都会崩溃；淘宝双 11 时，也会有短暂的购买失败的情况。究其原因还是，有限的服务器资源难以承受上千万人同时在线访问。同样，春晚的时候，微博的访问量也会激增，同时在线人数到达日常的数倍之多。面对突然增长的访问压力，大部分互联网公司都会临时扩容来加以应对，同样我们也需要进行扩容。那么如何进行扩容？哪些部分需要扩容？具体扩容多少？这都是厄需解决的问题。

需要提到一点的是，微博目前线上部署了几千台服务器，来保障日常的正常访问。假如面对原来数倍的访问压力时，如果简单粗暴通过线性扩容来应对的话，需要部署原来数倍的服务器，也就是需要上万台服务器。无论从硬件成本还是从管理成本上，这都是不可接受的。那么，又该如何做呢？

在线压测，找极限，最小化扩容前端机

众所周知，为了尽可能的保障线上运行的服务器的稳定，资源都是有一定冗余度的，一般安全值在 30% 以上。在面临 5 倍的访问量时，出于成本的考虑，单纯的扩容难以令人接受。这个时候，就要充分利用每台服务器，在不影响业务性能的前提下，使每台服务器的利用率发挥到极限，可以极大的降低资源扩容的数量。如何评估服务器的承受极限是其中的关键，为此我们在业务低峰时期，对线上的服务器进行了实际的压测。具体方法如下：

假如线上一个服务池里有 300 台 tomcat 服务器在提供 API 服务，正常情况下，每台服务器的负载都小于1（为了简化模型，我们这里只提到了系统 load 这个指标，实际情况要比这个复杂的多，还要考虑 CPU 利用率、带宽、io 延迟等）。通过运维系统，我们以 10%、20%、30%、40%、50% 等比例逐步将该服务池里的 300 台 tomcat 机器 503，通过观察一台 tomcat 服务器的负载以及 API 服务的接口性能，当服务器的负载达到极限或者 API 服务的接口性能达到阈值时，假设此时服务池里正常状态的 tomcat 服务器的数量是 100 台，那么我们就可以推断出该服务池，极限情况下可以承受 3 倍与日常的访问压力。同理，为了承担 5 倍的访问量，只需再扩容一倍机器即可。

挑战2：如何应对瞬时可达几万/s 的发表量？

互联网应用有个显著特点，就是读多写少。针对读多有很多成熟的解决方案，比如可以通过 cache 来缓存热数据来降低数据库的压力等方式来解决。而对于写多的情况，由于数据库本身写入性能瓶颈，相对较难解决。

微博系统在处理发表微博时，采用了异步消息队列。具体来讲，就是用户发表微博时，不是直接去更新数据库和缓存，而是先写入到 mcq 消息队列中。再通过队列机处理程序读取消息队列中的消息，再写入到数据库和缓存中。那么，如何保证消息队列的读写性能，以及如何保证队列机处理程序的性能，是系统的关键所在。

按消息大小设置双重队列，保证写入速度。

众所知之，微博最大长度不超过 140 个字，而大部分用户实际发表的微博长度都比较小。为了提高写入消息队列的速度，我们针对不同长度的微博消息，写入不同大小的消息队列。比如以 512 字节为分界线，大于 512 字节的写入长队列，小于 512 字节的写入短队列，其中短队列的单机写入性能要远远高于长队列。实际在线结果表明，短队列的 QPS 在万/s 级别，长队列的 QPS 在千/s 级别，而 99% 的微博消息长度均小于 512 字节。这种优化，大大提高了微博消息的写入和读取性能。

堵塞队列，压队列机极限处理能力。

为了验证队列机处理程序的极限处理能力，我们在业务低峰时期，对线上队列机进行了实际的压测，具体方法如下：

通过开关控制，使队列机处理程序停止读取消息，从而堵塞消息队列，使堆积的消息分别达到 10 万，20 万，30 万，60 万，100 万，然后再打开开关，使队列机重新开始处理消息，整个过程类似于大坝蓄水，然后开闸泄洪，可想而知，瞬间涌来的消息对队列机将产生极大的压力。通过分析日志，来查找队列机处理程序最慢的地方，也就是瓶颈所在。

通过两次实际的压测模拟，出乎意料的是，我们发现系统在极限压力下，首先达到瓶颈的并非是数据库写入，而是缓存更新。因此，为了提高极限压力下，队列机处理程序的吞吐量，我们对一部分缓存更新进行了优化。

挑战3：如何保证系统的可靠性？

无论是发微博，还是刷 feed，在微博系统内的处理过程都十分复杂，依赖着各种内部资源和外部服务，保证系统的可靠性显得尤为困难。

为此，我们内部开发了代号为试金石——TouchStone 的压测系统，对系统的可靠性进行全面检测。

首先，我们对微博的各个接口进行了服务依赖和资源依赖的梳理，并针对每个服务和资源定义了相应的 SLA 和降级开关。然后，模拟资源或者服务出现异常，再来查看其对接口性能的影响。以 redis 资源为例，假设系统定义了 redis 的 SLA 是 300ms，相应的端口是 6379，通过 TouchStone，使该端口不可用，从而模拟 redis 资源出现异常，然后验证依赖该资源的接口的性能，确保 SLA 。同时，通过降级开关，对该资源进行降级，验证降级开关的有效。

基于以上方法，对系统进行了全面的检测，并对各个服务和资源的 SLA 和降级开关进行梳理，总结成业务降级手册，保证在出现问题时，运维人员无需开发的介入，也能第一时间根据降级手册进行降级，确保问题能够尽快解决。

挑战4：如何保证核心系统的稳定性？

任何一个系统，都包含核心系统和非核心系统。在出现异常的情况下，弃车保帅，只保障核心系统的稳定性也是可以接受的。

为此，我们降核心接口和非核心接口拆分，部分部署到不同的应用池子当中，确保非核心业务不会影响核心业务。比如发微博和刷 feed 属于核心业务，而评论，赞属于非核心业务，所以两者应当部署到不同的应用池中。在评论或者赞出现异常时，发微博和刷 feed 就不会受到影响，从而保障系统核心业务的稳定性。

同样，对于一个业务，也要区分核心逻辑和非核心逻辑。以发微博为例，更新缓存和写数据库属于核心逻辑，而给其它业务部门推送数据则属于非核心逻辑。因此，可以将推送数据进行异步化处理，交给单独的线程池处理，在出现异常时，不会对更新缓存和写数据库造成影响。

挑战5：如何做到异地容灾？

近些年来，异地容灾成为全球性互联网企业面临的难题之一。无论是在国内，以微信为例，还是在国外，以 twitter 为例，都曾经出现过全球性宕机的事故。由此可见，异地容灾仍旧是一个挑战。

微博早在 2010 年就开始了多机房的部署，如今已经具备三大机房（分别针对联通、电信和海外用户）。

由于人为或者天气等不可抗拒因素，网络故障近年来时有发生。微博的三个机房，各自独立承担了一部分用户的访问。在一个机房出现故障或者压力过大的时候，通过 DNS 切换等手段，将流量迁移到另外两个机房，从而确保该访问该机房的用户不受影响。一个现实的情况例子，在马年春晚直播期间，由于观看人群的地域分布的特点，出现了联通机房的访问量突增，同时在线人数的增长超过了电信机房和广州机房，我们通过切换一部分联通机房的流量到电信机房，使得联通机房的负载降到了安全值的范围。

挑战6：如何实时监控系统状态？

我们都知道，地震的发生都是有前兆的，比如一些动物的异常反应。同样，系统中的任何问题出现之前，也是有线索可寻的。这就需要对系统的关键指标做实时的监控，当指标出现异常时，能够第一时间发出报警信息。

为此，我们基于实时流处理系统 Storm 开发了一套监控系统——dashboard。有别于以往的监控系统，它能实时处理系统产生的海量日志，绘制出更加直观的曲线，方便运维进行管理。通过 dashborad，我们能够了解系统的实时状态，主要包括 feed 的访问量、微博的发表量、队列机的处理性能，消息队列的堆积量等指标。当某个监控指标出现异常时，能够第一时间在 dashboard 中反映出来，从而第一时间采取措施，解决问题，避免问题扩大化。

后记

春晚已经过去一个月了，渐渐成为回忆。但春晚背后，我们的工程师所付出的巨大的努力所产生的价值，却是一笔宝贵的财富，希望这篇文章能给大家带来启发甚至帮助，也在此向为微博春晚默默贡献的工程师们致敬！

关于作者

胡忠想（微博昵称： @古月中心相心），目前任职于新浪微博的平台研发部门，主要负责微博 Feed 服务相关工作，曾先后参与微博 Feed 存储、微博计数器、微博阅读数等重大业务产品的开发。2012 年 3 月份毕业于北京航空航天大学计算系，同年 4 月份，加入新浪微博并工作至今。业余爱好户外，曾徒步过贡嘎、雨崩，攀登过四姑娘三峰。

本文链接

JamCam创业故事：辞掉工作，去开发一个应用

Wed, 25 Dec 2013 15:41:06 CST

编者按：这是JamCam创始人的自述。这家初创公司提供的应用很简单，但是极为成功：有了JamCam，你所录制的视频会自动添加你正在iPhone中聆听的音乐，作为视频的背景音乐。和朋友分享时是不是方便多了？它在发布第一周下载量就超过了5000次。而它的创始人的故事，则开始于在谷歌上的自学。

　　 自发学习：完全是好奇心的驱使

　　大学毕业后的一年，我在多伦多市郊的一家小公司工作，做一名视听技术顾问。这个公司承接了一些非常酷的项目，包括设计电影院外形和给大型建筑消音。

　　过去的这个夏天，每个周四中午吃饭前的一小时，我都要坐在办公桌前，完成这周的报告，但我很苦恼。并不是苦恼报告的提交截止日期，而是苦恼于根本无法集中注意力完成这份报告。我不想让我的余生都坐在一张桌子前写这样的报告。事实上，我甚至不想这周余下的时间里做这种事情。

　　这并不是因为我懒，或我更希望在家里一天到晚躺在床上看电视。事实上正好相反。

　　在过去的这一年里，我把大部分的空闲都用来自学如何编程，HTML,CSS,JavaScript,PHP,MySQL,和Objective-C等。我做了很多觉得很有趣的小东西，开发的过程中的每一步都通过谷歌搜索出相关的帮助教程自学。我非常喜欢这种为了完成某个特定任务而针对性的学习方法，而不是那种为了学习而学习的方式(当前的学校教育模式某种程度上就是这样)。我总是先对要做出的东西在脑海里有了雏形——虽然还没有开始实现它。更重要的，我喜欢这种对一个产品的功能和外观有完全的自主控制的感觉，这些都是关系到用户体验最重要的部分。

　　 辞职创业

　　然而，现在的我，坐在这张办公桌前，把这一年在这个公司里学到的知识，从胃里吐出来，重新咀嚼，创造出工作报告。我学到了很多，当然，还有很多需要学。但有些东西在折磨我，很显然，在这样的一个小技术顾问公司里，现在的工作缺乏创造性，缺少自由，缺少自我提高的空间。而且事实越来越明显，编程和设计的“白日梦”已经无法逃避，无法压抑更久。

　　到了午饭时间，我仍然在挣扎着写我的报告。在去外面吃饭前，我把车开到路边，停下来，安静的坐了几分钟。

　　我给女友打电话，告诉她明天我要辞掉工作。

　　她支持我的决定。晚上我跟父母的交谈也得出了相似的结论——尽管他们有更多的担忧。他们相信我，只是不知道现在是不是我“辞职创业”的最佳时期。但我很确信。

　　第二天我知会了老板，但仍然待了几个星期来收尾我的工作和交接培训接替我工作的人。在最后一天过完之后，在40分钟的回家的路上，我感觉好极了。我终于可以自由地做我任何想做的东西了——完全自我掌控。没有琐事打搅。我已经积攒了足够的钱来支撑我的创业生活。我已经有了好几个创意让我可以开始入手。

　　 产品开发

　　接下来的几周里，我所有的时间都在思考，计划以及做现实生活的各种交流、公关活动。我最终确定了一个目标，开始开发了。我大概90%的时间在家里开发，其它时间在咖啡馆里。辞职2个月后，我用了一个月的时间完成了1.0版本的JamCam。我可以在这里大说它一番，但我想你自己去看看才是最简单的方法。

　　 发布后始料未及的成功

　　JamCam的发布比我预想的要成功的多。一个朋友在Reddit提交了它的链接，它一下子就火爆了——冲到了iPhone版块的第一位，并且保留的整整一天。我从没见过有这么大的流量涌入——访客来自世界各地，任意时刻的平均在线用户数达到20个。整天下来总共加起来超过3000个访客，这已足够让这个应用在很多国家的应用商店里进入流行名单。在美国和加拿大的图片和视频应用分类里，它跻身于前250应用名单，在某些国家甚至冲进了前50强。第一周这个应用的下载量就超过了5000次。然后TechCrunch报道了它。还有让我感到神奇的是有600多个微博谈到了我这个自认为不是很优秀的应用，这同样也给我带来了相当大的一批流量。

　　 对成功的喜悦和对更多成功的渴望

　　这样就来到了我写这篇文章的现在。一方面，我对成功感到惊奇、兴奋和荣耀——这是我开发的第一个应用。另一方面，让我感到隐忧的是，虽然目前似乎有一次不错的成功，但冲到应用商店的第一名的道路还很漫长。在应用商店里大量的应用，让带有成见的我很奇怪为什么有很多平庸的应用能维持着它们的评级。

　　尽管有这些疑问的存在和前途未知的障碍，有一点我是十分确信的：过去的几个月将是我一生中最充实、兴奋、有意义的几个月。这听起来很戏剧化，但对于我来说这是真的。能每天早上兴奋地醒来，能够运用自己的能力将想法变成产品，让成千上万的人使用，对我来说这些真是不可思议。我会更加努力的工作，挣到更多的钱来让这种“梦想-现实”的变化继续下去，即使我破产或精力耗尽了，我也永远不会后悔这段经历。

　　 经验总结和今后的改进方向

　　●给自己干，即使付出了很多后失败了，也比给别人干强。鼓起勇气辞职，这是很难做到的事，除非你想清楚了你的决定。

　　●耐心是自学的关键。也许几天或几个星期内你感觉不到有多少的进步，但几个月后，你会吃惊于你学到了那么多技术(当然，在谷歌的帮助下)。

　　●也许你开发产品的过程中有数周或几个月得不到鼓励和奖赏，不要担心。开发一个产品需要时间(特别是你单干，自己设计，自己编码时)，这段期间，保持注意力和信念将是一场真正的心智斗争。

　　●获取建议，但不要全盘接受。作为一个开发者，最重要的一种技能就是，分清楚一个功能特征的增减是会给产品带来正面的影响，还是使产品背离了核心理念和目标。

　　●时常的回想那些以前你习惯的每天坐车上班的生活，然后想想现在，你会得意的对自己说：再也不用过那种生活了！

本文作者 Matt Loszak

论“伟大的产品”背后故事的重要性

Fri, 22 Nov 2013 01:03:17 CST

　　想要做一款5万用户的产品，只需把产品本身的功能体验做好即可;要做一款10万级别用户的产品，需在做好产品的基础上，对其进行针对性宣传;若要做成一款百万级别甚至更多用户的产品，那么我们就必须给产品赋予动人心弦的故事。让它像空气一样自由传播。

　　日前与老总Eric一起吃午饭时，聊到了我们公司开发的第六款APP——《商业科技》， Eric问我下一步打算，我说，业内的大媒体，已经基本与我们都有合作了。微博微信也在日常进行中。接下来肯定是产品的瓶颈期，要想突破这个瓶颈期，我们必须给这个产品赋予一个动人的故事。只有有故事性的产品，才具有强烈的传播性与延续性。Eric表示赞成，并让我举一些案例。由于笔者上一份工作从事的是珠宝行业媒体的市场总监工作，且近些年一直从事的市场及公关媒介相关工作。因此，或见或闻的例子还是有的，比如：

　　 1、卡地亚珠宝——它是在欧洲宫廷声誉鹊起。威尔士亲王 (1902年成为爱德华七世)，褒奖卡地亚为“国王的珠宝商和珠宝商的国王”，并于1904年授予卡地亚作为英国宫廷供应商的一等英庭供货许可证。Cartier的设计以三兄弟环球旅行所发现文明的异国情调为特色。(注：Louis, Pierre 与Jacques这三位卡地亚的创始人喜爱周游世界。)随着首饰王国的声名远播，卡地亚成为欧洲各国皇室的御用珠宝商，英国皇室曾向卡地亚订购27顶皇冠作加冕之用。此外，西班牙、葡萄牙、罗马尼亚、埃及、法国奥尔良王子家族、摩洛哥王子及阿尔巴尼亚的皇室亦委任卡地亚为皇家首饰商。

　　因此卡地亚也被誉为“珠宝商的皇帝，帝皇的珠宝商”。我们不去质疑卡地亚是否真实存在这些历史。但不得不承认，卡地亚一百多年以来一直以“贵族首饰”存在，只因它有一篇很长的“珠宝商的皇帝，帝皇的珠宝商”的故事。

　　 2、蒂芙尼珠宝——这个就更不用说了，相信很多业外人士都知道，它不但具有故事，而且这个故事还是曾经风靡全球的电影。你是否还记得“奥黛丽赫本一身经典的黑色晚装，来到纽约第五大道的蒂芙尼店橱窗前，一边吃着早餐，一边以艳羡的目光望着蒂芙尼店中的一切”没错，这就是女神奥黛丽赫本1961年主演的Breakfast at Tiffany's(又名《珠光宝气》)。

　　故事的类型有很多种，卡地亚珠宝是一个关于欧洲贵族的故事，蒂芙尼的则是一部美丽的爱情故事。当然，所有伟大的产品都有一个伟大的故事，或者是产品创始人的故事(如：马云的传奇经历);或者是产品及创始人二者结合的故事(如：乔布斯与苹果的故事);又或者其他原因造就的产品背后的故事。

　　那么把产品故事化到底有多重要，不妨来分析一下，笔者的意见是：

　　 一、人对故事的记忆更为深刻。试想，同样一款产品的文章推荐。单调的产品功能介绍远没有绘声绘色的产品案例的故事让人印象深刻。

　　 二、故事具有更好的延续性。产品和产品的故事就像一个点与一条线，产品完善的再好，无非就是把这个点扩展的稍微大一点;而一条线，虽然线的一头并不大，但它可以无限延长，超越时间与空间的束缚。(卡地亚延续了100多年前的故事)，甚至是产品不在了，故事却依旧还在延续下去。

　　 三、故事的传播性更强。笔者曾经为一位即将结婚且不懂珠宝的好友介绍结婚钻戒。当时就是介绍卡地亚与蒂芙尼两个牌子的钻戒。因为当时刚入行，对卡地亚的历史还不是特别了解，只知道是一个很大的品牌。所以当时只给他讲了蒂芙尼《珠光宝气》的电影故事，同时也告诉他说，卡地亚是一个非常大且历史悠久的品牌。最后朋友选择了蒂芙尼，问起原因，他说把这个故事连同蒂芙尼的钻戒一起送给女友，比送一个更贵的卡地亚钻戒能更让未婚妻感动，且他也希望能和未婚妻有这么美好的爱情。事后证明，他是对的，只是因为这个美丽的爱情故事。

　　 四、故事具有神秘性。越是久远的故事，我们会觉得越神秘，从而激发人们的原始好奇心，把这个故事牢记在心里，也间接的把与此故事同步的产品牢记在心里。而产品恰恰相反，越是时间长，发现缺陷越多，然后最终就会淘汰，并从人们的记忆中消失。

　　当然，笔者必须强调的是，好的产品是基础，没有好的产品，你就算给这个产品再美的故事，那也是会消亡的。

　　笔者认为，一款新的产品想要成为一款伟大的产品，至少具有以下三个步骤：

　　1、产品体验，——积累种子用户阶段(用户就是上帝，产品的好与坏是基础。它决定了产品的种子用户的忠诚度。)

　　2、针对性的宣传——积累小范围高质量用户。(新上线的产品必定会通过业内媒体报道、微信、微博宣传等手段来积累一些小范围的高自量用户。)

　　3、产品故事化——要想真正的成为一款伟大的产品，首先不是你的用户有多少，而是产品的知名度及口碑有多高。而要提高产品知名度和口碑，不是靠公司的那点人到处去演讲介绍产品功能能解决的。它必须是能有口口相传且具有戏剧系谈资的效果。因此，要想把产品做成伟大的产品，必须给它赋予一个动人的故事。让它自己一传十十传百的去传播。

　　最后，笔者总结认为：想要做一款5万用户的产品，只需把产品本身的功能体验做好即可;要做一款10万级别用户的产品，需在做好产品的基础上，对其进行针对性宣传;若要做成一款百万级别甚至千万级别的产品，那么我们就必须把产品做好，宣传做好的同时，赋予该产品一个动人心弦的故事，让它像空气一样自由传播。

本文链接： http://www.yixieshi.com/pd/14920.html

13则小故事彻底颠覆你的传统思维

Sat, 25 Jan 2014 07:23:56 CST

1.有个老人爱清静，可附近常有小孩玩，吵得他要命，于是他把小孩召集过来，说：我这很冷清，谢谢你们让这更热闹，说完每人发三颗糖。孩子们很开心，天天来玩。几天后，每人只给2颗，再后来给1颗，最后就不给了。孩子们生气说：以后再也不来这给你热闹了。老人清静了。
境界思维：抓住人性的弱点，无事不成。

2.两马各拉一货车。一马走得快，一马慢吞吞。于是主人把后面的货全搬到前面。后面的马笑了：“切！越努力越遭折磨！”谁知主人后来想：既然一匹马就能拉车，干嘛养两匹？最后懒马被宰掉吃了。这就是经济学中的懒马效应。
境界思维：如果让你的老板觉得你已经可有可无，那你已经站在即将离去的边缘。

3.夜市有两个面线摊位。摊位相邻、座位相同。一年后，甲赚钱买了房子，乙仍无力购屋。为何？原来,乙摊位生意虽好，但刚煮的面线很烫，顾客要15分钟吃一碗。而甲摊位，把煮好的面线在冰水里泡30秒再端给顾客，温度刚好。
境界思维：为客户节省时间，钱才能进来快些。

4.一禅师见一蝎子掉到水里，决心救它。谁知一碰，蝎子蛰了他手指。禅师无惧，再次出手，岂知又被蝎子狠狠蛰了一次。旁有一人说：它老蜇人，何必救它？禅师答：蜇人是蝎子的天性，而善是我的天性，我岂能因为它的天性，而放弃了我的天性。
境界思维：我们的错误在于，因为外界过多地改变了自己。

5.曼德拉曾被关压27年，受尽虐待。他就任总统时，邀请了三名曾虐待过他的看守到场。当曼德拉起身恭敬地向看守致敬时，在场所有人乃至整个世界都静了下来。他说：当我走出囚室，迈过通往自由的监狱大门时，我已经清楚，自己若不能把悲痛与怨恨留在身后，那么我仍在狱中。
境界思维：原谅他人，其实是升华自己。

6.有人问农夫：“种了麦子了吗？”农夫：“没，我担心天不下雨。”那人又问：“那你种棉花没？”农夫：“没，我担心虫子吃了棉花。”那人再问：“那你种了什么？”农夫：“什么也没种，我要确保安全。”
境界思维：一个不愿付出、不愿冒风险的人，一事无成对他来说是再自然不过的事。

7.三人出门，一带伞，一带拐杖，一空手。回来时，拿伞的湿透了，拿拐杖的跌伤了，第三个好好的。原来，雨来时有伞的大胆地走，却被淋湿了；走泥路时，拄拐杖的莽撞地走，时常跌倒；什么都没有的，大雨来时躲着走，路不好时小心走，反倒无事。
境界思维：很多时候，我们不是败在缺陷上，而是败在优势里。

8.一个小镇中，一位商人开了一个加油站，生意特别好，第二个来了，开了一个餐厅，第三个开了一个超市，这片很快就繁华了。另一个小镇，一位商人开了一个加油站生意特别好，第二个来了，开了第二个加油站，第三个、第四个恶性竞争大家都没得玩。
境界思维：一味走别人的路。必将堵死自己的路。

9.一只乌鸦在飞行的途中碰到回家的鸽子。鸽子问：你要飞到哪？乌鸦说：其实我不想走，但大家都嫌我的叫声不好，所以我想离开。鸽子告诉乌鸦：别白费力气了！如果你不改变声音，飞到哪都不会受欢迎的。
境界思维：如果你希望一切，都能变得更加美好，就从改变自己开始。

10.一户人家有三个儿子，他们从小生活在父母无休止的争吵当中，他们的妈妈经常遍体鳞伤。老大想：妈妈太可怜了！我以后要对老婆好点。老二想：结婚太没有意思，我长大了一定不结婚！老三想：原来，老公是可以这样打老婆的啊！
境界思维：即使环境相同，思维方式不同也会影响人生的不同。

11.小和尚负责清扫寺院落叶，每天要很长时间才能扫完。有人对他说：“你打扫前用力摇树，把落叶统统摇下来，明天就不用打扫了。”小和尚觉得很对，就高兴地照办了，可第二天院子里如往日一样满地落叶。无论你今天怎么用力，明天的落叶还是会飘下来。
境界思维：活在当下。

12.野猪和马一起吃草，野猪时常使坏，不是践踏青草，就是把水搅浑。马十分恼怒，一心想要报复，便去请猎人帮忙。猎人说除非马套上辔头让他骑。马报复心切，答应了猎人的要求。猎人骑上马打败了野猪，随后又把马牵回去，拴在马槽边，马失去了原先的自由。
境界思维：你不能容忍他人，就会给自己带来不幸。

13.人骑自行车，两脚使劲踩1小时只能跑10公里左右；人开汽车，一脚轻踏油门1小时能跑100公里；人坐高铁，闭上眼睛1小时也能跑300公里；人乘飞机，吃着美味1小时能跑1000公里。
境界思维：人还是那个人，同样的努力，不一样的平台和载体，结果就不一样了。

5time语录QQ认证空间： http://user.qzone.qq.com/7116069，求关注！

5time语录官方微信号：i_5time，或者扫描下面图片添加：

Google是如何让照片管理工具“Stories”学会讲故事的？

Tue, 22 Jul 2014 09:23:35 CST

“ Stories” 是Google+上一个很棒的照片管理工具，由Google 的社交网络工程师Joseph Smarr 负责。Stories 希望人们把所拍的照片都上传到网上，并自动将其生成为一个 由一系列照片讲述而成的故事。

也许Stories 所提供的功能听起来很简单——对人类而言，叙事能力是很自然的一件事。

。而机器不然。想让机器学会叙事的逻辑并不简单，哪怕你以用户在Google 上留下的所有信息为依据。“怎样让机器更懂人类的想法和情感？” 在这个问题上，Smarr 与他的团队花费了大量的时间。

Stories 的早期原型与最终成品差别巨大——Smarr 的团队进行了好一番探索。

最初的产品原型很有些个人年度报告的意思，里面包含了大量的数据，比如，在2012的5月的原型图里（下图）的数据就包括签到和徒步统计、与其他人的互动、音乐喜好，等等等等，数据精挑细选，细致而全面。背后的idea是，打造一款类似于Facebook News Feed 的产品：用算法对你的个人news 进行提炼。

但模型毕竟只是个模型。当真正开始琢磨能利用哪些Google 数据时，Smarr不幸的发现：“人们的历史（数据记录）充满噪音，且不完整。” 于是，他们继续打磨、调整idea，焦点最后总会回到照片上来。

他们开始针对用户进行调查，希望能找到新的思路。

针对用户最近拍摄的10张照片，他们发问：为什么要拍摄这些照片？拍给谁看？调查发现，一共有三种类型：拍照是为了给特定的人看；拍照是为了加强某个记忆，比如喜欢喝的啤酒，曾经路过想要下一次去地点等；第三种则是作为一种探险游历的证明。在调查中他们也发现探险游历类的照片是 其中意图最简单的。并且，前两种类型都相关性强的应用和服务，但第三种需求却没有被很好的满足。

Smarr 团队希望Stories可以解决这一需求。人们出去旅游时总是会拍摄大量的照片回来，但回到家后却不知道该如何处理这些照片。其中一小部分也许会被发布在Instagram上，但大部分就这样永远躺在了用户的电脑或手机里。而Stories就要成为人们一种探险有力的证明，用照片把人们的旅游故事尽量还原出来。

在此基础上，Smarr团队做了更多的测试。他们让更多的人参与到调查中来，让他们把照片打印并在桌子上排列开来。调查发现，大多数人会按照时间顺序从左到右排列照片，此外，很多用户都会挑出一张表示地理位置的照片，放在每次新地点游历的开头。

因此，Stories开始了对地理位置信息的提取。Stories 从每一个用户的”Google数据库“中截取的信息有：照片的定位信息、Google+和Google Maps的数据（通常可以知道用户去过哪里）、通过照片中的景物所推测出来的用户地理位置信息（特别适用于用相机而非手机所拍摄的照片）。Google 将运用它强大的计算能力对这些信息进行分析整合，勾画出一个故事，并用照片流的方式呈现出来。

最后，一起通过实际的例子来检验检验Stories有没有把故事讲好吧～

除非注明，本站文章均为原创或编译，转载请注明：文章来自 36氪

36氪官方iOS应用正式上线，支持『一键下载36氪报道的移动App』和『离线阅读』立即下载！

PM必看：用户场景神器—故事板

Wed, 06 Aug 2014 21:29:13 CST

大多数产品经理都知道说用户体验设计，但是对于用户角色模型和用户场景却了解较少，而在产品设计中“设计故事板”能够直观地体现出用户和产品使用情境。

那么，故事板是 什么呢？故事板，起源于动画行业。在电影电视中，故事板的作用是来安排剧情中的重要镜头。他们相当于一个可视化的剧本。故事板展示了各个镜头之间的关系，以及他们是如何串联起来，给观众一个完整的体验。

现在，“故事板”在产品设计过程中也被广泛的采用，虽然产品设计故事板和动画、影视制作故事板都是用一系列的图片和语言组成的视觉表现形式，但是之间的所表达的信息和目标用户却是不一样的。我们在做“产品设计故事板”的目的是让产品设计师在特定产品使用情境下全面理解用户和产品之间的交互关系。

故事板的主要形式有：

文字故事板

我们要描述一个好的用户场景，需要对用户使用这个产品的过程有一个基本的了解，还需要对用户角色和使用情景有所设想。好的用户情景，可以贯穿整个产品设计的过程，模拟现实的用户操作和交互方式，用于产品的可用性评估。

使用简单的语言描述人物角色、情境及用户使用情景，尽量避免不要给出具体的用户行为和交互动作。

合理的文字故事板应该注意以下几个方面：

确定角色，多个角色做多个故事板；
确定确实必须完成的目标；
确定故事的出发点或事件；
明确角色信息及关注点；
确定故事板的数量，取决于人物角色和目标数量；
书写故事，从触发到结束；

用户Tina：性别、年龄、职业、收入、学历、使用习惯、使用网络、关键特征、目标以及故事描述，这些作为人物角色模型的故事板信息内容。

图片故事板

对于交互设计师而言，图形故事板是最快让他人获取自己的想法的最佳手段。通过图形故事板，用户就像在看电影一样，融入到情景当中。

通过反思各个场景的的事件，提醒团队该注意哪些方面，反思交互效果，能够让他人通过看得见的方式面面加以注释。

在图形故事板中，用户通过一连串的用户行为，连接成一个完整的用户场景。

(故事板就是一个用户场景)

(事件/行为是具体的人和系统的交互行为，它将人、物和环境结合起来，构成了整个故事的内容)

(把角色放在某个场景里，讲一个故事。故事中应该包括对问题的研究和自己的想法)

如果着重研究线下任务，则故事板中线下场景居多，如关注屏幕任务则会展现界面居多。当然如果完全关注屏幕任务就是我们的线框图和原型了。

故事板关注的是屏幕任务和线下任务结合的边缘地带。

故事板是传统交互设计方法的重要补充工具，平时我们的原型设计仅仅局限于屏幕环境的设计，忽略了屏幕之外的使用情境，通过故事板绘制的关键使用场景有利于我们理解屏幕之外的用户目标和动机。其实有经验的设计师会在产品设计初期假想一些应用情境，只不过他们没有画在纸上而已。

另外，故事板不仅仅是设计师头脑中假想情境的具象化，他还可以使一些模糊的用户需求更加具象更有说服力，在设计沟通的过程中能发挥巨大的作用。

故事板揭示了用户与产品的各个交互行为，他可以让pm像用户一样，融入到用户的使用情景当中；又可以以一个旁观者的状态，观看全局，反思和总结使用场景的问题及真伪。

本文由人人都是产品经理团队@易卿收集整理，转载请注明来源

（关注更多人人都是产品经理观点，参与微信互动（微信搜索“人人都是产品经理”或“woshipm”）