【システム運用カイゼン】（2004.11.19）

**********************************************************************
■先ずは日記
**********************************************************************

先程一緒に仕事をしてきていた人が、プロジェクト撤退の挨拶に来てくれまし
た。一ヶ月ほど休職し、心と体を休めるとのことでした。

以前から軽鬱で病院に通っていたのは聞いてましたが、つらかったんですね。

あッ！、仕舞った。「頑張って！」って言ってしまった。
欝病の人にその言葉は禁句でした。

そう言えば、最初笑顔があったのに、途中からなくなったもんなぁ。
悪いことしてしまった。

ホント、申し訳ない。（ここで言っても本人には、伝わりませんが・・・）

ゆっくり休んで、心も体もリフレッシュして欲しいと、心から願うばかりです。


**********************************************************************
■変更管理ミス
**********************************************************************

私がＩＴ系の情報を入手する際、良く利用させてもらってます「＠ＩＴ］に、
今日掲載された記事で、「変更管理、その正体と対策」というものを目にしま
した。

記事掲載のアドレスは、次の通り。
http://www.atmarkit.co.jp/farc/rensai/config03/config03.html


変更管理に関する手法については、記事を参照してもらうとして、ここでは私
が経験した変更管理ミスに伴う、トラブルの事例を紹介することで、変更管理
の重要性を認識していただきたいと思います。


ある運用中のアプリケーションプログラムに、バグが発見されました。
そのプログラムソースは、数ヵ月後にリリースされる新サービスに伴い、変更
が発生していたため、

　　●正本ソース　⇒払出し⇒　●新サービス用ソース

という具合に、２元管理された状態になっていました。


本来であれば、現行システムで稼動中のコードは、当然「●正本ソース」にな
っているので、当然「●正本ソース」に対し修正を行う必要がありました。

（正確に言えば、「●正本ソース」を「●障害修正用ソース」に払出し、そこ
　へ修正を行うです。）

しかし誤って「●新サービス用ソース」に対し修正を行い、本番環境へリリー
スを行いました。

----------------------------------------------------------------------
【現行システムバグに対するプログラム修正】
　●正本ソース　　　　 ： ○
　●新サービス用ソース ： ×（新サービス用のロジックを組込み済みの為）
----------------------------------------------------------------------

当然ですが、まだ動作してはいけないロジックが組み込まれた状態で、本番環
境にリリースしたため、異常な動作をすることとなった訳です。

試験で発見されるべきものかもしれませんが、試験パターンの不足から発見さ
れないまま、リリースに至りました。

正直言って、とても単純なミスです。


こんな単純なパターンは珍しいと思いますが、複数のプロジェクト（案件）に
伴い、多次元管理状態になったソースでバグが発見された場合、バグに対する
修正結果を、多次元管理された全てのソースに反映させる必要があります。

全ての反映行為を、漏れなく確実に実施するには、やはりそれなりの仕組みが
必要です。

これは、開発時にも言えることだと思いますが、運用としては本番稼動におけ
る障害は一つでも発生させたくないはずです。


変更管理にはしっかり気を配り、ミスを発生させない仕組みをつくりましょう。


★システム運用カイゼンのポイント★

変更管理ミスによる障害を、発生させない仕組みをつくりましょう。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【システム運用カイゼン】
Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━