2015/10/14 第367期

Spotify的后台架构

非常 high level 地描述了 Spotify 的后台架构。每个团队全权负责独立的产品功能,包括网站、app、后台、数据分析的相应部分。每个功能相对独立;如果一个功能挂掉了,其他的功能还能照常运行。

又一个Conway's law的典型例子:软件系统的架构反映了公司内部的组织结构、团队间通讯的结构。

Reddit的产品经理谈Upvoted这个产品

Reddit最近用Wordpress搭了一个内容产品,叫“Upvoted”。一堆人类编辑精心挑选在Reddit上浮现出的好文章,放到Upvoted这个网站上。作者讨论了几个Upvoted的重要功能。

Measure Anything, Measure Everything

Etsy用node.js做的StatsD运行在每台服务器上;服务器上的程序发各种关键指标到本地StatsD进程;然后用Graphite根据StatsD收集来的数据画图,便于监控。

虽然创业公司要move fast,但举手之劳加几行代码收集、监控各种关键指标还是很有必要的。"The Effective Engineer" 这本书里有提到一些反例:Jack Dorsey说Twitter刚开始的两年一点监控都没有,网站常常挂,挂了不知道问题出在哪里,只能彻夜不眠不断重启(活该加班!);臭名昭著的Obamacare网站也是没有监控,网站挂了后,那些合同工们不知道从何修复,后来政府从硅谷搬来救兵,第一件事就是instrument代码,增加visibility。

去年湾区日报也推荐过 StatsD

创业不是你这种人干得了的

文章用星球大战里的绝地武士比喻创业者。绝地武士是要断手断脚的(星战粉丝应该知道什么意思),你行吗?你肯变卖一切家当支付整个团队下个月的工资吗?若公司快倒了,敢叫整个团队不拿钱干三个月活吗?

原文标题“have what it takes”:To have the right abilities, personality, etc, for success

通过这5个问题了解一个项目

作者作为空降兵刚接手一个新项目,为了更快地了解项目的情况,向同事们问5个问题:为啥做这个项目?有可能出怎样的差错?怎么知道出差错了?出差错了该怎么办?可以ctrl+z吗?

这几个问题很实用。尤其可以引导团队思考应该采用哪些指标来衡量business方面是否成功、以及做好工程方面的监控与警报。还可以避免这种情况:新功能做完了、上线了、发现效果不好;想回退到旧功能,结果发现把旧功能彻底删了或因为其他不可逆的改变,回不去旧功能了。