情報処理技術者試験☆合格への道

ライフワークとしての資格取得ブログ presented by Pman






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

にほんブログ村 資格ブログ 国家試験へ にほんブログ村 資格ブログ IT系資格へ
 にほんブログ村 資格ブログへ
 ブログの殿堂
資格・スキルアップ Ranking  ナレコム おけいこブログランキング

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

SEO対策・SEOとは
IT  資格  ブログ
受験  日記  合格  論文


最近の記事


リンク集




自己紹介など

    くつろぐ

  • ニックネーム:Pman
  • プロフィール:
     情報処理サービス会社に勤務。主に金融業のソフトウェア開発、システム運用・保守を担当。メインフレームからオープン系まで広く浅く経験。資格取得はライフワークとなりつつある。
    保有資格
    システム監査技術者
    プロジェクトマネージャ
    アプリケーションエンジニア
    テクニカルエンジニア(システム管理)
    ネットワークスペシャリスト
    情報処理技術者(一種、二種)
    電気通信主任技術者(第一種伝送交換)
    工事担任者(デジタル第1種)


  •  質問、要望、感想、応援などは
     下のメールフォームから、直接
     私あてに送ることができます。


     当ブログはリンクフリーですが、
     リンクした場合は、メール又は
     コメントで知らせていただくと
     ありがたいです。

メールフォーム

名前:
メール:
件名:
本文:

広告エリア2












スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

SM合格時の再現論文 -解説-

 1月25日に掲載した「SM合格時の再現論文」に、解説をつけ加えた。青字の部分がポイントかと思われる。システム管理だけでなく、その他の論文試験にも応用できるだろう。春試験まで、まだ時間はある。すでに準備論文を仕上げた方も、これから書こうという方も、最後までじっくりと取り組んでみよう。

【タイトル】
  システム障害の再発防止策について

【再現論文 Pman wrote】

1.システム概要及び発生した障害
1-1.私が携わった情報システムの概要
 首都圏を中心に約200支店を有する金融機関(以下、ユーザと呼ぶ)は、個人向け住宅ローンを主力商品の1つとしている。ユーザ業務は、6年前に稼働開始した住宅ローン情報管理システムにより運営されている。当システムの開発・運用は、情報処理サービス会社J社がアウトソーシングの形で受託しており、J社に勤務する私はシステム管理者として保守・運用に携わってきた。
 当システムは、J社に設置される汎用コンピュータ上のデータベース(以下、DBと呼ぶ)に対し、公衆回線を経由して、各支店の専用端末からアクセスする集中処理方式である。運用時間は、平日9時から17時までをオンライン時間帯、同17時から20時頃までをバッチ処理時間帯としている。

 ☆ 1-1.解説 ----------
 約200支店を有する/6年前に稼働開始
  システムの規模や背景がイメージしやすいように数字を使う。
 アウトソーシング
  組織間の関係を端的に示すための用語を入れる。
 集中処理方式
  集中か分散かを明らかにする。
 運用時間
  障害発生と防止策について論じるための伏線を敷いておく。
 ☆--------------------

1-2.発生したシステム障害
 稼働開始から2年程たった頃、オンライン時間中にあるユーザ支店の端末で、システムの異常終了が発生した。私はまず、障害事象を正確に把握するため、ユーザ窓口の担当者に状況を確認したところ、経理業務中にある顧客データのDB更新処理で、突然エラーメッセージが表示され更新不可になったという事象であった。次にJ社内部でダンプリスト取得により障害の原因を調査したところ、該当データのDB不整合のためアプリケーションエラーでアベンドしていたことが判明した。

 ☆ 1-2.解説 ----------
 障害事象を正確に把握
  システム管理エンジニアとして適切な行動を書く。
 DB不整合のためアプリケーションエラー
  ありきたりな事象だが発生したことを飾らず素直に書く。
 ☆--------------------

1-3.ユーザ業務への影響
 経理業務は、月単位で締め処理を行う期間が決まっている。この処理は、ローン残高の集計など企業経営に関わる重要な事務処理であるため、システム障害による業務の停止は避けなければならない。私は、早急に障害対策を講じる必要があると考えた。

 ☆ 1-3.解説 ----------
 企業経営に関わる重要な事務処理
  問題文の1行目「基幹業務に多大な影響」に合わせる。
 ☆--------------------

2.システム障害の再発防止策について(設問イ)
2-1.障害発生の根本原因
 障害発生の当日、ほかに13支店で同じように異常終了が発生した。このことから、特定の顧客データに何らかの異常が起きたのではないかと私は推測した。調査の結果、前日の夜間におけるDBパッチ作業のミスが判明した。DBパッチとは、ユーザからの依頼により、J社において特定のデータを強制的に塗り変える例外作業で、ユーティリティを用いた手作業である。ところが、本来パッチを当てるべきデータとは異なるデータに対し誤ってパッチを当てたため、DB不整合が発生したものであった。こうした作業ミスを引き起こすような運用方法に、障害の根本原因が潜んでいたと私は認識した。

 ☆ 2-1.解説 ----------
 DBパッチとは、
  読み手に伝わるように軽く説明を入れておく。
 運用方法に、障害の根本原因が潜んでいた
  やや漠然としているが、運用面の問題があることに言及する。
 ☆--------------------

2-2.システム運用面からの対策案
 以上の根本原因を取り除くための対策案を列挙する。
案(1) 作業要員の増強
 DBパッチ作業を実施するのは週1~2日、夜間バッチ処理後の2時間程度であったため、当初、作業担当者は1名で十分と考えていた。しかし、今回のシステム障害は、担当者のケアレスミスを防止または発見できなかったことに原因がある。また、顧客データを更新するという重要な作業を一人で行うことは、J社にとってリスクが高いと考えられる。そこで私は、作業要員を2名に増強し、パッチ作業時にダブルチェックを行い、ミスがないかどうかの検証を強化することを考案した。
案(2) 運用手順書の見直し
 運用記録の証跡書類を見ると、通常の運用作業における手順はほぼ確立されていたが、DBパッチ作業等の例外運用については確立されていなかった。例外運用の手順書は、ユーティリティの操作方法や障害発生時の対処方法が中心であり、J社の責任範囲や作業の承認ルールが不明確であった。今回のシステム障害は、パッチ作業における承認者及び確認者が曖昧であるなど、手続上の不備があったことに起因する。このため私は、運用手順書を全面的に見直し、改版することを考案した。
案(3) 検証ツールの導入
 パッチ対象のデータ件数が大きいほど、今回のような障害発生による影響も大きくなる。そこで、今までは作業結果をDBダンプリストの取得による目視確認としていたが、検証ツールによる自動確認に変更することを考案した。ツールは表計算ソフトのマクロ機能を利用したものであり、確認作業の省力化が期待できる

 ☆ 2-2.解説 ----------
 週1~2日、夜間バッチ処理後の2時間
  できるだけ定量的に表現する。
 担当者のケアレスミスを防止または発見できなかったことに原因
  2-1で言い足りなかったことを具体的に書く。
 J社にとってリスクが高い
  組織的な観点から分析したことをアピールする。
 ダブルチェックを行い、
  要員を増強して何を行うのか明記する。
 運用記録の証跡書類を見る
  客観的なデータをもとに分析したことをアピールする。
 承認者及び確認者が曖昧
  2-1で言い足りなかったことを具体的に書く。
 運用手順書を全面的に見直し、改版する
  問題文の「運用手順」に触れ、見直してどうするのか明記する。
 検証ツールによる自動確認
  問題文から引用できるものは引用し、論文に組み込む。
 表計算ソフト
  Excelなどの製品名は書かないこと。
 確認作業の省力化が期待できる
  どのようなメリットや効果があるのか述べる。
 ☆--------------------

2-3.対策案の採否の決定方法
 まず案(1)については、ダブルチェックの効果がある反面、作業時間が深夜に及ぶこともあるため、要員の工数確保が難しかった。体制面を変更するにはユーザからの承認が必要であったが、私の提案に対し、ユーザ側は「1名で十分」との見解を示した。確かに、発生確率の低い障害に対して体制面を強化するのは非効率である。このため私は案(1)を不採用とした。案(2)については、J社の各関係者に対しヒアリングを行ったところ、安定運用のために手順書は整備すべきとの意見が多かった。加えて、DBパッチ作業は一時的なものでなく、今後も継続する見通しであることを勘案し、私は、運用手順書を改版することに決定した(採用した)。案(3)については、ツールの開発工数・費用が膨らむことを懸念したが、必要性の高いチェック機能に絞り込むことで費用を抑えられる。さらに、ツールの入力となるチェック用データをユーザ側で作成して頂けるなど協力体制が得られたことから、私は案(3)を採用した。

 ☆ 2-3.解説 ----------
 作業時間が深夜に及ぶ/工数確保が難しかった
  要員管理の面から検討したことをアピールする。
 体制面を強化するのは非効率
  問題文の「体制面などから採否を決定する」に合わせる。
 各関係者に対しヒアリング
  問題文の「関係者と協議し、」に合わせる。
 今後も継続する見通しであることを勘案
  総合的に判断して決めた様子を述べる。
 改版することに決定した
  ここぞという箇所は自信をもって言い切ること。
 費用を抑えられる/協力体制が得られた
  問題文の「費用対効果、体制面などから採否を決定」に合わせる。
 ☆--------------------

3.評価及び課題(設問ウ)
3-1.評価
 運用手順書の見直しにより、DBパッチ作業時の承認~実施~検証の流れが明確になり、例外運用でありながら実際には定型的な業務として標準化することができた。また、検証ツールの導入により、パッチ作業時間が従来より30%短縮するなど、省力化及び効率化を図ることができた。これらの対策により、障害の再発防止ができていることから、私の実施した活動は全体的に効果があったと評価する。

 ☆ 3-1.解説 ----------
 承認~実施~検証の流れが明確になり、
  案(2)の効果があったことを書く。
 30%短縮
  案(3)の効果があったことを書く。
 障害の再発防止ができている
  論文のテーマをもう一度振り返り、その結果を明らかにする。
 ☆--------------------

3-2.今後の課題
 システム障害の再発防止策を検討して実施した結果、運用手順に関しては、改善すべき点が残っていると感じた。なぜなら、手順書の一部の項目については、運用環境の変化により形骸化したり、実態とかけ離れている部分もあったからである。したがって、今後も継続的に運用手順の有効性や妥当性を確認していく必要があろう。

 ☆ 3-2.解説 ----------
 運用環境の変化により形骸化
  システム管理エンジニアの視点から問題提起する。
 ☆--------------------

関連記事
スポンサーサイト

コメント

コメントの投稿



管理者にだけ表示を許可する

トラックバック

http://smpman.blog3.fc2.com/tb.php/154-676e2f1e

IT社会により、消えてゆく特技と経験

ITの進歩とともに社員に求められる専門性や資格が変化しています。これからは、PCやアウトソーシングで置き換えられることのない専門性や能力を身につけておくことが大切になっているのでしょうね…

グーグルアドセンス(google adsense)で住宅ローンを返済するぞ!!

4月も順調に稼げました。この調子で住宅ローン完済を目指します。夢ではないですよ!!
 | HOME |  ▲ page top


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。