IT業界(?)のトラブル情報を収集して、そこから教訓を抽出して公開するという取り組みをIPA/SECが行っている。わりと惰性でやっている感はあるのだけれど、2016年1月から3月までにいくつか教訓が追加されていたので目を通して感想を書いてみた。
前回記事はこちら
2016/1～3に追加された教訓
今回読んだのは以下のもの。
| ID | タイトル | 教訓 |
|---|---|---|
| T20 | パッケージ製品の機能カスタマイズに関する教訓 | パッケージ製品の機能カスタマイズはリスクを認識し、特に必要十分なチェック体制やチェック手順を整備して進めること |
| T21 | 運用保守で起きる作業ミスに関する教訓 | 作業ミスを減らすためには、作業指示者と作業者の連携で漏れのない対策を！ |
| T22 | バッファプールの管理に関する教訓 | 隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること |
| G10 | システム動作の疑義問合せがあった場合の対応に関する教訓 | 関係者からの疑義問合せは自社システムに問題が発生していることを前提に対処すべし！ |
| G11 | システムの運用・保守に関する教訓 | システムの重要度に応じて運用・保守の体制・作業に濃淡をつけるべし |
| G12 | キャパシティ管理のマネジメントに関する教訓（その1） | キャパシティ管理は、業務部門とIT 部門のパートナーシップを強化するとともに、管理項目と閾値を設定してPDCA サイクルをまわすべし |
| G13 | キャパシティ管理のマネジメントに関する教訓（その2） | キャパシティ管理は関連システムとの整合性の確保が大切 |
| G14 | キャパシティ管理のマネジメントに関する教訓（その3） | 設計時に定めたキャパシティ管理項目は、環境の変化にあわせて見直すべし |
[教訓T20]パッケージ製品の機能カスタマイズはリスクを認識し、特に必要十分なチェック体制やチェック手順を整備して進めること
微妙な事例。新規構築したコールセンタ受付システムにて、顧客向けにカスタマイズした箇所に不具合あり業務影響が出てしまったというもの。該当の不具合は事前のテストで検出することが難しいものだったということだが、そもそも顧客に「カスタマイズしている」ということを十分に説明していなかったという点が問題だったと言いたいようだ。
おそらく「このシステムは他社でも多数利用実績のある品質の高いパッケージです」という売り文句で導入したものの、いきなり不具合が出て「品質高いんと違うのか？」「そこだけは御社専用のカスタマイズ部分でした。本体品質は問題ありません」「そんなこと事前に聞いてないし、わかるかい！」という揉め方をしたのだろうと思う。
ちなみにIPA/SECでは「ソフトウェア品質説明」というキーワードで品質説明力(?)を高める検討をしているようで、以下の資料も興味深い。
[教訓T21]作業ミスを減らすためには、作業指示者と作業者の連携で漏れのない対策を！
わざわざ教訓にする必要があるのか、ちょっと悩ましい印象をもつ事例。あいまいな作業指示＋結果を作業指示者がちゃんとチェック検証していないでやらかしてしまったトラブルである。TPSにおけるポカヨケを考える必要がある印象。
[教訓T22] 隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること
こいつも微妙な事案。後方にあるキューが溢れて、業務全体を管理するキューまで溢れて全業務停止、といった内容。これは単純に運用設計の漏れな気がするのだけれども・・・。
[教訓G10]関係者からの疑義問合せは自社システムに問題が発生していることを前提に対処すべし！
一部の接続先通信業者から接続異常の問い合わせがあったにもかかわらず、自システムの障害の可能性に気づかず相手先の問題として切り捨ててしまったために、問題発覚が遅れたという事案。ある意味、インシデントの切り分けに課題があると思うのだけれども、保守体制にある程度の余裕がないと実運用で改善するのは難しいのではないだろうか。ただ、この事案は頭に入れておいたほうが良い気がする。
[教訓G11]システムの重要度に応じて運用・保守の体制・作業に濃淡をつけるべし
複雑で難しい事案。複合的な要因(製品不具合、リカバリー作業時の保守作業ミス)で重要なシステムが停止となったとのこと。教訓に書かれている通りでもあるのだけれど、システムの重要性を鑑みてレベル分けを行い、最重要システムはそれなりにコストをかけて障害対応訓練を行うべきだろう。防災訓練と同じで、スムーズな初動は訓練によって生み出されるものである。また教訓には書かれていないけれどシステムコンティンジェンシープラン的なものをきちんと策定し、毎年ちゃんと見直すような活動も重要だと思う。
[教訓G12]キャパシティ管理は、業務部門とIT 部門のパートナーシップを強化するとともに、管理項目と閾値を設定してPDCA サイクルをまわすべし
想定取引データ量の急変によりシステムが停止したもの。その後、IT部門と業務部門が連携してキャパシティ管理するようになったらうまくいったというベストプラクティスの共有となっている。
この教訓では「キャパシティ」というKPIについて議論がされているが、近年脚光を浴びているDevOpsに通じるものもある。システムという重要なビジネスリソースを最大限活用するという意味では、開発、運用、業務の三位一体での合意形成が必要という話があるが、まさにその一例であったという印象。2013年の夏のデブサミの基調講演でもそういった話があったことを思い出した。
[教訓G13]キャパシティ管理は関連システムとの整合性の確保が大切
次に紹介する教訓G14も含めて、単一の事例(どこかの会社からの報告)からいろいろと読み取って掲載しているようだ。この事例では、システム群全体のキャパシティを見極めるために、システム間の連携を台帳管理しながら関係者で頭を付き合わせて管理をするというプラクティスを紹介している。
このアプローチに似たものは何回か見聞きしたことがあって、確かに有用なのだけれども、台帳を維持する労力がバカにならないので、強い統制を効かせないと実行は難しいと思う。また、システム間連携管理台帳を「データディクショナリに登録して管理する」というのは考え方として違和感を感じる。マスタデータ管理と、トランザクション管理は別のスキームだと思うのだけれども、どうだろうか。
[教訓G14]設計時に定めたキャパシティ管理項目は、環境の変化にあわせて見直すべし
これも教訓G12,G13と同じ事例から抽出された教訓の模様。キャパシティをPDCAサイクルで維持管理しつつ、見直した内容を適切に次期システム検討のインプットに継承しましょう、ということが書いてある。その通りだし、異論は無いのだけれども現行システムの運用保守に、次期システムの考慮も同時に実施させるというのが現実的なのかどうか疑問を感じた。次期システム検討時に、きちんと非機能要件を検討分析すれば漏れないような気もするのだけれど。
SEC BOOKS 共通フレーム2013（電子版）: ?経営者、業務部門とともに取組む「使える」システムの実現?
- 出版社/メーカー: 独立行政法人情報処理推進機構
- 発売日: 2014/09/11
- メディア: Kindle版
- この商品を含むブログを見る
