2015-05-23 クラウドの運用になってインフラエンジニアは何が変わるのか?

Operation Lab運用設計ラボ

クラウドの運用になってインフラエンジニアは何が変わるのか?

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

2015-05-23

JAWS-UG Osaka 第13回勉強会オペレーションじょうず


1. オンプレミスからクラウドで何が変わるのかクラウドの運用になってインフラエンジニアは何が変わるのか?

オンプレミスからクラウドで何が変わるのか

1. カネが変わる

2. 時間が変わる

3. やり方が変わる



• 保有から利用へ • 「保有」が目的から「利用」が目的へ

• 資産から費用へ • 見た目の成果(資産)から実質的な成果(売上原価)へ • 共通配賦(コストセンター)から直接配賦(売上原価)ヘ


1. カネが変わる



2. 時間が変わる

• 利用単位が年から分(秒)へ • リソースの時間単価が年単位から分(秒)単位へ

• リードタイムが月から分へ • リソースの調達リードタイムが月単位から分単位へ

• 最低利用期間が月前提からゼロへ • 最低利用期間の縛りがなくなった


• 作り込みから使い捨てへ • 手段重視から目的重視へ • 歴史的経緯よりも合理性 • 確実性よりも迅速性 • 「運用でカバー」から《設計で保証》へ • 主観性よりも客観性 • テクニカルよりもエンジニアリング • やりっぱなしモデル(作りっぱなし)からサイクルモデル(スクラッチ&ビルド)へ


3. やり方が変わる


2. 「運用」の本質とは何かクラウドの運用になってインフラエンジニアは何が変わるのか?


「運用」を「サービスデリバリ」と捉える

リクエストに対するデリバリの繰り返し

顧客・外部サービスoutboundinbound

outboundinbound

外部支援組織inbound

inbound

運用メンバーoutboundinbound

内部協調/支援組織inbound

outbound

リクエストデリバリ

デリバリ

デリバリ

デリバリ

リクエスト

リクエストリクエスト

運用現場

窓口フロントエンド

バックエンド

outbound

outbound

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


• 客観的に俯瞰することが可能 • 科学的手法による測定が可能 • 論理的手法による分析が可能

誰が見ても同じ「運用」へ

「運用」を「サービスデリバリ」と捉える

inbound outbound Quality

Cost

Delivery 品質という価値観

デリバリリクエスト

やっていること(mission)の見える化

成果(output)の見える化

期待(input)の見える化

時間という物性

金額という物性売上原価

費用に見合った効果のある「運用」

かかるコストを直接配賦し「売上原価」として貢献

運用方法論経営論


参考: 問題解決のための論点整理

やっていること(mission)の見える化

成果(output)の見える化

期待(input)の見える化

適切な成果基準が必要

高負荷の解消

属人的の解消

費用対効果の見える化

運用方法論

経営論

運用業務を客観的、論理的に把握する必要

適切な客観化が必要


• 社内のインフラ運用 • 依頼元部署へのサービスのデリバリと考える。 • 「道具のお守り」からの脱却

• アラート対応 • システムから「復旧リクエスト」が来たと考える。 • 「復旧というサービス」のデリバリという視点で考える。

参考:「運用」とは「サービスデリバリ」である


デリバリの変化で運用業務の変化を

認識可能

Platform as a Service

Software as a Service

Infrastructure as a Service

SaaS

PaaS

IaaS

上位に対してサービスをデリバリ



ユーザ運用最小単位にライフサイクル

の概念


運用業務全体にライフサイクル

の概念




SaaS

PaaS

IaaS


「サービスデリバリ」とAWS (例)



ユーザ

EC2

S3RDS EMR

Elastic Beanstalk

App

amazon.com






SaaS

PaaS

IaaS




amazon.com

AWSの強さは「サービスデリバリ」の強さ

自前で多層にわたってサービスデリバリを実現している。

!ドッグフーディング




• 客観的に俯瞰することが可能 • 科学的手法による測定が可能 • 論理的手法による分析が可能

誰が見ても同じ「運用」へ

費用に見合った効果のある「運用」

かかるコストを直接配賦し「売上原価」として貢献

運用方法論

経営論「サービス」の専門集団

「デリバリ」の専門集団エンジニアリング価値

(生産工学)

サービス価値 (経営、実務)

「運用」に求められる2つの専門性

運用現場には、専門集団として2つの側面がある目的

手段

「運用」=「サービスデリバリ」


サービスとは何か? (仮説)

• エンドユーザの課題を解決すること

• 社内ユーザの課題を解決すること

• 誰かの課題を解決することを(間接的に)支援すること

全ての業務は「サービス」と捉えることができる


利用者の「課題」を解決すること



サービスとは何か? (利用者視点)

• 丸投げ: 代わりにやってもらう

• 半投げ: 手伝ってもらいながら自分でやる

• 丸被り: 自分でやる (自己責任)

(利用者視点)





サービスとは何か? (クラウド時代)


• SaaS: 代わりにやってもらう

• PaaS: 手伝ってもらいながら自分でやる

• IaaS: 自分でやる (自己責任)

費用型

資産型• オンプレミス: 自分でやる (自己責任)

(利用者視点)

(利用者視点)


丸投げ

半投げ

丸被り

丸被り



プロダクト指向運用からサービス指向運用へ

従来: プロダクト指向運用

今後: サービス(課題解決)指向運用へ

• SaaS: 代わりにやってあげる

• PaaS: 専門性や基盤で支援してあげる

費用型 (提供者視点)

手段の提供(コストセンター扱い)道具のお守り


利用者の「課題」を解決するか?



Service Operation

Service Design

Service Transition

Service Strategy

プロダクト指向運用からサービス指向運用へ従来: プロダクト指向運用

手段の提供(コストセンター扱い)道具のお守り


ITライフサイクル (ITIL v3)「運用」は結局下請け

Dev QA+Deploy

Ops

(コストセンター扱い)



プロダクト指向運用からサービス指向運用へ今後: サービス(課題解決)指向運用へ

• SaaS: 代わりにやってあげる • PaaS: 専門性や基盤で支援してあげる

費用型 (提供者視点)


考

作展

ユーザ

稼サービスの根幹は

稼ぐ人考える人

それを支える作る人展げる人

Ops

Dev

Deploy QA

営業

事業戦略、運用設計

サービス運用現場

サービス開発(支援)

リリースマネジメント+営業



デリバリとは何か? (仮説)

サービスを安定的合理的に提供すること

• 高度な反復性、再現性が求められる業務活動。

• 独自性よりも安定性、合理性が価値を持つ業務活動。

• 定量評価による合理性検証を前提とした業務活動。

全ての定常業務は「デリバリ」と捉えることができる

「運用」に求められる2つの専門性エンジニアリング価値

(生産工学)


SaaS

PaaS

IaaS

「サービス」の独自化と「デリバリ」の標準化

ユーザ

サービス価値

デリバリ価値

サービス価値の向上 (経営、実務)

エンジニアリング価値の向上 (生産工学)

独自色が求められる領域

標準化、スケーラビリティが求められる領域

目的

手段

デリバリ価値

サービス価値X

= 運用現場の価値



SaaS

PaaS

IaaS

これからの「運用」

ユーザ

サービス価値

デリバリ価値

どの領域を主戦場とするか?

客観的、論理的


サービス価値の向上 (経営、実務)


目的


エンジニアリング価値の向上 (生産工学)

手段


余談: OpsOpsもしくはOpsDevの未来

稼ぐ人

考える人

作る人

展げる人

OpsOps: サービス運用現場が全部やる

OpsDev: サービス運用現場が実装以外全部やる

稼ぐ人

考える人

作る人

展げる人

AWSとWebアプリケーションフレームワークが使えれば昔ほど難易度は高くない

(社内サービスの場合)

受託開発に近い

サービス指向運用

数年もすればVBAみたいな扱いに

(パブリックサービスの場合)



余談: OpsOpsもしくはOpsDevの未来

稼ぐ人

考える人

作る人

展げる人

OpsOps: サービス運用現場が全部やる

内製もできるサービス運用現場

サービス指向運用

「運用もやっている開発現場」がありますが

と捉えなおしてみましょう。サービス価値 (経営、実務)

エンジニアリング価値 (生産工学)



まとめ: 「運用」の本質とは何か?

「運用」が「サービスデリバリ」であるならば

「運用」の本質は「価値の提供」となる。決して「コストセンター」ではない

• 「サービス」とは、利用者の「課題」を解決すること • 経営的な専門性 (サービス)

• 「デリバリ」とは、サービスを安定的合理的に提供すること • 技術的な専門性 (エンジニアリング)




SaaS

PaaS

IaaS


AWSはよくできている



ユーザ

EC2

S3RDS EMR

Elastic Beanstalk

App

amazon.com

3. 「運用」の本質とは何か



4. 「インフラ自前主義」の終焉クラウドの運用になってインフラエンジニアは何が変わるのか?


自前主義の終焉

2つの側面で自前主義の時代は終焉工場型モデル

全てのプロセスについて自力でセキュリティを守ることは不可能に

サービスプロセス

サービス基盤自前での価値は

産みにくくなった

自前で価値を産みだせる

全てのレイヤを自前で用意することが割に合わなくなってきたインフラ


工場型モデル

優位性(コアコンピタンス)とは関係ない工程をマネージドサービスに処理させる

自前でスケールできない基盤をマネージドサービスに任せる

運用のコアコンピタンスとマネージドサービス

自前主義から、マネージドサービスの時代へ

サービスプロセス

サービス基盤自前での価値は

産みにくくなった

自前で価値を産みだせる

インフラ


「運用」イコール「サービス」の時代へ

「サービス」と「デリバリ」の両者を設計サービス価値 (経営、実務)


コアコンピタンス

サブコンピタンス

マネージドサービス利活用

運用

3者のいずれも激しく変化しつづけるはず


• 「運用」の本質は「価値の提供」である。 • 実は、価値を提供できれば「手段」は何でも良い

• 自前時代の終焉 • 価値の最大化のためにコアコンピタンスの明確化が必要 • マネージドサービスの利用を前提とした時代へ

まとめ: 「インフラ自前主義」時代の終焉

一般的な専門性の専業インフラエンジニアは歴史的役割を終えた。


SaaS

PaaS

IaaS

これからのインフラエンジニア

ユーザ

サービス価値

デリバリ価値




目的

手段


エンジニアリング価値(生産工学)

クラウドの中のスーパーエンジニア

大多数のエンジニア

仕事ないよ(>_<)

「ドッグフーディング」最強



EC2

S3RDS EMR

Elastic Beanstalk

App

amazon.com

4. 「インフラ自前主義」の終焉

SaaS

PaaS

IaaS

ユーザ

サービス価値



大多数のエンジニア

仕事ないよ(>_<)デリバリ価値

エンジニアリング価値(生産工学)

クラウドの中のスーパーエンジニア

「ドッグフーディング」最強


5. 「運用改善」を考えるクラウドの運用になってインフラエンジニアは何が変わるのか?

～「自動化」を考える前に

「運用改善」は「成功」するのか?


経験的に「だいたい失敗する」

実施直後に「効果」を実感できるときもあるが、 1年もすると、次の「運用改善」が必要な状態に

• 場当たり的な「改善」の実施

• 客観的な「到達点」の不存在

• 「効果測定」の曖昧さ


「運用改善」とは (仮説)

「運用の価値」を現状よりも高めるための改善活動

ToBe (理想)が明確であれば、場当たり的な「改善」は避けられる。

ToBe (理想)

AsIs (現状)

運用改善


「運用改善」が必要な状況とは (仮説)

• サービス価値の低下

• 処理能力の低下

• アジリティ (経営戦略への追随能力)の低下

運用の「価値」が低下している(可能性がある)状況

AsIs(現状)がわかれば、客観的な「到達点」を決めることもできる




「運用改善」はなぜ必要となるか (要因1)

• 外部からの情報と運用現場内部の情報の不均衡が「乖離」の原因 • 内部情報 (組織内の力関係を含む) > 外部からの情報 (経営方針、ユーザニーズ)

• 「組織の本能」としての「自己最適化」が「乖離」を拡大 • 「組織自体」が目的化する (変化を避ける、自己目的化、など局所最適化が発生)

運用現場と「外部」との乖離の存在、拡大 • 経営方針との乖離 • ユーザニーズとの乖離

運用現場と「外部」の乖離を解消する必要



「運用改善」はなぜ必要となるか (要因2)

• 運用組織の成果とメンバー個人の業績評価基準が一致していない • 運用メンバーの頑張りと組織の成果(外部からの評価)が連動しない

• 「生産性の向上」と矛盾する活動実体の存在 • 「定例会議」の自己目的化、「レポート」の自己目的化、など

運用現場「内部」での矛盾の存在、拡大 • 組織成果と業績評価基準の矛盾 • 活動実体の矛盾

運用現場「内部」の矛盾を解消する必要



「運用改善」とはどのような活動であるべきか

運用の「価値」の拡大

運用現場と「外部」との乖離の縮小、解消 • 経営方針との乖離 • ユーザニーズとの乖離

影響大

運用現場「内部」での矛盾の縮小、解消 • 組織成果と業績評価基準の矛盾 • 活動実体の矛盾


影響小 (相対的)エンジニアリング価値

(生産工学)


まとめ:「運用改善」とは

ToBe (理想)

AsIs (現状)

運用改善

「運用の価値」を現状よりも高めるための改善活動

運用現場と「外部」との乖離の縮小、解消

運用現場「内部」の矛盾の縮小、解消

影響大

影響小(相対的)




参考:「運用改善」のライフサイクル

運用現場と「外部」との乖離の縮小、解消

運用現場「内部」の矛盾の縮小、解消

影響大

影響小(相対的)

「運用」を客観的に捉える

運用の「価値」の拡大

Phase2. 任務(mission)の客観化

Phase3. 実績(output)の客観化 Phase1. 期待(input)の客観化

「運用」と「経営」の指針を合致させるToBe (理想)

AsIs (現状)

接近






SaaS

PaaS

IaaS上位に対してサービスをデリバリ




EC2

S3RDS EMR

Elastic Beanstalk

App

amazon.com

5. 「運用改善」を考える




「運用」と「経営」の指針が合致

「運用」を客観的に捉えている (Metric)

独自色あるサービスで一人勝ち

ユーザ


おまけ: 「運用改善」が「成功」する要因

• アラートメールが減った (400万通->数万通/年)

• 成果に必要な工数(時間)が減った (2時間->10秒)

• 部署間調整に必要な時間が減った (40人日->8人日)

経験的に「客観化」がキー

「誰がどう見ても同じ数字や事実」で Before/Afterを示すことが重要

+ チューニングできる余地を残しておくこと


6. クラウド時代の「自動化」は正義か?クラウドの運用になってインフラエンジニアは何が変わるのか?


自動化は、「客観化の結果」であって「目的」ではない。

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

手段: 自動「客観化(構造化)された業務の一部」を自動化する。

「目的と手段がひっくりかえる」ことは、よくある

クラウド時代の「自動化」は正義か?

「自動化が目的」の場合はNo「自動化が手段」の場合はYes

「自動化が目的」の弊害

• 属人化 • 「自動化された業務」の保守が属人化する。

• プロセスの硬直化 • 「自動化された業務」の仕様忘却による変更不可などにより、

業務プロセスが硬直化する。 • トラブル発生時のインパクト

• 「自動化された業務」の処理フローが不明なため、手動ではリカバリができない。



クラウド時代の「運用」のキーワード

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

エンジニアの仕事です」 @yoshiori

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

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


7. 明日のエンジニアライフのためにクラウドの運用になってインフラエンジニアは何が変わるのか?

スーパーエンジニアになる

• まずは、とにかく「実際に触ってみる」ことが第一歩。 • 離れた分野をいくつか経験していると、差別化しやすい。 • ITについては、抽象化能力(設計能力)と具体化能力(実装能力)のバランスが重要。

• 痛い目にあった経験は特に得難い財産になる。


いわゆるスーパーエンジニアかどうかは、知っているか、経験しているか、が大きい。

「どれだけ地雷を踏み抜いて、どれだけ血を流したか」は、運用屋さんとしての価値に決定的な影響(涙)。

※発表者はスーパーエンジニアではありません。

明日のエンジニアライフのために

サービスエンジニアリングの力を持つ

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

互接続。

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

可能。

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



サービスエンジニアリングに必要な知識

• 抽象化手法 (特にオブジェクト指向分析)

• カネの知識

• モノの知識

• ヒトの知識



オブジェクト指向分析の知識

• ヒト/モノ(オブジェクト)が、

• 相互にメッセージで会話する、

• 一連の相互作用を把握/表現するもの。


※個人的な意訳です:-)

抽象化能力重要


カネの知識

‣ 簿記 (ITの祖先。世界最古のシステムでもある。)

‣ 財務会計

‣ 管理会計

‣ IFRS (国際会計基準のうち資産負債アプローチ)



モノの知識

‣ 生産工学 (100年以上の歴史)

‣ ソフトウェア工学 (品質の考え方)

‣ Web アプリケーションフレームワーク

‣ IaaS (AWS / さくらのクラウド、VPS)

‣ スマートフォン

‣ デスクトップ自動化 (VBAなど)

‣ 3D プリンタ?



ヒトの知識

‣ 経営学全般 ‣ 経営学自体は主観的要素が強い。 ‣ オレはこう思う、に対する批評や事例研究が中心 ‣ でも、決して無駄な議論ではないものも多い。

‣ 例えば、組織運営や生産性向上など。


難しいのは、聞く側のコンディションによって、受け取り方が変わってしまうこと (経験あり)


サービスエンジニア(アーキテクト)のミッション

• 業務の構造化 (運用の構造を明確にする。)

• 期待の客観化 (運用品質を定義する。)

• 実績の測定化 (運用実績をデータに語らせる。)


運用現場の日常活動を「継続的」に「計測」し「振り返る」ための仕組みを構築する。


(参考) 電子書籍は重要

✴ 専門書PDF (O’reilly / 技評 / オーム社) ✴ 一般書籍 (KoBo / Amazon Kindle)


‣ 午前3時でも思い立ったら3分で購入完了。

‣ 積ん読の見えない化 (際限なく買っちゃいますね。オライリー本とか。)

‣ 割安で効率良くまとまっている。(知識大量消費時代の到来、急速な選別化)

‣ O’reilly の電子書籍全部読んできた新卒社員とか、オッサン中堅には危険すぎる存在。

‣ だがしかし、「学ぶ年寄り」には永久に追い付けないんじゃないか仮説 (豊富な前提知識と勘どころ)

‣ 電子書籍読まない、のはエンジニアにはハイリスクすぎる選択肢



Let’s buy電子書籍


8. 余談クラウドの運用になってインフラエンジニアは何が変わるのか?

ドキュメント管理ポリシー

Level-0. 管理しない (個人任せ)

Level-1. 台帳管理 (リスト化)

Level-2. バージョン管理/検索機能

Level-3. 分散協調管理 (集中管理は破綻するという仮説より)

5. 運用設計の諸要素

運用基盤の整備現在のレベルを記入する「ポリシーレベル」

2009年 InternetWeek 「運用方法論」より

ドキュメント管理ポリシー

Level-0. 管理しない (個人任せ)

Level-1. 台帳管理 (リスト化)

Level-2. バージョン管理/検索機能

Level-3. 分散協調管理 (集中管理は破綻するという仮説より)

5. 運用設計の諸要素

運用基盤の整備現在のレベルを記入する「ポリシーレベル」

2009年 InternetWeek 「運用方法論」より

Sphinx ならできるよ

JAWS-UG CLI勉強会 #24 (7/20 茅場町)

• 設立1周年記念イベント

• Sphinx-Users.jpとの共催

• 午前: Sphinxで構造化記法を使ってWebコンテンツ作成 • 午後: AWS CLIを利用してS3上に静的Webサイトを構築します。


Let’s buy

Sphinx連載は4月号からですけど


8. 宣伝クラウドの運用になってインフラエンジニアは何が変わるのか?


JAWS-UG CLI専門支部

• AWS CLIを使いこなしたいユーザの集まり。

• Unified AWS CLIの他、AWS API、CloudFormation、Lambdaが対象とします。 (SDKやIDEは対象外)

• 「運用エンジニアのためのAWS」知識や経験の交換をしていきましょう!

• 互助的な勉強会です! 間違いがあったらごめんなさい(><

• ハンズオン20回 • 呑み会3回

AWS Summit 2014の会場で立ち上げ (2014年7月)

> aws _

HUB #1 Elastic Beer’s Talk入門HUB #2 Elastic Cloud Communicationg(EC2)入門

JAWS-UG CLI勉強会 #21 (5/25 茅場町)

• ハンズオン中心の相互勉強会

• コワーキングスペースを利用 (ドロップイン費用1000円)

• 後半は、雑談タイム。(今回はIAM RoleのLT)

AWS Config入門


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

OperationLab運用設計

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

2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?

Internet

2015-05-23 クラウドの運用になってインフラエンジニアは何が変わるのか?