2015关于技术和产品的反思

2015过去好一段时间&＃xff0c;想好好总结一下自己和团队的一些感受&＃xff0c;算是对技术的反思&＃xff0c;也是对过去时光的留念。

##Log first 在年末的时候&＃xff0c;我们发现我们2年来对新浪微博API调用有大量的浪费&＃xff0c;事实上在动辄几十台服务器24*7运行的年代&＃xff0c;想要发现数据的不一致并不容易。

从2015年开始&＃xff0c;团队开始广泛的使用ELK(Elasticsearch&＃43;Logstash&＃43;Kibana)&＃xff0c;在ELK之上构建的监控、告警工具以及相对应的日常检查流程从很大程度上把之前埋在沙海中的问题及时发现出来&＃xff0c;从意识上改变了大数据系统时代“谁知道问题在哪里”心理恐惧。

最新的几个项目&＃xff0c;我们开始在构建项目的最初期就搭建ELK&＃xff0c;从一个个模块开始就能及时发现数据问题和性能瓶颈&＃xff0c;非常值得借鉴。

##Scale out & Realtime system design 多年前设计老的Crawler时就享受了队列解耦系统的甜头&＃xff0c;在如今系统解耦和scale out的方案选择更多了。不仅有适应各种场景的各种队列&＃xff1a;SQS&＃xff0c;Kafka, ZMQ&＃xff0c;还有像AKKA这样的分布式actor框架。设计师在设计之初预计可能的性能瓶颈会很大程度决定系统的架构和选型。

Storm、spark、kinesis这些技术高效稳定的支持构建一个实时系统&＃xff0c;在当前技术栈的支持下&＃xff0c;数据处理的消耗所用的时间应该是会忽略不记的。唯一会影响系统实时性的操作就是持久化。广义的持久化包括存储数据库&＃xff0c;也包括写日志、远程调用API等。设计一个实时系统应努力做到&＃xff1a;

1. 存NMB&＃xff0c;不要持久化&＃xff01;
2. 一定要存&＃xff0c;要保证是非阻塞的最终worker在做这样的事情。

##Better Product, not bigger product 谁都知道产品要做精&＃xff0c;有经验的CTO和产品经理都懂得控制产品功能过于泛化。但是每当你听到这些“真诚”的反馈时可能会去考虑帮助公司的其他团队&＃xff1a;

• “这功能太重要了&＃xff0c;不需要很强大&＃xff0c;有了我们就可以卖。”
• “我们如果可以添加这个功能&＃xff0c;不仅XX客户可以用&＃xff0c;YY客户也可以用&＃xff0c;太美好了&＃xff01;”
• “这个客户占了公司营业额的25%&＃xff0c;他们要的功能我们能不能优先满足&＃xff1f;”

作为创业公司&＃xff0c;销售的压力是永远不会小的&＃xff0c;毕竟活下去才有做好产品的机会。但是无论销售的压力有多大&＃xff0c;作为产品和技术的负责人还是需要问自己这样的问题&＃xff1a;

• 我的产品到底是做什么的&＃xff1f;
• 产品在想做的事情上完美了吗&＃xff1f;
• 这个功能是产品想做的事情吗&＃xff1f;
• 这个功能是产品现在想做的事情吗&＃xff1f;

事实上&＃xff0c;最终让产品长青的都不是那些重要客户“急需”的功能(通常是些这样那样的管理功能)&＃xff0c;反而是一些经过思考和钻研做出的有技术含量的功能。而且根据我的经验&＃xff0c;向客户妥协通常最终也不会真的带来太多的销售和用户忠诚度 - 95%的已完成功能都不能征服用户&＃xff0c;再加5%快速完成的新功能也多半没戏。

##Auto &＃43; User Calibration > Customerization 大数据时代&＃xff0c;最终都要接受一点&＃xff1a;数据如此之大&＃xff0c;你不可能拥有所有。产品或精细挖掘数据&＃xff0c;从而失了scalability&＃xff0c;或强化覆盖范围&＃xff0c;从而失了细节。不同产品本不一样&＃xff0c;两者并无优劣&＃xff0c;但是越来越多的情况下&＃xff0c;后者比前者会更聪明。这里特意写得泛泛&＃xff0c;于是这个想法可以应用到更多环境。 既然是"大数据"时代&＃xff0c;细节的偏差或者精确需求的不满足通常是可以理解的。于是用自动的方式提供近似最优解是非常不错的做法&＃xff0c;若还想有更好的用户体验&＃xff0c;把修改结果的权利交给用户就足够了。这样的解决方案会比针对特定用户去做定制化要更容易扩展&＃xff0c;即使结果有时候有些便宜&＃xff0c;用户有时候要自己整理整理&＃xff0c;也是非常值得的。