あなたの組織には、新しいシステム全体の導入からケーブルのパッチに至るまで、あらゆる変更を正式なものにする変更プロセスがありますか?
もしそうなら、あなたのプロセスでは、変更を要求した人や変更を実行した人を、その良し悪しに基づいて評価していますか? もしそうなら、それはあなたにとってどのように機能していますか? 何かヒントはありますか? そうでない場合、それは良いアイデアだと思いますか?
プロセスはありますが、変更がどれだけ小さくても、またはリクエスト者/実装者が以前にどれだけ「信頼できる人物」であったかに関係なく、すべての変更は同じ精査を受けます。私はこれを変更したいのですが、この方法で問題が発生したかどうかを確認するのが賢明だと思いました。
答え1
すべてが通過しなければならない CR プロセスはありますが、スコアリングはありません。もちろんレベルはあります。たとえば、変更に関連するリスクは何か、どの環境がそれらのリスクの影響を受ける可能性があるかを示します。環境は、たとえば「Portal にサービスを提供する本番 Oracle DB」のようなものになります。
CR に軽微な事項以上のことが記載されている場合、CR 担当者は大規模な会議を開く必要があります。
CR の一環として、全員が完全なロールバック プランを用意する必要があります。
...しかし、彼らがあなたを知るようになると得られる評判以外には、スコアリングのようなものはありません。
ただし、これはまったく悪いアイデアではないと思います。人々が CR を行う動機となるかもしれません。私が特に働いている場所で CR が部分的に役に立たないもう 1 つの理由は (私見ですが)、CR を送信しても、それを有用な方法で照会する手段がないため、やはり動機が薄れることです。
このようなものを便利にする最善の方法は、それを使用すると予想される人々に何らかの価値を返すことだと私は思います。機能性、スコアリング (serverfault など)、またはその他の方法で。
答え2
追加の精査を回避する方法を備えた変更管理プロセスは、変更管理プロセスの主な目的をそもそも回避することになります。変更について話し合うために人々を集めることの利点の 1 つは、潜在的な変更についてより多くの目と頭脳が検討することです。問題を検討する人が増えるほど (できれば、全員が運用インフラストラクチャのさまざまな領域で作業している)、潜在的な影響についてより完全なイメージを得ることができます。
採点システム（このサイトのシステムと似たもの）を導入するのは良いアイデアだと思いますが、オールスターでもミスや見落としはあります。ある場所での小さな変化が、別の場所で大きな影響を及ぼす可能性があります。
答え3
この種のスコアリング システムは、すぐに政治やゲームに利用されやすくなるようです。実際、あなたは、インクラウドが変更管理を回避できるようにしようとしているようです。それが良いアイデアかどうかは、この距離からは判断できません。
CYA ではなくリスク管理の手段として変更管理にこだわるのであれば、すべてにリスクと影響の評価が必要です。誰が変更管理を行っているかは、通常、何かがどの程度リスクがあるかの要因にはなりません。また、リスクがある場合でも、安全とは言えない人物であるにもかかわらず、一部の人物が変更を許可されている状況は非常に奇妙に見えます。