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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

往期好文推荐：

• 经验谈：如何培养团队使用看板的习惯

• 个人开发习惯与团队效率之间的关系

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览93540 人正在系统学习中