让我想起在百度的时候.
级别最低的称呼一般叫 x 爷, x 少, x 神
中层的话, 一般只叫名字. 不包括姓. 如 x
更高的话是英文名, 肉饼, 詹姆斯之类的

杭州的互联网氛围和创业公司是最好最多的
笑尿

滴

@Immortal 咋搞进去啊

但是实际上百度自己校招升起来的 T5, 如果阿里不给 P7 的话 是不会过去的

坐等房产税立法

百度的核心部门是中国互联网技术最好的部门

@shengyu 为啥说颜色管理更好?

我买的 LG 型号是 69 感觉很好

呵呵, 谁去谁傻逼

当时面完面试官就加我微信了, 过了几天 HR 就给了 offer

全微软技术栈,画面太美

Pagico 8：PGCO8-C7B3C5-1878
已使用 感谢楼主

如果你有理, 那就去投诉,如果你就想赖账的话, 我只能说
违谁的约都不要违阿里的约, 万一因为这 70 多块钱, 不能用淘宝, 不能用支付宝, 芝麻信用有污点, 你说亏不亏.

@swulling
共享存储替换已经是非常美妙的事情了,之前我在公有云工作, 宕机压力也很大, 问题有以下几点
1. 宿主机上的虚机不全是远端存储, 所以即使只有一个本地存储的, 你也要起来处理, 做备机替换(拔掉硬盘, 插到另外一台完全相同配置的主机上,然后在机架位替换掉这台故障机, 然后启动机器, 恢复服务并热迁(部分需要冷迁), 结束之后, 逆向备机替换过程. 避免机架位错乱影响资产管理)
2. 底层 qemu/kvm 版本没有打平, 所以迁移,重建经常失败.
3. 业务限制非常多, 比如:远端存储的虚机购买了本地 SSD 临时盘, 这种是没法迁移的
4. bug 超多, 使用 qcow2, 一个用户的 base 映像被拉到了本地, diff 文件在远端, 很遗憾, 限制用户快照链长度, 把之前的 base 镜像在对象存储里删掉了, 现在只有一个 diff, 没法启动.解法是,禁止这种 base 被删的虚机重建
5.作为一个分布式系统, 业务完全没有处理宕机问题, 所有宕机都是手动处理,包括筛选出哪些可以迁移, 发起迁移, 确认迁移成功业务恢复, 发送故障报告和赔偿报告, 都是依赖手工处理, 我把这部分工作自动化掉然后就离开了.

@swulling vmware 的这个让我想起了 NEC 的 Fault Tolerant Server
The FT servers deliver exceptional uptime through dual modular hardware redundancy and help maximize your business outcomes.
两套硬件,即时同步操作.

另外, 我们把 Docker 当做 VM 来用, 针对 Docker 容灾有没有什么奇技淫巧?

好了, 看到楼上这么多都没有说到点子上
用 go 写脚本 随你怎么拆, 编译好一个 binary 丢到服务器上 完美

如果大家不想喷, 建议看看《批判中医》方舟子写的, 真实佩服佩服