@mritd 业务应用的指标需要开发自己搞么？

D 点没有展开说了么？？？

@zhoudaiyu 日志基本看不出什么来，还是从原理上抓起，理解消息队列模型，理解 worker 工作过程，然后根据这些去深挖

@zhoudaiyu 一定还会有的，哈哈哈
其实我那时候这么分析，消息队列模型，worker 主动去 MQ 取出消息消费，监控 MQ 消息有没有丢（一般不会），再做一些 worker 的监控，最终看下次遇到问题的情况进一步处理。
如果单纯的是 beat 定时任务，可以做一个超时重试的参数（我那时候的业务，定时任务就是去改数据库的一些东西，无所谓就做了超时）。但是非 beat 的，这个真的需要去好好定位，如果对业务无所谓，可以考虑加 timeout 参数

@zhoudaiyu 哈哈哈，你要是处理了这个，记得分享一下呀

@zhoudaiyu 我是运维，那时候是开发那边去看的，我觉得可以尝试多加点监控看看，监控 celery 和 mq，做到精细化去，我后面离职了，对这个 bug 一直念念不忘，诶。

之前用 celery 和 rabbitmq 也遇到过同样的问题

@Keyes 沟通也是和直接上级沟通吧

和我前一家公司的领导一模一样，可能还差点
入职第一个月，有次打卡忘记了，然后他群里喊谁忘记打卡了，他可以补申请的审批，于是马上我提交申请，到他那里审批，他回一个：“考勤表都交上去了你现在补申请干嘛？”
哈哈哈
类似的操作还不只一个，我现在就只觉得悲哀我居然跳坑了，万幸也早点出来了，好爽哦⊙∀⊙！

标记一下

第二份到底是什么样的工作？

@BALDOOR 深表同意

@kevin1234 😌😌😌可我现在不能停呀

在哪里可看到招聘信息？

@iiduce 老哥可否详细说说？

@bernie9 戝赞同，为什么非要加班？有话就说，实习生你招来的时候没有定位么？

@liuxu 记错了 这样子操作，主机 NAT 在后面，会有坑

@liuxu 关闭本机的 timestamps 是为了避免 recycle NAT 后的坑吧？但是这样子不会对本机带来什么坑么？

@EchoUtopia 代码里面的连接池么？