绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
节省显示器同时提升持续集成问题修复及时性的“流水线问题责任聚焦”实验
2023-08-02 15:54:55
作为企业IT部门某个开发团队负责人的你,从书上和大佬那里得知,软件开发团队,如果采用持续集成实践,那么就能降低软件开发过程中的返工。

于是你按照书中和大佬所说的,在团队工位显眼位置,摆放了一个大显示器,并接上持续集成流水线。

你喊团队中所有的5位开发人员来开会,告诉他们,一旦流水线运行出现问题,比如编译打包错误或自动化测试运行失败,显示器就会显示告警的红色/黄色画面。团队中无论谁看到了红色/黄色告警,时间就要放下手中工作,及时修复流水线。团队中的其他人,也要配合这位同事的修复工作。

开发人员都答应了。

但很快你就发现,你所辛辛苦苦搭建的流水线健康显示屏,其实就是一个摆设。团队开发人员根本就不关注。即使显示屏变红/黄好几天,也无人修复。

这个问题该如何破?

你读了阿伦森的《社会心理学》,其中的“责任稀释假说“给了你很大的启发。即目睹紧急情况的人越多, 他们中任何一个人干预的可能性就越小。

你觉得工位边上的持续集成流水线健康状况显示器,其实就再现了一个*责任稀释的场景*。看到红色/黄色告警的开发人员,都会觉得其他开发人员已经看到并处理了,于是不再采取行动。

你从书中了解到,在1968年,两位社会心理学家用实验模拟了一个人命关天的紧急情况。实验结果发现,当受试者面临要出人命的紧急情况,并意识到周围有4个旁观者时,只有31%的概率会去施救。若旁观者下降为2人,施救的概率上升到62%。当周围没有旁观者,施救的概率会达到85%(如图)。

图:当周围没有旁观者,受试者施救的概率会达到85%

我在“吾真本说混沌工程”知乎专栏的文章“做软件的人不被他人忽悠的方法”里,说只有自己动手做有对照组的科学实验,才能避免被忽悠。

为了避免被忽悠,你觉得可以设计一个实验,来找到提升自己团队流水线问题修复及时性的方法。

该如何设计这个实验?

我在下面帮你列出这个实验的6个步骤和具体实施方法。你可以根据团队具体情况,*做适当的调整*。如果遇到问题,欢迎在评论区留言,与我交流。

1 基于观察

放置在工位附近显眼位置的持续集成流水线健康显示屏,就是一个摆设。团队中的5位开发人员平时根本就不关注。即使显示屏变红/黄好几天了,也无人修复。

2 问出问题

是什么阻碍了开发人员,让他们即使看到了显示屏的红色/黄色告警,也不及时修复流水线问题?

3 形成可验证的解释性假说

根据“责任稀释假说“,目睹流水线红色/黄色告警的开发人员越多, 他们中任何一个人修复流水线问题的可能性就越小。

4 基于假说做出预测

如果将工位附近的流水线健康显示屏撤掉,并要求每位开发人员,在向流水线合并代码后,需要通过自己的电脑显示器,观察流水线健康状态。直到状态变为健康的绿色,才算合并成功。若其间发现红色/黄色告警,因为只有她/他一人在场,周围没有旁观者,那么她/他主动修复流水线所发现的问题的概率会达到大。

5 设计并执行有对照组的实验检验预测

你需要设法吸引IT部门负责人对这个实验感兴趣,并获得她/他的支持,比如帮助你找到另一个同样有5人左右开发人员的开发团队作为*对照组*,并获得那个开发团队负责人的支持。而你所在的团队,可以作为*实验组*

由IT部门负责人和实验组与对照组这两个开发团队负责人,三人成立实验小组。

为了让实验结果不会因为实验组和对照组两个开发团队的开发人员,因相互攀比而有损数据的准确性,该实验*从始至终秘密进行*。即实验的事情,只有实验小组的那三人知道。若其他人问起实验过程中一些事情的缘由,比如为何撤销显示屏,可以编一个理由,比如其他团队临时借用。总之不要透露正在开展的实验和实验意图。

在实验开始前,两个开发团队的负责人,需要各自准备好流水线健康状况观测工具。比如能通过工具,观测出流水线何时出问题变红/黄,何时修复好变绿。可以设置一个及时修复的时长范围。比如流水线每次从变红/黄到变绿之间,没有超过4小时,算及时修复。否则,就不算。

对照组在工位显眼位置,摆放一个大显示器,并接上持续集成流水线。对照组团队负责人在实验开始前一天,召集所有开发人员,告诉他们一旦流水线运行出现问题,显示器显示告警的红色/黄色画面,团队中无论谁看到了红色/黄色告警,时间就要放下手中工作,及时修复流水线。团队中的其他人,也要配合这位同事的修复工作。

实验组则悄悄撤销工位附近的流水线健康显示屏。实验组团队负责人,就是你,在实验开始前一天,召集所有开发人员,要求他们在向流水线合并代码后,需要通过自己的电脑显示器,而不是工位附近的流水线健康显示屏,观察流水线健康状态。只有健康状况变为绿色,才算合并成功。若发现红色/黄色告警,就需要立即修复。其他开发人员在修复期间,需要积极配合。

设置一个开展实验时间段,比如6周。两个团队同时开展实验,并同时采集数据。

每2周作为一个迭代。实验小组在迭代末就开一次碰头会,分析和对比这2周采集的观测数据,即这2周流水线问题及时修复的百分比。

6 根据实验结果可回到第3步不断迭代优化假说/预测/实验过程

到第6周结束,总结和对比这3个迭代实验组和对照组流水线问题及时修复百分比。根据实验数据,看看是否支持第4步的预测,并决定是否回到第3步,改进假说、预测或实验过程。

如果在实验过程中遇到问题,欢迎在评论区留言,与我交流。

如果觉得本文对你有帮助,欢迎点赞,点击在读,并转发给其他经常受流水线问题修复不及时之害的小伙伴。你觉得提升流水线问题修复及时性,还有什么其他好办法你还希望我聊有关做软件的其他什么新话题?欢迎在评论区留言。我会仔细阅读每一条留言。期待听到你的声音。


企业生意蒸蒸日上,软件系统稳定运行。你所阅读的文章,来自“吾真本说混沌工程”知乎专栏。


分享好友

分享这个小栈给你的朋友们,一起进步吧。

吾真本说混沌工程
创建时间:2023-06-15 15:36:20
用好企业软件系统稳定性与混沌工程相关技术和过程
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • 程序员吾真本
    栈主
戳我,来吐槽~