说个在小 team 里面实现得还过得去的模式（当时 docker 还不够流行）

前提：
1. 强大的测试能力或者说自动化测试
我们的测试哥们工资很高，能指导开发数据库设计不合理，能写自动化测试
2. 较好的线上环境重建能力；包含标准测试数据库依赖的环境 5 分钟（也就是不管因为测试把数据库弄得怎么样了，5 分钟全套回复到标准环境）；线上数据库脱敏重建 30 分钟；
3. 变更管理较完备，数据库变动版本化进入代码。

做法：
敏捷模式，每周 release，但是每 2 ～ 4 周为一个 sprint，每个 sprint 里面程序员手头 3 ～ 6 个功能 /Fix，每个功能一个分支。少数情况 2 ～ 3 人工作在一个分支上
hotfix/紧急变动在测试通过后会迅速合并到 master
分支提测前，会保证合并了当前 master （普通 merge 模式；不 rebase -- 当时大家 rebase 用得实在不熟，否则 rebase 应该也行）。会要求程序员做基本自测。
自动化测试通过后，该分支会被合并到一个测试环境（代码包括所有提测的分支），合并有冲突会打回让程序员自己去兼容其它分支（这个情况比较少，可能也是比较麻烦的，基本上让他们本地拿测试分支 merge 找问题）；这个测试环境会再来一轮自动化，有问题也打回，然后 revert （这两步后期是土法脚本化了）；
然后在这个环境上做对应的新功能测试，有问题也是 revert 掉这个分支带来的改动。
周五下午会决定哪些功能在上述环境上已经稳定并且准备上线，所有待上线分支都冻结，然后单个分支 squash merge 到 master。对这个 master 做一些最后测试并确认。
周一上线。（只有脚本自动化，有回退，但是没有灰度发布，有数据库变动且不兼容回退也碰到过，这个没完美解决好）
之后删除已上线两周的老分支（少数重要分支打 tag 后删除）。

优势是 master 上都是干净的一个个功能 commit 和部分 hotfix。

另外，如果分支跨了 sprint，基本上也是很烦的，和其他分支冲突几率大大增加；通常我们在回顾会上检讨是产品经理粒度不合适还是开发没做好。

现在有 docker 了按说可以把上面的自动化测试和环境重建做得更好方便。我仍然觉得 CI 流程做好了是基础，git 只是更灵活更能适应各种的 CI 流程而已。

@changkong 数字键盘这玩意用在笔记本上，那种不对称感真是逼死强迫症啊；我觉得没有还是优点。

再推 play framework 神教，akka 和 scala 系的底层，新版基本上 java api 全开。

reactive stream 真正的启动倡导者，几年前就完备的异步调用原语，等 java8 completestage 处理又再次做了兼容。

akka-persistence 已经成熟，作为 CQRS 及 Event Source 方案简洁优雅。

ebean 作为 ORM 选项之一，我觉得设计得恰到好处(简单 1vsN map，无 session)，喜欢 jpa 及 spring-jpa 也可以用。

除了模板系统强制 scala 系导致模板编译有点慢之外无缺点。

pv
管道看实时流量
cstream
管道限流

default_storage_engine = MyISAM
...
key_buffer_size = 2048M
default_storage_engine = InnoDB
...
innodb_buffer_pool_size = 1024M

这是干啥呢？用的 engine 定了没？
数据库版本？

innodb_flush_log_at_trx_commit = 1
sync_binlog = ?
没 SSD 没带电池 raid 还上这个参数？

补充一个情况，ubuntu 16.04，6626432 字节的 liblkl-hijack_patched.so，直接 python 运行永远是 resource busy, 用 haproxy 运行就正常。

没有 芒果激活码 吗？

网络丢包率波动太大，有个 18 刀 /年的 kvm 考虑不续约了
还有一个 5 刀 rjjx/年（ 128M 内存 250G 流量，优点是联通 155 的 ping ）

基本都在吃灰中，有兴趣的可以连帐号转让。

用 kcptun 吧，适合双向

@AVC
199.181.238.1 CatalystHost OVZ Incero Dallas
202.5.17.1 HostUS OVZ LA
199.188.102.1 Virmach KVM NJ
104.223.16.1 TragicServers OVZ QuadraNet LA

哪有那么困难，而且最近新光缆开通后，到西海岸整体还是有改善的。

另外全都是超贵的，
西海岸甚至中部和东海岸的 kvm ，都能有不少可以捡的线路。

v2ray 也可以搞这个，原生自动。

@akring
我从北京华翼（电信和歌华杂交）的结果， la 的 sharktech 机房、某 vps 的 lax03 机房， QuadraNet 机房的 ping 都可以， BBR+SSR 最高能到 1MB ～ 1.5MB 左右。 ColoCrossing 的新泽西线路意外的稳定， aria2c 5 线程下载能到 2.5MB 左右。
但是油管只能 1080p ，不算顺滑，但是缓存几秒后基本上不卡了。

下载跑满的话，感觉不是电信 QOS 的问题了。

服务器端 dns 问题？
或者是油管的猝发式流量风格对延迟较高的梯子效果不好？这个不知道有谁会调 kernel/锐速之类的参数解决。

@mrlong centos 现在开 bbr 貌似也行了啊， elrepo-kernel kernel-ml ，甚至觉得更新上还更有保证一点。

报告一下，不知道啥原因，可能固件还没完全适配，老毛子固件下的 re6500 的 2.4G 和 5G 信号都弱于华为荣耀，最悲剧的是 5G ，靠得很近也不到 90Mbps 。
其它方面正常，千兆 lan 以及千兆 lan 到百兆电信测速能有 120Mbps 。

可能只能折腾中继了， sigh 。

谁知道 R6900 的信号怎么样？

西海岸到中部，大部分 kvm 只要丢包率别超过 10%，装个 BBR 或者锐速，基本上翻墙都还可以，看 720p 无压力，更高看你本地 isp 或者其它的。
因此推荐 virmach / BudgetNode / ImpactVPS / Hostus / Prometeus 这几个最近名声比较好，价格较低的 vps 供应商，看看啥时候有 offer 。