問です。 変更管理とリリース展開管理についてです。変更、リリース展開をテーマとした論文のネタとして、マルウェア感染対策として、インターネットとの境界にUTMを新たに設置するというネタを考えています。設置する上で、変更管理、リリース展開管理を適切に実施する必要がある。のような流れです。この時、UTMのconfigに誤りがあって、機器設置後、通信不可となり、変更に失敗したとします。config誤りによる変更の失敗は、変更管理とリリース管理のどちらのプロセスに問題があったと書くのが適切でしょうか? リリース展開管理は、検証、リハーサルも含む認識です。そもそも、configに間違いがあったなら、検証・リハで気付くから、失敗はリリース展開管理に問題があったと考える方が自然な気がしています。 変更管理は、リスクの評価は行うが、configまでは関与しない認識ですので、やはりリリース展開管理でconfgi誤りを検出できなかったのが原因である。が自然な流れでしょうか?
42閲覧
いえ、一般的には変更管理です。通常は変更管理できちんとconfigを変えた後の運用試験を試験環境で行う筈です。そこでOKだからリリースを行う承認がされるまでが変更管理です。 リリース展開管理が検証って試験の話ではないですよね?あくまでもリリースの検証の筈です。リリース展開管理が変更の中見をわかっているのは一般的にはおかしいです。変更する側が変更する際の影響もわかってる筈です。 例えば、configが今回のリリースのためのconfigであればリリース展開管理側になりますが、機器の設定であれば変更管理がリスクの評価しかせずに試験は一切しないのはおかしいと思います。
< 質問に関する求人 >
求人の検索結果を見る
< 質問に関する求人 >
求人の検索結果を見る
< いつもと違うしごとも見てみませんか? >
求人の検索結果を見る