如何善用云端服务 加速网站产品开发的理解

作者:课课家更新于： 2015-11-27 16:05:39

大家是否还对这部分产品运营知识存在疑问呀，让我来为大家详细解答一下。下面由课课家带你走进文章的学习！！！希望你们能认真倾听哦！！

 
 
三个月前我离开上一间公司，投入 iCook 食谱社群网站的建设与营运工作，从我们正式开工、上线到目前短短几个月，我们一路跌跌撞撞，学了很多经验，想借由这篇文章分享一下我们如何善用各种云端服务来加速我们的网站开发，让我们可以专注在网站产品开发与社群的营运上，我们可以说是只花了不到两个月的时间就让网站从无到有并且上线。虽然网站目前流量还不是挺大，没有太多数据可以拿出来分享，不过我们在有限的人力做了满多看得到与看不到的事情，我个人认为真的要感谢现在许多现成的云端服务。我个人的 Twitter 是 twitter.com/deduce ，欢迎在 Twitter 上与我交流。
首先要简短说明一下我们整个公司的编制，我们目前共有 8 位伙伴，一位是 Fox，从营销、社群经营、业务合作到开**、发薪水都是他在负责；一位是 Leo，是我们的首席设计师，主导产品的视觉设计与UI/UX设计；另外有三位 IOS developer（或说是 App developer）；剩下的三位就是 Web developer 了。
Web developer 的组成则是一位因为被骗进来至今仍无法毕业还在读研究所的年轻人（就是我本人，对，还是个年轻人），一位刚从政大资科毕业就被我们骗进来的资优生（第一名毕业）还有一位还在读政大资管就被我们骗进来的实习生。
Web team 虽然有三个人，但我们不是叶问，无法一个打十个，尤其被骗进来的年轻人，我们要多花一些时间与耐心陪伴他们与产品一同成长。这样的编制，我们无法像很多公司一样把前端、后端、系统管理、测试等角色明确的分开。考量到人力运用的效率，我们在最初的产品发展规划时，不得不做了两个决定：
我们要大量运用各种现成的服务，尽可能透过租用的模式，节省人力的运用，让大家的心力是专注在产品本身的核心价值、体验设计与功能的实现。
我们要跑得比平常更快一点，即使是还有许多没有写完的功能、模组，也要尽快上线，每天都要前进。

每天都发布新版的网站程序，持续改善，让社群来协助我们决定下一步该做什么，并且尽可能将上线前还没完善的功能尽快做完。我常说产品上线后才是真正的开始，所以即使到今天，我们都还有一堆没做完的功能、没改完的臭虫、没调整完的介面，不过没关系，我们就每天改。我们跑得快的方法是每天持续的优化，今天要比昨天更好，这礼拜要比上礼拜更好。
打造一个食谱社群网站，乍看之下没什么困难的，不过我可以举几个实际的案例，来说明为何我会特别强调，我们有限的人力必须更专注在产品的核心上：
我们网站同时支持 IE7/IE8/IE9、Firefox、Google Chrome 以及 Safari 浏览器，同时还有专门支持手机版的页面（目前仅对 iPhone 最佳化， Android 跟 WindowsPhone 也可以看到手机页面，不过某些小细节可能会爆炸），我们目前几乎确保了 97% 的用户看到的介面、编辑的介面尽可能是一致的（IE7还是小有问题，不过今年底我们就会捨弃 IE7 了）
我们的介面设计上有一些很刁钻的需求，流程的规划也预留了未来发展移动版应用的空间（例如 iOS apps），我们可以说是在打造网页版应用的同时，也必须考虑到未来发展手机应用时的使用流程以及 API 的规划，这一点是相当耗费心力的
我们在数据的统计、资料的分析上下了很多功夫，理论上一年内我们的食谱数量就会成长到将近10，000笔，届时如何可以让使用者轻松的找到喜欢的食谱，或是透过食材的组合找到正确的食谱，光是食材资料库的建置、推荐机制的设计，就会花掉许多时间（简单来说，我们在进行简单的 text mining 与 data mining 来建置 recommendation system），这是网站的核心价值之一，也是未来我们可以确保产品营运上可以有良好基础的关键
在大家都不是叶问的情况下，又想要追求卓越、打造一个体质良好、得以长久经营的网站，显然我们需要强大的火力支援才能确保我们的网站开发能达到我们的最低要求。而针对运用各种现成的服务方面，我简短分享我们一共用了哪些现成的资源，以下的顺序就是看心情，想到什么写什么 ：p
与网页技术无关的服务
Google Analytics
我们利用 Google Analytics 来追踪使用者在我们网站上的赞数、留言数、收藏数，另外我们也用来追踪每日登入的会员数还有一部分的电子商务营收数据。使用 Google Analytics 的好处是它提供了强大的多维度报表分析功能，我们可以透过许多方式来检讨我们每天、每週的经营成效。
另外，透过即时线上人数的统计，我们可以很直接的观察到各类营销活动的成效，这也非常有趣，当你看到同时在线人数有上百人的时候，真的会有一种既感动又兴奋，同时愿意再多熬夜拼个几天的感觉XD
Mailchimp
这是另外一个发信服务，Mailchimp 的好处是有完整的后台可以让营销人员自行编辑信件的内容，进而发送电子报。换句话说，我们目前不花费任何开发者的时间开发相关的功能，先外包出去，以后有时间、有更进阶的需求，才拉回来自己做。
Mailchimp 同样也会提供统计数据，让你了解发信量、开信量等，你甚至可以看到是哪些人有点开你的电子报，进而将这些人依不同的维度划分成不同的群组，未来可以进行简单的客製化电子报派送。就小规模的团队与服务来说，这是顾客关係管理的第一步。
Uservoice
Uservoice 是一个非常重要的服务，我们从开站以来，我们几乎每天都会透过 Uservoice 收到来自我们访客的建议与问题回报，Uservoice 透过简单的介面让访客可以轻松的发信告诉我们他的想法。我们透过 Uservoic 来掌握使用者对于我们网站产品的看法，也藉此可以更加深入的了解我们社群。
我们可以透过后台清楚的看到目前所有尚未回应的问题，或是谁已经回应了哪些问题，甚至可以建立罐头讯息，还有积分的设计，客服人员每当回答了问题，就会得到额外的积分。（不过其实我们目前是共用帐号、共享积分XD）
Google WebMaster
除了 Google Analytics 之外，我们会透过 Google Web Master 来观察网站目前在 Google 上的搜索成效与排名。不过毕竟我们网站才上线两个多月，这部份我们其实还没有太高的期待XD
与网页技术相关的服务
Ruby on Rails
这是我们网站主要使用的框架，近年来有满多网站选择使用的，使用 Rails 最大的好处是 Rails 目前有相当成熟的 ecosystem，有许多现成的套件可以让我们很快实现许多功能，让我们可以专注在打造网站产品。
另外，使用这类框架最大的好处是，这些框架都由非常资深的前辈们用心打造而成，可以替我们这些后辈们避开许多问题，我们可以说是站在巨人的肩膀上、善用前辈的智慧、心血结晶在打造我们心目中卓越的产品。
如今要打造一个网站，你能选择的框架越来越多，像是 ASP.NET MVC、Django、CodeIgniter、Node.js，都渐渐有越来越多的资源可以运用。当然，我建议撰写网页还是要从基础练起，不然这些框架很多时候会让你感到非常痛苦，因为你不会知道它背后到底帮你做了哪些事情，反而会让你绑手绑脚的。
Heroku
这是我们放置网页应用程序的空间，这是一个号称云端的网页空间，我曾经写过几篇文章介绍 Heroku。
简单来说，Heroku 提供了简单的资源动态调配的选项，你可以视网站流量、负载随时调整投入的资源（与资金），几乎可以不必修改你的程式。像是东森新闻在总统大选时也是运用了类似的平台来应付超过 2，400 万个网页读取。除了 Heroku 之外，现在有非常多类似的平台，像是 Google App Engine， Gondor， no.de， nodecloud， nodester， ， Microsoft Azure。
AWS RDS
AWS 是由全球最大网络书店 Amazon 提供的云端服务，RDS 简单来说就是他们提供的一个云端资料库，说穿了就是一个不用自己架设的 MySQL。RDS 算起来其实非常昂贵，但是初期我们为了直接跟 Heroku 搭配，就毫不犹豫的选购了。RDS 的好处是它的效能很好（相对于我们自己的小机器）、稳定度超高、有定时的备份机制。
Airbrake
这是我们的应用程式例外处理服务，每当应用程式出错时，应用程式会主动将错误发生时的所有资讯发送到 Airbrake，网站营运的相关人员也会在第一时间收到错误发生的讯息。借此，我们可以掌握每天发生的错误，并且尽早处理。我个人认为，网站发生错误经常是不可避免的，但应该透过各种方式在第一时间掌握并且迅速回应。
Redis
Redis 不是第三方服务，而是一个 NoSQL资料库。我们利用 Redis 来存放几种资料：所有的统计数据（例如每小时、每天的流量）、与搜索相关的数据，以及某些特别的应用。选用 Redis 的理由也很简单，有些事情不太适合用关联式资料库处理，Redis 刚好满适合的，包括统计或是索引方面的功能。
Redis To Go
这是一个 Redis 云端服务，方便归方便，但是当你的应用程式吞吐量较大的时候，经常会出现错误讯息。此外，他们没办法提供用户自订维修的时间，因此如果你的网站时区与他们不一样，那很可能会导致你在某些奇怪的时段无**常使用。
Websolr
Solr 是一个 Apache基金会底下的开放源代码的搜索引擎专案，我们利用 Solr 作为我们的搜索引擎。Websolr 则是一个云端 Solr 服务。Websolr 也是满不给力的，无**确回应的频率颇高，不过我们现在搜索量也还不大，所以之前都还得过且过。（不得不说，Websolr 效能算是挺好的）
Resque
讲 Resque 其实是太偏了，比较好的说法是我们有使用 Message Queue 在处理我们某些需要进行排程的工作。我遇过很多网站经营团队，在网站营运时是完全不用 message queue 的，使用 message queue 的理由很简单，某些工作如果会吃到比较多的资源，或是没有急迫性，或是例行性的工作，应该排进 Message queue，除了可以确保这些工作的完成度之外，也可以在流量突然变大时将工作分散到不同的机器上处理。
New relic
New relic 是一个应用程式的监控服务，简单来说它可以让你清楚的看到目前应用程式运行的效率、资料库的吞吐量之类的，比较好的是它可以提供精确的报表，让你掌握究竟是哪一段程式执行时间特别久，让你可以更有效率的进行改善。New Relic 会在应用程式负载过高时主动通知，这一点也是非常实用的。
AWS S3
我们利用 AWS S3 来存放所有的照片，使用 S3 的好处是我们不需要自己处理储存空间与备份的问题，也不需要负担图片的流量。
AWS Cloudfront
Cloudfront 是 AWS 提供的 CDN 服务，简单来说，CDN 是分散于全球各地的内容发布网络，假设你有一个台湾网站，有一个人从美国上了你的网站，若你有使用 CDN，这位访客有很大的机会可以就近在美国的服务器下载你网站的内容，如此浏览你网站的速度与体验就会大幅的提升。我们网站目前有超过 10% 的海外用户，我们几乎可以确保这些海外用户跟台湾用户可以拥有差不多的浏览速度。
Sendgrid
Sendgrid 是一个专门用来发信的服务，Sendgrid 的好处是提供了一些统计数据，让你了解每日的发信量、开信量、信件点击率。目前我们的发信量还小，倘若以后再大一点，或许我们会自建发信服务。
结语
你可以看到，我们运用了大量的第三方服务，有些是与网页技术比较有关的，有些则是非技术人员就可以迅速套用并且上手的网路服务。
说穿了，除了我们真的没有多余的人力投入在这方面的建置之外，我们也满懒的。此外，现阶段比较现实的是，我们必须专注在网站的核心价值上，宝贵的人力、宝贵的时间都是成本，应当投入在最重要的地方，至于其他次要的事情，我们先花钱外包。
而且，就我个人而言，我更有兴趣的是让产品可以稳定的营运与成长，因此我们目前利用了成本比较低的方式来建置资讯技术上的基础架构，有些服务我们在不久的将来会开始投入资源开始建置自己的版本，有些服务则会转移到别的厂商，这部份的经验与决策的塬因，就留待下一篇文章分享了。
目前说起来，我们终究还是个小网站，等过阵子我们流量大一点了，我会再进一步分享许多营运上、费用与成本相关数据，希望可以藉此与读者们多多交流。
 关于产品运营之类的知识，可到课课家官网查看。我在等你哟！！！你一定会得到你想要的！！