Skip to content

DNET_AdvancedAMServiceManagementSM

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

高度午前 - サービス・マネジメント - サービス・マネジメント

概要

サービス・マネジメントのサービス・マネジメント（高度：午前Ⅰ、午前Ⅱ）

ISO/IEC 20000 及び ITIL

その他

運用

データ管理者の役割

  • データ管理者（DA : Data Administrator）

    • DBMSの評価・選択、論理データベース設計
    • データ項目の設計・管理・標準化
    • 個々のデータ項目へのアクセス権の管理

  • データベース管理者（DBA : DataBase Administrator）
    データベースの構築と運用・保守を行う。

    • データ増加を見積もり、ディスク増設など計画・実施
    • データベースのパフォーマンス・チューニング
    • 障害時、データベースの復旧と整合性のチェック

データベースのバックアップ

更新頻度の少ないデータベースのフルバックアップ取得間隔を２倍に伸ばした場合。

  • ×：フルバックアップ１回あたりの容量が2倍になる。
  • ×：フルバックアップ１回あたりの容量が1/2倍になる。
  • ×：フルバックアップ１回あたりの時間が2倍になる。
  • 〇：ログを用いた復旧時間が2倍になる。

データベースのバックアップと復旧についての知識があればOK

ファシリティ

UPS設備の冗長化に関するティア構成

JDCC（日本データセンター協会）が制定する
「データセンター・ファシリティ・スタンダード」
において、UPS設備の冗長化に関するティア構成がある。

  • ティア 1

    • UPSの冗長性 : N
    • 瞬間的な停電に対し、コンピューティング・サービスを継続して提供できる設備がある。

  • ティア 2

    • UPSの冗長性 : N
    • 長期的な停電に対し、コンピューティング・サービスを継続して提供できる設備がある。

  • ティア 3

    • UPSの冗長性 : N + 1
    • UPSのメンテナンスなど、UPS設備の一時停止時も、
      コンピューティング・サービスを継続して提供できる設備がある。

  • ティア 4

    • UPSの冗長性 : N + 2
    • UPSのメンテナンスなど、UPS設備の一時停止時に、
      更に、一部のUPS設備に障害が発生しても、
      コンピューティング・サービスを継続して提供できる設備がある。

計算問題

稼働品質率

  • 稼働品質率 = 迷惑回数 / システム資産規模

    • 単位規模辺りの迷惑回数。
    • 資産規模には、総運用費用を用いる。
    • 値が低い程、品質が高い。

  • 計算

システム 迷惑回数（回/年）
オンライン		 迷惑回数（回/年）
バッチ		 稼働時間（千時間/年） 総運用費用（百万円/年） 稼働品質率
A 3 12 6 120 (3 + 12) / 120 = 0.125
B 4 8 3 100 (4 + 8) / 100 = 0.12
C 6 2 4 80 (6 + 2) / 80 = 0.1
D 6 3 2 60 (6 + 3) / 60 = 0.15

TCO（Total Cost of Ownership）

  • 以下を全てを含む、システムの総所有コスト。

    • イニシャル（システム構築のハード・ソフトの導入費用など
    • ランニング（運用後の維持費・管理費・人件費など

  • 3年稼働でTCOが最小のものはどれか

費用 A案 B案 C案 D案
ハードウェア導入費用 30 30 40 40
システム開発費用 30 50 30 40
導入教育費用 5 5 5 5
ネットワーク通信費用 / 年 20 20 15 15
保守費用 / 年 6 5 5 5
システム運用費用 / 年 6 4 6 4
  • 計算
    • 案１：30+30+5+203+63+6*3=161
    • 案２：30+50+5+203+53+4*3=172
    • 案３：40+30+5+153+53+6*3=153
    • 案４：40+40+5+153+53+4*3=157

システム改善案の評価

  • 案
区分 評価項目 案１ 案２ 案３ 案４
効果 作業コスト削減 5 4 2 4
効果 システム運用品質向上 2 4 2 5
効果 セキュリティ強化 3 4 5 2
リスク 作業コスト削減 4 1 5 1
リスク 作業コスト削減 2 4 1 5
  • 重み
区分 評価項目 重み
効果 作業コスト削減 3
効果 システム運用品質向上 2
効果 セキュリティ強化 4
リスク 作業コスト削減 3
リスク 作業コスト削減 8
  • 計算
    • 案１：53+22+34-(43+2*8)=3
    • 案２：43+42+44-(13+4*8)=1
    • 案３：23+22+54-(53+1*8)=7
    • 案４：43+52+24-(13+5*8)=-13

オペレータの必要人数

オペレータの必要人数

  • シフト勤務条件

    • サービス
      24時間365日
    • 勤務
      週休2日(5/7)
    • シフト
      • 3シフト（８時間 / 人）
      • 各シフトで２人以上

  • 計算

    • シフト
      3 * 2 = 6人
    • 勤務
      6 / (5/7) = 42 / 5 = 8.4人 = 9人

バックアップに必要な磁気テープ数

  • 要件

    • バックアップ
      • 月初にフルバックアップ、媒体は１本必要。
      • 翌月まで、差分バックアップ、媒体は１本 / 月必要。
    • 復元
      • 6か月前の同一日までのデータを復元
      • 同一の月末日（29 - 31）が無い場合、月末日の状態に復元
      • 例えば、10/31の場合、4/30 - 10/31の指定日のデータを復元可能。

  • 計算

    • 6か月分ではなくて7か月分を保持
    • 7 * (1 + 1) = 14

移行メモ

  • 「システム改善案の評価」のリスク側の評価項目は、 元 Wiki でも 2 行とも「作業コスト削減」となっており原文ママ （2 行目は別の項目の書き掛けと思われる）。
  • 元 Wiki の結合セル（> / ~）を含む表は、GitHub Wiki では再現できないため、 セルの内容を展開して平坦な表にした （「稼働品質率」の迷惑回数の 2 列、「システム改善案の評価」の区分列）。
  • 元 Wiki で見出しそのものが他ページへのリンクになっていた箇所 （「ISO/IEC 20000 及び ITIL」）は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
  • マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みの SQL Server の障害復旧 に張り替えた。
  • 未移行のページはファイル名を予約し、TODO.md に記録した。

Tags: 移行, 資格, 高度午前, サービス・マネジメント, ITIL, ISO/IEC 20000, データ管理者, DBA, UPS, ティア構成, TCO

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally