2014年1月に、ある企業様向けに作成したプレゼン資料のダイジェスト版です。

1. Operation Lab
運用設計ラボ
これからのシステム運用
運用設計ラボ合同会社
シニアアーキテクト 波田野 裕一
2014-01-28
運用アーキテクチャの時代へ

2. Operation Lab
運用設計ラボ
自己紹介
✦ Sphinx Users-jp 会長 (2014年度)
✦ 日本UNIXユーザ会(jus) 幹事 (副会長)
✦ IPv6普及・高度化推進協議会 (サブWG 部会長 共同)
✦ Internet Week プログラム委員
✦ Internet Conference 実行委員
✦ BSD / OSS / JANOG
波田野 裕一 (HATANO Hirokazu)
運用設計ラボ合同会社 シニアアーキテクト
‣ ADSLキャリアで開通業務、ATM運用、ISP運用および障害監視を担当
‣ SIerで公共系サービスのサーバ保守
‣ ASP でミドルウェアおよび障害監視システムの設計構築運用
‣ 運用設計ラボを設立。主にドキュメンテーション活動。
業務歴
参加コミュニティ

3. Operation Lab
運用設計ラボ
参考:「運用研究」活動の概要
‣ サービスの安定
社会基盤に相応しい安定運用。
‣ 業務負荷の平準化
個々人ががんばりすぎなくてもうまく業務が回る運用現場。
‣ 運用に対する評価の適正化
適正な利潤を生む現場と、適切に評価される要員。
「安定した運用」の実現
「楽な運用」の実現
「稼ぐ運用」の実現
従来、現場ごとの個別事情によりやり方が異なるため、標準化が難しいと言われてきた「運用」
モデル化することで「実践的な運用設計のための方法論」を確立
「実践的な運用設計」への取り組みを促進し、 3つの実現を目指す
出展: CTC Academic User Association 第9回研究会 2010 「サービス運用の現状と課題 費用対効果との闘い」
2014-01-28

4. Operation Lab
運用設計ラボ
agenda
1. システム運用の課題
2. 今後どう変えていくか
3. 運用のアーキテクチャ
2014-01-28

5. Operation Lab
運用設計ラボ
1. システム運用の課題
2014-01-28

6. Operation Lab
運用設計ラボ
運用現場の諸問題
1.高負荷
2.属人的
3.見えぬ費用対効果
ブラックボックス化
低付加価値化
業務が複雑化
「費用」は一定で「効果」は経年劣化する
「費用対効果」は勝手に低減していく
現場では制御不能状態
2014-01-28
1. システム運用の課題

7. Operation Lab
運用設計ラボ
運用でカバー
制御不能状態を加速する
2014-01-28
1. システム運用の課題

8. Operation Lab
運用設計ラボ
運用研究から見えてきたもの
テキストを入力してください
1. 高負荷
2. 属人的
3. 見えぬ費用対効果
運用現場の現実
ブラックボックス化
低付加価値化
業務が複雑化
1. 業務の複雑化を許さない仕組み作り
2. 業務のブラックボックス化を許さない仕組み作り
3. 業務価値の陳腐化を許さない仕組み作り
運用設計の目的運用現場の理想
‣ サービスの安定
社会基盤に相応しい安定運用。
‣ 業務負荷の平準化
うまく業務が回る運用現場。
‣ 運用に対する評価の適正化
適正な利潤を生む現場と、適切に評価される要員。
1. 「運用」への期待の明確化
3. 期待に対する消費リソースの測定化
2.「運用設計」の確立
常にシンプル
常に見える
常に価値を生む
運用設計の本質、目的、その現実
出典: Think IT 「現場視点からの運用方法論 第2回 自分たちの「運用」を知る - 運用設計の本質」(2010-12)
2014-01-28
1. システム運用の課題

9. Operation Lab
運用設計ラボ
2. 今後どう変えていくか
高負荷 / 属人的 / 費用対効果
2014-01-28

10. Operation Lab
運用設計ラボ
重要なキーワード
「問題を根性で解決するのは馬鹿です。
問題をエンジニアリングで解決するのが
エンジニアの仕事です」
構造化ここでは「エンジニアリング(工学)の実践」に近い意味で使います。
工学では何らかの構造物・構造体を作ることが不可避なためです。
http://d.hatena.ne.jp/Yoshiori/20120217/1329491437
2014-01-28
2. 今後どう変えていくか

11. Operation Lab
運用設計ラボ
2-1. 「高負荷」をどう変えていくか
常にシンプル
2014-01-28
2. 今後どう変えていくか

12. Operation Lab
運用設計ラボ
「(質的な)高負荷」からの脱却
1.業務の構造化
‣ 時系列構造化
‣ 機能別構造化
2.業務の分散化、多重化、標準化
‣ その結果としての自動化 (自動化は目的ではない)
常にシンプル
2014-01-28
2. 今後どう変えていくか

13. Operation Lab
運用設計ラボ
サービス運用全体の流れ
顧客・外部サービス
inbound チケット outbound の繰り返し
outboundinbound
outboundinbound
外部支援組織
inbound
inbound
運用メンバー
outboundinbound
内部協調/支援組織
inbound
outbound
リクエストデリバリ
デリバリ
デリバリ
デリバリ
リクエスト
リクエストリクエスト
運用現場
窓口 フロントエンド
バックエンド
outbound
outbound
出典: 経営情報学会 2010年春季全国研究発表大会 「運用業務プロセスのモデル化」
2014-01-28
2. 今後どう変えていくか
常にシンプル

14. Operation Lab
運用設計ラボ
業務の構造化 (時系列)
サービス
工程
Step1
開
始
サービス
工程
Step2
サービス
工程
Step3
サービス
工程
Step4
サービス
工程
Step5
提
供
前処理inbound 本作業 後処理 outbound
基本
設計
Step1
開
始
機能
設計
Step2
詳細
設計
Step3
コーディング
Step4
テスト
Step5
完
成
「前の工程の成果」を「後の工程が加工する」という点において
運用の工程はプログラム開発と似ている
一つの事を上手にやるプロダクト群 / 疎結合
inbound outbound
2014-01-28
2. 今後どう変えていくか
常にシンプル

15. Operation Lab
運用設計ラボ
時系列: 業務の分散化
• 大きな業務粒度を細分化する。
• 依存関係の整理。ボトルネックの洗い出し
運用プロセス
(サービス工程)
工程
A
工程
B
工程
C
ボトルネック
inbound inboundoutbound outbound
2014-01-28
2. 今後どう変えていくか
常にシンプル

16. Operation Lab
運用設計ラボ
時系列: 業務の多重化
• 細分化した業務を多重化して実行する。
• リードタイムの短縮。実行要件やインタフェースの明確化。
工程
A
工程
B
工程
C
ボトルネック
inbound outbound
工程
A
工程
B-1
工程
C
ボトルネック
inbound outbound
工程
B-2
短
縮
2014-01-28
2. 今後どう変えていくか
常にシンプル

17. Operation Lab
運用設計ラボ
時系列: 業務の標準化
• 多重化された業務を標準化する。
• コードへの落し込み可能化。標準工数の確立。
共通
inbound
工程
独自
工程B-1 共通
outboun
d
工程
inbound outbound
標準
前処理
工程
標準
後処理
工程
独自
本処理
工程R-1
独自
工程 A-1
独自
本処理
工程R-2
標準
本処理
工程
2014-01-28
2. 今後どう変えていくか
常にシンプル

18. Operation Lab
運用設計ラボ
時系列: 業務の自動化
• 標準化された業務を自動化する。
• 自動化のbefore/after で自動化自体とその後の改善効果の測定が可能に。
標準工程
(コード)input output
類似の機能を集約していく (機能別構造化へ)
2014-01-28
2. 今後どう変えていくか
常にシンプル

19. Operation Lab
運用設計ラボ
業務の構造化 (機能別)
業務機能ユニット マップ
作業チケット
サービスリファレンス
コスト算定/請求
計画イベント 作業ロジック
問題チケット
顧客
サービス
支援協調組織
inbound outboundモニター
作業インタフェース
出展: Internet Week 2009 「運用方法論 ∼ 運用現場の現状分析 そして運用設計へ」
一つの事を上手にやるプロダクト群 / 疎結合
2014-01-28
2. 今後どう変えていくか
常にシンプル

20. Operation Lab
運用設計ラボ
1.設計: 業務の構造化
‣ 時系列構造化
‣ 機能別構造化
2.実装: 業務の分散化、多重化、標準化
‣ その結果としての自動化 (自動化は目的ではない)
「(質的な)高負荷」からの脱却 (まとめ)
2014-01-28
2. 今後どう変えていくか
常にシンプル

21. Operation Lab
運用設計ラボ
2-2. 「属人的」をどう変えていくか
常に見える
2014-01-28
2. 今後どう変えていくか

22. Operation Lab
運用設計ラボ
「属人的」からの脱却
1. 専門領域と非属人領域
2. ドキュメント化による業務の客観化
3. ドキュメント構造化による価値の明確化
常に見える
2014-01-28
2. 今後どう変えていくか

23. Operation Lab
運用設計ラボ
専門領域と非属人領域
常に見える
定常運用
非定常運用
情報
管理
要員
管理
予算
管理
属人作業緊急作業
申請作業定時作業
実働業務
業務コア
「ブラック・ボックス化が許されない」領域
365日24時間稼動が求められる業務 (事業継続性)
出典: Think IT 「現場視点からの運用方法論 第3回 明日の運用現場のために」(2010-12)
担当者の「ノウハウや個性」が期待される領域
定時作業 申請作業 緊急作業
属人作業
「属人回避すべき範囲」を明確にする必要がある。
なんでもかんでも「属人的」と言うのは不適切
2014-01-28
2. 今後どう変えていくか
常に見える

24. Operation Lab
運用設計ラボ
ドキュメント化による業務の客観化
運用ドキュメントの必要性
脱属人化のために必要
客観化のために必要
整理のために必要
「自分達のやっていることを知る&改善するために」
「自分達のやっていることの説明&(自己・他者)評価のために」
「自分達のやっていることの安定化&永続化のために」
出典: Internet Week 2011 「運用ドキュメント2011 ∼手軽にスピーディに継続的に保守するためのツール入門」 Part-1
2014-01-28
2. 今後どう変えていくか
常に見える

25. Operation Lab
運用設計ラボ
ドキュメント構造化による価値の明確化
時間軸 activity活動
状
態
変化前 変化後
変化
Future Status
将来の状態ドキュメント
Past Activity
活動履歴
Change
変化差分ドキュメント
Future Activity!
活動予定
費用性情報
収益性情報
Past Status
過去の状態ドキュメント
「状態」と「変化」と「活動」に関するドキュメントを分離する意識が必要。
資産性情報
出典: Internet Week 2011 「運用ドキュメント2011 ∼手軽にスピーディに継続的に保守するためのツール入門」 Part-1
2014-01-28
2. 今後どう変えていくか
常に見える

26. Operation Lab
運用設計ラボ
2-3. 費用対効果をどう変えていくか
常に価値を生む
2014-01-28
2. 今後どう変えていくか

27. Operation Lab
運用設計ラボ
費用対効果の見える化
1.カネの話
2.モノの話
3.ヒトの話
常に価値を生む
2014-01-28
2. 今後どう変えていくか

28. Operation Lab
運用設計ラボ
運用会計論 (カネの話)
会計上、運用は「コストセンター」
製造業: 製造工程は売上原価(製造直接費)であり、利益の源泉と認識される。
サービス業: 運用工程は販管費(製造間接費)であり、コストと認識される。
加工 出荷原材料 製品
集約 提供
サービス
リソース
サービス
運用
売上原価
販管費
財務会計上の論点
出典: 経営情報学会 2010年秋季全国大会 「運用研究部会 サービス運用における 「費用対効果」に関する考察」
2014-01-28
2. 今後どう変えていくか
常に価値を生む

29. Operation Lab
運用設計ラボ
運用品質論 (モノの話)
品質の定義、基準が曖昧
サービス
リソース
加工 出荷原材料
集約
サービス
運用
製品
提供
商品
満足
目に見えない
目に見える
品質上の論点
出典: 経営情報学会 2010年秋季全国大会 「運用研究部会 サービス運用における 「費用対効果」に関する考察」
2014-01-28
2. 今後どう変えていくか
常に価値を生む

30. Operation Lab
運用設計ラボ
運用組織論 (ヒトの話)
二極化する運用現場
クラウドに吸い込まれる運用現場
尖ったモノを持つ「攻める」運用現場
変化に柔軟に対応高度な専門性
短納期/スピード 費用対効果が明確
スケーラビリティ スティッキー
一般的な専門性 硬直的
意思決定に時間 どんぶり勘定
高コスト体質 非合理的
出展: CTC Academic User Association 第9回研究会 2010 「サービス運用の現状と課題 費用対効果との闘い」
2014-01-28
2. 今後どう変えていくか
常に価値を生む

31. Operation Lab
運用設計ラボ
今後どう変えていくか (まとめ)
構造化された業務の中で、
課題をエンジニアリングを以って解決する
構造化
エンジニアリング(工学)の実践
2014-01-28
2. 今後どう変えていくか

32. Operation Lab
運用設計ラボ
3. 運用のアーキテクチャ
運用業務構造化のための指針
2014-01-28

33. Operation Lab
運用設計ラボ
アーキテクチャとは
‣ architecture とは、「構造、構成」を意味する英単語。
‣ 構造全体は、構造要素で構成される。
‣ 構造全体の振舞いは、構造要素の振舞いの総和で表現さ
れる。
2014-01-28
3. 運用のアーキテクチャ

34. Operation Lab
運用設計ラボ
運用アーキテクチャに求められるもの
‣ 疎結合 (UNIXの哲学/カスタマイザブル)
‣ 一つの事を上手にやるプロダクト
‣ 新規追加の仕組み
‣ 他組織との相互接続。
‣ 永続的 (事業継続性/商用製品に非依存)
‣ 災害に強い。
‣ ベンダーロックインされていない。
‣ 設計自体が引き継ぎ可能。
‣ フレームワーク (科学的/エンジニアリング)
‣ 理論と実践。
‣ 再現性(たいていの人が実践できること)の重視。
‣ 反復性(定期的な棚卸しなど継続するための仕組み)の実現。
2014-01-28
3. 運用のアーキテクチャ

35. Operation Lab
運用設計ラボ
まとめ
2014-01-28

36. Operation Lab
運用設計ラボ
運用の今後
• 運用アーキテクチャ(業務の構造化)が必須に
• 業務の分散化、標準化、その結果としての自動化へ
• ドキュメント価値の明確化
• カネ(管理会計)、モノ(品質基準)、ヒト(アジャイル組織設計)の構造化設計と
その客観的評価による費用対効果の説明可能化
• 運用アーキテクトという職能の確立
• 幅広い知識と痛い目にあった経験が求められる。
• 経営知識を追加すれば独立してサービスはじめられるような人達である。
• 運用工学の登場
• サービス工学とも言われますが、この先50年以内には成立する、はず。
2014-01-28

37. Operation Lab
運用設計ラボ
http://www.operation-lab.co.jp/