oncall重到忍无可忍了

Hi 大家好，
我在亚麻retail的一个组，这个组建组之初做了一个功能很强的产品，这个产品可以根据config满足各种PM的需求。最近几个月是retail的peak，我们几乎天天在config/deploy configuration，每个sprint一半的时间在做这些事/开会。感觉这种工作对职业发展完全不健康，时间长了只有英文水平提升了（应该也不过是流利工地英语），每天都不知道在干嘛。应该只能跑路了。

retail的组好多都有这样的问题。pm需求很多变化还快，那就用config，比如各种promotion/deals的设定等等。这种config如果参数太多pm自己是搞不定的也不敢搞，只能求dev，一旦弄错还很容易搞出大问题。

换不换组应该综合考虑很多因素。单就这一点的话，可以这么分析：

1.你是否是SME？离了你是不是config会麻烦很多？
2.过了peak有没有plan用来streamline这个手动过程？比如加UI方便使用，automate validation甚至dryrun等等。这些development work是不是可以你来做
3. 没有plan的话，你是否可以提出计划并get buyin from leadership？这个是你再往上走的必备技能，用数据提出ideas并获得支持。


问题和机会并存。当然我也只看到你的三言两语，还需要你自己考虑是否真的有机会。跑路也完全理解。

可不可以做个internal tool, 把改config，跑测试，测试结果，config deploy进度什么的都在一个页面上呈现，PM傻瓜式操作就可以搞定

了解为什么config，可以对未来系统设计有帮助吗？

nathan2016 发表于 2020-12-19 05:47:46
了解为什么config，可以对未来系统设计有帮助吗？

没有系统 就一个复杂算法的config

yucan1104 发表于 2020-12-19 08:50:19
retail的组好多都有这样的问题。pm需求很多变化还快，那就用config，比如各种promotion/deals的设定等等。这种config如果参数太多pm自己是搞不定的也不敢搞，只能求dev，一

1. 不是。组里有那种极其热爱oncall还很厉害的，他愿意在所有人oncall的时候提供支持，时间久了有他在吩咐做事的感觉。有些PM和他打交道久了直接联系他，然后由他来教别人做事。
2. 我们有一个项目把这个过程offload给PM，但是项目看起来黄了。我们不管怎么样，改了config都要测试，因为这个config是一个复杂算法的config，改了后必须写mcm写出哪些log metric表明这个config改的满足了需求，是正确的。

幻影奇袭 发表于 2020-12-20 01:46
可不可以做个internal tool, 把改config，跑测试，测试结果，config deploy进度什么的都在一个页面上呈现， ...

这都是今年的大项目，黄了，最后设计有问题

我一抬头 就看见了 当时的我

根据以往经验，这种config platform稍微出点问题就是很大的outage

如果能有办法把这些作为痛点drive几个initiative还不错，否则就是只忙着背锅没时间claim credit

最近有同感，而且看不到尽头。哎。