如何做一个快速运转的大规模网络开发公司

受《精益创业》 http://www.duokan.com/book/35802 这本书影响甚多,然而在思考和实施的过程中,却又遇到各种各样的问题。

不仅仅是一些令人苦恼的“人的问题”,还有一些,是无从下手、或者不知道未来是怎样的疑惑。

以下,列出一些“看得见的未来”,因为是一些系统已经在线上服务过亿的用户,如果你在思考相同的问题,也许会有一些用处。

一.流程与制度

1.代码质量

  • 没有经过适量单元测试的代码,不能发起code review。
  • codereview:每行code都经过超过两双眼睛阅读。
  • 没有经过code review的代码不能进入代码库。
  • 没有经过完整bvt测试的代码,不能merge到线上分支。
  • 没有完成上述流程的代码,不应该被用户访问到。

2.故障报告

  • 实际上最有效的制度是postmortem制度,但往往在国内被称为“故障报告”。
  • 如果在你的公司里,《故障报告》与工资是挂钩的,恭喜你,制度用错了。
  • 故障报告的本意,是让发生的故障告诉所有的人,让所有的工程师都学到,这次故障的起因是什么、如何避免。
  • 故障报告绝对不是用来惩罚和警告你犯错了。
  • 不情愿的故障报告,宣告了这个制度在你司实施的失败。
  • 经常性的重复的故障报告,一定是制度没有彻底实施或者招聘人员眼神错了(眼神错的几率小之又小)。

总结

  • 做一个让所有工程师(包括开发测试运维)勇于出来告诉大家我哪里错了的制度。
  • 不断去总结和完善故障中的处理办法。

二.工程

  • 从工程上,不断去提炼与归并,抽象出高度集成化的系统和服务。

1.storage

  • 越早的引入key-value的稳定高效存储,可以事半功倍,但一定要稳定高效(高性能、高可用性)。
  • 类似key-value的业务写法,应该深入人心。
  • 可以选择的开源的有一些类dynamo系统,使用会较复杂,也许直接使用mysql的table更加有效。

2.paas

  • 越早的引入paas平台,也可以事半功倍,但一定要是靠谱的平台。(市面上大量的开源平台,需要有一支团队研究它)
  • paas平台的目的,是统一了dev与op的接口层。
  • paas还可以为你的硬件和网络资源做出更准确的预估。

3.监控与报警

  • 越早的建立此平台,越能提升团队对线上问题的警觉性。
  • 标准的监控与报警平台,有助于更加方便地了解整个环境的情况。
  • 报警一定要命中要害,减少误报,更牛的要做到预报。

4.dbproxy layer

  • 此层需要有高手存在,会各种开发的dba。
  • 目标是做好隔离、做好分区、做好自动化扩容。
  • 这层建立好了,以后服务可用性大大提升。

5.异步事件服务

  • 此服务在人手多时可考虑。
  • 写多线程程序不是容易的事情,把可异步处理的业务,在逻辑中交给一个专门的服务处理。
  • 在这之前,需要统一rpc相关框架。

6.配置中心

  • 典型的开源产品zookeeper。
  • 服务的发现与故障自动摘除。
  • 最好对zookeeper进行一层权限包装,避免实习生干坏事。

7.服务框架

  • 典型的开源产品thrift。
  • 内网的rpc框架,是让你服务与服务之间保持良好架构的必须品。
  • 框架一定要快,一定要有各种可测量的指标。但是thrift是没有的,需要自己加。

8.web框架

  • 典型的开源产品rose spring play。
  • 用于统一大家的代码结构,能够换岗维护。

9.代码规范

  • 不用讲了,就是为了美观。

10.文档规范

  • 不用讲了,就是为了可维护。
  • 闲时多写,忙时少写。
  • 但不能不写。


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]

捐款订阅54chen
捐赠说明