本文主要是介绍DevOps系统对软件团队管理模式的影响，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
午餐后，和同事一起围着当地标志性的大厦散步。当走到一处被安全线隔离的区域时，我抬头看到外墙玻璃清洗平台。清洗平台停在地面时，足足有3米长、1.2米宽，而现在看上去就像悬在半空中的一个黑色文具盒。
因为害怕它从天上掉下来，我和同事赶紧走到十米外。这时，我留意到旁边站着一个嘴叼着烟，戴着略显偏小的安全帽的中年男人在注视着清洗平台。由于仰着头，他的啤酒肚显得更大了。
他就是那个监工。我很好奇，他站在这里，光靠肉眼能看清玻璃是否被清洗干净么？为什么不用望远镜？另一个念头跳进脑海，他为什么不站在清洗平台上呢？
这个案例中，我看到了体力密集型工作中常见的管理模式：肉眼监工。抱歉，我没有专业学习过管理学，只能给它起这个名称。
然而这样的管理模式在我们知识密集型的工作中也非常常见。比如以工作时长来判断一个人的产能；非得要求员工坐在工位上才算在干活；发呆就是在摸鱼（程序员在思考时很像在发呆）……
最近我们团队发生了一个看似不相关，但是管理模式相关的例子。
一个本应该通知到重点观察群里的告警，却发送到了普通群里。目前的告警规则配置方式过程如下：
1. 需求方建卡给员工A，说明期望配置哪些告警；
2. 员工A登录公有云的告警平台，点点鼠标，输入配置。即完成工作（这个过程通常被认为很轻松）；
3. 员工A将任务卡移到“待测试”中，等待其他人测试；
4. 员工B在对任务卡进行验证通过后，会被移到“已完成”中。
按这样的协作流程工作，最后为什么还会出现告警配置错误呢？
在界面优先的DevOps系统中，管理者倾向于认为员工AB的不负责导致了配置错误。进而增加更多的“肉眼监工”的过程。一家企业中，人工流程越来越多，即是肉眼监工管理模式盛行的体现；
而在代码配置优先的DevOps系统，管理者倾向于认为是流程工具本身的问题。以下是代码配置优先的DevOps系统下的工作流程：
1. 需求方建卡给员工A，说明期望配置哪些告警；
2. 员工A找到相应的代码仓库，修改告警规则配置，提一个MR；
3. 告警规则自动化检测程序对MR进行一系列测试，并将结果附在MR的评论中；
4. 员工B在确认修改和任务卡的需求一致后，将代码合并到主干，并把任务移到“已完成”中；
5. 告警规则被自动化部署到告警系统。
当出现告警配置错误后，管理者更倾向于优先告警规则自动化检测程序或者重构告警规则，而不至于让员工A容易犯错。
在《人类简史》中，作者有一个观点：是小麦驯化了人类，而不是人类驯化小麦。因为人类为了适应小麦和小麦农业，付出了无数健康、劳动、营养、人身安全的代价 。
而在软件工程中，这个观点依然适用。不是我们影响工具，而是工具影响着我们。
欢迎关注公众号：
往期好文推荐：
经验谈：如何培养团队使用看板的习惯
这篇关于DevOps系统对软件团队管理模式的影响的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
