我感觉你说的需求和回调或者轮训没直接关系，问题是抢锁，你们关注的是怎么触发。
这种应该是任务提交，服务端控制并发一个，任务结束了通知到前面继续吧。

@Reficul
你们用的是 remote cache 还是 buildfarm 那一套？如果需要频繁的 integration test ，很多 bazel 的 layer 不用缓存的？
我追求效率没使用 gateway cache ，用的还是 buildfarm 本地存储之类

@Reficul @aljun
bazel rules docker 的好处是确定性。但是目前 bazel 对内存的消耗和时间效率啥的还是不如 docker 好。。。。此外要有效处理缓存机制，避免 bazel 层面 cache layer 。

这种如果不是整体做 bazel 的平台相关的话还是不推荐用

如果整体用 bazel 体系做的话会比较爽

额。。。。这种研究的唯一意义可能只是满足好奇心，因为从虚拟机到物理机变化的东西太多了。。。IO 层面，上下文层面都不一样。。。

安全渗透是只招有经验的是吧，在考虑加点到 devsecops 上是不是加错了。

现在这个环境，写啥都白扯，这两年做工程，逐渐发现了水货多的一批，你写的很深入他不懂。然后除了八股文之外，很多基本的工程素养都没有。。。。所以还是多背诵八股文吧

这种会不会有人投了，最后发现是自己家的尴尬情况

很有趣，哪一家呀？这么神秘。

这个听起来像是 rbac 不能充分的表达角色？最根本的解决还是说该拆分为
运营总经理，运营经理，运营主管，运营员工
开发总经理，开发经理，开发主管，开发员工

然后开发总经理能增删改查剩下三个，开发经理增删改查剩下两个

如果实现不了的话，在 rbac 的基础上加上基于 attr 的校验？这里的 attr 是指需要校验属性是否相匹配啥的，比方说总经理增删改查只能影响同部门（ attr ）的员工？

@timelessg 不知道是我运气不好还是怎么地，四季民福吃的鸭子两只腥的不行，远没有便宜坊好吃。松鼠桂鱼就跟裹了棉被一样，贼 tm 硬。。。。

是的，我也感觉到了，就是 OKR 对于一些很难量化收益的东西是非常难以评价的。有些单纯就是实现功能这种实际上 OKR 是很难以衡量的。

当然这个不能说是 OKR 的问题，而是业务团队本身做的事情偏从上向下的任务分配，而 OKR 是要求自己主动的。

所以我的建议是，不要每个人的 okr 都每周汇报，做一段时间之后选择大一些的成功汇报一次。

另外试试从小的地方看看能不能汇总为大的可以继续做的方面。另外就是督促团队内部做文档输出 /nano talk 等东西，转化为知识库

不对，应该是疫情基本算是过去了，好多年了

2023 年了，疫情已经很多年了
不知道 lz 的酒吧怎么样了

不过说起来，你连大学都没毕业，我觉得可以了。
不能指望上小学的爱因斯坦就搞出来波粒二象性。。。。

所以也不用太在乎面试官

感受：从简历来看确实有一种我用技术很牛逼，但是我都是 crud 的感觉，而且有东西让了解的人看了下感觉就是用现成的库。。。


简历里面

项目方面应该表明我解决什么问题，这个问题的难点在哪里。而不是把项目泛泛而谈，重点是难点。简单说就是求点不求面。

如果你觉得你做的项目很棒，那就要突出项目。如果觉得项目不够突出，就往基础比方说操作系统，基本知识上面引。另外技能方面建议不要些什么缓存穿透，直接熟悉 redis ，mysql 就够了

所以建议精简一下简历？改成最多三个项目

针对性的说的话，

> 南京市第一中学内网运维与安全审计

这个直接去掉吧，内网扫描应该是直接用 kali linux 扫的，格式转换感觉也没啥难点。。。而且本身你是要做安全吗？如果想留着，可以讲讲校园内部的内网安全从你的视角应该怎么做，这个实际上可以合并到高校学生宿舍管理系统里面去讲讲内网安全

> 华泰证券量化交易仿真系统

这个我觉得可以好好讲一讲，仿真框架的实现，仿真算子的计算啥的，讲讲亮点

> 阿里云云原生 Serverless 技术实践营

这个直接讲实现过程当中遇到的困难，不要说“别人做不到，我做到了”（这个可以在面试的时候说），重点突出遇到的问题，千万别说什么“照着做一遍就完了”

我印象中，无论是 gitblame 还是 svn 都有渴死的功能吧。。。。
这以后代码多了就变成一层一层的梯田了吧。。。。

@lscbqr
Nmmmmm ，lz 能考上北邮证明还是很聪明的，不过肄业确实有点尴尬。。。
领域深度实际上是很蛋疼的一个事情，因为很多领域深度确实就是背诵八股，我司一堆排错能力基本为 0 的工程师平时说话头头是道，到最后写出来各种各样的问题靠谁来排错？最后还是 infra 背锅，我查了一堆莫名其妙的问题。

具体到你所的做哪些项目，搭建什么平台这些抛开业务都是空谈，而解决方案又必须是紧跟业务的。所以我觉得 lz 还是需要提炼下自己做的事情到项目高度

@perfectlife
重点是特色，不是说光看了具体咋回事就完了，
另外做事情需要做进去，然后做出来。你光写了具体做了什么，解决了什么问题？比方说 iam 这些实际上怎么结合到具体的项目生产中这些都可以写一下

另外，安全思维是个筐，啥都可以往里装。如果面试官不懂安全还好，如果安全真的展开说非常难。。。

你这个唯一缺点就让我想起来有些招聘的人问，你有什么缺点？答：我太投精力到工作，把身体累坏了。一样。。。
我感觉 stdk 的缺点是电量不够用，手动狗头

索引和大纲，框架制造，某种程度来说，至少可以干掉百度？

我感觉比较恐怖的是它可能已经具备了一种内嵌的逻辑，并且能在这个逻辑上不断迭代推理？

或许计算能力和数据量的进步，每个人真有个随身的系统，随时提示该做什么，做些什么
但是我更觉得到时候人类可能就变成了每个人就是一个潜入了这个东西的系统。