在组内, 经常会有各种系统需要帮忙解答, 排查问题, 问题查看等等, 大家的公司是如何安排人员去做这些事情的呢?
- 是每人(几人)负责一个(几个)系统, 这几个系统出现问题都找这个人去解决?
对于这种安排, 每人都仅需要熟悉自己的系统, 但会出现单点问题. 对于我个人来言, 我是不希望每时每刻都有人来找我的, 例如我休假之后都会打电话让我看问题.
- 还是每周安排一人(几人)Oncall 去做这些事情?
这种安排就需要组内人员对涉及的系统都有一个基本的认知, 出现问题后有排查思路, 每个系统能有基础可读的设计文档, 使用文档等等. 这就要求组内的人员要熟悉其他人的系统了. 好处是大家能对组内负责的业务都有基础的了解, 并且用户提问问题时都是有人在响应的. 非 Oncall 的人员时间也可以专心做其他事情, 不需要随时被打断.
大家个人又是如何看待这个问题的呢, 觉得哪种方案是可以接受的, 或者有什么更好的解决方法吗, 欢迎大家来讨论~
- 是每人(几人)负责一个(几个)系统, 这几个系统出现问题都找这个人去解决?
对于这种安排, 每人都仅需要熟悉自己的系统, 但会出现单点问题. 对于我个人来言, 我是不希望每时每刻都有人来找我的, 例如我休假之后都会打电话让我看问题.
- 还是每周安排一人(几人)Oncall 去做这些事情?
这种安排就需要组内人员对涉及的系统都有一个基本的认知, 出现问题后有排查思路, 每个系统能有基础可读的设计文档, 使用文档等等. 这就要求组内的人员要熟悉其他人的系统了. 好处是大家能对组内负责的业务都有基础的了解, 并且用户提问问题时都是有人在响应的. 非 Oncall 的人员时间也可以专心做其他事情, 不需要随时被打断.
大家个人又是如何看待这个问题的呢, 觉得哪种方案是可以接受的, 或者有什么更好的解决方法吗, 欢迎大家来讨论~
 | 1 canteon 7 天前 不是自己不会，安排了再说了 |
 | 2 midsolo 7 天前 入职的时候就分好了，每个人负责 1 个系统，外加 2 个中间件，互为 backup ，平时谁有空谁看，周末轮流 oncall |
 | 3 qweruiop 7 天前 国内的话，看 team 内是否说好了。 国外的话，看薪酬和合约的部分是否包含了。 |
 | 4 kingcanfish 7 天前 我们是每周安排一个人专门 oncall 也就意味着你对组内的几个模块都得熟悉，解决不了了再找负责的这个模块的同学一起看看 |
 | 5 swim2sun 7 天前 oncall 是有补贴的，没补贴的不叫 oncall ，你有权不回任何消息。 哪怕是临时找人解决，也得安排调休 |
 | 6 coderluan 7 天前 套路这种话题，楼主得把自己的业务或者说 on call 的必要性说清楚，毕竟 on call 和 on call 是不同的，有些就是所有人都得有准备，钱给足就行。相反有些就是多余的，告诉对方下周处理就完了。 |
 | 7 fregie 7 天前 钱到位啥都好说 |
 | 8 cominghome 7 天前 人手够的话最好是轮班，最好是一人一天/两天这样。 频繁被打断+oncall 的精神压力不能一直指向一个人（所有人） |
 | 10 ryd994 6 天前 via Android 要明确一点：oncall 的作用仅限于应急处置，不包括修复。就像急诊只管把病人救活，不治慢性病。 我们组是核心组件，SLA 要求非常高。经过几年时间的完善，从我刚入职时的 7x24 改成了 12x3 。 最初是一轮班就是 7 天 24 小时有电话进来，主要就是两个人负责整个大组，确实需要对所有组件都比较熟悉，挡不住了第三个叫到老板。两个人一般会商量好轮流休息。 现在一轮班 3 天，晚上有印度组负责。大组两个人负责基本的 debug 和分流。每个小组还有两个人负责深度调查。大组 oncall 解决不了的时候再问小组 oncall 。或者应急处置之后后续交给小组跟进。小组 oncall 大部分时间没事，不影响正常工作。 如果是真的出了大问题，sev1 ，那会把所有小组的 manager 全部叫起来。所以在我们这里，manager 比 IC 累多了。 |
Select Language