@jackon 鄙司也正好有做招聘，不用地推，各个国家需求非常不一样，RD 中心太远了根本感觉不到。鄙司在北美和东京都有 RD 中心，分别负责北美和亚太区业务。PM 需要本地化，RD 更需要本地化

建议要做北美市场的话好好 track DoL 的各种统计数据

过来说两句，有些坑工作几年都不一定知道，或者不需要知道。
稍微大点的公司就会在已有的基础上做自己一套全套的前端架构，基本上就是把这些坑都填平了。我们公司就专门有一个前端核心组负责发布通用组件，所有浏览器的问题全部是他们组来 handle。而面向业务的程序员主要负责写业务。
若楼主只是想找个能做前端核心组的人，然后面试的都是一些面向业务的程序员，那上来吐槽就是南辕北辙了。
建议楼主多招一些做轮子的工程师，把公司的各种 framework 和监控环境搭起来，然后再来考虑怎么招普通程序员。
原来你们是做招聘的，这么本地化的需求你们居然把 RD 放到中国…

less/grep

Rancher 有个短小精悍的文章可以看看
http://rancher.com/rancher-moby-project/

加到内存就可以了

mmap 主要用于进程间通信的文件共享

巧了，我们公司正好就是你这个 case ，但是 producer 有好几百台机器， consumer 在一万台以上，每天 deliver 的数据在 TB 级吧
我们这么做的，以一个 producer 为例
- producer 读取数据库，生成一个压缩的 snapshot
- producer 分发种子给 consumer ，然后 consumer 通过 bittorrent 协议（私有云）下载 snapshot
- consumer 定期直接加载到内存，只读，不 mmap 。

周而复始

不需要，直接在旧接口的基础上开发新的服务
你这才从 1.0.0 到 1.1.0 就不想兼容旧接口了么…

如果每次版本升级都是一个新的 repo ，一些影响多个版本的旧 bug 的修复和部署会非常非常痛苦。

人体工程学键盘，微软的 surface 那款和 Sculpt 都不错
有效缓解手部疲劳
尤其是你 code 比较多的时候

这么明显的 A/B test 需求…
不要瞎选，你把几个关键指标的监控放好，然后做 A/B Test ，每个样式给 5%-10%的用户，然后看看哪种样式的结果最好就行。例如停留时间，翻页点击等等

删掉原始文件出问题的时候真是会欲哭无泪，比较推荐 stream 读取然后写到新文件

@hantsy Loggly, LogEntries 比较局限，没有 joining log 功能

我们有的时候会需要看一个用户在不同子系统之间的情况， log join 的功能会很有用（虽然也很慢）

强烈不推荐这么做，如果是用于生产环境的话
Nginx 、 apache 、 tomcat 这些 server 的配置一般不是由开发来管理的，因此
- 每次更新的时候都需要运维参与
- 出现问题的时候回滚非常麻烦
- 性能倒是其次， debug 会非常复杂

一般都会在 container 跑个小程序做这个，好处有
- 自己更新
- 出问题了自己回滚
- 容易 debug

把难以监控，不透明的东西做的简单，复杂的东西做的透明，就是这样

Actually working there.

在一家小垂直搜索引擎干活，这几个东西做得很好
- 日志的集中处理，分析，并且有自己的一套系统可以让所有人看， PM 也可以看一些 AB 测试导致的 metrics 变化
- 大量的自动化工具以及监控系统，覆盖业务、工程数据监控
- 工程师救火之后会写总结，并且要求开发工具来减少人工失误
- 任何请求必须开 JIRA 来跟踪
总之就是： 1 、增加系统的 visibility ，任何的变动都会在某个指标上反映出来。 2 、尽量减少人的干预
食堂方面
- 免费饭菜
- 免费饮料：可乐、红牛、 Monster 、各种茶等
基本上和湾区差不多。不过我们在德州。

写一个用户中间件服务，可以在后面同时带 django 和 oauth

discuzX 直接和这个服务通讯

Log4j 的 Appender 支持写到远程服务器
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/SocketAppender.html
知道这个的话剩下就是找个合适的服务了， logstash, syslog-nd 等等

但是你这样只是解决了一个问题，日志的集中归纳

建议你们在这之上搞一个日志分析系统，好处至少有这样几个：
- 工程师可以更广地看待整个系统问题
- 学习成本不高，因此 PM 也可以很好分析各种业务情况

第一个问题的话，着重解决的应该是部署流程。代码发布的时候应该尽可能自动化。最好新的接口使用灰度发布，例如 AB test

安全问题的话 token ，然后 HTTPS 尽可能保证没有中间人

python 3 的步子迈得太大了，这点还是得和 Java 学一下， JVM8 跑 JAVA7 的代码还是无压力的。

python 2.7 的好处也在于是开源的，因此有什么坑自己没准还能填上。

@dtfm 单纯用发布多久来衡量是不对的，一般至少要等这种大版本发布 2-3 年之后才会开始大规模用。尤其你要考虑到重写的代价以及业务压力。银行系统里面十几二十年老的系统多的是。业务没有急迫的需求，就不要随意上新技术…

一般上新技术的步骤都是几个小产品先踩坑，踩的差不多了协助稍微有点流量的来上线，继续踩坑，最后才是最大最重要的产品。

IT Support 看起来还行，不过这个职位招的比较少，而且也很稳定，除非是要换职业方向，一般不会有人离职

楼上的不要喷了… 这个不是运维(ops)…