2015-09-01 クラウド時代の運用エンジニアは何が変わるのか

2015-09-01 クラウド時代の運用エンジニアは何が変わるのか

1. 1. Operation Lab 運用設計ラボ クラウド時代の運用エンジニアは何が変わるのか 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一 2015-09-01 Ops JAWS #1
2. 2. Operation Lab 運用設計ラボ 1. オンプレミスからクラウドで何が変わるのか クラウド時代の運用エンジニアは何が変わるのか
3. 3. オンプレミスからクラウドで何が変わるのか 1. カネが変わる 2. 時間が変わる 3. やり方が変わる Operation Lab 運用設計ラボ あらゆることが根本的に変わる
4. 4. オンプレミスからクラウドで何が変わるのか • 保有から利用へ • 「保有」が目的から「利用」が目的へ • 資産から費用へ • 見た目の成果(資産)から実質的な成果(売上原価)へ • 共通配賦(コストセンター)から直接配賦(売上原価)ヘ Operation Lab 運用設計ラボ 1. カネが変わる
5. 5. オンプレミスからクラウドで何が変わるのか Operation Lab 運用設計ラボ 2. 時間が変わる • リードタイムが月から分へ • リソースの調達リードタイムが月単位から分単位へ • 利用単位が年から時(ミリ秒)へ • リソースの時間単価が年単位から時(ミリ秒)単位へ • 最低利用期間が月前提からゼロへ • 最低利用期間の縛りがなくなった
6. 6. オンプレミスからクラウドで何が変わるのか • 作り込みから使い捨てへ • 手段重視から目的重視へ • 歴史的経緯よりも合理性 • 確実性よりも迅速性 • 「運用でカバー」から《設計で保証》へ • 主観性よりも客観性 • テクニカルよりもエンジニアリング • やりっぱなしモデル(作りっぱなし)からサイクルモデル(スクラッチ&ビルド)へ Operation Lab 運用設計ラボ 3. やり方が変わる
7. 7. Operation Lab 運用設計ラボ 2. 「運用」の本質とは何か クラウド時代の運用エンジニアは何が変わるのか ∼「運用」の2つの専門性
8. 8. Operation Lab 運用設計ラボ 「運用」とは「サービスデリバリ」である リクエスト に対する デリバリ の繰り返し 出典: 経営情報学会 2010年春季全国研究発表大会 「運用業務プロセスのモデル化」 顧客・外部サービス outboundinbound outboundinbound 外部支援組織 inbound inbound 運用メンバー outboundinbound 内部協調/支援組織 inbound outbound リクエストデリバリ デリバリ デリバリ デリバリ リクエスト リクエストリクエスト 運用現場 窓口 フロントエンド バックエンド outbound outbound 2. 「運用」の本質とは何か
9. 9. Operation Lab 運用設計ラボ 「運用」を「サービスデリバリ」と捉える Quality Cost Delivery 品質という価値観 時間という物性 金額という物性 • 「サービス」視点で物事を考えるようになる • 「デリバリ」視点で定量評価が可能になる • 専門性(サービスとデリバリ)が明確になる ユーザ サービス デリバリ 2. 「運用」の本質とは何か
10. 10. Operation Lab 運用設計ラボ 誰が見ても同じ「運用」へ 費用に見合った効果のある「運用」 運用方法論 経営論 「サービス」の専門集団 「デリバリ」の専門集団 「サービスデリバリ」に求められる2つの専門性 運用現場には、専門集団として2つの側面がある 目的 手段 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) 2. 「運用」の本質とは何か
11. 11. Operation Lab 運用設計ラボ デリバリとは何か? サービスを安定的合理的に提供すること • 高度な反復性、再現性が求められる業務活動。 • 独自性よりも安定性、合理性が価値を持つ業務活動。 • 定量評価による合理性検証を前提とした業務活動。 全ての定常業務は「デリバリ」と捉えることができる エンジニアリング価値 (生産工学) 手段 運用方法論 2. 「運用」の本質とは何か
12. 12. Operation Lab 運用設計ラボ 参考: 「デリバリ」を「工程」として捉える 工場型モデル • 手戻りに対する違和感 • QCDへの意識付け • 作業員保護機構の重要性 (セキュリティ強化) エンジニアリング価値 (生産工学) 手段
13. 13. Operation Lab 運用設計ラボ サービスとは何か? 全ての業務は「サービス」と捉えることができる 利用者の「課題」を解決すること サービス価値 (経営、実務) 目的 • エンドユーザの課題を解決すること • 社内ユーザの課題を解決すること • 誰かの課題を解決することを(間接的に)支援すること 2. 「運用」の本質とは何か
14. 14. Operation Lab 運用設計ラボ サービスとは何か? (利用者視点) • 丸投げ: 代わりにやってもらう • 半投げ: 手伝ってもらいながら自分でやる • 丸被り: 自分でやる (自己責任) (利用者視点) サービス価値 (経営、実務) 目的 利用者の「課題」を解決すること 2. 「運用」の本質とは何か
15. 15. Operation Lab 運用設計ラボ サービスとは何か? (クラウド時代) • SaaS: 代わりにやってもらう • PaaS: 手伝ってもらいながら自分でやる • IaaS: 自分でやる (自己責任) 費用型 資産型 • オンプレミス: 自分でやる (自己責任) (利用者視点) (利用者視点) 丸投げ 半投げ 丸被り 丸被り サービス価値 (経営、実務) 目的 利用者の「課題」を解決すること 2. 「運用」の本質とは何か
16. 16. Operation Lab 運用設計ラボ プロダクト指向運用からサービス指向運用へ • SaaS: 代わりにやってあげる • PaaS: 専門性や基盤で支援してあげる 今後: サービス(課題解決)指向運用へ 費用型 (提供者視点) 従来: プロダクト指向運用 手段 の提供(コストセンター扱い) 道具のお守り サービス価値 (経営、実務) 目的 利用者の「課題」を解決すること 資産型 2. 「運用」の本質とは何か サービス価値を見ていない サービス価値重視
17. 17. Operation Lab 運用設計ラボ まとめ: 「運用」とは 目的 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) ユーザ 費用に見合った 効果のある「運用」 経営論 誰が見ても 同じ「運用」へ 運用方法論 手段 サービス価値 を支える価値の提供 「運用」とは「サービスデリバリ」である。 「運用」の本質とは「価値の提供」 価値を提供できれば「手段」は何でも良い 2. 「運用」の本質とは何か
18. 18. Operation Lab 運用設計ラボ 3. 「運用」に求められる2つの専門性 クラウド時代の運用エンジニアは何が変わるのか
19. 19. Operation Lab 運用設計ラボ (再掲) 「運用」とは 目的 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) ユーザ 費用に見合った 効果のある「運用」 経営論 誰が見ても 同じ「運用」へ 運用方法論 手段 サービス価値 を支える価値の提供 「運用」とは「サービスデリバリ」である。 3. 「運用」に求められる2つの専門性 「運用」の本質とは「価値の提供」 価値を提供できれば「手段」は何でも良い
20. 20. Operation Lab 運用設計ラボ Platform as a Service Software as a Service Infrastructure as a Service SaaS PaaS IaaS 上位に対してサービスをデリバリ 上位に対してサービスをデリバリ 上位に対してサービスをデリバリ ユーザ 参考:「運用」とは「サービスデリバリ」である
21. 21. Operation Lab 運用設計ラボ Platform as a Service Infrastructure as a Service SaaS PaaS IaaS 上位に対してサービスをデリバリ 「サービスデリバリ」とAWS (例) 上位に対してサービスをデリバリ 上位に対してサービスをデリバリ ユーザ EC2 S3 RDS EMR Elastic Beanstalk App amazon.com 参考:「運用」とは「サービスデリバリ」である Software as a Service
22. 22. Operation Lab 運用設計ラボ Platform as a Service Infrastructure as a Service SaaS PaaS IaaS 上位に対してサービスをデリバリ 上位に対してサービスをデリバリ 上位に対してサービスをデリバリ amazon.com AWSの強さは「サービスデリバリ」の強さ 自前で 多層にわたって サービスデリバリ を実現している。 ! ドッグフーディング 参考:「運用」とは「サービスデリバリ」である Software as a Service
23. 23. Operation Lab 運用設計ラボ Platform as a Service Infrastructure as a Service SaaS PaaS IaaS 上位に対してサービスをデリバリ AWSはよくできている 上位に対してサービスをデリバリ 上位に対してサービスをデリバリ EC2 S3 RDS EMR Elastic Beanstalk App amazon.com Software as a Service サービス価値 (経営、実務) エンジニアリング価値 (生産工学) 「運用」と「経営」の指針が合致 「運用」を客観的に捉えている (Metric) 独自色あるサービスで 一人勝ち ユーザ 参考:「運用」とは「サービスデリバリ」である
24. 24. Operation Lab 運用設計ラボ SaaS PaaS IaaS 「サービス」の独自化と「デリバリ」の標準化 ユーザ サービス価値 デリバリ価値 サービス価値の向上 (経営、実務) エンジニアリング価値の向上 (生産工学) 独自色が求められる領域 標準化、スケーラビリティ が求められる領域 目的 手段 デリバリ価値 サービス価値 X = 運用現場の価値 3. 「運用」に求められる2つの専門性
25. 25. Operation Lab 運用設計ラボ SaaS PaaS IaaS これからの「運用」 ユーザ サービス価値 デリバリ価値 どの領域を 主戦場とするか? 客観的、論理的 サービス価値の向上 (経営、実務) 独自色が求められる領域 目的 標準化、スケーラビリティ が求められる領域 エンジニアリング価値の向上 (生産工学) 手段 3. 「運用」に求められる2つの専門性
26. 26. Operation Lab 運用設計ラボ 「運用」のリソース戦略 サービス価値 デリバリ価値 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) 目的 手段 売上原価 売上 リソースは有限なので2要素の戦略的なバランスが重要 サービス価値の無い運用はコストセンター デリバリ価値の無い運用は、要求の変化に対応する体力がない 3. 「運用」に求められる2つの専門性
27. 27. Operation Lab 運用設計ラボ 「運用」にも欠かせない「サービス価値」 目的 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) ユーザ 費用に見合った 効果のある「運用」 経営論 誰が見ても 同じ「運用」へ 運用方法論 手段 サービス価値 を支える価値の提供 どちらの価値も重要だが…… サービス価値が無いと「運用」の存在意義がない 利用者の「課題」を解決できない X 独自色 標準化、スケーラビリティ 3. 「運用」に求められる2つの専門性
28. 28. Operation Lab 運用設計ラボ 4. 「インフラ自前主義」の終焉 クラウド時代の運用エンジニアは何が変わるのか
29. 29. Operation Lab 運用設計ラボ 自前主義の終焉 2つの側面で自前主義の時代は終焉 工場型モデル 全てのプロセスについて自力でセキュリティを守ることは不可能に サービス プロセス サービス 基盤 自前での価値は 産みにくくなった 自前で価値を産みだせる 全てのレイヤを自前で用意することが割に合わなくなってきた インフラ 4. 「インフラ自前主義」の終焉
30. 30. Operation Lab 運用設計ラボ 工場型モデル 優位性(コアコンピタンス)とは関係ない工程をマネージドサービスに処理させる 自前でスケールできない基盤をマネージドサービスに任せる 運用のコアコンピタンスとマネージドサービス 自前主義から、マネージドサービスの時代へ サービス プロセス サービス 基盤 自前での価値は 産みにくくなった 自前で価値を産みだせる インフラ 4. 「インフラ自前主義」の終焉
31. 31. Operation Lab 運用設計ラボ 「運用」イコール「サービス」の時代へ 「サービス」と「デリバリ」の両者を設計 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) コアコンピタンス サブコンピタンス マネージド サービス 利活用 運用 3者のいずれも激しく変化しつづけるはず 4. 「インフラ自前主義」の終焉
32. 32. Operation Lab 運用設計ラボ • 「運用」の本質は「価値の提供」である。 • 実は、価値を提供できれば「手段」は何でも良い • 自前時代の終焉 • 価値の最大化のためにコアコンピタンスの明確化が必要 • マネージドサービスの利用を前提とした時代へ まとめ: 「インフラ自前主義」時代の終焉 一般的な専門性の専業インフラエンジニアは 歴史的役割を終えた。 4. 「インフラ自前主義」の終焉
33. 33. Operation Lab 運用設計ラボ SaaS PaaS IaaS これからのインフラエンジニア ユーザ サービス価値 デリバリ価値 サービス価値 (経営、実務) 独自色が求められる領域 標準化、スケーラビリティ が求められる領域 目的 手段 エンジニアリング価値 (生産工学) クラウドの中の スーパーエンジニア 大多数のエンジニア 仕事ないよ(>_<) 「ドッグフーディング」最強
34. 34. Operation Lab 運用設計ラボ まとめ クラウド時代の運用エンジニアは何が変わるのか
35. 35. まとめ 1. カネが変わる 2. 時間が変わる 3. やり方が変わる Operation Lab 運用設計ラボ 1. あらゆることが根本的に変わる 2. サービス価値が無いと「運用」の存在意義がなくなる 3. 自前主義から、マネージドサービスの活用へ クラウド時代の運用エンジニアは何が変わるのか
36. 36. Operation Lab 運用設計ラボ http://www.operation-lab.co.jp/ OperationLab運用設計