DevOps工作法第二步:在复杂中安全的工作

2023-05-19 08:00:00
翰德恩咨询
原创
501
摘要:在devops培训课程中学到DevOps三步工作法-反馈原则。
复杂系统的一个重要特征是,无法将系统视为一个整体,去理解各个部 分是如何组合在一起的。复杂系统的组件之间通常是紧耦合且紧密关联 的,不能仅仅依据组件的行为来解释系统的行为。

Charles Perrow博士研究了三里岛核事故,他发现没有人能了解核反应堆 在所有情况下的行为,以及在何种情况下会发生故障。当核反应堆的一 个组件出现故障时,很难将其与其他组件隔离,以不可预测的方式快速地流过阻力最小的路径。

Sidney Dekker博士提出了一些关于安全的重要元素,他发现了复杂系统的另一个特点:相同的事情做两次,结果未必相同。也正是因为这个特点,即便施行了有价值的静态检查和最佳实践,还是不足以防止灾难发生。

DevOps工作法

复杂系统中的故障是存在且不可避免的。因此,无论在制造业还是信息 技术行业,我们都必须设计出一个安全的工作系统,让员工能无所畏惧地开展工作,确保早在灾难性后果(例如人员伤害、产品缺陷或负面的客户影响)发生之前,能快速检测出错误。

Steven Spear博士在他的哈佛商学院博士论文中揭示了丰田生产系统背后的因果机制。他认为,我们可能无法设计出绝对安全的系统,但是可以通过采取以下4项措施让复杂系统更安全地工作:

(1)管理复杂的工作,从中识别出设计和操作的问题;

(2)群策群力解决问题,从而快速地构建新知识;

(3)在整个组织中,将区域性的新知识应用到全局范围;

(4)领导者要持续培养有以上才能的人。


要在复杂系统中安全地工作,必须具备上述4种能力。接下来,我们将描述前两种能力及它们的重要性,同时还会探讨其他领域是如何实现这些能力的,以及如何在技术价值流中实现它们。

1.及时发现问题

在安全的工作系统中,我们要不断地对设计和假设进行验证。目标是更 早、更快、以尽可能低的成本、从尽可能多的维度增加系统的信息流, 并尽可能清晰地确定问题的前因后果。能排除的假设越多,定位和解决 问题的速度就越快,从而提高我们的顺应力、敏捷性以及学习和创新能力。

我们通过在工作系统中建立反馈和前馈回路的方式实现这一点。反馈和前馈回路能让系统内各部件之间的关系增强或抵消。

在制造业,如果缺乏有效的反馈机制,往往会酿成重大质量和安全问题。有这样一个典型的案例:通用汽车的弗里蒙特制造厂既没有有效的 流程来检测装配过程中的问题,也没有明确的步骤来解决问题。结果导 致了各种问题,比如发动机倒置,汽车缺少方向盘或轮胎,甚至是由于 根本无法启动,不得不把汽车拖出装配流水线。

相比之下,在高绩效的制造业运营中,整个价值流里存在着快速、频繁和高质量的信息流——每个工序的操作都会被度量和监控,任何缺陷或严重偏差都能被快速发现和处理。这些是保证质量、安全和持续学习与改进的基础。

在技术价值流中,由于缺少快速反馈机制,我们经常会得到糟糕的工作结果。例如,在瀑布型软件项目中,代码的开发可能花上一整年,在开始测试之前(甚至在向客户发布软件前),我们得不到任何质量反馈。

在反馈稀少且滞后的情况下,工作结果是很难达到预期的。

及时反馈问题

相反,我们的目标应该是在技术价值流的每个阶段(包括产品管理、开 发、QA、信息安全和运维),在所有工作执行的过程中,建立快速的反馈和前馈回路。这包括创建自动化的构建、集成和测试过程,以便尽早检测出那些可能导致缺陷的代码变更。

我们还要建立全方位的监控系统,监控服务组件在生产环境中的运行状态,以便快速探测到服务的意外情况。监控系统还能帮助我们度量是否偏离了预期目标,并将监控结果辐射到整个价值流中,这样就能看到我们的行为是如何影响系统里的其他部分的。

反馈回路不但能让问题的快速探测和修复成为可能,而且还能告诉我们如何防止问题复发。这样做不但提高了工作系统的质量和安全性,还创造了组织性知识。

我们必须不断地验证目标,验证实施是否满足了客户的需求,而测试仅仅是一种反馈

2.群策群力,战胜问题获取新知

显然,仅仅检测出意外的发生是远远不够的。一旦问题出现了,我们还 必须群策群力,发动所有相关的人员解决问题。

群策群力的目的是遏制住问题,防止蔓延,然后定位和处理问题,避免复发。他说:“这样做可以让所有参与者都得到更深入的知识,理解如何管理系统,把无法规避的、早期的无知阶段变成学习的过程。 这个原则的典范是丰田的“安灯绳”。在丰田制造工厂里,每个工作中心都是一条绳索,每个工人和经理都受过培训,他们会在出现问题时拉下安灯绳,比如,当零件有缺陷时,当需要的零件用光时,或者是加工时间比文档中描述的长时。

在安灯绳被拉动时,团队领导就能第一时间得知并立即着手解决问题。

战胜问题获取新知

如果问题不能在指定的时间(如55秒)内解决,就会停掉整个生产线,调动整个企业一起协作,直到成功地找出解决问题的对策。

我们不应绕开问题,也不应该用“有更多时间时再解决”来搪塞,而要立刻群策群力修复问题——这与通用汽车弗里蒙特工厂的做法几乎完全相反。群策群力的原因如下:

防止把问题带入下游的处理环节,否则不但修复的成本和工作量会;

呈指数级增加,而且还会欠下技术债;

防止工作中心启动新的工作,那样可能会在系统中引入新的错误;

如果问题还没有得到解决,那么工作中心在下一次操作中,可能还会遇到相同的问题,需要更高的修复成本.

这种全民总动员的做法似乎违背了常规管理方法,因为局部问题扰乱了整体的运营。然而,全民总动员让学习成为了可能。它还能防止由于记忆模糊和情况变化导致的关键信息遗失,这在复杂系统中显得尤为重要。在复杂的系统里,由于人员、流程、产品、地点和境况中存在着很多意想不到的、特殊的相互作用,会出现很多问题。随着时间推移,谁不可能精确地重现问题发生时的场景。

正如Spear博士所说,全民总动员是“实时的问题识别、定位和处理(在制造业称为对策或纠正措施)循环的一部分。这就是休哈特提出的循环(即PDCA环)——计划(Plan)、实施(Do)、检查(Check)、改进(Act),后来由爱德华兹·戴明推广并得到了迅猛发展”。 只有尽可能在早期阶段,通过全民总动员的方式来解决小问题,才能把灾难性事故消灭在萌芽状态。换句话说,当核反应堆的堆芯熔毁了,那就太迟了,已经回天乏术。

为了在技术价值流中实施快速反馈,我们必须建立等同于安灯绳和全民响应的机制。这要求我们也创造出这样一种文化,让人们在发生问题时就去拉动安灯绳,无论是在生产事故发生时,还是在价值流的早期出现错误时,并且这个行为是安全的甚至是受鼓励的。例如,当有人提交了个代码变更,而这导致了持续构建或测试过程失败的时候。

触发了安灯绳时,我们就聚集在一起解决问题,停止开展任何新工作, 直到问题解决。这给价值流中的每个人提供了快速反馈(特别是那个导致系统故障的人),让我们能够快速地隔离和定位问题,避免出现更复杂的状况,导致问题的因果关系变得模糊。

阻止开展新工作有助于实现持续集成和部署,这就是技术价值流中的单件流。能通过持续构建和集成测试的所有变更都可以部署到生产环境中,任何导致测试失败的变更都会触发安灯绳,并且会将大家聚集起来解决问题。

文章来源:《DevOps实践指南》


关于翰德恩咨询(www.hardenx.cn):是一家由华为系专家联合创办,专注于企业级敏捷&DevOps落地咨询、IPD落地咨询和数字化转型教育的企业,沉淀10年+的众多500强实战经验,为企业提供从业务到交付的端到端全价值链赋能。

课程体系详情,请戳: 企业级敏捷的完整体系


联系我们
联系人: 田老师
电话: +86 135 5227 9573
Email: clientservice@hardenx.cn
地址: 北京市朝阳区福码大厦B座17层1705

加微领1G资料