直播间这种普遍做法是机器审核+两道人工审核队列。事发时机器审核肯定杀疯了，但是机器审核的策略可能并不够激进。大量内容被打上“疑似”标签，导致人工审核队列严重积压，人审的两道队列以正常速度压根审核不过来。

这时候他的容灾预案缺失问题就被放大的很严重，正常来说这种平台至少得有个“是否允许新直播间开播”这类的全局开关的。甚至一键下线全部直播间。这里就不清楚是快手的决策链条太长没人拍板，还是压根没有相关预案，导致问题持续了这么久

500 + 走公司账的几十 M token

@kyonn 逆向看接哪些推送 sdk ，但是注意应用来源，有些 app 会在不同渠道打包不同的 sdk

直接塞 Redis 里算了。你这每个实例都 cache 相同的数据，加起来的资源消耗肯定比 Redis 更大了

领域层提供原子服务接口，应用层提供业务编排接口。

如果他是一个项目里直接从 HTTP API 干到数据库，我的建议是直接跑路

代码加保密等级，最低等级的就所有人都有权限，高等级的按需申请呗。绝大多数工程代码都是屎，没啥好看的

内部结算? 是 babi 那套么

题外话，4 亿搜索 5000 单，这个转化也太差了吧，万分之一?

招你进来的人不行，主管也不行

万得感觉薪资前景不太行。我 3 年多的时候，面 wind 面到 3 面聊的都挺好，到最后 3 面面试官非要问我现在的薪资，我兜了半天圈子没兜过去就说了，然后反手就被挂了。HR 给的反馈是我工资比未来 leader 都高，给不起。。

https://prometheus.io/docs/prometheus/latest/http_sd/

自己写个服务，通过 http-sd 的协议暴露 metrics endpoint 给 prometheus ，数据来源可以是注册中心、cmdb 等等。。

这谁敢用啊，别忘了腾讯员工涉嫌偷看创业公司未公开权限的工作文档那事。

国内正经用途的这个价格还行，不算贵，而且你也只买一台得不到比较大的折扣

可以考虑下联想 think staion p500 之类的准系统，二手机箱 x99 主板 散热 电源 加起来 500 左右，这个机箱做工很扎实。类似的还有惠普的 z400

内推投了，简历都过不了，蓝瘦

@suikatw hello ，顺便问一下，现在阿里系各个子公司的招聘系统都是分开了吗? 面其中一家失败会影响到其他子公司吗?

感觉上面说的都过于麻烦了。直接在一台服务器上部两个实例，然后 Nginx 上通过 nginx_upstream_check_module 模块配一个主动的健康检测就好了，后端使用滚动发布，发布过程中 Nginx 会通过心跳检测自动把不可用的那个实例摘除掉的

我是用 httpdns ，把流量分到不同 nginx 节点上