2014-01-28 operation in the future

Operation Lab運用設計ラボ

これからのシステム運用

運用設計ラボ合同会社シニアアーキテクト波田野裕一

2014-01-28

運用アーキテクチャの時代へ


自己紹介

✦ Sphinx Users-jp 会長 (2014年度) ✦ 日本UNIXユーザ会(jus) 幹事 (副会長) ✦ IPv6普及・高度化推進協議会 (サブWG 部会長共同) ✦ Internet Week プログラム委員 ✦ Internet Conference 実行委員 ✦ BSD / OSS / JANOG

波田野裕一 (HATANO Hirokazu) 運用設計ラボ合同会社シニアアーキテクト

‣ ADSLキャリアで開通業務、ATM運用、ISP運用および障害監視を担当

‣ SIerで公共系サービスのサーバ保守

‣ ASP でミドルウェアおよび障害監視システムの設計構築運用

‣ 運用設計ラボを設立。主にドキュメンテーション活動。

業務歴

参加コミュニティ


参考:「運用研究」活動の概要

‣ サービスの安定社会基盤に相応しい安定運用。

‣ 業務負荷の平準化個々人ががんばりすぎなくてもうまく業務が回る運用現場。

‣ 運用に対する評価の適正化適正な利潤を生む現場と、適切に評価される要員。

「安定した運用」の実現

「楽な運用」の実現

「稼ぐ運用」の実現

従来、現場ごとの個別事情によりやり方が異なるため、標準化が難しいと言われてきた「運用」

モデル化することで「実践的な運用設計のための方法論」を確立

「実践的な運用設計」への取り組みを促進し、 3つの実現を目指す

出展: CTC Academic User Association 第9回研究会 2010 「サービス運用の現状と課題費用対効果との闘い」

2014-01-28


agenda

1. システム運用の課題

2. 今後どう変えていくか

3. 運用のアーキテクチャ

2014-01-28



2014-01-28


運用現場の諸問題

1.高負荷

2.属人的

3.見えぬ費用対効果

ブラックボックス化

低付加価値化

業務が複雑化

「費用」は一定で「効果」は経年劣化する「費用対効果」は勝手に低減していく

現場では制御不能状態

2014-01-28



運用でカバー

制御不能状態を加速する

2014-01-28



運用研究から見えてきたもの

テキストを入力してください

1. 高負荷

2. 属人的

3. 見えぬ費用対効果

運用現場の現実

ブラックボックス化

低付加価値化

業務が複雑化

1. 業務の複雑化を許さない仕組み作り

2. 業務のブラックボックス化を許さない仕組み作り

3. 業務価値の陳腐化を許さない仕組み作り

運用設計の目的運用現場の理想

‣ サービスの安定社会基盤に相応しい安定運用。

‣ 業務負荷の平準化うまく業務が回る運用現場。

‣ 運用に対する評価の適正化適正な利潤を生む現場と、適切に評価される要員。

1. 「運用」への期待の明確化

3. 期待に対する消費リソースの測定化

2.「運用設計」の確立

常にシンプル

常に見える

常に価値を生む

運用設計の本質、目的、その現実

出典: Think IT 「現場視点からの運用方法論第2回自分たちの「運用」を知る - 運用設計の本質」(2010-12)

2014-01-28



2. 今後どう変えていくか高負荷 / 属人的 / 費用対効果

2014-01-28


重要なキーワード

「問題を根性で解決するのは馬鹿です。問題をエンジニアリングで解決するのが

エンジニアの仕事です」

構造化ここでは「エンジニアリング(工学)の実践」に近い意味で使います。工学では何らかの構造物・構造体を作ることが不可避なためです。

http://d.hatena.ne.jp/Yoshiori/20120217/1329491437

2014-01-28



2-1. 「高負荷」をどう変えていくか常にシンプル

2014-01-28



「(質的な)高負荷」からの脱却

1.業務の構造化 ‣ 時系列構造化

‣ 機能別構造化

2.業務の分散化、多重化、標準化 ‣ その結果としての自動化 (自動化は目的ではない)

常にシンプル

2014-01-28



サービス運用全体の流れ顧客・外部サービス

inbound チケット outbound の繰り返し

outboundinbound

outboundinbound

外部支援組織inbound

inbound

運用メンバーoutboundinbound

内部協調/支援組織inbound

outboundリクエストデリバリ

デリバリ

デリバリ

デリバリ

リクエスト

リクエストリクエスト

運用現場

窓口フロントエンド

バックエンド

outbound

outbound

出典: 経営情報学会 2010年春季全国研究発表大会「運用業務プロセスのモデル化」

2014-01-28

2. 今後どう変えていくか常にシンプル


業務の構造化 (時系列)

サービス工程

Step1開始

サービス工程

Step2

サービス工程

Step3

サービス工程

Step4

サービス工程

Step5 提供

前処理inbound 本作業後処理 outbound

基本設計

Step1開始

機能設計

Step2

詳細設計

Step3

コーディング

Step4

テスト

Step5 完成

「前の工程の成果」を「後の工程が加工する」という点において運用の工程はプログラム開発と似ている

一つの事を上手にやるプロダクト群 / 疎結合

inbound outbound

2014-01-28



時系列: 業務の分散化• 大きな業務粒度を細分化する。

• 依存関係の整理。ボトルネックの洗い出し

運用プロセス

(サービス工程)工程

A

工程B

工程C

ボトルネック

inbound inboundoutbound outbound

2014-01-28



時系列: 業務の多重化• 細分化した業務を多重化して実行する。

• リードタイムの短縮。実行要件やインタフェースの明確化。

工程A

工程B

工程C

ボトルネック

inbound outbound

工程A

工程 B-1

工程C

ボトルネック

inbound outbound

工程B-2

短縮

2014-01-28



時系列: 業務の標準化• 多重化された業務を標準化する。

• コードへの落し込み可能化。標準工数の確立。

共通 inbound

工程

独自工程B-1 共通

outbound

工程

inbound outbound

標準前処理工程

標準後処理工程

独自本処理工程R-1

独自工程 A-1

独自本処理工程R-2

標準本処理工程

2014-01-28



時系列: 業務の自動化• 標準化された業務を自動化する。

• 自動化のbefore/after で自動化自体とその後の改善効果の測定が可能に。

標準工程 (コード)input output

類似の機能を集約していく (機能別構造化へ)

2014-01-28



業務の構造化 (機能別)業務機能ユニットマップ

作業チケット

サービスリファレンス

コスト算定/請求計画イベント作業ロジック

問題チケット

顧客サービス支援協調組織

inbound outboundモニター

作業インタフェース

出展: Internet Week 2009 「運用方法論～運用現場の現状分析そして運用設計へ」

一つの事を上手にやるプロダクト群 / 疎結合

2014-01-28



1.設計: 業務の構造化 ‣ 時系列構造化

‣ 機能別構造化

2.実装: 業務の分散化、多重化、標準化 ‣ その結果としての自動化 (自動化は目的ではない)

「(質的な)高負荷」からの脱却 (まとめ)

2014-01-28



2-2. 「属人的」をどう変えていくか常に見える

2014-01-28



「属人的」からの脱却

1. 専門領域と非属人領域

2. ドキュメント化による業務の客観化

3. ドキュメント構造化による価値の明確化

常に見える

2014-01-28



専門領域と非属人領域

常に見える

定常運用

非定常運用

情報管理

要員管理

予算管理

属人作業緊急作業

申請作業定時作業

実働業務業務コア

「ブラック・ボックス化が許されない」領域 365日24時間稼動が求められる業務 (事業継続性)

出典: Think IT 「現場視点からの運用方法論第3回明日の運用現場のために」(2010-12)

担当者の「ノウハウや個性」が期待される領域

定時作業申請作業緊急作業

属人作業

「属人回避すべき範囲」を明確にする必要がある。なんでもかんでも「属人的」と言うのは不適切

2014-01-28

2. 今後どう変えていくか常に見える


ドキュメント化による業務の客観化運用ドキュメントの必要性

脱属人化のために必要

客観化のために必要

整理のために必要「自分達のやっていることを知る&改善するために」

「自分達のやっていることの説明&(自己・他者)評価のために」

「自分達のやっていることの安定化&永続化のために」

出典: Internet Week 2011 「運用ドキュメント2011 ～手軽にスピーディに継続的に保守するためのツール入門」 Part-1

2014-01-28



ドキュメント構造化による価値の明確化

時間軸 activity活動状態

変化前変化後

変化

Future Status 将来の状態ドキュメント

Past Activity 活動履歴

Change 変化差分ドキュメント

Future Activity! 活動予定

費用性情報

収益性情報Past Status

過去の状態ドキュメント

「状態」と「変化」と「活動」に関するドキュメントを分離する意識が必要。

資産性情報

出典: Internet Week 2011 「運用ドキュメント2011 ～手軽にスピーディに継続的に保守するためのツール入門」 Part-1

2014-01-28



2-3. 費用対効果をどう変えていくか常に価値を生む

2014-01-28



費用対効果の見える化

1.カネの話

2.モノの話

3.ヒトの話

常に価値を生む

2014-01-28



運用会計論 (カネの話)

会計上、運用は「コストセンター」

製造業: 製造工程は売上原価(製造直接費)であり、利益の源泉と認識される。

サービス業: 運用工程は販管費(製造間接費)であり、コストと認識される。

加工出荷原材料製品

集約提供サービスリソース

サービス運用

売上原価

販管費

財務会計上の論点

出典: 経営情報学会 2010年秋季全国大会「運用研究部会サービス運用における「費用対効果」に関する考察」

2014-01-28

2. 今後どう変えていくか常に価値を生む


運用品質論 (モノの話)

品質の定義、基準が曖昧

サービスリソース

加工出荷原材料

集約サービス運用

製品

提供

商品

満足

目に見えない

目に見える

品質上の論点

出典: 経営情報学会 2010年秋季全国大会「運用研究部会サービス運用における「費用対効果」に関する考察」

2014-01-28



運用組織論 (ヒトの話)二極化する運用現場

クラウドに吸い込まれる運用現場

尖ったモノを持つ「攻める」運用現場

変化に柔軟に対応高度な専門性短納期/スピード費用対効果が明確スケーラビリティスティッキー

一般的な専門性硬直的意思決定に時間どんぶり勘定高コスト体質非合理的

出展: CTC Academic User Association 第9回研究会 2010 「サービス運用の現状と課題費用対効果との闘い」

2014-01-28



今後どう変えていくか (まとめ)

構造化された業務の中で、課題をエンジニアリングを以って解決する

構造化エンジニアリング(工学)の実践

2014-01-28



3. 運用のアーキテクチャ運用業務構造化のための指針

2014-01-28


アーキテクチャとは‣ architecture とは、「構造、構成」を意味する英単語。

‣ 構造全体は、構造要素で構成される。

‣ 構造全体の振舞いは、構造要素の振舞いの総和で表現される。

2014-01-28



運用アーキテクチャに求められるもの

‣ 疎結合 (UNIXの哲学/カスタマイザブル) ‣ 一つの事を上手にやるプロダクト ‣ 新規追加の仕組み ‣ 他組織との相互接続。

‣ 永続的 (事業継続性/商用製品に非依存) ‣ 災害に強い。 ‣ ベンダーロックインされていない。 ‣ 設計自体が引き継ぎ可能。

‣ フレームワーク (科学的/エンジニアリング) ‣ 理論と実践。 ‣ 再現性(たいていの人が実践できること)の重視。 ‣ 反復性(定期的な棚卸しなど継続するための仕組み)の実現。

2014-01-28



まとめ

2014-01-28


運用の今後• 運用アーキテクチャ(業務の構造化)が必須に

• 業務の分散化、標準化、その結果としての自動化へ • ドキュメント価値の明確化 • カネ(管理会計)、モノ(品質基準)、ヒト(アジャイル組織設計)の構造化設計とその客観的評価による費用対効果の説明可能化

• 運用アーキテクトという職能の確立 • 幅広い知識と痛い目にあった経験が求められる。 • 経営知識を追加すれば独立してサービスはじめられるような人達である。

• 運用工学の登場 • サービス工学とも言われますが、この先50年以内には成立する、はず。

2014-01-28


http://www.operation-lab.co.jp/

http://www.operation-lab.co.jp/