DBA notes

游击队 vs. 军团作战

dbanotes@gmail.com(Fenng) — Sun, 29 Jan 2012 15:24:09 +0800

在过去一段时间发现，一些大的互联网公司，比如 Amazon、Google、Facebook、Tencent，已经非常倾向于「游击队」作战模式，也即启用技术小团队，快速灵活、便于沟通；而不是动辄几百上千人攻关大项目，我知道淘宝以前有「上万人天」的大项目。

比如，亚马逊 CTO Werner Vogels接受访谈时透露：「亚马逊就建立了很多的技术小团队，每个团队基本上都是 8-10 个人，这种团队的灵活性体现在，当有了新的想法马上就能够行动起来，而且沟通简单，不需要开很多会议才能把事情说清楚」，「」这些技术小团队围绕的是亚马逊提供的各种服务，比如购物、推荐系统、甚至评论服务。」

而 Facebook ，公司已经形成了「特别认可小团队」的文化，「It's important to understand that, at Facebook, we believe in particularly small teams」(refer), 绝大多数项目最多六七个人。

至于 Google，施密特曾有一次在接受采访时表示，「我们的成功产品都是由反应快的小团队开发的」，即使 Google+ 这样毕其功于一役的项目动用了超过 500 人，但「Circles 的设计是由一个人主导的。团队约为5-10人，他们在通用平台上做彼此的工作」

至于腾讯，从对张小龙的采访可知一斑。甚至去年的明星产品微信，团队也并不大，「微信第一批成员不到十人」(refer)。

我不厌其烦的举众多例子，是无意陷入到争论中(至于软件行业的朋友，就更没必要来抬杠了)。这些信息或许给我们一个启示: 游击队模式或许是个好方法。毕竟，军团作战，我是说几十乃至数百上千人的协同开发，实际上给协调和沟通带来了相当大的挑战，与其投入昂贵的管理成本，不如反其道行之，让这些问题不存在。

从我过去一年中的实践来看，收效不错。作为一个管理者，应该尽量克制投入军团作战的野心，尽管「小即美」的道理浅显易懂，但跳出思维定势似乎不那么容易。对于创业团队，人手本来就少，更是应该将单个开发小组尽可能的缩小，两三个人一个小组，效率应该会非常好，而且，创业团队几乎不存在「基础设施集中与否」的问题。

--EOF--

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(10)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

2011年个人总结

dbanotes@gmail.com(Fenng) — Sat, 31 Dec 2011 20:29:45 +0800

by Fenng@dbanotes.net

本年度的最后一天，个人惯例，度过元旦的方式是做一下过去一年的个人总结。翻看了一下去年的总结和计划，完成度还过得去，这一年虽有遗憾，但没有虚度。

2011 年中在工作上多少做出了一点成绩，回顾了一下，上半年经历了从业以来几乎是最为严峻的考验，有段时间头发都急白了不少；下半年则相对顺利，团队效率提升很多，项目和产品上到了收获期，我甚至还能有时间顺路做做公关宣传。这是最有效率的一年。如果用一句话总结，那就是：丁香园全站过去一年中从传统的 1.0 模式升级到了 2.0 版本，打通了任督二脉，甚至还有一点延伸 --比如丁香园用药助手。作为第一款试水性的移动应用，一定程度上获得了用户的认可并且在业界有一点反响，这是整个团队乃至我个人都是始料未及的，很欣慰。总体来说，从大公司到小公司落了地，并且还能做点实际的事儿(某些人看这事儿：真是奇迹)，也对自己有了一点信心，「如人饮水，冷暖自知」。

技术团队规模与去年相比，增加了60%。因为自己不喜欢大公司做事方式，己所不欲，勿施于人，所以对团队完全采取采取扁平结构、氛围尽量保持宽松，收效还不错。其实，一个团队负责人如果能充分调动大家的能动性，你会发现身边都是天才。《道德经》中有一句话：功成事遂，百姓皆谓：我自然。这是个值得努力的境界。

经济上，因为机会合适兑现了一些原公司的股票，算是过去几年的加班费吧，能让家里生活质量暂时提高一点点。投资方面，收获不错。投资老同事的项目成功出售，作为小小天使的另一个项目已经拿到风投并进入良性循环期；贝塔咖啡开了两家分店，「无形资产」起码增长了不少 ;) 允许我自我满足一下。尝试炒了一点美股，战绩还行，这个更大的收获还是了解到了一些公司的业务模式，其实也是在学习。顺便说一下，雪球是个有价值的网站。

这一年中，如果要问在那几个地方获取到有价值的信息最多？第一个是曹政大侠的神秘群组，让我了解到一个不一样的互联网生态圈；第二个地方是在知乎，内容质量非常好；第三个地方是新浪微博，获取到了很多有价值的产品反馈；然后是 Twitter，这一年发言少了很多。当然，要了解医学和健康知识，那还必须是丁香园，中立、客观是丁香园的准则。

拖延了好久的驾照考试终于通过(refer:学车记)，虽然这事儿说出去挺丢人的，但对我自己来说，起码证明我的执行力终于改进了一点儿，自我满足一下。考过驾照之后出门也不怎么晕车了，伴随我这么多年的老毛病总算有所缓解。今年还有一件值得一提的事情是回到母校参加了毕业十周年的同学聚会，是啊，大学毕业10年了，从业也有10年了，就连我自己的个人站点都存在八年多了，时间真是个可怕的东西，不知道下一个十年会是怎样。我想，我应该抽空再修改一下上半年写的那篇《十年莽撞IT路》，算是一份人生的记忆。

这一年，自己完全变成了一个创业者。心态、思维模式改进了不少，人要改变自己很难，还好我不是不可救药。要批评自己的是在微博上不知不觉的暴露了个性上不那么讨好人的一面，有必要收敛一点。读书方面，阅读量还行，和去年相比不相上下(荐书清单)。参加的会议与往年相比，少了不少，只参加了QCon和移动开发大会等几个会议，全程免费的 Oracle Open World 也没时间去了，不过并不遗憾。Blog 数量少了很多（写邮件倒是多了），一是我不再想重复以前的那些东西，二是质量的确所下降，水分增加了，对读者朋友们说声抱歉! 对了，喝咖啡多了，但是失眠少了；几经折腾之后，开始尝试新的生物制剂药物，关节痛基本控制住了，体重居然也增加了 :)

身边的朋友多多少少对这狗日社会的渐渐有了幻灭感，只要我们相信有些事情会变好的，那不妨就积极的一点点做起来。从你我开始。

家庭生活上，有一点失落，但总有些事情是改变不了的，随遇而安吧。

我的 2011 榜单：

年度致敬：陈光诚这个社会缺少有勇气的人；
年度媒体：知乎在这里学到了很多知识，活到老，学到老嘛；
年度图书：吴军大作《浪潮之巅》。候选图书:《黑客与画家》...
年度视频：罗永浩保利剧院演讲(一个理想主义者的创业故事II）；
年度电影：钢的琴，有些生活总是让人感动；
年度音乐：左小祖咒《苦鬼2011》

2012 年的 TO-DO List：

Lean Startup. 过去的一年，其实团队做事一定程度上已经暗合 Lean 理念，2012 还要深入实践。如果还用老思路、老方式做事，不想办法做改进的话，成长自然不会好到哪里，所以，需要新思维。PS. 精益创业模式的理念和原则如下：1.创业第一天就设定收入目标 2. 持续的客户互动 3. 如果没有收入，就一定限制规模(别乱花VC的钱) 4.产品开发周期粒度减小：以小时/天计而不是月或者年为单位 5. 产品开发 - 最少的功能，最大的客户覆盖率 6. 客户驱动的产品开发.

产品研发. 如果2012不是世界末日的话，事情还要继续做下去。计划中还至少有两款有意思的产品要推动，要做出来；

运营意识. 毫不客气的说，过去一年中做的产品有几个并不那么成功，这并不都是产品本身的问题，运营能力不足的确存在，技术部门当然也要有运营意识。多和业界同仁学习，实践，还要勤奋一点。

寻觅人才. 丁香园技术团队仍然需要各方面的人才，尤其是移动应用开发的人才，我们有足够的耐心，也有足够的信心。如果你想在浮躁的环境中想静下心来做点对中国人有价值的事情，为什么不联系我一下呢？

好好生活. 新的一年要多出去走走。旅游，2011年两次国外旅游都挺有收获，怀念长滩的芒果沙冰。新的一年争取好好利用一下假期。另外，如果不是生活必需品，尽量少购买。简化一点生活，没什么不好。

最后，祝愿朋友们在新的一年更好的实现个人价值，让自己和家人生活得更好一些。

致谢：曹政、Hawk、召唤、大风、周拓、肖头、云风、Benjurry、Robbin、校长、Bluedavy、Hugo、国平、夏天天...... (不分先后，肯定还有遗漏的朋友，见谅! )，感谢各位朋友们一年来在技术上给我的帮助，让我学到很多很多，感谢!

--EOF--

这里有我的一份针对互联网的 2012 预测，仅供娱乐。

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(11)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

Instagram 架构分析笔记

dbanotes@gmail.com(Fenng) — Wed, 07 Dec 2011 15:11:44 +0800

by Fenng@dbanotes.net

Instagram 团队上个月才迎来第 7 名员工，是的，7个人的团队。作为 iPhone 上最火爆的图片类工具，instagram 用户数量已经超过 1400 万，图片数量超过 1.5 亿张。不得不说，这真他妈是个业界奇迹。

几天前，只有三个人的 Instagram 工程师团队发布了一篇文章：What Powers Instagram: Hundreds of Instances, Dozens of Technologies，披露了 Instagram 架构的一些信息，足够勾起大多数人的好奇心。读罢做点笔记，各种线索还是有一定参考价值的。能打开原文的建议直接读原文。

Instagram 开发团队奉行的三个核心原则：

Keep it very simple (极简主义)
Don't re-invent the wheel (不重复发明轮子)
Go with proven and solid technologies when you can(能用就用靠谱的技术)

OS/主机

操作系统的选择，在Amazon EC2上跑 Ubuntu Linux 11.04 (Natty Narwhal) ，这个版本经过验证在 EC2 上够稳定。因为只有三名工程师，只有三名工程师，所以自己部署机器到 IDC 是不靠谱的事情。幸好有亚马逊。

负载均衡

此前曾用过两台 Nginx 做 DNS 轮询承载前端请求，这样做会有副作用，现在已经迁移到Amazon的ELB(Elastic Load Balancer)，起了三个 Nginx 实例，在 ELB 层停掉了 SSL , 以缓解 CPU 压力。DNS 服务使用 Amazon Route53 服务。

应用服务器

启用了 25 个 Django 实例，运行在 High-CPU Extra-Large 类型的服务器实例上，之所以用 High-CPU Extra-Large 实例是因为应用请求是 CPU 密集型而非 IO 密集型。

使用 Gunicorn 作为 WSGI 服务器。过去曾用过 Apache 下的 mod_wsgi 模块，不过发现 Gunicorn 更容易配置并且节省 CPU 资源。使用 Fabric 加速部署。

数据存储

用户信息、图片元数据、标签等大部分数据存储在 PostgreSQL 中。主要的 Shard 数据库集群有 12个节点。

实践中发现 Amazon 的网络磁盘系统单位时间内寻道能力不行，所以有必要将数据尽量放到内存中。创建了软 RAID 以提升 IO 能力，使用的 Mdadm 工具进行 RAID 管理。

管理内存中的数据，vmtouch 这个小工具值得推荐。

PostgreSQL 设置为 Master-Replica 方式，流复制模式。利用 EBS 的快照进行数据库备份。使用 XFS 文件系统，以便和快照服务充分配合。使用 repmgr 这个小工具做 PostgreSQL 复制管理器器。

连接池管理，用了 Pgbouncer。Christophe Pettus 的文章包含了不少 PostgreSQL 数据库的信息。

TB 级别的海量图片存储在 Amazon S3 上，CDN 采用的也是 Amazon 的服务，CloudFront。

Instagram 也是 Redis 的重度用户，Feed 以及 Session 信息都用 Redis 处理，Redis 也是以 Master-Replica 方式部署。在 Replica 节点上进行数据备份。

使用了 Apache Solr 承担 Geo-search API 的工作，Solr 简单的 JSON 接口也不错。

缓存使用了 6 个 Memcached 实例，库使用 pylibmc 和 libmemcached。亚马逊也提供缓存服务－Elastic Cache service ，Instagram 也有尝试，不过不便宜。

任务队列/发布通知

队列服务使用 Gearman ，通知系统则使用 pyapns 来实现。

监控

前面提及的服务器实例数量加起来，的确有100多个，有效的监控是相当有必要的。使用 Munin 作为主要监控工具 , 也写了不少定制插件，外部监控用 Pingdom 的服务。通知服务使用 PagerDuty。

对于 Python 的错误报告，使用 Disqus 团队开源的 Sentry 来处理。

几个感想

0）轻装上阵说起来容易，做起来非常难。这也是 Instagram 团队目前最令人着迷的地方；

1）Python 社区已经足够成熟，各个环节上都已经有不错的解决方案了。

2）如果要问我最大的一个感慨，我要说：Amazon 真是一家伟大的公司，甚至比 Google 还伟大。

--EOF--

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(12)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

对 Pinterest 类应用的一点思考

dbanotes@gmail.com(Fenng) — Tue, 29 Nov 2011 23:56:37 +0800

by Fenng@dbanotes.net

最近一段时间 Pinterest 类应用相当火爆，引发了不少讨论。我自己最近也一直在使用花瓣，也在捉摸为什么这一类应用这么有魔力。知乎上有个问题是: Pinterest 好在哪里？，尝试做了一下回答，也稍作整理，发在这里做个记录，会随着理解再做进一步修改。

本质上，Pinterest 类应用属于社会化书签站点的延续，只是要处理的数据对象变成了「图片」，而不是传统社会化书签的URL。这是社会化信息处理的一次改良。

提到社会化书签，不得不提 Del.icio.us ，不过或许 Del.icio.us 模式已经到头了，即使现在从Yahoo! 手里卖给了陈士骏，也不太可能玩出新花样，因为核心的数据对象没变。

相比 Flickr 来说，Pinterest 主要的生成内容动作是 Pin (花瓣叫采集)，而 Flickr 则是 Upload，这个动作上的不同导致 Flickr 向左，Pinterest向右。Flickr 重心是「照片」(Picture)，尤其是原创照片，而非图片(Image)。 Flickr的一个弊端是大量的图片没有标题，这意味着元数据的先天不足，不太可能和其他网络内容进一步结合起来。但是也要说一下，Flickr 现在的价值是被低估了。

Pinterest 相对 Flickr 来说，恰恰是一种互补，每张图片基本可以关联到一条URL，进一步可以抽取其他信息。

从用户行为的角度上看，满足了用户天生的「收集癖」，很多人都有看到一张照片想顺手存起来的冲动，没有Pinterest这类产品之前，这个交互操作太费事了... Pinterest 无疑弥补了人的这个原始的需求。

Pinterest 类应用的创新之处我认为是「降低了收集信息的门槛」，或者，至少做到了这一点。其价值是不言而喻的，每一次信息处理的门槛降低都会得到商业价值的变现，你可以不信。

要有足够好的技术团队支撑、足够好的数据处理能力才能走到最后，这也是在国内众多产品中我看好花瓣(huaban.com)的主要理由。

--EOF--

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(3)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

技术人创业建站简略指南(Version 0.03)

dbanotes@gmail.com(Fenng) — Mon, 21 Nov 2011 19:41:28 +0800

by Fenng@dbanotes.net

你是一个技术人员，你想创建一个站点，或许是一时心血来潮，或许是为了自己的兴趣爱好，或许是...「创业」前的热身准备？那么，如何少走弯路的构建起来你的 Web 站点呢？别笑，不是每个做技术的都捣鼓过个人站点，不是每个人都独立搭建过网站(我不是说个人Blog这样简单的东西)，下面的简略指南或许能帮到你。毫无疑问，以下都是广告。

0. 信用卡

这个真要有!

确保有一张具备境外支付功能信用卡。这一点我想不是难事，就算是在校的学生，申请信用卡的门槛也小了很多。现在各个银行发信用卡都是求着用户的，申请的时候问清是否具备外币支付能力就好了。有了信用卡之后，你可以较为方便的申请 Paypal 、App Store 帐户、Google Checkout...

有了信用卡之后，你可以大大方方的收美元了 -- 如果你是面向非中国用户的话。

1. 购买域名

不要在国内的域名提供商那里购买域名。为了一时方便以后你会付出更多的代价，你可以看一下这里的血泪史。购买域名，我建议在Name.com（ ~~Godaddy~~ )上购买就可以，~~顺便说一下，GoDaddy 也支持支付宝~~。如何买到好的域名? 我没办法告诉你(如果你要从别人手里购买域名的话，可以看一下 4.cn).

域名备案怎么办？如果你的内容不是特别敏感的话，不备案可能问题也不大，低调一点，别自己往墙上撞。

备选: Domain

2. 主机服务

有了域名之后，那么购买主机就要提上日程。建议用 Linode 的 VPS 服务，价格不算贵，关键是容易上手，相对比较稳定，Linode 在东京的 IDC 访问速度居然...和国内某些 IDC 差不多。有些做技术的朋友，可能自己手头有个主机什么的，尽量不要托管在 IDC 了，机器硬件坏了或是被拔了网线，会让你很闹心。

如果你的Web应用已经写的差不多了，购买主机之后不妨进行部署，在线测试。如果应用正式上线，那么不妨买一个备份服务，每个月5美元而已。

有了境外的 VPS 的一个好处是，你可以通过 VPS 「翻墙」，锻炼一下腿脚。怎么做，搜索一下就知道了。如果要简单的优化一下 VPS ，参考这篇。

备选: Slicehost

3. 域名解析

为什么要单独提 DNS 解析？GoDaddy 和 Linode 都提供 DNS 解析能力，不过，域名在哪里注册的和域名在哪里解析是两回事。重要的是，DNS 修改之后的有效验证是个不小的问题，还有一个是影响因素 DNS 解析速度，所以，有必要启用智能 DNS 解析服务，DNSPod 做的相当不错。用了之后你就知道，而且，没有副作用 :)

4. 静态文件

服务器在境外，经常遇到的一个性能瓶颈静态文件(尤其是图片)的访问速度上不来，而恰好你的应用要存储较多的静态文件的话，不妨研究一下 UpYun 的服务。如果你是个开发者，你会体会到一定的妙处，去看看又拍云的 API，你会喜欢的。重要的是，价格也可控制。在项目的启动阶段，时间是最宝贵的资源，一切能节省时间的手段都要充分利用，否则国内 Startup 怎么做到比国外快？

阅读: 又拍云实战

备选: CloudFlare(如果你的服务是面向国外用户的话)

5. 运维监控

即使是最简单的站点也有必要关注可访问性，监控机器运行状态。推荐监控宝的免费服务，足以满足小型个人站点对于监控的要求。Google Analytics 和 Google Webmasters 有必要启用。百度的统计服务最近一段时间也越做越好。

6. 邮件方案

如果是做邮件托管的话，也就是你的站点本身的邮件帐户解决方案，Google Apps 是不二之选。如果需要发邮件给你站点的注册用户，或者做小规模的 DM , 在 Linode 上启用 EXIM 就差不多了。

备选: 网易免费企业邮局/腾讯企业邮箱

7. 字体问题

如果你的项目需要较多的设计工作，不可避免的要用到一些商业字体，如果想避免收到律师信或是勒索信的话，建议使用造字工房的字体，性价比非常高。

N. 接下来呢?

下一步该做什么？或许有必要成为 Github 的付费用户，开发、部署、上线、推广...等你到了一定规模，咱们再来第二季。

恭喜你走上不归路，也祝愿你得到一些因为折腾而带来的乐趣.

--EOF--

(发现还是太简略了，欢迎大家留言补充)

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(22)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

从开发者角度看国内 Android Market 的用户体验

dbanotes@gmail.com(Fenng) — Thu, 10 Nov 2011 18:52:22 +0800

by Fenng@dbanotes.net

近一段时间在发布丁香园用药助手 Android 版的过程中把国内几个重要的 Android Market 用了个遍，每次要发布新版本的时候都要感慨一下：几乎所有的 Android Market 后台的用户体验都不怎么好。

信息各有一套

国内所有的 Android Market 和 Google 官方 Android Market 都是不"兼容"的，无论是产品的描述信息以及应用类别划分，每一家都是自成一套。比如，软件截图，各有各自的要求，尺寸、格式如果不一致的话，还要针对性的单独人工处理，对开发者的工作量无形中增加了许多。对产品的描述也是千奇百怪，有的支持富文本编辑，有的只支持普通文本。有的更新软件要求写更新内容，有的则不提示填写，如果自己想写的话，需要修改整个 App 的描述信息。再比如分类信息，丁香园用药助手在有的 Market 上只能列入到「生活」类，而在另一个 Market 或许就要被迫列入「其他」，因为实在找不到和健康或是医疗相关的类目。

版本控制问题

只有少数一两家对版本控制还算有点意识，多数都没有相对靠谱的版本控制机制。有放任自流派：开发者在后台任意更新版本；也有关卡审核派：让你处于一个无法修改也无法撤销的"审核中"状态，一旦发现错误，想更正只能等下一个版本。至于审核周期，也是千奇百怪，有的立等可取，有的需要人工联系「我们发布了一个新版本，抽空给审核一下吧」，也有的长达一周。

后台可访问性

有的后台速度慢(这是很难让我想通的问题)，甚至应用截图都不能正常显示；而上传的接口，也有很多细节问题，比较离谱的是有几家居然不提示上传进度，整个上传过程中只能凭感觉，等待，刚好丁香园用药助手的软件包还比较大，有的时候遇到传输中断，简直令人抓狂。

界面信息混乱

第一次注册后提交软件的时候要把整个流程跑通还是比较难的，提示和术语都要理解半天才知道是怎么回事，文案差异性太大。登录到后台后，一个典型的情况是多数 Market 从后台找不到发布后的应用在前台的链接，比如应用汇。而有的 Market 更加离谱的是，后台还是传统的表格形式的展示，比如魅族。

数据不够准确

几乎所有的 Android 市场，统计信息都不是特别准确，有些甚至下载统计数天都不更新，有的甚至后台就不做数据统计，下载多少要前台页面自己去看。想得到靠谱的 Android 下载数据，哦，你实际上得不到靠谱的 Android 下载数据，如果想统计应用打开的数据，最好是早点启用类似友盟这样的应用统计服务。

流程足够复杂

流程复杂这个主要是针对联通、移动、联想这些富有官僚气息的 Market 来说的，比如用户资质信息最多的有上百条信息要填写，你就折腾吧，没有几个小时，没有公司上下配合(还要营业执照副本什么的)你根本搞不定，在你提交应用之前你准会崩溃。所以，有些时候，对这样的市场不得不放弃，即使有用户真的要从这些渠道下载你的应用，也没办法。

结束语

其实，倒也不只是国内的 Android 市场对开发者的用户体验差，Google 官方的菜市场也不咋地。每天在网上看到网友数落这个网站用户体验差，那个网站用户体验差什么的，其实如果你去用一下这些Android软件市场，就知道用户体验差其实是没有底线的。

前几天参加移动开发者大会，发现 App Market 俨然已是各大互联网公司的标配，都在纷纷的推出自己的 Market ，恐怕以后还会更乱。据悉，已经有创业团队在开发一次性提交到多个 Market 的工具了，不知道什么时候能看到。很明显，这也是吃力不讨好的事儿。

也可能是每家 Android Market 都在拼前台的用户体验呢吧，真心期待国内 Android Market 能早日关注一下针对开发者和维护者的用户体验问题，这也是每个 Android 开发者期待的，让开发者有更多精力做应该做的事情。

--EOF--

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(4)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

Tuning Linode VPS－小规模低性能低流量网站优化实践

dbanotes@gmail.com(Fenng) — Mon, 10 Oct 2011 19:26:20 +0800

by Fenng@dbanotes.net

偶然看到以前写过的这篇帖子『小规模低性能低流量网站设计原则』，重新发到微博上引起了一点反响，觉得有必要以 Linode VPS 为例再做个简单的优化实践说明，免得总有人问我，也顺便赚点点击量 :)

假定现在你已经有了一个基本的 VPS 可用，基本内存 512MB 。参考官方提供的各种安装指导将 LAMP 这个组合运行了起来，操作系统一般 Ubuntu ，Web 服务器 Apache ，数据库 MySQL ，然后是 PHP ，以及需要安装的应用软件，WordPress 、Drupal 或是 OpenCart 什么的，一步一步配置好，能够正常的浏览页面。按照官方指导文档操作的一个好处是会包括一些基本的优化一点的配置。不至于出现太大的错误。

一旦应用就绪后，登录到操作系统中，通过 top / iostat / free 等基本操作系统命令收集基准数据，做记录。收集信息越全面，对于后面的优化就越便利。优化没有魔法，只有合理的方法。

1.内存相关的调整

内部测试或是较小范围使用，可能这样也不会遇到太大问题。一旦访问人数多了一点，机器响应可能就有点慢了。对于 VPS ，第一步着手调整的就是各个组件对内存的使用。因为内存受限，对内存的使用一定要精打细算一点。记住一旦内存耗尽，一部分内存调用压到磁盘上，系统负载会飙升，一般就会挂掉。

一般来说，对于 LAMP 环境，以下几个地方要注意：

PHP 程序的内存相关的调整

PHP5 配置文件 php.ini 中 memory_limit 定义的值默认情况是16MB，该参数定义单个 PHP 脚本消耗最大的内存大小(大意)。如果程序某个页面需要的内存超过这个限制，访问者最可能遇到一个 HTTP 500 错误，查看 Web 服务器错误日志也可以看到。多数情况下，这个值需要做相应调整。比如设置为32MB，是否合适，需要做观察。有一个经验方法是观察 top 命令的输出，看相应进程的 SHR 字段的值，实际上总是尽量大一点点。但不能过大，一旦有个别程序写的不好调用的时候占用过多资源，会导致 VPS 挂掉。

经常有人问，这个服务器跑某某 Web 应用，能支持多少并发? 一个大致的思路是估算单个进程占用的内存，看系统能分配多少内存给应用程序，并发的量大致可以估算得到。但实际上，这个提问基本没多大价值。

另外，还有一个比较重要的参数需要修改 output_buffering 需要修改为 On 或是具体数值(eg, 4096)。修改配置后，检查是否生效(如何检查?)。另外，记住error_log的位置，随时查看。

MySQL 数据库内存占用

如果不确定 MySQL 内存使用情况，可以利用 MySQLReport 这个工具收集一下 MySQL 实例的信息报告，不同时间段多收集几次作为对比。然后相应的调整 key_buffer/query_cache_size 等参数的大小, 一次调整一个参数，重启动 MySQL ，继续抽取报告，分析数据，然后调整下一个参数。既然需要编辑配置文件 my.cnf , 建议顺手加大一点 max_connections 这个参数(为什么?)。

多数内存问题都是由数据库 I/O 引起，导致 I/O 问题多由不合理数据库调用有关(这么说严谨么?)，解决不合理调用要么修改应用，要么通过查询缓存或是 Key-Value Cache 等办法缓解。这地方说来话长，假定 VPS 上基本不会有这么复杂的环境。

2. 影响 CPU 利用率的调整

这个主要针对 PHP 的 Opcode(Accelerator) 而言，解析、编译PHP代码是相当消耗CPU的操作。常见的要么是 APC, 要么是 eAccelerator 或是 XCache，在 Ubuntu 下安装配置都相对简单，参数调整简单搜索一下就知晓了。如果是 PHP 环境，那么一定要用 Opcode 减少 CPU 的负荷(为什么?)。至于用哪一个关系倒是不大，但前提是必须要有一个。

另外，张磊同学这篇让进程运行在指定的CPU 对于特定需求的应用，很有借鉴意义。

3. 网络参数控制

修改 /etc/sysctl.conf 文件，增加如下几行：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

然后 sudo sysctl -p 使修改生效。使用如下一行命令观察半连接数量：

$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

其实一般来说，网络连接数不会成为最明显的瓶颈。但顺手调整一下也好，「不费电」。有人问，如果遇到 DDoS 怎么办？忍着。

4. 应用程序相关的调整

比较流行的开源程序，不安装第三方插件的情况下，性能多少过得去。建议如果没有必要，不要启用过多的第三方插件，尤其是一些带有统计或是「智能」显示内容之类的插件能不用就不用。

这些开源程序也基本上都有面向前端优化的静态化解决方案，比如 WordPress 的 Cache 相关的插件，强烈推荐启用。有时间看看前端优化的实践建议。

(图片来源)

优化最重要的是找到瓶颈，对症下药。前面已经说到了内存、CPU、网络，大致提了一点 I/O 问题，基本也就够了。PHP 的 Log , MySQL 的慢查询 Log ，Apache 的 Error Log ，常过滤看一下有没有新情况。

补充一点，别忘了修改 OS 的 ulimit 限制：

编辑 /etc/security/limits.conf 增加如下两行(具体数值大点小点问题不大)：

*  soft  nofile 40960
*  hard  nofile 40960

编辑 /etc/pam.d/common-session ，增加如下一行：

session required pam_limits.so

编辑 /etc/profile ，增加如下一行：

ulimit -SHn 40960

重新启动 OS 即可生效。

Linode 后台提供了几个基本的统计图，基本够用。可以设置磁盘 I/O 过高的时候报警，系统会发邮件给你。注意看一下网络流量的使用。不要因为个别文件被盗链而将带宽消耗殆尽。

上面提到的不少修改建议不要照葫芦画瓢，知其然，还要知其所以然。每一步的调整多阅读系统手册，尤其是涉及到具体的参数数值，一定要针对实际情况修改。对基本的配置足够掌握之后，可以根据具体情况尝试性能效率的组件，比如用 Nginx/Lighttpd 替换 Apache ，但是要记住，如果 Apache 不是瓶颈的话，用传说中性能更好的 Web 服务器来替换无疑是折腾。

再次提醒不要过度优化，足够满足需求就行了。有更多的精力完全可以放在其他环节上。另外，如果基本的调整做过之后，想用最省事的办法改善性能，那么，直接向服务商购买额外的内存吧。

好吧，最后我想说的是其实这个优化思路并不局限于 VPS ，这个最小实践套路对于复杂的服务器环境也是基本适用的。

--EOF--

Tip：页面不要引用太多的三方脚本。否则也会被拖慢不少。

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(18)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

丁香园技术团队是怎么招人的

dbanotes@gmail.com(Fenng) — Wed, 28 Sep 2011 21:33:43 +0800

by Fenng@dbanotes.net

不知道国内是否有创业团队招人是不费吹灰之力的，至少我了解到的绝大多数创业团队都面临招聘难的问题，而且不是一般的难。和一些中小互联网公司的技术负责人交流，也都会为招人的问题而诉苦，丁香园作为创业团队当然也是这样。从去年年中我加入丁香园负责技术团队开始，招聘就是最大的挑战之一。今天在阅读完知乎上「创业公司应该如何招人？」这个讨论之后，在这里也想分享一下丁香园技术团队的招聘经验。

我们找什么样的人？

概括一下说，我们要找的人最后一定是个「能解决问题」的人。另外，需要有一定的自我驱动能力，不要事事都要别人来管理。一定程度上，我们力争把技术团队打造成「自我管理型」的团队，真正「有效率」的团队。

通过影响力吸引人

是否小的团队影响力一定小？是否足够有名气才有足够的影响力？当然不是，看你通过什么方式、什么渠道去影响什么人。比如对我们来说，Twitter 是相当不错的扩大影响力的工具，也是个非常好的招聘渠道，在长期认真经营之后，有必要进行合理利用。有很多给丁香园投递简历的人在之前都通过我的 Twitter 关注我在丁香园这家公司的动态，绝大多数人也都阅读过我的Blog上的文章，如果他们认为我是不靠谱的人的话，不可能投递简历过来。

Twitter、微博、Blog 等平台和工具是创业团队最应该利用好的渠道。谁让你没有其它资源呢? 这就是创业团队的局限性。我不喜欢用相对封闭的资源(比如学校的BBS)去发招聘信息，同时希望能找到的人有一点信息外向的意识，而不是只等着别人找到他/她。

通过价值观说动人

当然，投递简历过来只是第一步，重要的是沟通并确定是否是"志同道合"的人，是否认同这个团队做的事情，是否认同这家公司做的事情，是否认同这个行业，是否想让自己创造更大的价值 -- 这些当然都要弄清楚。还要弄清楚候选人不单单为了一两个技术明星而过来，「慕名而来」往往是很危险的事情。

可能很多人会很反感"价值观"这三个字，别误会，在这里我只是想强调一下我们彼此共同认可的东西，我们是为了彼此认同的东西才共事，而不只是通过薪水去诱使人进入公司。同时，在面谈的时候我也会直接告之候选人丁香园技术团队的不足之处，甚至我们公司的不足之处。短期内我们给不出足够高的薪水，但我们力争中长期让你有足够的回报。甚至就拿办公环境来说，肯定不如一些大公司那么舒适。当然，有差距不要紧，只要真的能够逐步改进。

不作校园招聘但招实习生

坦率的说，中小公司如果不是特别特别有魅力的话，跑到学校大张旗鼓的去做校园招聘，无论时间、人力还是物力，都实在是一种铺张浪费，而且，效果未必好，毕竟那是在和大公司直接在校园招聘市场竞争。

我们的做法是，通过 Twitter、Facebook 等网站寻找实习的同学(尤其倾向有能力「翻墙」的同学)，提供不固定限额的实习岗位，提供成长环境和学习机会。值得一提的是，实习期间表现优异的话我们提前支付转正后的薪水。过去一年中，一共有 8 位同学来实习过(包括即将大三的也有)，最终有四位同学留下来，正式加入了我们团队，在各自的技术方向上都有不小的进步，而且对团队贡献不小。

有效控制招聘成本

在今年年初的时候，技术团队的招聘停掉了在智联招聘、中华英才网等各个大型招聘网站上的招聘广告，我不是说通过这些网站找不到适合我们的人，而是因为隐性成本相当的高，不只是广告费用上的投入，还有简历筛选以及面试，都要投入很大的精力。去年2010年下半年还有通过这些网站在收集、筛选简历，2011年基本上就停掉了。不过，我们依然会在专业的技术网站上投递招聘信息，当然，免费的更好。

尽管之前曾经通过委托招聘的方式找到过非常好的人才，但以后将不再通过猎头进行招聘工作，主要是出于成本的考虑。另外如果花钱就能解决，那么还要我有什么用？

节省下来的招聘成本一部分用在推荐或是内部推荐的激励上。对于内部推荐，我们给出的是相当高的激励标准：一个月的薪水。有些特殊岗位的招聘，自荐也给奖励。我们不会去「高薪挖人」，这实在是很愚蠢的做法。对每个人来说，薪水和回报是自己的工作付出得到的，不是被挖了才有的。

随时随地做招聘工作

Facebook 前工程总监黄易山在总结 Facebook 研发文化中的宝贵经验中说道「永远将招聘作为你的第一要务」，于我心有戚戚焉。实际上，要我说出来我用了多少时间去做招聘，无法给出具体可靠的数据(如果有人给出你数字，要么公司足够庞大有闲人去做统筹，要么是在蒙人)。但有一点我可以保证：随时随地做招聘，时刻想着招人。比如，我在知乎阅读 iOS 相关问答的时候偶然发现一位不错的工程师的主页写着准备找工作，立刻联系... 最后又经过几次沟通之后成功说服他加入了我们团队。

不能等有了招聘名额再去行动，那样必然被动，创业团队不要做刻舟求剑的事情。有一点要说明的是，不作限制的情况下不是招到越多的人越好。这个似乎人人都明白，但是有些人一有点小权利就喜欢扩充地盘，盲目的认为自己管理的人越多就是权利越大，就越有晋升的机会，在大公司里面很常见，最终是人浮于事。这一点上我倒是很庆幸。

招聘工作永远要改进

每过一个季度会审视一下整个团队过去的招聘工作，如果发现过程有做的不够好的地方(比如招聘环节衔接上的疏漏)需要立即在下一个周期着手改进。招聘工作永远都不是完美的，但能做的更好一点为什么不做？

在这里也向曾经接触过的朋友们说一下：如果有做的不好的地方，还望见谅!

一年过去了，回头一看，团队规模已经扩大了整整一倍，四分之三是新人。当然，我们现在依然缺人。比如，现在依然在招聘移动应用开发的人才：

如果你对丁香园技术团队感兴趣，我们干脆一起谈一谈!

--EOF--

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(15)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

Linux Ksplice，MySQL and Oracle

dbanotes@gmail.com(Fenng) — Thu, 22 Sep 2011 13:34:57 +0800

by Fenng@dbanotes.net

Oracle 在 7 月份收购了 Ksplice。使用了 Ksplice 的 Linux 系统，为 Kernel 打补丁无需重启动，做系统维护的朋友应该明白这是一个杀手级特性。现在该产品已经合并到 Oracle Linux 中。目前已经有超过 700 家客户，超过 10 万套系统使用了 Ksplice (不知道国内是否已经有用户了？）

今天看到，Oracle 今后将只对 Oracle Linux Premier Support 客户提供 Ksplice 服务(refer)。毫无疑问，这个产品从一定程度上大大提升生产环境(尤其是数据库服务器)的安全性、可靠性和可用性，对购买了 Oracle 相关服务的用户来说，无疑这是个好产品，但对于 Linux 生态来说可能是灾难，尤其是 Red Hat，市场或许将进一步被 Oracle 蚕食，短时间内不太可能找到替代性的产品，看 fork 出来的 Ksplice 分支会怎样吧。Oracle 已经成为 Linux 操作系统市场上举足轻重的玩家，但是不交钱，用户没办法和 Oracle 玩儿。

MySQL 最重要的存储引擎 InnoDB 也控制在 Oracle 手上，当然 MySQL 也在 Oracle 手上。最近的有部分迹象表明 MySQL 部分功能即将闭源。MySQL 官方博客说部分插件只有商业版才会提供，比如 Thread Pool ，官方的测试报告显示，配置了 Thread Pool 的MySQL企业版，在4K个并发链接的情况下展示了良好的可扩展性(refer)。想使用? 交钱吧!

别忘了，Java 也在 Oracle 手里。

--EOF--

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(9)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...

Linode VPS 迁移到日本 Tokyo IDC

dbanotes@gmail.com(Fenng) — Tue, 20 Sep 2011 19:43:02 +0800

by Fenng@dbanotes.net

Tokyo Hot!

今天看到 Linode 针对亚太地区用户的需求新开辟了日本东京机房。价格不变，速度会更快(地理优势)，看了网友的反馈也是如此。所以第一时间迁移了过去。

迁移 VPS，需要在后台 Support 处开一个 Ticket ，客服人员会在分钟级别提供响应，提供一个简单的指导，要你关掉 VPS , 点击迁移 , 然后耐心等待。并且会告之你在东京机房的 IP 地址。

这里有一个小技巧：在客服通知你新的 IP 之后，先在后台 DNS Manager 中修改 DNS, 以便减少一些宕机时间，否则迁移完了还要再等 DNS 生效(另：推荐使用 DNSPod 的服务，谁用谁知道）。因为是跨机房迁移，所以操作系统磁盘镜像文件传输速度并不是特别快，我观察到的速度是 2MB/s 左右。启用新的IP之后，如果你的服务器配置绑定了IP，记得修改一下。

如果 Startup 团队要选择 VPS ，面向国内用户的话，建议选择 Linode 东京的机房就可以，访问速度相当不错。值得一提的是，Linode 前不久推出的 NodeBalancer 也是个很有趣的服务。如果对可用性要求较高，或许可以尝试一下。

每当品评国内云计算公司，我喜欢拿 Linode 说事儿，或许有些人会觉得 Linode 做的是小生意，也有人私下里嘀咕：是不是你只知道 Linode？看看数据吧，事实是：Linode 去年(2010)收入1070万美元。而员工数？只有19人！位列 Inc. 500 名单。这家公司并不是一夜之间冒出来的，2003年就已经成立。如果前几年乱烧钱，早死在沙滩上了。

--EOF--

BTW, 我的 Linode referral code: 92405a6e282a712f7a1270e98d16eba13efb1b68
如果你也准备购买，不妨用一下我的 referral code :)

最近文章|Recent Articles

本站赞助商：豆瓣网(Douban.com)

评论数(21)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

DBA Notes 理念: 用简约的技术取得最大的收益...