一个运维时间变更的小调研

  前几天发起了一个小调研,如果你所在部门发起了一个变更需求,明细如下:

需求覆盖范围:公司对外服务

影响范围:已测试验证,最大影响时长是2秒

计划变更时间:4:00,假设业务低峰是3:00-4:00

变更人员:A部门

联动部门:B部门,C部门

问题:如果A,B,C部门的人在3:00就已经就位,可以在3:30开始变更,是提前半小时开始,还是按兵不动,依然按原计划4:00开始?

经过时间的发酵,很快收到了不少朋友的反馈,整体的数据比例是7:3,即7成以上的人认为按照原计划,而3成的人认为可以提前变更。

一个运维时间变更的小调研
一个运维时间变更的小调研

所以问题到了这个阶段还是蛮有意思,在不同的场景和信息量背景下,我们可能得到的结果也会有很大的差别,我们再给这个场景加几个限制条件:

1)没有对外发布维护公告,不涉及对外的服务时间承诺

2)影响2秒不是丢数据,而是应用会自动会做容错处理

3)最重要的,假设我们就是环境属主,不存在甲方乙方

到了这里,我想很多人开始有些犹豫了。

这里有一个时间点很纠结,那就是低峰期是3:00~4:00,但是变更偏偏要从4:00开始,可能是有一定的考量,但是还是比较勉强。 

很多同学做变更时会发现,所谓的4:00开始,前期其实是要做很多准备工作的,一旦你的操作比预期时间提前,那么所有的事情都可能提前,也就意味着大家的时间灵活性和心理状态会大大改善,也会留给后面更多的容错时间。

另外就是通过大家的评论也可以看出来,其实都是怕出事,越是怕出事的越是有故事的人,而从另外一个层面也可以看出很多同学在工作中的话语权还是不够。 

那么如果明明4:00开始的时间不合理,你会据理力争还是默默接受,在我看来,我喜欢那种做事有韧性的人,我的选择是计划提前,评估之后就应该提前。 

来源:杨建荣的学习笔记,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/77696

发表评论

电子邮件地址不会被公开。 必填项已用*标注

侵权联系
分享本页
返回顶部