@no13bus 哈哈，就差不多那个时间，感叹岁月流逝啊

@15342 在请求入口持续传递一个大版本号（比如通过 http header ，或者 rpc 的 req context ）
假设有 a/b/c/d 四个应用，这次发布 a(v1.1.0) / b(v1.2.0)，之前都是 v1.0.0 版本
定义大版本号 1.1.0 访问，a: v1.1.0 b: v1.2.0 c: 1.0.0 d: 1.0.0
定义大版本号 1.0.0 访问，a: v1.0.0 b: v1.0.0 c: 1.0.0 d: 1.0.0
相互之间不会交叉访问，形成逻辑上独立的访问集群
那么，就可以从入口开始慢慢放量，把大版本号 v1.0.0 慢慢发布到 v1.1.0

基于方法其实同理，只是服务注册中心，变成了方法注册中心 :-)


@CC11001100 是 ping++，习惯 pingxx

@foxio2 乐鑫挺有意思，现在要求估计很高了吧
@mazyi 远远没，请看我上一片

@yangyaofei 这个问题在于，真实世界不会有人关注你代码真的写的好不好，只看人效，这是一个短期利益 vs 长期利益的过程，而大部分公司，只会关注短期利益

@yhxx 涉密信息对外开放了（前提是的话），做人事系统，等于大家可以看到工资或者股票了，这属于严重事故了，3.25 不过分，当然，这个事情到底是否属于涉密的？

HR 方，就如同你作为小兵，突然流程变了，加了一个离职面谈，然后大家一脸朦，只能大家怎么做我就怎么做（很明显也请示了上级了），这时候刚好就你出事故，重罚小兵，小兵不委屈吗？

这个事情 彭蕾 出来自认责任，已经是最高级别的（当然他们之间可能一笑而过），你觉得一个公司：
1. 因为流程问题，牺牲一个小兵，谁碰到谁倒霉
2. 还是高层自认责任，承认流程不对导致下面的人不好做事

更加让人觉得合理？
这里我的小兵不该重罚，但是引入这个系统以及上线对接 HR 这一方高层，要承担责任

@yangyaofei 这个地方在于，写写业务代码，替代性太强了，我有一个“极端”的想法，在常规业务项目里，把那些 35+ 开除了，换那些 30 上下，履历好，激情慢慢的程序员，一样能完成业务，成本还低，是的，hr 就这么想的 :-)

加了个后续 https://v2ex.com/t/1102913

@yhxx 我也是第一次知道这个事情，如果 https://www.zhihu.com/question/30328482/answer/47635666 这个答案是真的，那么其实这个处理并不算过分

涉密信息对外开放了（前提是的话），绩效 325 很合理
只是因为流程需要，没有明确定义离职面谈来自上司评价

“但是一个比较糟糕的地方是，我们刚刚 Launch 了一个新的员工离职系统，在这个离职的系统当中，离职员工的面谈这个事情又作为了一个必填项”

所以，看上面的说法，是不是和你：
处理方案是东厂无事发生（婷儿的三类违规），开发人事系统的技术被开除（ 3.25 ）。

看起来差别很大

@yhxx 你说的事情我无法确认真假，但是 HR 这么做，应该立刻开除

@liu731 商业选择的话，那肯定是太早离开阿里了，哈哈哈
牛逼的公司干普通的活，这个事情，其实还是自己的原因多，所有的企业都是让你做钉子

@VchentozV 因为不会每个领域做的不深

@liu731
@evan1
写这些不是让人来喊大佬的:0 ，大佬还会被裁员吗？哈哈哈
而是每一个小个体，其实都非常有意思，只是淹没洪流之中

@VchentozV 对于长久考虑，不建议你按照兴趣驱动（因为我就是），在一个领域能长久积累下来，是要依靠长期的坚持的，才能有一定门道

保证可见性，只是说一定能看到，happens before
但不是说，一直不可见，理论上，随着内存的同步周期变化，是能感知到变化的

@adoal 说的已经是接近最科普的了，op 学习一下即可，没必要挽尊了。openssh 99% 以上的场景，都是为了远程 shell ，为了文件的话，只能说内部文件系统支持的不够好

@jciba5n4y6u 对，乐鑫非常有意思，回头有空了，我总结一下每家公司的经历和感想
@qixinwuchen 加你微信了，只是说，每个人的经验，也不一定适应其他人
@MasterC 都是经历了才总结一些出来的

@uuair 说起来，按照我阿里的几个同事观察，去创业的朋友，基本没有一直留下来的人，获得世俗的收益多
我现在看，创业也是一个急需要天赋的，我更适合做一个“打手”

@VchentozV 你和我的理念一致的，我一直鼓励年轻人一定要去大厂见识一下

@defunct9 绝对部分这段时间的人，都有类似经历，就看自己是否把握得住