您的变更控制流程是否对变更请求者和/或实施者进行评分?

您的变更控制流程是否对变更请求者和/或实施者进行评分?

您的组织是否有一个变更流程,将每个变更(从全新的系统部署到电缆补丁)正式化?

如果是这样,您的流程是否会根据要求变更的人或/以及执行变更的人的优秀程度对他们进行评分?如果是这样,这对您来说如何 - 有什么建议吗?如果没有,您认为这是一个好主意吗?

我们有一个流程,但每个变化都会受到同样的审查,无论请求者/实施者之前的变化有多小或有多“安全”——我想改变这一点,但认为看看您是否遇到了这种方法的问题是明智的。

答案1

我们确实有一个 CR 流程,所有事情都必须经过,但没有评分。当然有级别 - 例如,您可以指出与变更相关的风险是什么,以及哪些环境可能受到这些风险的影响 - 例如,环境可能类似于“生产 Oracle DB 服务门户”。

如果 CR 声明的内容不仅仅是小事 — — 那么 CR 人员就必须召开一次大型会议。

作为 CR 的一部分,每个人都需要有一个完整的回滚计划。

...但是,除了他们认识你之后你将获得的声誉之外,没有任何得分。

我认为这并不是一个坏主意,可能会对人们做 CR 提供一些激励,另一个原因是为什么 CR 在这里部分无用,特别是我工作的地方(在我看来) - 你提交了 CR,但没有任何有用的方式查询它们,所以再次 - 激励较少。

我认为让这些东西变得有用的最佳方法是向你期望使用它们的人提供一些价值。无论是通过功能,还是评分(如 serverfault),或者其他。

答案2

如果变更控制流程可以规避额外的审查,那么它从一开始就绕过了变更控制流程的主要原因。让人们聚在一起讨论变更的好处之一是,您可以让更多的人关注潜在的变更。让越多的人(最好都在生产基础设施的不同领域工作)关注这个问题,您就能越全面地了解潜在影响。

虽然我认为设立一个评分系统是个好主意(可能类似于这个网站上的评分系统),但即使是全明星也会犯错误/疏忽。一个地方的微小变化可能会对另一个地方产生巨大影响。

答案3

这种评分系统听起来很快就会受到政治和游戏的影响——事实上,听起来你是想让圈内人绕过变更控制。从这个角度看,我无法判断这是否是个好主意。

如果您打算将变更控制作为风险控制手段,而不是 CYA,那么一切都需要进行风险和影响评估。谁来执行通常不是决定某件事风险大小的因素 - 即使如此,如果某些人被允许进行变更,尽管他们不安全,这种情况看起来也很奇怪。

相关内容