Unsplash.com如何用小团队实现规模增长？
作者 Luke Chesser, Unsplash联合创始人译者：顾青 Dtalk.org创始人
这些年来，许多国内的公众号都会使用一个著名图片网站Unsplash的图片，包括许多大V。我之前在谈论关于如何增长的时候，一直强调的“小而美”，“产品驱动增长“等理念，与Unsplash这个团队的生存哲学非常接近，所以我翻译了一篇他们联合创始人Luke Chesser的文章特意分享给大家。
注：照片来自Unspalsh.com
关于构建Unsplash的最有趣的事情之一是产品的规模，规模和受欢迎程度。
平均每天来说，我们的API会处理来自unsplash.com和数千个第三方应用程序的上千万个请求，我们的数据系统会处理数百万个事件，我们的Feed会添加6000万条更新，并为支持6000万张图像。
同时，我们的团队相对较小：2名设计师，3名前端，3名前端，3名后端，和1名数据工程师（看到我们重视数据的程度了吗？1/12的人力噢）。没有人管运维的工作，每个人都花费大部分时间进行实验和新功能开发来推动用户增长。
虽然我们已经在Unsplash完成了很多工作，但我们仍然处在产品和业务发展的早期。我们还需要花更多的时间去证明我们的想法，这意味着我们需要整个团队专注和解决Unsplash独有的问题，而不是每个公司可以共享的解决方案，比如部署，网络安全，基础架构，性能管理等。
在过去3年中，我们制定了一套原则，使我们能够专注于增长，克服规模化的挑战。不幸的是，对于那些寻找一劳永逸解决方案的人来说，是没有的：有的只是常识和我们从逐步从其他人那里学习来的一套原则。
1. 打造”无聊而且明显“的解决方案
AKA Be Pragmatic （这里可以理解为“也就是实际一点”）。
我建议你去接触一个新的工具之前，无论是新的数据库（RethinkDB，RocksDB等），一个新的模式（“全功能技术包！”），还是一个新架构（“微服务来了！”），先选择比较实际可靠的选项吧！
仔细想一想，在系统后端，不会有太多的问题无法通过标准的工具和一些经过验证的模式（如缓存，批处理，异步操作和预先请求聚合）来达到足够好的结果。
2. 专注于解决用户问题，而不是技术问题
Unsplash是一家产品公司，而不是一家技术公司。投资者给我们提供了大量资金，是希望我们可以专注于解决产品和市场问题，而不是我们把钱用来改造现有的应用技术，让运营成本可以降低3％（发明这个技术的公司该做这件事）。
相反，我们专注于整合现有的技术，以解决用户的需求并扩大Unsplash的社区规模。这些是Unsplash独有的部分。如果我们可以成功构建独特的和有价值的产品，为什么不稍晚一些再来处理优化和深入系统做定制化提升呢？这3％的优化可能是剩下的主要增长来源。
当然，这可能会让我们潜在的员工感到困惑。
一方面，他们会听到有关Unsplash的“大规模”和小团队，图像和人工智能的使用以及未来的功能，另一方面，人们却意识到我们使用了很多现成的技术，服务和框架。同时准备支付低廉的费用，将这些技术的内部开发交给未来的员工。
噢，部署数据管道，服务器配置，系统可靠性，数据处理，数据分析，图像处理和个性化（仅举几个例子），这些方面为什么要消耗工程资源呢？
我们选择第三方服务来处理这些工作。
3.在技术问题上花钱
不把注意花在技术问题上另一面就是使用已经挺好的先有技术，或者付费去使用第三方服务。
在团队中曾经我和大家有过这样的笑话，我对任何问题的第一反应都是“你尝试过花钱解决吗？”。
但这不是一个笑话，而是我最喜欢解决问题的方法之一。
优化基础设施和技术相关的成本是一种简单和可重复的的事情，一个有投资支持的产品公司不应该关注它，除非有一天他们认为业务上的核心指标增长不再是其首要任务。
在技术问题上投入资金使我们的团队能够专注于没有重复性的难题，比如在一个季度里如何增长40％的用户群体。
所以这些是我们遵循的三个相当简单但抽象的原则。
不过实际上，我们的系统长什么样子呢？
如果看到Unsplash的架构，您可以看到我们有一个非常简单 – 几乎无聊（至少在2017年的标准）的技术架构设置。
我们可以随时使用Heroku来简化主应用程序的部署，配置，测试，维护和扩展。Heroku真是太棒了，因为它可以抽象出部分应用程序和开发过程，这样团队不必为了做实验和测试去熟悉底层的每个细节。
我们尽可能地少写应用程序逻辑代码（紫色区域）。在应用逻辑中，我们严格依赖其他人建立的框架，他们凭借其领域的专长早已制定了一套可以应用于95％用例的原则。
对于所有的生产系统负载，我们几乎完全依赖Redis，ElasticSearch和Postgres。过去我们尝试过其他的数据库，但是我们还是回到使用这三个技术，因为我们对这些数据库如何在负载下运行的理解非常有自信。
我们积极地使用工作队列，将尽可能多的操作推送到异步处理队列中，无论是资源更新，聚合还是同步。
我们在数据处理（比如大量的事件数据）方面使用了Snowplow，这是用scala编写的开源集成数据处理框架，这样我们的团队主要注意力放在了数据系统的输入和输出，而不用担心数据的的处理。
（顾青注：SnowPlow也是一个很强大的用户行为分析解决方案，下次有机会介绍给大家）。
我们使用一系列云监控服务，如Datadog， New Relic，Sentry和Logentries，而不是花时间去管理我们自己的StatsD或ELK堆栈。
我们将所有的图像托管和基础设施外包给Imgix，这是世界领先的动态图像处理公司。由于它们提供了行业领先的功能，我们的团队只需要选择单一的URL更改，就能为用户提供最新的图像优化和处理。
我们将所有的用户活动推送到Stream，一种Feed聚合服务，利用他们技术和知识来优化高度可扩展的个性化feed。Stream通过一个API来处理输入和输出，简化了数十亿个活动的处理，要达到这样的系统性能，我们团队即便不用花几年来学习和优化，几个月还是要的。
我们不训练自己的图像识别算法，而是使用TinEye进行反向图像搜索，并使用Google Vision进行图像理解和分类。
我们将所有的用户行为事件推送到Vero，一个电子邮件营销和通知平台。这样，我们就把电子邮件的互动项目从我们的应用程序开发团队转移到非开发者团队的手中，允许他们基于复杂的事件逻辑和自己的见解来制作高度个性化的邮件内容。
同时，我们把工程资源用于提升Unsplash核心竞争力的部分。
在过去一年中，我们逐渐将应用程序从单一的Rails应用程序转变为Rails API，也就是一个Node + React驱动的Web应用程序，以及一个单独的数据应用程序，用来解决所有内部和产品指标的数据收集和处理。
总的来说，这使我们的团队能够构建在以前的仅Rails堆栈中几乎不可能的功能。通过分解应用程序的关注点和技术，我们的团队还可以在每个领域使用最好的工具：
1）在前端，我们的团队使用React和Webpack. 我们用了一个小型Express服务器来支持服务器端的渲染以及API代理。我们非常刻意地将前端工具与后端团队解绑，比如用react-rails或者webpacker。Javascript社区无疑是生产最好前端工具的地方，所以我们通过在原生Javascript中工作，团队可以更快地更好地推出的功能。
2）在后台，我们的团队继续使用最好的框架来实现一个简单的Web应用程序：Rails。Rails生态系统一直在为后端功能开发提供最佳的集成工具，而Rails是如此广泛使用的技术框架，事实上每个可能的问题都已经被其他团队经历过，记录过和解决过。
3）在数据方面，我们的团队使用一个小型Express服务器来收集并对数据进行排序处理。数据处理的工作实际上由Snowplow处理，托管在一组AWS映像上，便于配置和设置。这允许我们唯一的数据工程师Tim可以将他的大部分时间集中在管理数据如何进出Snowplow进出，这样的安排让数据容易理解，也可以帮助团队的其他人洞察数据中的价值。
我们大量投入时间在编写测试上，并使用Sientist和Datadog等工具测量性能，通过实验推出更改，并尽可能多地自动完成基础设施。
我们正在开发一个新的内部GraphQL API，这样我们可以加快实验，新功能和新产品的独立迭代，因为我们发现我们的RESTful API在我们的数据，设计，前端和后端团队中一直很难达到高度的工作协调。 我们的时间应该用于提供更好的产品体验和功能，而不是JSON更改。
虽然花点时间来处理这种JSON更改很有意思，但是我们不想过开发人员的瘾，而是希望通过快速迭代和增长来解决实际问题。
我认为大多数明白Unsplash是如何打造出来的人可能会有以下三个反应之一：
- Unsplash很简单，显然你可以采取这种方法。我正在打造的东西非常复杂，所以需要做这些事情。
- 我是开发人员，这听起来很无聊 – 我想建立下一个高度可扩展的图像识别系统！
- 酷👍我不在乎，只要给我提供一些惊人的免费照片可以用就好。
对于思考＃1的人来说，你是对的，总有一些公司在做比Unsplash远远复杂的事情。不过说到底，大部分公司根本没有这样。我们都基本上构建了相同的系统，只是重点略有不同，这就是为什么技术可以被抽象为框架，并重用于许多项目，以及为什么大多数招聘岗位看起来都很相似。
到＃2，我说这取决于你觉得什么有趣。如果你有兴趣推动技术的跳跃式发展，那么干脆去有这个目标的公司去上班吧。这种公司很少见，因为到了最后，大多数公司根本就不会这样做。
而对于号码＃3，我说是的，这是对的。说到底，这也是我们最希望的.最后我们也关心这样做！
想深入了解这一点，你可以在Twitter@ lukechesser 上联系他 ;-)
联系我们咨询规模增长
