20110722 #odstudy 1回目発表資料 (運用設計ってこんなこと？)

運用設計ってこんなこと？

2011/07/22 #odstudy
@imksoo

「ガン○ムとかま○☆マギとかのヲタ知識をひけらかして盛り上がっちゃ
うのがイタい」（30代・業務系エンジニア）

「全ての障害を、発生する前に消し去りたい。
全てのシステムの、過去と未来の全ての
障害をこの手で」( ･`ω･´)

すみません、以降まじめにやります。

出典: [女性が参加しやすいITイベントの作り方 1/2] わたしたちが勉強会に行かない7つの理由
http://engineer.typemag.jp/entra/2011/07/-it6.php

1

About Me
@imksoo / Kirino Minato
とある基盤の技術者(エンジニア)
時々基盤構築、時々基盤運用、時々運用設計
とりあえずMicrosoft/EMC/HPサーバと声優好きなおたく
※ここでの発言は個人の見解であり、所属する会社・組織の公式な(ry
http://twitter.com/imksoo

2

運用設計とは
 そもそも運用設計とは
– おおざっぱに言えば、
運用に必要なヒト・モノ・カネ(=時間)の事前整理

– 運用設計しておくことで運用業務を定型化・平準化するのが目的

 運用業務設計 (ヒト・カネ)
– 運用する上での前提事項
 例) 運用業務対応時間の定義
– 運用する範囲や役割など
 例) 運用業務範囲、運用役割分担、運用体制図

 運用環境設計 (モノ)
– 運用する上で必要な環境の設計・整備
 例) 監視環境、ジョブ管理環境、バックアップ環境
– 運用環境には、台帳や手順書なども…
 例) IPアドレス・ホスト名一覧、パスワード一覧
システムバックアップ手順書

3

運用設計プロセス
[Service Strategy]の確認
[Service Design]の基本構想運用設計の範囲
運用基本方針、運用業務項目
/体制/範囲の設計と文書化
運用環境(運用システム)の
基本設計
運用環境(運用システム)の
構築・単体テスト
運用業務・運用環境のテスト
[Service Transition]へ

運用テスト・引
運用要件定義運用業務設計運用環境設計運用環境構築本番運用
き継ぎ

[Service Operation]へ
4

ITILv3におけるプロセス
・Supplier Management
・Service Level management
・Service Catalog Management Service
・Availability Management Design
・Information Security Management
・Service Portfolio Management
・IT Financial Management
・Demand Management
Service
Strategy

Service Service
Operation Transition

・Event Management
・Incident Management ・Change Management
・Problem Management ・Knowledge Management
・Release & Deployment Management
・Service Training & Validation
・Configuration Management System
5

運用設計の範疇は？
 会社や体制によりけりとは思いますが…

顧客側要件・ポリシー
＝運用前提

運用受託側にて定義
＝狭義の運用設計

運用設計と運用業務の狭間
＝運用受入

運用専門部隊による
＝運用業務
6

例) 社内ファイルサーバの運用設計
 運用対象システムの前提
– よくあるWindowsファイルサーバの運用
 サーバOS Windows Server 2008 R2
 クライアントPC Windows 7, XPの混在環境
 アカウント管理 Active Directory
 ファイルサーバ MSFCによる冗長化
 バックアップ BackupExecによる日次バックアップ
社内ネットワーク

ファイル共有
クラスタ

システム管理者
一般ユーザ
FC共有ストレージ

7

運用要件の定義
き継ぎ

 運用要件の洗い出し
– サービスレベル方針 (Service Level Management)
 サービス稼働時間・復旧目標時間 (Service Level Mgmt.)
 サービス可用性・性能管理 (Availability Mgmt.)
 データセキュリティ・データ保全 (Information Security
Mgmt.)

– 運用体制 (Supplier Mgmt.)

– 運用業務 (Service Catalog Mgmt.)

8

運用要件の定義方法 … ファイルサーバの場合
き継ぎ

 ファイルサーバの例を取ると、
– ファイルサーバの必須稼働時間
 一般ユーザが利用する時間＝平日日中時間帯
 残業してる人のために、平日夜間はどう考える？
 メンテナンス時間は休日日中時間で良いのか？休日出勤をどう扱うか？
 片系サーバ障害時の切り替え時間はどこまで許容されるか？
– ファイルサーバの中のデータ保全
 無くなると会社の業務が止まる＝バックアップ環境にかけるコストと天秤
 バックアップから戻す場合は何日・何時間前まで戻っても良いか？
 バックアップからの戻し時間はどれだけ用意できるのか？
 そもそもデータが無くなった場合にどの範囲で戻すのか？
 災害対策をどうするか？社屋に置いてる場合は他の紙書類同様に命運を同じにするか？
– 情報セキュリティ・内部統制
 社員アカウント管理をどうするか？
 フォルダ毎にアクセス範囲を管理するか？
 人が着任・離任する場合、人事部門とのやりとりは誰がやるか？
(そもそもシステム運用側にそういう情報を渡してくれるのか？前準備が必要であれば先に知りたいが、個人の地位に関する情報
はなるべく知りたくない)
– 運用業務
 ファイルサーバの管理範囲はどこまで？
Windows OS+MSFCだけ面倒見るのか、フォルダ追加・削除もやるのか、アカウント管理もやるのか？フォルダアクセス権管理
は？棚卸は？
 定常的な監視をどうするか？

– 業務体制
 社内ファイルサーバの主管は誰か？総務部？情報システム部？人事部？各業務部門？
 一般ユーザの問い合わせ対応を誰がやるか？
 サービスデスク・ヘルプデスク機能を誰が担当するのか？

9

運用要件の定義結果
き継ぎ

 運用体制
– 運用体制図・運用連絡フロー
社長

総務部

ユーザアカウント情報システム課
作成・削除の連絡

ADサーバ担当
システムアカウント情報の共有
ファイルサーバ担当
保守連絡
人事部サーバ保守ベンダ
フォルダ追加・アクセス権ストレージ保守ベンダ
付与申請など
業務部門
10

運用要件の定義結果
き継ぎ

 運用範囲・運用分担
社内ネットワークネットワーク・設備担当

ADサーバ担当ファイル共有
クラスタ

ファイルサーバ担当
＜AD上のアカウント＞
・サーバOS・システムサービスアカウント
＝ADサーバ担当による管理
・ユーザアカウント
＝人事部が直接作成・削除 FC共有ストレージ
一般ユーザ
＜ファイルサーバ上のローカルアカウント＞
・ローカルアカウント
＝ファイルサーバ担当が管理 11

運用業務の設計
き継ぎ

 運用業務として代表的なもの
– 全体管理業務
– サービスデスク・ヘルプデスク業務
– サービス監視・運転管理業務
– システム障害対応・障害管理業務
– システム資源管理業務
– システム性能管理業務
– システム変更管理業務
– システム構成管理業務
– セキュリティ管理業務

12

運用業務設計 … ファイルサーバの場合
き継ぎ

業務項目目的・概要具体例関連資料
全体管理業務運用業務全体の管理稼働実績、月次運用レポート月次報告書
運用連絡先・体制・フローの管理
サービスデスク・ユーザ部門への統一的な対応フォルダアクセス権付与申請対応、組ユーザ向け申請様式
ヘルプデスク業務織改編対応
サービス監視・一定のサービス提供と、サービスシステムログ監視監視環境・監視項目
運転管理業務レベル低下の検知バックアップジョブ管理障害時連絡フロー
システム障害対応・速やかなサービスレベルの復旧と、 HW/SW障害対応、システム・データ障害時対応フロー
障害管理業務予防対策バックアップリカバリ対応、インシデ
ント管理・傾向分析
システム資源管理業務サービスレベルの把握と、システディスク使用量管理、クォータ管理、管理台帳
ムコンポーネントの効率的な活用増強計画管理
システム性能管理業務 CPU・メモリ使用率監視、月次性能ト管理台帳
レンド分析
システム変更管理業務システムに対する変更作業の管理フォルダアクセス権設定作業、月次作業承認フロー
と影響範囲の把握パッチ適用作業作業手順書
システム構成管理業務システムコンポーネントの構成情サーバ構成台帳管理管理台帳
報の管理・最新化フォルダ構成・アクセス権台帳管理
セキュリティ管理業務セキュリティ管理ポリシーへの準アカウントパスワード管理管理台帳
拠、違反の早期検知、セキュリフォルダアクセス権管理情報セキュリティポ
ティレベルの維持アクセスログ管理リシー
セキュリティインシデント対応
13

運用環境の設計
き継ぎ

 運用業務を進めるために必要な運用環境を設計・選定する
– システム化の前提＝人がやった場合の時間工数との比較
(明らかな場合も多いが迷った場合は単純に、製品ライセンス費用＋エンジニアリング費用
と、運用期間×運用工数×単価の比較論になる)

– 代表的なシステム化の例
 システム監視
– JP1/IM, Tivoli Enterprise Console, SystemWalker Operation Manager, Senju Enterprise Manager, SCOM
 ジョブ管理
– JP1/AJS3, Tivoli Workload Scheduler, Senju Operation Conductor, タスクスケジューラ
 バックアップ環境
– BackupExec, NetBackup, ARCserve, Networker
 統合認証・自動アカウント管理
– Active Directory, LDAP, ACTCenter
 ログ管理・集約・セキュリティ管理
– ArcSight, ESS-REC, Logstorage
 構成配布
– JP1/NETM/DM, System Center Operations Manager, グループポリシー

– 運用環境の定型化
 運用手順書の整備
 運用管理台帳・管理ドキュメントの整備

14

運用環境の設計 … ファイルサーバの場合
き継ぎ

 運用環境のシステム化
– システム監視
 タスクスケジューラによる、Windowsイベントログ監視
 検知時はメールサーバ経由で携帯電話に通知
– ジョブ管理
 特に複雑なジョブはないため、ジョブ管理ソフトは不要とする
 将来的にID管理システムと連携して、自動的に個人別のアカウントの作成を行う場合には再検討
– バックアップ環境
 BackupExecを使い、日々テープバックアップを行う
 テープメディアの交換、外部待避はファイルサーバ担当が手動にて行う
 バックアップ失敗時は、Windowsイベントログ経由でメール通知
– 統合認証・アカウント管理
 Active Directoryを用いて、ユーザアカウントの管理を行う(人事部にて対応)
 組織グループアカウントの追加・削除は手動にて行う (ADサーバ担当にて実施)
 フォルダへのアクセス権付与は、対象ユーザアカウント・組織グループアカウント作成後に、ファイルサー
バ運用担当が実施する
– ログ管理・集約・セキュリティ管理
 Windows監査ログ・アクセスログは、定期的にタスクスケジューラからエクスポートする

 運用環境の定型化
– 運用手順書の整備
 各種運用作業手順は事前に運用手順書として整備を行う
– 運用管理台帳・管理ドキュメントの整備

15

運用環境構築
き継ぎ

 システム基盤構築とほぼ同じですので省略

16

運用テスト・引き継ぎ
き継ぎ

 運用業務設計～運用環境構築にて整備した、運用システム・運用手順書、管理ドキュメン
ト類の総合テスト
 基本的にはすべての業務をテストケースとして洗い出し、実施することが望ましい
 もし運用設計者と運用業務担当者が別になる場合は、このときに合わせて引き継ぎ・教育
を行いたい
(本番化すると練習できないものはこのときに実績を作っておきたい)

＜利用するマテリアル＞
– 運用テストケース表
– 運用テストスケジュール
– 運用引き継ぎ項目
– その他、運用設計書・運用手順書・運用管理ドキュメントすべて

17

本番運用へ
き継ぎ

18

20110722 #odstudy 1回目発表資料 (運用設計ってこんなこと？)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

Empfohlen

Empfohlen (20)