如何做一个快速运转的大规模网络开发公司
一.流程与制度
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://2014.54chen.com/blog/2014/12/11/how-to-big-network/
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://2014.54chen.com/blog/2014/12/11/how-to-big-network/
还没人赞这篇日记
