================================================================ Operation Improvement ================================================================ ---------------------------------------------------------------- 運用改善の基本アプローチ ---------------------------------------------------------------- See(Before) - 問題の認識 - 運用あるあるシート - 現状認識の抽出/共有 - 例えば、3大課題は何か、その悪影響は何か、望ましい状態は何か、望ましい状態実現への障碍は何か、中間目標は何にして行動すればいいか - 現実 / 要望(望ましい状態) / 行動 - 調査分析 - データの裏付け、科学的/客観的な根拠。 - 効果測定用のデータを事前に収集 Plan - 解決策の立案 (Design) - 分析、再設計 (工程分析、工程設計) - 実現案の作成 - KPIの決定 - ロードマップ/タスクシート Do - 解決策の実施 - 変更の実施 (Transition / リリースマネジメント) - 変化の測定 See(After) - 効果測定 - 変化の分析 - KPIによる評価 - 運用あるあるシートの更新/変化点の抽出 - 次の "問題の認識"(See Before) へ ---------------------------------------------------------------- 運用改善のゴール像 ---------------------------------------------------------------- 1. 負荷を下げる (ゴール2) 2. 属人性を下げる (ゴール1) 3. 付加価値を上げる (ゴール3) スタートから最終ゴール(逆順) ******************************** ゴール3. 付加価値を上げる - Step3. 質、量、スピードで差別化を図る (どうやって??) - Step2. リソースをひねり出す / 即応性を上げる - Step1. 負荷を下げる(ゴール2) ゴール2. 負荷を下げる (例: トラブルをなくす) - Step3 (Do). ボトルネックを消す - Step2 (Plan). 問題点解消対象の選択 & 解消実現案の作成 - Step1 (See). サービス/システムの概念、構成を知る(ゴール1) & 問題点の理解と整理 ゴール1. 属人性を下げる (例: サービス/システムに関する脳内ダンプを行なう) - Step3. サービスとリソースのリレーション(ワークフロー)を知る [インターメディエイト] - Step2. リソース(サービスの原単位)を知る [バックエンド] - Step1. サービス(ユーザ視点の全体像)を知る [フロントエンド] スタート. ---------------------------------------------------------------- サービス運用の構成概念 ---------------------------------------------------------------- 属人性を下げるには: - その人の脳内をダンプする必要がある。 - ダンプ用のモデルスキームが必要。 サービス運用のモデルスキーム - フロントエンド/インターメディエイト/バックエンドの3層構造 .. blockdiag:: :desctable: blockdiag { user -> front-end front-end <-> intermediate-auto; front-end <-> intermediate-hand; intermediate-auto <-> back-end-outer; intermediate-auto <-> back-end-inner; intermediate-hand <-> back-end-outer; intermediate-hand <-> back-end-inner; user [shape = "actor", label="User"]; front-end [shape = "box", stacked, label="Services"]; intermediate-auto [shape = "roundedbox", stacked, label="Automation", width="200"]; intermediate-hand [shape = "roundedbox", stacked, label="Operation", width="200"]; back-end-inner [shape = "box", stacked, label="Inner Object"]; back-end-outer [shape = "box", stacked, label="Outer Object"]; group { label = "Services (Front End)" color = "blue" front-end; } group { label = "Work flows (Intermediate)" color = "green" intermediate-auto; intermediate-hand; } group { label = "Resoueces (Back End)" color = "orange" back-end-inner; back-end-outer; } } バックエンド (リソース) サービス提供の原単位 - 内部リソース: 自社リソース,自部署(チーム)の提供するリソース (Controlable) - 外部リソース: 他社、他部署、クラウドサービスやプラットフォームの提供するリソース (Uncontrolable) インターメディエイト (ワークフロー) リソースのメソッド/データを組み合わせてサービスの構成要素を作るもの。 (ワークフロー自身が中間プロパティや組み合わせメソッドを持つこともある) - 自動ワークフロー (サービス関数/サービス要素) - リソースを組み合わせてサービスに必要なメソッドを自動実行(データを出力)する。 - 手動ワークフロー (オペレーション) - リソースを組み合わせてサービスに必要なメソッドを手動実行(判断を伴う)する。 フロントエンド (サービス) ユーザに対して、データ(メソッドによる処理含む)を提供する。 複数のワークフローを組み合わせて実現する。 .. note:: - デリバリを伴うサービス運用(L4:サーバから上)はたぶん上記で説明可能。 - オブジェクトによるサービス(メソッド/プロパティ)の提供 - L3から下の運用は、コネクション(空間)の提供なので、デリバリを前提とした説明は難しいかも。 ---------------------------------------------------------------- (共通)基本概念 (5W1H / 6W2H) ---------------------------------------------------------------- What: 対象(サービス/ワークフロー/リソース)のスコープ Why: 対象(サービス/ワークフロー/リソース)の利用目的 Who: 対象(サービス/ワークフロー/リソース)の関係者(直接ステークホルダー) When: 対象(サービス/ワークフロー/リソース)の利用場面 Where: 対象(サービス/ワークフロー/リソース)の接点/窓口(インタフェース) How: 対象(サービス/ワークフロー/リソース)の利用方法(呼び出し) (オプショナル) Whom: 対象(サービス/ワークフロー/リソース)の二次関係者(間接ステークホルダー) (オプショナル) HowMuch: 対象(サービス/ワークフロー/リソース)のコスト/収益構造 ---------------------------------------------------------------- フロントエンド(サービス) の論理構成 ---------------------------------------------------------------- - サービス関連の用語/概念 (なるべくグローバル用語 + 独自サービス用語) - サービスカタログ .. list-table:: サービスカタログ :widths: 15 20 20 20 25 :header-rows: 1 * - サービス名 - 提供メソッド - 提供プロパティ - 5W1H - 関連するワークフロー * - - - - - ---------------------------------------------------------------- intermediate(ワークフロー) の論理構成 ---------------------------------------------------------------- - ワークフロー関連の用語/概念 (ローカルにならざるを得ない) - ワークフローカタログ - 自動ワークフロー (サービス関数 例: バッチ処理) - ワークフロー処理カタログ (自動処理一覧) - 手動ワークフロー (オペレーション 例: 判断が必要な作業) - ワークフロー作業カタログ (手動作業一覧) .. list-table:: ワークフローカタログ :widths: 15 10 45 20 20 :header-rows: 1 * - ワークフロー名 - 5W1H - ワークフロー構成(リレーション)図 - 関係メソッド群 - 関係プロパティ群 * - - - (いわゆるサービス構成図) - 組み合わせメソッド / リソースのメソッド - 中間プロパティ / リソースからのデータ - リレーション(関わり方) - システム間連携(設計) - システム間トラブル - システム間ボトルネック/キャパシティ ---------------------------------------------------------------- バックエンド(リソース) の論理構成情報 ---------------------------------------------------------------- - 論理構成関連の用語/概念 (なるべくグローバル用語で) - 論理リソースカタログ .. list-table:: 論理リソースカタログ :widths: 15 15 30 20 20 :header-rows: 1 * - リソース名(識別子) - 5W1H (6W2H) - 論理リソースの種別 - メソッド(処理/挙動) - プロパティ (データ/ステータス) * - - - | - プラットフォーム | - ノード | - Web | - DB | - バッチ | - ファイル共有 | - アプリケーション - - ---------------------------------------------------------------- バックエンド(リソース) の物理構成情報 ---------------------------------------------------------------- - 物理構成関連の用語/概念 (なるべくグローバル用語で) - 物理リソースカタログ .. list-table:: 物理リソースカタログ :widths: 15 10 20 25 30 :header-rows: 1 * - リソース名(識別子) - 5W1H - ノード(ネットワーク機器/サーバ)のスペック - ネットワークセグメント - 物理位置 * - - - - - | - ロケーション (データセンター/拠点) | - ラック収容位置 | - ケーブル終端接続点 - ネットワーク物理構成(L1-3) .. note:: - ラック収容位置、ケーブル終端接続点、ネットワーク物理構成は、コロケーションまで管理する場合以外は不要かも。 - ノードスペックはキャパシティプランニング上必要。 - ネットワークセグメント/ロケーションは、ネットワーク/上位障害の場合に、影響範囲を特定するのに必要。 - ネットワークセグメントは、マルチホーミングの場合はASも見た方がよさそう。 ---------------------------------------------------------------- 付属資料 ---------------------------------------------------------------- - 運用あるあるシート (Before / After) - 現象 (表層) - 中間要因 (表層 - 中間層) - 3大要因 (深層: 高負荷/属人的/費用対効果が見えない) - 理解度チェックシート (Before / After) - サービス(フロントエンド)理解度チェックシート - ワークフロー(インターメディエイト)理解度チェックシート - リソース(バックエンド)理解度チェックシート - 改善ロードマップ/改善タスク一覧 - 成果物一覧 - 効果測定シート (KPI)