服务组件，每个组件都有对应的点数。大家轮流放置，直到完成架构设计或者达到一定的回合数，占据更多点数的一方获胜。我玩了几轮（当中不小心还输了一次），发现这个游戏藏了不少细节。比如说使用像

miss。出不同等级的故障是概率大小的问题。就像之前分析「阿里云大故障」说的，也不能因为一次大故障就拉黑，反而更可能的是谷歌云经历了这次事件后，会更加重视稳定性。

DTC，提供了国内数据库同行们一起交流的机会。每次要去外地参会，我都有点挣扎，因为路上要花不少时间。但每次能碰到旧友新朋，吸收到新东西，旅途上我也能切换模式想想事情，回过头来看也挺好的。

链路都垄断了。下周去北京参加数据技术嘉年华，我在数据库生态软件专题论坛有一场演讲，主题是「全球数据库生态软件：现状，趋势与机遇」，我被安排在了周六最早的第一场

在背后推动。大国崛起需要的基础设施跃迁，除了有高屋建瓴的方针外，也依然要靠那些既有眼光也敢浪费的浪漫主义者，才能创造奇迹吧。关于

年前的历史，也是在当时最热的技术领域-数据库，主角之一同样是微软。论白嫖收购，微软一直是行业内的佼佼者（虽然也发生过收购诺基亚这样的翻车事故）。这也是它基业长青的原因之一。近的有包罗万象的

研究团队。简单消化了一下信息，脑袋里就跳出一个问题，奥特曼加入微软后该向谁汇报呢？首先微软的领导人页面上并没有技术线负责人这点和苹果的页面形成强烈反差再去

的投资人们也是事后才知道的。如果这次兵变成功，那之后整个投资规则就乱套了，投资人们还怎么保证自己的利益？所以可以看到现在硅谷投资人是清一色地站在奥特曼这边的。举几个例子：Khosla

当然也不能超预算看到阳老师讲到最后，出现了这句话。很自然会联想到阿里云的那句「梦想永在凌云意，代码成就万事基」。基础设施领域也就两大赛道，云和数据库。纵然

这次阿里云的故障又刷爆全网，目前官网的公告只阐述了时间线，没有透露任何的技术细节。内部肯定在连轴转，准备详细的复盘报告。在官方发布报告前，我先来尝试分析一下这次故障的原因。毕竟之前在

昨天阿里云发生了一次史诗级故障。看到群里有讨论是否要从阿里云润，我觉得是反过来的，正因为有了这次的大故障，阿里云接下来一段时间的稳定性反而会更有保障。道理也很简单，稳定性工作一直就没有刷业务有存在感，而真把稳定性做好了，又表现为善战者无赫赫之功的样子。日常工作中，组织内是缺少要素去推动稳定性建设的。稳定性建设的最佳时机都在大故障发生之后。像支付宝的高可用是在一次光缆挖断事故后建起来的，而整个的资金对账是在一次因第三方集成

的时候，自己也是能访问整个公司几乎所有的代码，说几乎就因为最核心的搜索排名算法是看不到的。或许马斯克这么不按套路出牌的一搞，倒是能推动整个行业都逐渐开源自己的推荐排名算法呢。

平台，都大大降低了应用开发者使用数据库进行开发工作的门槛。尤其让许多之前的前端研发变成了全栈工程师。但这只是降低了入门使用的门槛，但数据库的专业性和复杂度还是在那里的。就像

points。文章不短，而且故意用了粗糙的文笔，读起来有点吃力，不过作者还是花了不少心思构思内容的。比如讲其他部分时都写了点篇幅，提到

的实现也变得简单。除非有必须的理由，尽量避免持久化状态。持久化状态会大大增加将来迁移和升级的复杂度。架构设计篇先设计

之上，更可贵的才能是勇气和执着。我自己在上家大厂也有一个遗憾，我曾经也提出过要把某款数据库开源的想法，但被主管答复了一个合理但谈不上信服的理由后，我也就妥协了。如果当初我据理力争，一路

年也和国内同行互勉，虽然我们和业界最领先差距尚存，但已经越来越接近。数据库赛道是国内基础软件里离业界顶尖最接近的，TP，AP，中间件，工具均具备了一定的实力。业务场景，资本加持，人才储备也都有，相信

最近一直和同事们讨论一些产品交互的问题，就想到了这个话题。https://en.wikipedia.org/wiki/Nudge_theory这个理论里最广为人知的一个例子，来自于阿姆斯特丹

哦，对了，我们确实是在寻找具备良好工程素养和架构能力的后端工程师，如果你有兴趣和国内最顶尖的工程产品团队一起共事，做一款世界级的开发者工具的话，欢迎投递简历至

研发背景，主要经验在iOS移动端，早先创业的公司被Groupon收购，之后担任过Groupon和Uber的研发以及管理职位。在Uber帮助把移动工程团队从15人扩张到400人。Jori

http://antfin.tupu360.com/social/position?pCode=597VigRmunMvVaP0ARH/FA==&wxt=fmdxxqdstaxax_a9

https://mailchimp.com/what-we-learned-from-the-recent-mandrill-outageJoyent: