2014-01-28 Operation in the future
18 likes3,202 views
2014年1月に、ある企業様向けに作成したプレゼン資料のダイジェスト版です。
2014-01-28 Operation in the future
- 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
- 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
- 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. 今後どう変えていくか 常に見える
- 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. 今後どう変えていくか
- 33. Operation Lab 運用設計ラボ アーキテクチャとは ‣ architecture とは、「構造、構成」を意味する英単語。 ‣ 構造全体は、構造要素で構成される。 ‣ 構造全体の振舞いは、構造要素の振舞いの総和で表現さ れる。 2014-01-28 3. 運用のアーキテクチャ
- 34. Operation Lab 運用設計ラボ 運用アーキテクチャに求められるもの ‣ 疎結合 (UNIXの哲学/カスタマイザブル) ‣ 一つの事を上手にやるプロダクト ‣ 新規追加の仕組み ‣ 他組織との相互接続。 ‣ 永続的 (事業継続性/商用製品に非依存) ‣ 災害に強い。 ‣ ベンダーロックインされていない。 ‣ 設計自体が引き継ぎ可能。 ‣ フレームワーク (科学的/エンジニアリング) ‣ 理論と実践。 ‣ 再現性(たいていの人が実践できること)の重視。 ‣ 反復性(定期的な棚卸しなど継続するための仕組み)の実現。 2014-01-28 3. 運用のアーキテクチャ
- 36. Operation Lab 運用設計ラボ 運用の今後 • 運用アーキテクチャ(業務の構造化)が必須に • 業務の分散化、標準化、その結果としての自動化へ • ドキュメント価値の明確化 • カネ(管理会計)、モノ(品質基準)、ヒト(アジャイル組織設計)の構造化設計と その客観的評価による費用対効果の説明可能化 • 運用アーキテクトという職能の確立 • 幅広い知識と痛い目にあった経験が求められる。 • 経営知識を追加すれば独立してサービスはじめられるような人達である。 • 運用工学の登場 • サービス工学とも言われますが、この先50年以内には成立する、はず。 2014-01-28