Operation Architecture¶
「運用」の定義、「運用」の目的¶
「運用」の定義 (仮説)¶
大辞泉:
そのもののもつ機能を生かして用いること。活用。
- 運用
- 運用組織のリソースを活用し、 対価や評価を得ることを目的に、 外部に対して、継続的に何らかのサービスを提供し続けること、を言う。
Note
"運用" == "サービスデリバリ"
運用業務の目的 (仮説)¶
仮に「運用」=「サービスデリバリ」と捉えた場合、「運用の目的」は、主要なステークスホルダーに期待される品質(Q)、リソース(C)、期限(D)で、サービスを提供し続け、適切な利得や評価を得ること、と考えられる。
視点1: 運用プロセスをQCDで捉える¶
運用プロセス (サービス工程)の性質¶
プロセス == 工程¶
プロセスとは「工程」である。
運用作業を「工程」として捉える。
プログラム開発と運用の工程は似ている。
各工程を「パイプでつないでいる」と考えれば極めて「UNIX的」と言える。
視点2: 運用プロセスのOOA的性質(外観) (仮説)¶
運用プロセス (サービス工程)の要素¶
サービス運用全体の流れ¶
「運用」=「サービスデリバリ」と捉え、全ての業務上のやりとりをリクエストに対するデリバリであると考えた場合、運用業務プロセスは inbound -> 内部処理 -> outbound の繰り返し、であると言うことができる。
運用組織の基本機能¶
どんな運用組織でも、最低限、inbound/outbound/作業チケットの3機能をもっている。
Note
- inbound/outbound: インタフェース
- work ticket: 状態管理(queue)
サービス運用における参照、支援¶
各組織では作業チケット処理時に各種作業支援(ツール)、リファレンスを利用している。
Note
- 作業支援: ロジック(method)
- リファレンス: 構造化データ(property)
視点3: 運用プロセスのOOA的要素 (内部) (仮説)¶
まとめ: 運用プロセス(サービス工程)¶
工程設計¶
- 設計/投資(C)/成果物(Q/D)の関係の方程式化
- 投資 (ex. ドキュメント/教育/ツール)
- 原価 (ex. 人件費)
- 利益率 (対売上)
- 変数
- 手順
- 材料
- 設備
- 時間
- 人員
- 設計/集計項目
- 作業名
- 作業順
- 単位作業時間
- 原単位
- 件数
- 総作業時間
- 作業価値分類 (有価値/無価値必要/待機)
- 設計手順
- 現状調査
- 仮標準 (やる人が書く)
- 標準作業
- Why
- 例外処理 (運用でカバーの範囲/対応)
- 見直し
- 固定標準
- 水平展開/定期的な見直し
- 標準作業時間のポイント
- ムリ(高負荷)
- ムダ(ヒマ)
- ムラ(高負荷&ヒマ)
- 要点
- つなぎ目(人と人、ツールとツール)に注目すべし。
運用アーキテクチャへの展望¶
(記述予定)