新的芯片多多少少会有坑，但普通使用估计也没多少机会能遇上，原则上买新不买旧

瞎回答一下：会不会是 jmeter 这个显示就只代表本机的数据，我记得好像是在压测结束后，slave 才会把数据统一返回和 master 去做分析。试想一下，作为 master 自己既要压测干活，还要在压测的时候接受 slave 的数据信息去处理，其实是干不过来的。

Keep 不是一个专业的运动工具 app，而是做成了运动社区，这些数据我认为仅供娱乐（For 社交），认真就输
不过这里说的是数据覆盖的问题，也确实恼人

综合看起来简历是属于业务骨干，不适合 leader，也许有机会做储备 leader。

从互联网大厂的要求来看，这个年纪的要求是做一个子方向的 owner，带几个同学一起去负责把这个方向做起来（也会要极少数的岗位是技术专家的角色，攻坚问题管事不管人），看的是胜任力。对比楼主的简历，一定要说不合适的话，要不就是业务领域不匹配，要不就是做的深度不足够（有时候所谓深度，前提是先有业务体量才会出现深度）。

不需要妄自菲薄，至少在核心技能上应该没问题，建议后续多花些时间做系统的思考，留意落地上遇到的问题，除了传统的各类自动化外，看看其他地方的质效建设，如灰度线上、研发期间等，把体系知识呈现出来，同时了解一些管理方法论，就能继续平稳进步。

我注意到的点可能比较奇怪，为什么这个小伙伴可以摆烂 3 个月，才和他一对一沟通了解问题。
从老板角度去想，是不是意味着少着一个人也没有什么影响，然后就顺理成章地优化掉（无恶意），可能楼主也要想想在日常沟通上是不是要定期开展来及时了解小伙伴们的想法。

一开始选择 apscheduler 就是想轻量快速，搞着搞着我们发现不适合有坑，就只能回去大家都用的 celery 上，目前还没出现问题

yes，apscheduler 没提供有分布式多实例环境下的解法（至少我完整看了官网文档，也翻过源码，确实没发现），现在我们还是选择逐渐迁移到 celery 上去了

• 现象：服务上线，出现多个 apscheduler object，每个 object 都会执行它的定时任务 —— 简单来说就是一个定时任务被执行多次，本质原因是存在多个 apscheduler 库的 object。
• 原因：我们服务有多机房实例，而且上线时会有小流量灰度发布的流程，先在单机房部署一个服务实例，此时该实例产生一套定时任务；后面在其他机房部署服务实例，就又产生一套定时任务了。
• 解法（不严谨不保险）：redis 做个简单的分布式锁，生成 apscheduler object 时判断一下是否其他机房已经生成过，从而保证全局只有一套定时任务。但是存在分布式锁超时失效的问题，这样还是会存在多套定时任务。

好像直接用 apscheduler 这个库还方便点，我也有在用，本身库封装得很好，拿过来就直接用了。

不过我遇到另一个问题，是多服务实例下的会出现多套定时任务，apscheduler 好像没有提供分布式下的解决方案，当时我自己解决就用了个分布式锁去做，但感觉不够保险。

在和别人聊天时，时常会聊出到一种 “从一线退回二三线城市，就是认输” 的感觉。

而我认为，当一个人决定了从一线城市退出那一刻，也说明了 ta 知道什么生活才是自己想要的，是更成熟的表现。

2020 年时在看一本鸡汤书《优秀到不能被忽视》时有一句话很触动我，赠予大家：不要把自己变成一个脾气暴躁的工作受虐狂，把休息视为失败，将同行的成就视为自己的悲剧。

点到具体的 pdf 文件里，稍稍右上角的地方，有个下载按钮可以直接下载

在 Testerhome 网页编辑太卡了，可能因为本身文本比较多，操作起来有点痛苦。而且很多图片呈现格式上不太好看，所以就没贴完。（是我没贴图，不是 Testerhome 没展示图 ）

感同身受，我前后大概面试了近 300 个校招/实习同学（集中在 20~21 年），22 年降本增效嘛，就没怎么面了……刚好分享一下我的感想

对于校招面试，有几个主要印象：

1. 校招面试绝对是一个体力活，体现在校招同学的经历高度相似，如项目经验，面试形式大多数只能从项目展开再去到八股文，要追求高效面试没有其他办法
2. 选择测试和测开岗位，确实就是研发岗自我感觉达不到要求，退而求其次的选择（这很正常，岗位要求差异是客观原因，同时对于没实习过的同学，本来就很难理解岗位之间的真实差异）
3. 测试和测开，很多电子通信专业的同学会投过来（本质上是和计算机有交集但不深入的专业，科班出身倾向于投研发）

我在面试时的偏好：

1. 代码题上，【逻辑明确的工程题】要比【奇技淫巧的算法题】更优先。算法题讲究个临场发挥，需要专门训练，而工程能力是在日常编码中积累，和学校经历更贴切
2. 面试表现聪明机敏优先，校招生看的终究是潜力和意愿，如果各方面发挥没有达到不及格的地步，人比较聪明我也是会通过
3. 以挖掘亮点为主，而不是刻意去寻找同学的缺点去证明他无法通过
4. 对于后期参与面试的同学，因为已经经历过很多轮其他公司面试的洗礼，在交流沟通的要求上我会稍稍提高一点点
5. 有真正思考过的同学，对于某个技术点，能表现出触类旁通，能沉淀出知识脉络，会使用工具去提高效率（如看书后会梳理脑图），我是很喜欢的

印象比较深刻的，就是遇到一个本硕都是化学专业的同学，在研二开始刻苦自学计算机，白天在实验室做化学项目，晚上在宿主自学理论知识和实践项目，最后拿了我们的测开 offer。

如果有这种问题，建议关注 Testerhome 官方微信视频号，上面有以前的大厂分享录播，可以看看别人家遇到什么问题，是怎么去解决的。还有历届 MTSC 大会的 PPT，拿点思路。

楼主应该是平时很少主动去了解业界，多去看看就知道了。

社区太棒了，这些周末的质量保障分享一定捧场！

我可能会答非所问，我的观点是：

1. 不要把技术和业务放在对立面，对于绝大多数公司而言，明确了业务是要先于技术，业务要活下来，才有技术的事情。
2. 对于个人而言，业务和技术的全面发展，我觉得要优于专精业务而荒废技术。毕竟我们本质上是技术人员，不是业务人员，技术技能是通用的，而业务技能可能和公司岗位绑定的。
3. 一定要分清楚，自己当下的产出和成绩，是依托公司这个平台才做出来的，还是靠自己做出来的，不要把公司的成绩归因在自己身上，容易膨胀。
4. 有些时候看着别人和老板关系混得很好，扶摇直上，不要产生负面心理，客观地去分析比较自己和别人的优缺点，尝试自己在老板角度去看待，再下判断，找出自己后续需要改进的点。不要忽略别人晋升背后的逻辑，同时无法改变环境那就改变自己。

最后的教练总结属实戳到心里去了

理论总结的不错~

针对偶发性问题，希望提前挖掘出来一般 2 种做法：遍历测试、探索测试。这些测试，都可以引入各种故障异常的条件，比如磁盘打满、弱网等。

那假设确实无法提前挖掘，想后置复现出来怎么做：流量回放（服务端流量 + 移动端操作的录制与回放）、埋点跟踪、日志回捞…… 利用这些手段去缩小排查范围，最后还是要人肉找出问题。

不要想着有什么神仙方案能全自动化，太不切实际，更多是经验导向，可能这个问题一出现，基于经验和对系统的熟悉就能猜出大概是哪几方面的排查思路。

固定机型，不过是少了一维变量，转化一下就是固定机型下的偶发性问题罢了，同样的思路。

有开源的话希望拜读一下

打卡~

字节的全球真机房好像只是内部使用，定位上确实是用来做评测和本地化验证

应该要在研发内部推广一下 git rebase，把无效的 commit 合并在一起，这样提交记录才干净且可 review
参考：http://jartto.wang/2018/12/11/git-rebase/

这篇之前发过的老文，把它搬过来当专栏~ 后面把 testerhome 当成一个自己沉淀的主要阵地了