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 当成一个自己沉淀的主要阵地了

本质就是 持续且高质的输出。

途径可以是：

1. 图文输出 - 个人博客、各类论坛社区、公众号、专栏
2. 音视频输出 - 各类视频社区
3. 代码输出 - 参与开源项目，或其他形式分享自己的代码
4. 行业大会

输出类型可以是：

1. 技术输出 - 最纯粹的技术，单点技术、技术体系等
2. 观点输出 - 趋势、新技术评论？
3. 领域知识输出 - 质量保障各方面
4. 经历输出 - 工作经历、自己的实践

当然，如果在业界本身做出很好的成绩，带出很好的团队，自然也会有名气。

看来我提了不少 bug

这么说也确实有道理

已阅

请问这次三个分享有公开的 PPT 可以下载么？

具体看 app 是怎么实现的，WiFi 和 移动网络很多时候会有细分的网络策略，这些策略可能会具体到底层网络协议等在网络传输性能方面的影响，大厂会有相关专门团队做网络策略优化，具体就很深了我也没什么了解。

如果 app 本身的实现没考虑这些，那本质上我理解就是弱网区别而已，WiFi 也可以去构造弱网。