2011/07/22 #odstudy

@imksoo

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

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

1

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

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

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

About Me

2

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

http://twitter.com/imksoo

運用設計とは そもそも運用設計とは

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

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

運用業務設計 (ヒト・カネ) – 運用する上での前提事項

例) 運用業務対応時間の定義

– 運用する範囲や役割など 例) 運用業務範囲、運用役割分担、運用体制図

運用環境設計 (モノ)

– 運用する上で必要な環境の設計・整備 例) 監視環境、ジョブ管理環境、バックアップ環境

– 運用環境には、台帳や手順書なども… 例) IPアドレス・ホスト名一覧、パスワード一覧

システムバックアップ手順書

3

運用設計プロセス

4

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

[Service Strategy]の確認 [Service Design]の基本構想

運用環境(運用システム)の 基本設計

運用環境(運用システム)の 構築・単体テスト

運用業務・運用環境のテスト [Service Transition]へ

[Service Operation]へ

運用基本方針、運用業務項目/体制/範囲の設計と文書化

運用設計の範囲

Service Design

Service Transition

Service Operation

Service Strategy

ITILv3におけるプロセス

5

・Supplier Management ・Service Level management ・Service Catalog Management ・Availability Management ・Information Security Management

・Event Management ・Incident Management ・Problem Management

・Change Management ・Knowledge Management ・Release & Deployment Management ・Service Training & Validation ・Configuration Management System

・Service Portfolio Management ・IT Financial Management ・Demand Management

運用設計の範疇は？

会社や体制によりけりとは思いますが…

6

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

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

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

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

例) 社内ファイルサーバの運用設計

運用対象システムの前提 – よくあるWindowsファイルサーバの運用

サーバOS Windows Server 2008 R2

クライアントPC Windows 7, XPの混在環境

アカウント管理 Active Directory

ファイルサーバ MSFCによる冗長化

バックアップ BackupExecによる日次バックアップ

7

FC共有ストレージ

ファイル共有 クラスタ

社内ネットワーク

一般ユーザ システム管理者

運用要件の定義

8

運用要件の洗い出し – サービスレベル方針 (Service Level Management)

サービス稼働時間・復旧目標時間 (Service Level Mgmt.)

サービス可用性・性能管理 (Availability Mgmt.)

データセキュリティ・データ保全 (Information Security

Mgmt.)

– 運用体制 (Supplier Mgmt.)

– 運用業務 (Service Catalog Mgmt.)

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

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

9

ファイルサーバの例を取ると、 – ファイルサーバの必須稼働時間

一般ユーザが利用する時間＝平日日中時間帯 残業してる人のために、平日夜間はどう考える？ メンテナンス時間は休日日中時間で良いのか？休日出勤をどう扱うか？ 片系サーバ障害時の切り替え時間はどこまで許容されるか？

– ファイルサーバの中のデータ保全 無くなると会社の業務が止まる＝バックアップ環境にかけるコストと天秤 バックアップから戻す場合は何日・何時間前まで戻っても良いか？ バックアップからの戻し時間はどれだけ用意できるのか？ そもそもデータが無くなった場合にどの範囲で戻すのか？ 災害対策をどうするか？社屋に置いてる場合は他の紙書類同様に命運を同じにするか？

– 情報セキュリティ・内部統制 社員アカウント管理をどうするか？ フォルダ毎にアクセス範囲を管理するか？ 人が着任・離任する場合、人事部門とのやりとりは誰がやるか？

(そもそもシステム運用側にそういう情報を渡してくれるのか？前準備が必要であれば先に知りたいが、個人の地位に関する情報はなるべく知りたくない)

– 運用業務 ファイルサーバの管理範囲はどこまで？

Windows OS+MSFCだけ面倒見るのか、フォルダ追加・削除もやるのか、アカウント管理もやるのか？フォルダアクセス権管理は？棚卸は？

定常的な監視をどうするか？

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

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

運用要件の定義結果

10

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

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

総務部

人事部

情報システム課

社長

サーバ保守ベンダ

ストレージ保守ベンダ

ファイルサーバ担当

ADサーバ担当

ユーザアカウント 作成・削除の連絡

業務部門

保守連絡

システムアカウント情報の共有

フォルダ追加・アクセス権 付与申請など

運用要件の定義結果

11

運用範囲・運用分担

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

FC共有ストレージ

ファイル共有 クラスタ

社内ネットワーク

一般ユーザ

ADサーバ担当

ファイルサーバ担当

ネットワーク・設備担当

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

運用業務の設計

12

運用業務として代表的なもの – 全体管理業務

– サービスデスク・ヘルプデスク業務

– サービス監視・運転管理業務

– システム障害対応・障害管理業務

– システム資源管理業務

– システム性能管理業務

– システム変更管理業務

– システム構成管理業務

– セキュリティ管理業務

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

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

13

業務項目 目的・概要 具体例 関連資料

全体管理業務 運用業務全体の管理 稼働実績、月次運用レポート 運用連絡先・体制・フローの管理

月次報告書

サービスデスク・ ヘルプデスク業務

ユーザ部門への統一的な対応 フォルダアクセス権付与申請対応、組織改編対応

ユーザ向け申請様式

サービス監視・ 運転管理業務

一定のサービス提供と、サービスレベル低下の検知

システムログ監視 バックアップジョブ管理

監視環境・監視項目 障害時連絡フロー

システム障害対応・ 障害管理業務

速やかなサービスレベルの復旧と、予防対策

HW/SW障害対応、システム・データバックアップリカバリ対応、インシデント管理・傾向分析

障害時対応フロー

システム資源管理業務 サービスレベルの把握と、システムコンポーネントの効率的な活用

ディスク使用量管理、クォータ管理、増強計画管理

管理台帳

システム性能管理業務 CPU・メモリ使用率監視、月次性能トレンド分析

管理台帳

システム変更管理業務 システムに対する変更作業の管理と影響範囲の把握

フォルダアクセス権設定作業、月次パッチ適用作業

作業承認フロー 作業手順書

システム構成管理業務 システムコンポーネントの構成情報の管理・最新化

サーバ構成台帳管理 フォルダ構成・アクセス権台帳管理

管理台帳

セキュリティ管理業務 セキュリティ管理ポリシーへの準拠、違反の早期検知、セキュリティレベルの維持

アカウントパスワード管理 フォルダアクセス権管理 アクセスログ管理 セキュリティインシデント対応

管理台帳 情報セキュリティポリシー

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

運用環境の設計

14

運用業務を進めるために必要な運用環境を設計・選定する – システム化の前提＝人がやった場合の時間工数との比較

(明らかな場合も多いが迷った場合は単純に、製品ライセンス費用＋エンジニアリング費用と、運用期間×運用工数×単価の比較論になる)

– 代表的なシステム化の例

システム監視 – 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, グループポリシー

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

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

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

15

運用環境のシステム化 – システム監視

タスクスケジューラによる、Windowsイベントログ監視 検知時はメールサーバ経由で携帯電話に通知

– ジョブ管理 特に複雑なジョブはないため、ジョブ管理ソフトは不要とする 将来的にID管理システムと連携して、自動的に個人別のアカウントの作成を行う場合には再検討

– バックアップ環境 BackupExecを使い、日々テープバックアップを行う テープメディアの交換、外部待避はファイルサーバ担当が手動にて行う バックアップ失敗時は、Windowsイベントログ経由でメール通知

– 統合認証・アカウント管理 Active Directoryを用いて、ユーザアカウントの管理を行う(人事部にて対応) 組織グループアカウントの追加・削除は手動にて行う (ADサーバ担当にて実施) フォルダへのアクセス権付与は、対象ユーザアカウント・組織グループアカウント作成後に、ファイルサー

バ運用担当が実施する

– ログ管理・集約・セキュリティ管理 Windows監査ログ・アクセスログは、定期的にタスクスケジューラからエクスポートする

運用環境の定型化 – 運用手順書の整備

各種運用作業手順は事前に運用手順書として整備を行う

– 運用管理台帳・管理ドキュメントの整備

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

運用環境構築

16

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

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

運用テスト・引き継ぎ

17

運用業務設計～運用環境構築にて整備した、運用システム・運用手順書、管理ドキュメント類の総合テスト

基本的にはすべての業務をテストケースとして洗い出し、実施することが望ましい

もし運用設計者と運用業務担当者が別になる場合は、このときに合わせて引き継ぎ・教育を行いたい (本番化すると練習できないものはこのときに実績を作っておきたい)

＜利用するマテリアル＞

– 運用テストケース表

– 運用テストスケジュール

– 運用引き継ぎ項目

– その他、運用設計書・運用手順書・運用管理ドキュメントすべて

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

本番運用へ

18

運用要件定義 運用業務設計 運用環境設計 運用環境構築 運用テスト・引

き継ぎ 本番運用

Thank you!!

Fin.