DevOps系统对软件团队管理模式的影响

导读:本篇文章讲解 DevOps系统对软件团队管理模式的影响,希望对大家有帮助,欢迎收藏,转发!站点地址:www.bmabk.com

01d75c405f18e9834e25157f37e6b1c3.png

午餐后,和同事一起围着当地标志性的大厦散步。当走到一处被安全线隔离的区域时,我抬头看到外墙玻璃清洗平台。清洗平台停在地面时,足足有3米长、1.2米宽,而现在看上去就像悬在半空中的一个黑色文具盒。

因为害怕它从天上掉下来,我和同事赶紧走到十米外。这时,我留意到旁边站着一个嘴叼着烟,戴着略显偏小的安全帽的中年男人在注视着清洗平台。由于仰着头,他的啤酒肚显得更大了。

他就是那个监工。我很好奇,他站在这里,光靠肉眼能看清玻璃是否被清洗干净么?为什么不用望远镜?另一个念头跳进脑海,他为什么不站在清洗平台上呢?

这个案例中,我看到了体力密集型工作中常见的管理模式:肉眼监工。抱歉,我没有专业学习过管理学,只能给它起这个名称。

然而这样的管理模式在我们知识密集型的工作中也非常常见。比如以工作时长来判断一个人的产能;非得要求员工坐在工位上才算在干活;发呆就是在摸鱼(程序员在思考时很像在发呆)……

最近我们团队发生了一个看似不相关,但是管理模式相关的例子。

一个本应该通知到重点观察群里的告警,却发送到了普通群里。目前的告警规则配置方式过程如下:

  1. 1. 需求方建卡给员工A,说明期望配置哪些告警;

  2. 2. 员工A登录公有云的告警平台,点点鼠标,输入配置。即完成工作(这个过程通常被认为很轻松);

  3. 3. 员工A将任务卡移到“待测试”中,等待其他人测试;

  4. 4. 员工B在对任务卡进行验证通过后,会被移到“已完成”中。

按这样的协作流程工作,最后为什么还会出现告警配置错误呢?

在界面优先的DevOps系统中,管理者倾向于认为员工AB的不负责导致了配置错误。进而增加更多的“肉眼监工”的过程。一家企业中,人工流程越来越多,即是肉眼监工管理模式盛行的体现;

而在代码配置优先的DevOps系统,管理者倾向于认为是流程工具本身的问题。以下是代码配置优先的DevOps系统下的工作流程:

  1. 1. 需求方建卡给员工A,说明期望配置哪些告警;

  2. 2. 员工A找到相应的代码仓库,修改告警规则配置,提一个MR;

  3. 3. 告警规则自动化检测程序对MR进行一系列测试,并将结果附在MR的评论中;

  4. 4. 员工B在确认修改和任务卡的需求一致后,将代码合并到主干,并把任务移到“已完成”中;

  5. 5. 告警规则被自动化部署到告警系统。

当出现告警配置错误后,管理者更倾向于优先告警规则自动化检测程序或者重构告警规则,而不至于让员工A容易犯错。

在《人类简史》中,作者有一个观点:是小麦驯化了人类,而不是人类驯化小麦。因为人类为了适应小麦和小麦农业,付出了无数健康、劳动、营养、人身安全的代价 。

而在软件工程中,这个观点依然适用。不是我们影响工具,而是工具影响着我们。

欢迎关注公众号:

往期好文推荐:

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/70957.html

(0)
小半的头像小半

相关推荐

极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!