首页> DevOps> 自适应变更管理:DevOps变更管理方法

[文章]自适应变更管理:DevOps变更管理方法

收藏
0 437 0

变更管理是基于ITIL的流程的另一个示例,可以通过应用DevOps实践来显着改善。变更管理通常以面对DevOps关键原则的方式实施。传统的实现方式为每次更改都设置了多层批准,插入了大量官僚机构和门,几乎可以保证更长的发布周期和为客户带来价值的延迟。这从根本上与DevOps强调的短发布周期和快速向客户交付价值相矛盾。

 

但是,几乎没有理由认为跟踪技术环境中的更改可能具有很高的价值。尤其是在同时发生许多不同更改的大型环境中,至关重要的是要了解更改的内容以及这些更改可能相互影响以及最终影响最终客户的方式。通过将DevOps原则用于变更管理,我们可以确保在保持速度和敏捷性的同时跟踪和管理变更。

 

 

DevOps进行变更管理的方法要求我们将变更管理的重点从近视重点转移到稳定性上。我们必须拓宽视野,将变更管理理解为一个既能确保速度又能确保敏捷性的过程。我们没有将其用作防止更改的闸门,而是将其用作使更改能够快速到达客户的过程。

 

我们经常使用持续集成和持续部署来处理每天进行数十甚至数百个发布的文化。为了以这种速度进行变更管理,您必须自动化变更管理过程。ServiceNow和其他ITSM工具公开了API,使您可以轻松地将CD管道与变更管理系统集成在一起。公司可以使用这些API自动创建变更凭单。这样可确保每次更改都有票证,而不会造成额外负担或减慢部署过程。这样的例子很多,流程框架,协作文化和工具可以一起使用,以真正创造出巨大的价值。

 

适应性变更管理

 

与客户合作,我们开发了一种变更管理方法,称为自适应变更管理。自适应变更管理的目标是实施轻量级,可伸缩和敏捷的过程,以提高稳定性并提高业务速度。此过程考虑了更改的风险,以确保在不减慢低风险更改的情况下,对高风险更改给予了适当的关注。这种方法还为团队提供了一种机制,以降低其降低摩擦并鼓励持续改进的风险。

 

在这种变更管理方法中,每个变更都被分配了一个风险。这符合确保我们适当地管理风险并适应风险的总体目标。然后根据给定更改的风险动态调整批准和监督级别。此外,释放时间可以根据风险水平进行调整。在这些参数下,发布低风险更改,并使用CI / CDA / B部署进行全自动测试,无需任何批准。另一方面,高风险的变更可能需要与多个团队进行协调,并且可能是高度手动的,因此会受到所有团队的审查,这些审查可能会受到影响,以确保各个级别的协作和适当的集成测试。

 

风险计算

 

变更的风险计算可以与使用风险的影响和概率的标准方法保持一致。在这种方法中,概率反映,虽然效果反映对业务的影响将会出现一个给定的风险的可能性,如果不考虑概率的发生风险。也就是说,假设更改失败,那么对业务的影响程度是什么?允许团队评估自己的影响和风险非常重要。这与DevOps的责任和信任概念保持一致。通过信任团队来准确评估变更的风险,我们可以建立一种高度信任的文化,以驱动高性能的公司。

 

我知道有些人可能会拒绝这种谴责,因为我们不能相信发布者能够准确地评估其变更的风险,而这些变更有利于快速交付而不是稳定。但是,我可以说,对于高信任度的环境而言,情况并非如此,因为开发和运营团队都将重点放在客户的成功上。也就是说,如果需要,可以实施缓解控制措施。一种方法是根据团队过去的表现以及他们准确评估变更风险的能力来权衡风险等级。通过将实际绩效重新纳入风险等级,我们可以建立数字反馈格式,并消除某些人可能会玩弄系统的担忧。

 

指导原则

 

一旦计算出变更风险,就可以调整审核和批准,以与给定变更的风险水平保持一致。低风险的更改可能需要经理的审查。高风险的变更可能需要与具有交叉依赖关系的其他团队进行协调,在这种情况下,变更咨询委员会的审查可能会有所帮助。使批准与风险保持一致时,请牢记一些指导原则,这一点很重要:

 

变更复审越接近代码的技术细节,效果越好。也就是说,与该团队的副总裁相比,同一个开发团队中的工程师对代码更改的影响会有更好的了解。

尽管高度信任是至关重要的,但是审计确实需要另一组眼睛来审查更改,以避免在有人确实有恶意的情况下进行非法或有害的更改。

变更咨询委员会(CAB)应该充当不同团队和业务需求之间的飞行控制CAB不应是旨在阻止变革的官僚机构。

较小的增量更改更安全。

我们越容易提交更改,人们越有可能遵循该流程。

牢记这些原则,我们可以开发一个批准系统,以确保适当的监督,同时允许对生产的更改尽可能减少摩擦。

 

标准更改和“更改冻结”

 

除了这些类型的更改外,还存在不需要任何批准的标准更改。这是在DevOps世界中进行更改的理想状态,在这种情况下,几乎可以连续地将小的更改发布到生产中。标准更改是预先批准的更改,风险极低,相对常见,并且遵循既定流程。这是一个可以使用持续集成持续部署以完全自动化的方式部署的变更的想法,其中包括最佳实践,例如连续测试,自动回滚,功能标记等。这些类型的更改可以被批准为标准更改。为了使变更成为标准变更,它必须具有低风险并具有成功执行的历史。一旦获得批准,这些标准变更无需任何批准即可部署。对于想要快速行动的组织来说,这是理想的选择。通过鼓励尽可能多的变更通过标准变更流程,组织可以减少组织的官僚主义并增加上市时间。

 

重要的是要注意,时间安排可能会在变更管理中起重要作用,因为它会影响变更的风险。繁忙的时期,例如商务平台的网络星期一,以及大型公司活动,对于企业来说可能是高风险时期。通常希望在这些时间中尽一切可能使风险最小化。

 

但是,这并不是说在这些时间内没有发生更改时应进行“更改冻结”。以我的经验,“更改冻结”根本不起作用。这些不起作用的原因有很多,第一个原因是实际上几乎没有遵守它们(如果有的话)。事实是,即使在高风险时期,业务和技术也必须继续向前发展。无论是针对客户问题的紧急解决方案还是对业务至关重要的版本,变更冻结几乎总是有例外。这种事情发生得如此之多,以至于我经常听到被称为“变更雪泥”的情况。

 

此外,数据显示,变更冻结通常会在冻结之前直接导致大量变更涌入,在此之前,团队尝试在高风险导致企业在试图保护的整个时间内显着不稳定之前,紧紧抓住所有关键功能。此外,在变更冻结期结束后,我们立即看到大量发布,这表明积压了变更,并且公司在此期间无法为客户提供价值。来自一家公司的以下数据准确描述了这种情况:

 

 

您能猜出“更改冻结”在哪里吗?

 

变更冻结期的最后一个问题是,它以处理低风险变更的方式与处理高风险变更的方式相同,用笼统的声明“您不可变更”。

 

解决这些问题的一种方法是简单地按现状进行处理:高风险期。考虑到这一点,我们可以简单地增加在此期间发生任何更改的风险。从我们的适应性方法开始进行变更管理,我们可以提高所有变更的风险,以便将低风险变更评估为中等风险变更,中等风险,高风险和严重风险。但这并不一定要产生高于高风险的附加风险。我们发现,这可以很好地准确反映业务现实,而不会强加很少执行的武断,不现实,笼统的声明。现实情况是,这对于企业来说是一个较高的风险时间,因此应在评估任何更改时加以考虑。

 

当然,对于任何变更管理流程而言,测试都是成功的关键因素。从单元级别到集成测试的所有测试都很重要。这里的关键是要尽可能地自动化,并将这种自动化构建到您的部署管道中。有了自动测试,就可以部署资源来进行测试,这在本质上更具探索性,可能会捕获自动化测试无法做到的事情。这种测试自动化可以在每种环境中使用,并且应该集成到部署管道中。

 

从时间角度来看,这是一种平衡,因为这些测试必须测试完整的系统功能,但是如果要在快速部署的管道中使用它们,则不会花费很多时间。各个团队之间的平衡会有所不同,但一定不要太耗时,以免团队倾向于跳过测试或减少发布频率。最终,开发代码的团队有责任确定这种平衡。他们必须负责确保代码毫无问题地交付给客户。一旦测试自动化并证明是成功的,就很容易主张将这些更改作为标准更改包括在内,从而可以快速无缝地交付给客户。

 

结论

 

在所有计划和风险分类中,重要的是要记住,始终会有计划外/紧急更改,并确保您的流程将这些更改考虑在内。为了保持变更管理流程的适应性,即使在紧急情况下,您也可以继续使用上述分类和批准矩阵。但是,在紧急情况下,必须进行修改,以便更快地进行更改。为了适应快速变化,经常需要口头批准这些变化。通常也应将更改表的提交推迟到紧急情况得到纠正之后再提交。

 

技术世界正以不断增加的速度变化,我们的流程在很大程度上适应了这种变化。借助DevOps的原理和实践,我们看到部署软件的频率越来越高。随着迁移到云,我们看到了可以在几分钟内创建的动态基础架构。除非我们的变更管理流程具有适应性,否则我们将阻碍我们快速进入市场并推动创新的能力。了解环境的变化是有价值的,但是随着变化速度的增加,我们跟踪和管理这些变化的方式必须适应。

DevOps
最近热帖
{{item.Title}} {{item.ViewCount}}
近期热议
{{item.Title}} {{item.PostCount}}