Oncall/ops 到底能学到东西吗？还是纯粹浪费时间？

我觉得oncall 的痛才有可能帮助大家做好系统设计。以前公司不让我们做ops，我都是主动加入帮忙。现在公司大家都做，其实很有帮助。当然当晚上被叫醒几次的时候也是骂娘的。我自己的感受是1. 为了减少问题，必须深入了解系统。以后做类似的东西可以参考，不会走原来的弯路。2. 如果你的系统的问题是因为外部影响，你就可以学到很多怎么处理外部dependencies 有问题的情况，现在系统都是microservice，这个很重要。3. 你现在知道怎么用metrics /log 或者其他手段了解分析问题，那下次设计系统的时候你就会想出问题怎么办，我需要哪些metric/log帮我快速知道哪里有问题，不用等到出问题了再加。很多时候系统一定有问题，只要早于客户知道并解决就好了。 4. 你在修复的过中如果没法或者很难打补丁的时候，或许会想重写，这个过程也是很好的学习过程。为什么其他人会推荐不同的做法，如果是我怎么选。

我感觉你的问题可能是没有看到自己做的东西的价值在哪里。很多人提到他们在公司特意去看其他部门写的这些总结，因为这些都是实战经验，非常宝贵。

分布式系统的ops, troubleshooting是很有价值的，但如果只做这个就没什么意思。
你要用这些经验position自己到一个能主要开发分布式系统+维护这些系统的组，这种经验比较稀缺和难以acquire，卖价高。

这么说吧，ops 可以学东西，但是一直做就没个地基，不扎实。

刚开始可以从 ops 先入手，理解大概的分布式框架，但是之后不让 SDE own 一个 feature 就有点尬了，毕竟是 SDE 嘛

我觉得可能有机会接触非常多的shitty code，但是这和自己写clean code还是有挺远的距离的。

CH3COOH 发表于 2022-7-24 22:35
我觉得可能有机会接触非常多的shitty code，但是这和自己写clean code还是有挺远的距离的。

亚麻的code还真不shitty。最后root cause各种各样，但是改code的solution还真不多。

aws的slo要求很高，latency/availability 要求高 alarm设置的很aggressive

fb的业务逻辑代码倒是挺shitty，还不让写注释，醉了

可能分场景, 有的ops只是tier 1那一层的, 主要就是看看run book, 把问题归类后下发给module owner. 这种比较浪费时间. 还有一种就是需要dive into大部分问题找root cause那种, 相对锻炼人一些.

当然有用，楼主不必妄自菲薄. 有强大的产品维护经验是大的加分项，但避免把5年经验变成了1年经验重复5次

Ops ing前来学习。

一个几乎天天修SEV的人来答一下。

onboarding的时候当oncall帮忙修东西是有好处的，是学习已有架构最快的方式。别人的doc不一定好好写，有也不一定很详细。doc里有high-level的东西，但亲自下场修下东西才能知道具体的坑都在哪里。

之后就看情况了。首先重复性的ops（比如修过的SEV再次发生）不会让你学到新东西，反而会把WLB搞得很差，人很累。

其次产品组没必要花太多时间在这个上面。如果产品组oncall load很重，那肯定是哪里有大问题。

比较tricky的是很复杂的infra组。有些组平时正常的engineering活就很像ops。架构级别的修改不会让Junior上，所以就只能干点大家都不太爱干的活。这种时候1)看有没有升职机会；2)如果没有，待个一两年学到东西跑路还是有好处的。