还行吧，当年把我职级升到 2B 我也没说啥。。。

@sammo #26
上有所好，下必甚焉。
新晋菜鸡程序员代码都看得不太明白，能提得了什么靠谱的 PR ？
所以都是自作自受：那些能提靠谱 PR 的，并且以此打击新晋菜鸡的人，就只能看着自己参与的项目被辣鸡 PR 淹没。

我一直以为这种 bug 只有我才能写出来

支付宝的扫码如果没有微信快，那就永远会被喷。
货比货得扔啊。

安排个同事接收，你先培训，培训完了你处理他观摩一个月，然后他处理问题你指导一个月。再往后除非是很棘手的问题，否则一般不用你操心了。

@fengchang #2
是的，非常典型：
1、话少
2、重点被标注
3、各项数值精确

干活赚钱而已，不用想太多，但是一般升职加薪是有难度的。
如果不介意其实也挺轻松的，因为你不用背什么大锅。

前司到处都是：
1、一觉起来发现数据库因为连接错误过多关闭连接了，所有业务停摆几小时
2、php-fpm 内存泄漏，终于在某天中午占满了所有内存导致业务停摆几小时
3、被当成 ddos 肉鸡，随机时间向外打流量，所有业务停摆 48 小时
4、cron 触发的系统邮件文件占满了所有 inode，无法创建任何新文件，导致所有业务停摆几小时
5、删错数据、删错订单、退错款、付了款订单失败、App 推送点不开、App 推送不到达都是家常便饭，不说了
6、景区保安把手持验票机（ Android 系统）热点打开，3 天耗完 4GB 流量
7、短信通道被 ddos，几百条订单短信发不出去，节假日客服电话被打爆，我的电话被客服打爆
8、工程师把生产库当测试库调整 sql，join 死循环导致 mysql 吃 100%cpu，好在站库分离影响不大
9、推送的 react native 热更新把热更新检查代码注释了，不得不更新原生版本
10、合作方在业务高峰前夜切换接口实现，三天内囤积了 5w 左右的订单无法验证状态（是否使用），老板用从未有过的认真表情问我这 5w 到底会落实成多少损失，好在实际上没多少损失

终于凑够 10 条了，其实 v2 上大佬很多，说话也很好听，技术都很高明，但是实际上大部分的小公司真的只有我这样的一个技术头目带几个兄弟做研发，没有什么精力去做很完善的运维，维持 bug 不比 feature 多就已经竭尽全力了。
希望大家负责的项目都能稳定运行，天长地久。

@BeatenMo #348
目前腾讯云的说法是物理硬盘的固件有问题，这种情况打快照应该也是没有意义的。

@void1900 #78
软件研发通常的目标是实现业务需求，谨慎之类的底裤也是针对程序逻辑的，谨慎对待硬件 bug 毫无意义。难道调用一下 write() read()还要谨慎考虑一下硬盘会不会在这次写入的时候挂了？

@jedihy #146
@nicoljiang #164

腾讯云主机的 SLA：
2.1.1 数据存储的持久性
每月您申请实例的云服务器块存储的持久性为 99.999%。即每月每 100000 个云服务器的块存储实例，每月只有 1 个存储卷有数据丢失的可能性。
------------
这个没什么好说的，碰到了就是碰到了。比较重要的是：

2.1.10 故障恢复能力
腾讯云云服务器具备故障迁移能力，可在母机故障发生时，无需用户参与，自动将云服务器迁移至新的母机，保证客户服务的连续性。同时，腾讯云提供专业团队 7x24 小时帮助维护。
------------
这个在本事件里完全没看到自动迁移的实现。

想了想感觉这事有点怪，按说云盘数据是不可能突然完全丢失的，顶多丢几天的数据。按照这个情况是一点数据都不剩了，即使打了快照恐怕也没用，只有全量备份才能完全保证安全。不知道这个到底是什么故障。

楼上说要打快照要备份的是没错，但是在购买云服务器的时候，服务商有没有提示：本云服务器存储不可靠，需要用户自行解决备份问题？
如果云服务不能让运维更简单的话，那发展云服务的意义就很小了。

@initdrv #9
其实我遇到过类似的事儿，我给自己和同事点了同一个商户的两份饭，结果超时 1 小时，而且送来只剩一份了。给客服说了，客服让配送员和我协商解决，反正和他们没关系。最后想了想还是算了，折腾也没啥意思。

小微厂小项目，好处是代码短，坏处是需要花一定时间才能看懂

@tyhunter #6
打开控制台找找线索？

同样的版本，没有这个问题

@reus #3
文件比较多的项目，复制一次很麻烦的，如果有 node_modules 目录就更尴尬了