严格来说，年假是需要提前请好的，而且需要交接工作。我请年假都是提前两个月就和老板说明大致日期和长度。提前一个月左右发邮件确定日期，往日历上挂提醒。为的就是给老板充分的时间能安排工作。oncall 也要全部找人代替。

事假才是临时请的。然后我们公司没有单独的事假。病假不查证明。年假，事假，病假实际上都是混用的。如果我有事，一般就请半天，实际上不计考勤，因为本来就是弹性工作制。但是这都是以老板同意为前提。

反正只要老板同意，什么都可以……
一周五天全部 wfh 都可以……
年假休超额变成负数也可以……
早上起不来说自己头痛请病假也可以……

所以和老板关系要搞好一点

我年初连休 17 天，用了 11 天年假。
组里还有个 senior，去年 11 月说，我年假要过期了。12 月整个月都是年假。

@pangleon 你说的是哪家外企？年假不提前安排还有理了？员工守则上怎么规定的就应该怎么做。老板从来不看，这是情分。问清原因要求交接，这是本分。

新代码应该测试，从测试分支到主分支，还有一层层测试，这个阶段出问题，就不可能 merge。也不存在什么责任。
线上出问题，别纠结谁的锅，大家一起先应急处置完，这是对用户负责。能力范围内能处理就先处理，处理不了就赶紧找人，上级还有同事，反正只要有关的先叫起来再说。
等情况稳定了，收集好日志和记录，再讨论 root cause。背不背锅是整个组的事，轮不到你。虽然代码是你写的，但其他人批准了 PR，那就也有责任。领导管理不足，那就也有责任。
其他组代码会影响到你组的，那就需要相互 code review，相互负责。出了事，事批准过的，那大家都有责任。没批准过的，首先你活该，其次你领导还是有责任。

@devlnt 你英文有没有问题大家看的懂
*extrapolated*
*statistical models*

一比一的实验是不可能的，否则希捷不用卖了

@ysc85 你到底是千兆网还是万兆网？
千兆网，假设 MTU 1500，TCP 效率 94.93%，所以理论最大 TCP 数据带宽 118.6MB/s
不排除 samba 带压缩，那就可以解释超过这个数的速度

@devlnt Based on the observed error rate over a few weeks or months, the MTBF is estimated and not representative of how long your individual drive, or any individual product, is likely to last. Nor is the MTBF a warranty
建议你好好补习一下英文呢。免得贴个链接打自己脸。

@devlnt AFR and MTBF are population statistics that are not relevant to individual units.
墨菲定律此处适用，average ≠ maximum

建议换个标题。raid50 牛爆天际，raid6 吃饱了撑的。
你爱用就用，问个 P

@devlnt 你也知道工信部油耗做不到啊？那怎么 mtbf 就一定能做到？那你应该往高了估还是往低了估？
一万块一起测？一万块测一小时就等于一万小时的数据？硬盘到寿命末期故障率会迅速上升。混用批次，分批投用，就是为了避免一批一起挂的情况。
你还没考虑人为错误和重建前的人员响应时间。你能做到 24 小时机房有人，长备替换盘么？如果用热备的话你会希望热备随时上线还是错开负载高峰再上线？

*更可能是厂家根据各个原件的故障率，理论推算全盘故障率*

@devlnt 你怎么证明？这只是一个理想条件下的推算，实际上怎样，厂家也不可能知道。难道新出一块盘就先跑个十年再卖吗？最多高温加速实验，但是加速实验的前提就是假设了加速比例，实际上加速了多少，谁也不知道。很可能是厂家根据各个原价的故障率，理论推算全盘故障率。计算方法不同，得出的数据可以差好几个数量级。

要看实际数据，backblaze 有。真正生产线上跑出来的统计。

@devlnt 他们说的是数据冷错误。也就是宇宙射线翻转了一个 bit。raid 无法检测和预防这种错误。如果刚好是文件系统的关键 bit，那恭喜了。事实上，别说重建期间，正常运行期间 raid 也无法处理冷错误。raid 设计规范并不指定冷错误时，返回的是哪个盘的数据。一般控制器就是随便取一个。重点：raid5/6 读的时候可以不校验，为了性能。因为 raid 的故障模型是热故障，所以假设只要能读出就是正常数据。
这一点 zfs 吊打同级 raid，缺点是钱要够不然性能太差。

你需要的冗余度要和单盘大小成正比。因为单盘是故障单元，而读写速度和单盘容量远不成正比。甚至基本无关。因此重建时间和单盘成正比
@devlnt 不能按企业级标称值计算。且不说标称值只是一个估算，厂家出于自身利益倾向于高估。标称值的前提是恒温无震动电压稳定，也就是什么条件都完美，你问问自己有没有可能做到。而且重建期间是满负荷长时间运转。故障率肯定要比标称值高。
最后，上面纯概率计算成立的前提是两块硬盘的故障事件无关。如果你买的是同一批次或相近批次的盘，而且这些盘同时投入使用。浴缸曲线两个高点。如果是制造有问题，那整个批次都没得跑。如果是正常磨损寿命，那其中一块盘挂的时候，剩下 11 块也活不了多久了。这时候故障率肯定比标称值高得多。
@msg7086 raid6 当然软 raid 啊，为什么用 raid 卡

既然你不会读别人的空气，凭什么别人要会读你的空气呢？

这么折腾，还不如用个垃圾 U 盘做引导盘。只要能加载 grub 就完成了

加班多说明积极认真，那这企业文化有问题。
干活积极不积极我不在乎，只要你能积极出成果，你上班睡觉都可以。越积极破坏越大算什么事？

1. 你们 tm 不锁主分支的吗？什么阿猫阿狗的代码不经过 code review 就能进库？
2. 他每天加班你们没人知道他忙什么？领导不知道手下人忙点什么，那这领导不及格
3. 他平时的任务量领导不知道？知道的话是不是应该先质疑一下他每天加班都在 xjb 忙什么？是不是应该质疑一下他干活效率为什么这么低？

招人找到傻 B 不奇怪，傻 B 能搞破坏搞这么久才被发现，你们领导可真该反思反思管理上的漏洞。