1.
Operation Lab
運用設計ラボ
クラウドの運用になって
インフラエンジニアは何が変わるのか?
運用設計ラボ合同会社
シニアアーキテクト 波田野 裕一
2015-05-23
JAWS-UG Osaka 第13回勉強会
オペレーションじょうず

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

3.
オンプレミスからクラウドで何が変わるのか
1. カネが変わる
2. 時間が変わる
3. やり方が変わる
Operation Lab
運用設計ラボ

4.
オンプレミスからクラウドで何が変わるのか
• 保有から利用へ
• 「保有」が目的から「利用」が目的へ
• 資産から費用へ
• 見た目の成果(資産)から実質的な成果(売上原価)へ
• 共通配賦(コストセンター)から直接配賦(売上原価)ヘ
Operation Lab
運用設計ラボ
1. カネが変わる

5.
オンプレミスからクラウドで何が変わるのか
Operation Lab
運用設計ラボ
2. 時間が変わる
• 利用単位が年から分(秒)へ
• リソースの時間単価が年単位から分(秒)単位へ
• リードタイムが月から分へ
• リソースの調達リードタイムが月単位から分単位へ
• 最低利用期間が月前提からゼロへ
• 最低利用期間の縛りがなくなった

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

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

8.
Operation Lab
運用設計ラボ
「運用」を「サービスデリバリ」と捉える
リクエスト に対する デリバリ の繰り返し
顧客・外部サービス
outboundinbound
outboundinbound
外部支援組織
inbound
inbound
運用メンバー
outboundinbound
内部協調/支援組織
inbound
outbound
リクエストデリバリ
デリバリ
デリバリ
デリバリ
リクエスト
リクエストリクエスト
運用現場
窓口 フロントエンド
バックエンド
outbound
outbound
出典: 経営情報学会 2010年春季全国研究発表大会 「運用業務プロセスのモデル化」

9.
Operation Lab
運用設計ラボ
• 客観的に俯瞰することが可能
• 科学的手法による測定が可能
• 論理的手法による分析が可能
誰が見ても同じ「運用」へ
「運用」を「サービスデリバリ」と捉える
inbound outbound Quality
Cost
Delivery 品質という価値観
デリバリリクエスト
やっていること(mission)の見える化
成果(output)の見える化
期待(input)の見える化
時間という物性
金額という物性
売上原価
費用に見合った効果のある「運用」
かかるコストを直接配賦し
「売上原価」として貢献
運用方法論経営論

10.
Operation Lab
運用設計ラボ
参考: 問題解決のための論点整理
やっていること(mission)の見える化
成果(output)の見える化
期待(input)の見える化
適切な成果基準が必要
高負荷の解消
属人的の解消
費用対効果の見える化
運用方法論
経営論
運用業務を客観的、論理的に把握する必要
適切な客観化が必要

11.
Operation Lab
運用設計ラボ
• 社内のインフラ運用
• 依頼元部署へのサービスのデリバリと考える。
• 「道具のお守り」からの脱却
• アラート対応
• システムから「復旧リクエスト」が来たと考える。
• 「復旧というサービス」のデリバリという視点で考える。
参考:「運用」とは「サービスデリバリ」である

12.
Operation Lab
運用設計ラボ
デリバリの変化で
運用業務の変化を
認識可能
Platform as a Service
Software as a Service
Infrastructure as a Service
SaaS
PaaS
IaaS
上位に対してサービスをデリバリ
上位に対してサービスをデリバリ
上位に対してサービスをデリバリ
ユーザ 運用最小単位に
ライフサイクル
の概念
参考:「運用」とは「サービスデリバリ」である
運用業務全体に
ライフサイクル
の概念

13.
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

14.
Operation Lab
運用設計ラボ
Platform as a Service
Infrastructure as a Service
SaaS
PaaS
IaaS
上位に対してサービスをデリバリ
上位に対してサービスをデリバリ
上位に対してサービスをデリバリ
amazon.com
AWSの強さは「サービスデリバリ」の強さ
自前で
多層にわたって
サービスデリバリ
を実現している。
!
ドッグフーディング
参考:「運用」とは「サービスデリバリ」である
Software as a Service

15.
Operation Lab
運用設計ラボ
• 客観的に俯瞰することが可能
• 科学的手法による測定が可能
• 論理的手法による分析が可能
誰が見ても同じ「運用」へ
費用に見合った効果のある「運用」
かかるコストを直接配賦し
「売上原価」として貢献
運用方法論
経営論「サービス」の専門集団
「デリバリ」の専門集団
エンジニアリング価値
(生産工学)
サービス価値
(経営、実務)
「運用」に求められる2つの専門性
運用現場には、専門集団として2つの側面がある
目的
手段
「運用」=「サービスデリバリ」

16.
Operation Lab
運用設計ラボ
サービスとは何か? (仮説)
• エンドユーザの課題を解決すること
• 社内ユーザの課題を解決すること
• 誰かの課題を解決することを(間接的に)支援すること
全ての業務は「サービス」と捉えることができる
「運用」に求められる2つの専門性
利用者の「課題」を解決すること
サービス価値
(経営、実務)

17.
Operation Lab
運用設計ラボ
サービスとは何か? (利用者視点)
• 丸投げ: 代わりにやってもらう
• 半投げ: 手伝ってもらいながら自分でやる
• 丸被り: 自分でやる (自己責任)
(利用者視点)
「運用」に求められる2つの専門性
利用者の「課題」を解決すること
サービス価値
(経営、実務)

18.
Operation Lab
運用設計ラボ
サービスとは何か? (クラウド時代)
利用者の「課題」を解決すること
• SaaS: 代わりにやってもらう
• PaaS: 手伝ってもらいながら自分でやる
• IaaS: 自分でやる (自己責任)
費用型
資産型
• オンプレミス: 自分でやる (自己責任)
(利用者視点)
(利用者視点)
「運用」に求められる2つの専門性
丸投げ
半投げ
丸被り
丸被り
サービス価値
(経営、実務)

19.
Operation Lab
運用設計ラボ
プロダクト指向運用からサービス指向運用へ
従来: プロダクト指向運用
今後: サービス(課題解決)指向運用へ
• SaaS: 代わりにやってあげる
• PaaS: 専門性や基盤で支援してあげる
費用型 (提供者視点)
手段 の提供(コストセンター扱い)
道具のお守り
「運用」に求められる2つの専門性
利用者の「課題」を解決するか?
サービス価値
(経営、実務)

20.
Operation Lab
運用設計ラボ
Service
Operation
Service
Design
Service
Transition
Service
Strategy
プロダクト指向運用からサービス指向運用へ
従来: プロダクト指向運用
手段 の提供(コストセンター扱い)
道具のお守り
「運用」に求められる2つの専門性
ITライフサイクル (ITIL v3)
「運用」は結局下請け
Dev QA+Deploy
Ops
(コストセンター扱い)
サービス価値
(経営、実務)

21.
Operation Lab
運用設計ラボ
プロダクト指向運用からサービス指向運用へ
今後: サービス(課題解決)指向運用へ
• SaaS: 代わりにやってあげる
• PaaS: 専門性や基盤で支援してあげる
費用型 (提供者視点)
「運用」に求められる2つの専門性
考
作展
ユーザ
稼サービスの根幹は
稼ぐ人
考える人
それを支える
作る人
展げる人
Ops
Dev
Deploy QA
営業
事業戦略、運用設計
サービス運用現場
サービス開発(支援)
リリースマネジメント+営業
サービス価値
(経営、実務)

22.
Operation Lab
運用設計ラボ
デリバリとは何か? (仮説)
サービスを安定的合理的に提供すること
• 高度な反復性、再現性が求められる業務活動。
• 独自性よりも安定性、合理性が価値を持つ業務活動。
• 定量評価による合理性検証を前提とした業務活動。
全ての定常業務は「デリバリ」と捉えることができる
「運用」に求められる2つの専門性
エンジニアリング価値
(生産工学)

23.
Operation Lab
運用設計ラボ
SaaS
PaaS
IaaS
「サービス」の独自化と「デリバリ」の標準化
ユーザ
サービス価値
デリバリ価値
サービス価値の向上
(経営、実務)
エンジニアリング価値の向上
(生産工学)
独自色が求められる領域
標準化、スケーラビリティ
が求められる領域
目的
手段
デリバリ価値
サービス価値
X
= 運用現場の価値
「運用」に求められる2つの専門性

24.
Operation Lab
運用設計ラボ
SaaS
PaaS
IaaS
これからの「運用」
ユーザ
サービス価値
デリバリ価値
どの領域を
主戦場とするか?
客観的、論理的
「運用」に求められる2つの専門性
サービス価値の向上
(経営、実務)
独自色が求められる領域
目的
標準化、スケーラビリティ
が求められる領域
エンジニアリング価値の向上
(生産工学)
手段

25.
Operation Lab
運用設計ラボ
余談: OpsOpsもしくはOpsDevの未来
稼ぐ人
考える人
作る人
展げる人
OpsOps: サービス運用現場が全部やる
OpsDev: サービス運用現場が実装以外全部やる
稼ぐ人
考える人
作る人
展げる人
AWSとWebアプリケーションフレームワーク
が使えれば昔ほど難易度は高くない
(社内サービスの場合)
受託開発に近い
サービス指向運用
数年もすればVBAみたいな扱いに
(パブリックサービスの場合)
これからの「運用」

26.
Operation Lab
運用設計ラボ
余談: OpsOpsもしくはOpsDevの未来
稼ぐ人
考える人
作る人
展げる人
OpsOps: サービス運用現場が全部やる
内製もできるサービス運用現場
サービス指向運用
「運用もやっている開発現場」がありますが
と捉えなおしてみましょう。
サービス価値
(経営、実務)
エンジニアリング価値
(生産工学)
これからの「運用」

27.
Operation Lab
運用設計ラボ
まとめ: 「運用」の本質とは何か?
「運用」が「サービスデリバリ」であるならば
「運用」の本質は「価値の提供」となる。
決して「コストセンター」ではない
• 「サービス」とは、利用者の「課題」を解決すること
• 経営的な専門性 (サービス)
• 「デリバリ」とは、サービスを安定的合理的に提供すること
• 技術的な専門性 (エンジニアリング)

28.
Operation Lab
運用設計ラボ
Platform as a Service
Infrastructure as a Service
SaaS
PaaS
IaaS
上位に対してサービスをデリバリ
AWSはよくできている
上位に対してサービスをデリバリ
上位に対してサービスをデリバリ
ユーザ
EC2
S3
RDS EMR
Elastic Beanstalk
App
amazon.com
3. 「運用」の本質とは何か
Software as a Service

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

30.
Operation Lab
運用設計ラボ
自前主義の終焉
2つの側面で自前主義の時代は終焉
工場型モデル
全てのプロセスについて自力でセキュリティを守ることは不可能に
サービス
プロセス
サービス
基盤 自前での価値は
産みにくくなった
自前で価値を産みだせる
全てのレイヤを自前で用意することが割に合わなくなってきた
インフラ

31.
Operation Lab
運用設計ラボ
工場型モデル
優位性(コアコンピタンス)とは関係ない工程をマネージドサービスに処理させる
自前でスケールできない基盤をマネージドサービスに任せる
運用のコアコンピタンスとマネージドサービス
自前主義から、マネージドサービスの時代へ
サービス
プロセス
サービス
基盤 自前での価値は
産みにくくなった
自前で価値を産みだせる
インフラ

32.
Operation Lab
運用設計ラボ
「運用」イコール「サービス」の時代へ
「サービス」と「デリバリ」の両者を設計
サービス価値
(経営、実務)
エンジニアリング価値
(生産工学)
コアコンピタンス
サブコンピタンス
マネージド
サービス
利活用
運用
3者のいずれも激しく変化しつづけるはず

33.
Operation Lab
運用設計ラボ
• 「運用」の本質は「価値の提供」である。
• 実は、価値を提供できれば「手段」は何でも良い
• 自前時代の終焉
• 価値の最大化のためにコアコンピタンスの明確化が必要
• マネージドサービスの利用を前提とした時代へ
まとめ: 「インフラ自前主義」時代の終焉
一般的な専門性の専業インフラエンジニアは
歴史的役割を終えた。

34.
Operation Lab
運用設計ラボ
SaaS
PaaS
IaaS
これからのインフラエンジニア
ユーザ
サービス価値
デリバリ価値
サービス価値
(経営、実務)
独自色が求められる領域
標準化、スケーラビリティ
が求められる領域
目的
手段
「運用」に求められる2つの専門性
エンジニアリング価値
(生産工学)
クラウドの中の
スーパーエンジニア
大多数のエンジニア
仕事ないよ(>_<)
「ドッグフーディング」最強

35.
Operation Lab
運用設計ラボ
AWSはよくできている
EC2
S3
RDS EMR
Elastic Beanstalk
App
amazon.com
4. 「インフラ自前主義」の終焉
SaaS
PaaS
IaaS
ユーザ
サービス価値
サービス価値
(経営、実務)
独自色が求められる領域
大多数のエンジニア
仕事ないよ(>_<)
デリバリ価値
エンジニアリング価値
(生産工学)
クラウドの中の
スーパーエンジニア
「ドッグフーディング」最強

36.
Operation Lab
運用設計ラボ
5. 「運用改善」を考える
クラウドの運用になってインフラエンジニアは何が変わるのか?
∼「自動化」を考える前に

37.
「運用改善」は「成功」するのか?
Operation Lab
運用設計ラボ
経験的に「だいたい失敗する」
実施直後に「効果」を実感できるときもあるが、
1年もすると、次の「運用改善」が必要な状態に
• 場当たり的な「改善」の実施
• 客観的な「到達点」の不存在
• 「効果測定」の曖昧さ

38.
Operation Lab
運用設計ラボ
「運用改善」とは (仮説)
「運用の価値」を
現状よりも高めるための改善活動
ToBe (理想)が明確であれば、場当たり的な「改善」は避けられる。
ToBe (理想)
AsIs (現状)
運用改善

39.
Operation Lab
運用設計ラボ
「運用改善」が必要な状況とは (仮説)
• サービス価値の低下
• 処理能力の低下
• アジリティ (経営戦略への追随能力)の低下
運用の「価値」が低下している(可能性がある)状況
AsIs(現状)がわかれば、客観的な「到達点」を決めることもできる
サービス価値
(経営、実務)
エンジニアリング価値
(生産工学)

40.
Operation Lab
運用設計ラボ
「運用改善」はなぜ必要となるか (要因1)
• 外部からの情報と運用現場内部の情報の不均衡が「乖離」の原因
• 内部情報 (組織内の力関係を含む) > 外部からの情報 (経営方針、ユーザニーズ)
• 「組織の本能」としての「自己最適化」が「乖離」を拡大
• 「組織自体」が目的化する (変化を避ける、自己目的化、など局所最適化が発生)
運用現場と「外部」との乖離の存在、拡大
• 経営方針との乖離
• ユーザニーズとの乖離
運用現場と「外部」の乖離を解消する必要
サービス価値
(経営、実務)

41.
Operation Lab
運用設計ラボ
「運用改善」はなぜ必要となるか (要因2)
• 運用組織の成果とメンバー個人の業績評価基準が一致していない
• 運用メンバーの頑張りと組織の成果(外部からの評価)が連動しない
• 「生産性の向上」と矛盾する活動実体の存在
• 「定例会議」の自己目的化、「レポート」の自己目的化、など
運用現場「内部」での矛盾の存在、拡大
• 組織成果と業績評価基準の矛盾
• 活動実体の矛盾
運用現場「内部」の矛盾を解消する必要
エンジニアリング価値
(生産工学)

42.
Operation Lab
運用設計ラボ
「運用改善」とはどのような活動であるべきか
運用の「価値」の拡大
運用現場と「外部」との乖離の縮小、解消
• 経営方針との乖離
• ユーザニーズとの乖離
影響大
運用現場「内部」での矛盾の縮小、解消
• 組織成果と業績評価基準の矛盾
• 活動実体の矛盾
サービス価値
(経営、実務)
影響小 (相対的)
エンジニアリング価値
(生産工学)

43.
Operation Lab
運用設計ラボ
まとめ:「運用改善」とは
ToBe (理想)
AsIs (現状)
運用改善
「運用の価値」を
現状よりも高めるための改善活動
運用現場と「外部」との乖離の縮小、解消
運用現場「内部」の矛盾の縮小、解消
影響大
影響小(相対的)
サービス価値
(経営、実務)
エンジニアリング価値
(生産工学)

44.
Operation Lab
運用設計ラボ
参考:「運用改善」のライフサイクル
運用現場と「外部」との乖離の縮小、解消
運用現場「内部」の矛盾の縮小、解消
影響大
影響小(相対的)
「運用」を客観的に捉える
運用の「価値」の拡大
Phase2. 任務(mission)の客観化
Phase3. 実績(output)の客観化 Phase1. 期待(input)の客観化
「運用」と「経営」の指針を合致させる
ToBe
(理想)
AsIs
(現状)
接 近
サービス価値
(経営、実務)
エンジニアリング価値
(生産工学)

45.
Operation Lab
運用設計ラボ
Platform as a Service
Infrastructure as a Service
SaaS
PaaS
IaaS
上位に対してサービスをデリバリ
AWSはよくできている
上位に対してサービスをデリバリ
上位に対してサービスをデリバリ
EC2
S3
RDS EMR
Elastic Beanstalk
App
amazon.com
5. 「運用改善」を考える
Software as a Service
サービス価値
(経営、実務)
エンジニアリング価値
(生産工学)
「運用」と「経営」の指針が合致
「運用」を客観的に捉えている (Metric)
独自色あるサービスで
一人勝ち
ユーザ

46.
Operation Lab
運用設計ラボ
おまけ: 「運用改善」が「成功」する要因
• アラートメールが減った (400万通->数万通/年)
• 成果に必要な工数(時間)が減った (2時間->10秒)
• 部署間調整に必要な時間が減った (40人日->8人日)
経験的に「客観化」がキー
「誰がどう見ても同じ数字や事実」で
Before/Afterを示すことが重要
+ チューニングできる余地を残しておくこと

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

48.
Operation Lab
運用設計ラボ
自動化は、「客観化の結果」であって「目的」ではない。
「自分達のやっていることの安定化&永続化のために」、目的:
手段: 自動 「客観化(構造化)された業務の一部」を自動化する。
「目的と手段がひっくりかえる」ことは、よくある
クラウド時代の「自動化」は正義か?
「自動化が目的」の場合はNo
「自動化が手段」の場合はYes

49.
「自動化が目的」の弊害
• 属人化
• 「自動化された業務」の保守が属人化する。
• プロセスの硬直化
• 「自動化された業務」の仕様忘却による変更不可などにより、
業務プロセスが硬直化する。
• トラブル発生時のインパクト
• 「自動化された業務」の処理フローが不明なため、手動では
リカバリができない。
Operation Lab
運用設計ラボ

50.
Operation Lab
運用設計ラボ
クラウド時代の「運用」のキーワード
「問題を根性で解決するのは馬鹿です。
問題をエンジニアリングで解決するのが
エンジニアの仕事です」
@yoshiori
構造化ここでは「エンジニアリング(工学)の実践」に近い意味で使います。
工学では何らかの構造物・構造体を作ることが不可避なためです。
http://d.hatena.ne.jp/Yoshiori/20120217/1329491437

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

52.
スーパーエンジニアになる
• まずは、とにかく「実際に触ってみる」ことが第一歩。
• 離れた分野をいくつか経験していると、差別化しやすい。
• ITについては、抽象化能力(設計能力)と具体化能力(実装能力)の
バランスが重要。
• 痛い目にあった経験は特に得難い財産になる。
Operation Lab
運用設計ラボ
いわゆるスーパーエンジニアかどうかは、
知っているか、経験しているか、が大きい。
「どれだけ地雷を踏み抜いて、どれだけ血を流したか」は、
運用屋さんとしての価値に決定的な影響(涙)。
※発表者はスーパーエンジニアではありません。
明日のエンジニアライフのために

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

54.
サービスエンジニアリングに必要な知識
• 抽象化手法 (特にオブジェクト指向分析)
• カネの知識
• モノの知識
• ヒトの知識
Operation Lab
運用設計ラボ
明日のエンジニアライフのために

55.
オブジェクト指向分析の知識
• ヒト/モノ(オブジェクト)が、
• 相互にメッセージで会話する、
• 一連の相互作用を把握/表現するもの。
Operation Lab
運用設計ラボ
※個人的な意訳です:-)
抽象化能力重要
明日のエンジニアライフのために

56.
カネの知識
‣ 簿記 (ITの祖先。世界最古のシステムでもある。)
‣ 財務会計
‣ 管理会計
‣ IFRS (国際会計基準のうち資産負債アプローチ)
Operation Lab
運用設計ラボ
明日のエンジニアライフのために

57.
モノの知識
‣ 生産工学 (100年以上の歴史)
‣ ソフトウェア工学 (品質の考え方)
‣ Web アプリケーション フレームワーク
‣ IaaS (AWS / さくらのクラウド、VPS)
‣ スマートフォン
‣ デスクトップ自動化 (VBAなど)
‣ 3D プリンタ?
Operation Lab
運用設計ラボ
明日のエンジニアライフのために

58.
ヒトの知識
‣ 経営学全般
‣ 経営学自体は主観的要素が強い。
‣ オレはこう思う、に対する批評や事例研究が中心
‣ でも、決して無駄な議論ではないものも多い。
‣ 例えば、組織運営や生産性向上など。
Operation Lab
運用設計ラボ
難しいのは、聞く側のコンディションによって、
受け取り方が変わってしまうこと (経験あり)
明日のエンジニアライフのために

59.
サービスエンジニア(アーキテクト)のミッション
• 業務の構造化 (運用の構造を明確にする。)
• 期待の客観化 (運用品質を定義する。)
• 実績の測定化 (運用実績をデータに語らせる。)
Operation Lab
運用設計ラボ
運用現場の日常活動を「継続的」に「計測」し
「振り返る」ための仕組みを構築する。
明日のエンジニアライフのために

60.
(参考) 電子書籍は重要
✴ 専門書PDF (O reilly / 技評 / オーム社)
✴ 一般書籍 (KoBo / Amazon Kindle)
Operation Lab
運用設計ラボ
‣ 午前3時でも思い立ったら3分で購入完了。
‣ 積ん読の見えない化 (際限なく買っちゃいますね。オライリー本とか。)
‣ 割安で効率良くまとまっている。(知識大量消費時代の到来、急速な選別化)
‣ O reilly の電子書籍全部読んできた新卒社員とか、オッサン中堅には危険す
ぎる存在。
‣ だがしかし、「学ぶ年寄り」には永久に追い付けないんじゃないか仮説 (豊
富な前提知識と勘どころ)
‣ 電子書籍読まない、のはエンジニアにはハイリスクすぎる選択肢
明日のエンジニアライフのために

61.
Operation Lab
運用設計ラボ
Let s buy電子書籍

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

63.
ドキュメント管理ポリシー
Level-0. 管理しない (個人任せ)
Level-1. 台帳管理 (リスト化)
Level-2. バージョン管理/検索機能
Level-3. 分散協調管理
(集中管理は破綻するという仮説より)
5. 運用設計の諸要素
運用基盤の整備
現在のレベルを記入する 「ポリシーレベル」
2009年 InternetWeek 「運用方法論」より

64.
ドキュメント管理ポリシー
Level-0. 管理しない (個人任せ)
Level-1. 台帳管理 (リスト化)
Level-2. バージョン管理/検索機能
Level-3. 分散協調管理
(集中管理は破綻するという仮説より)
5. 運用設計の諸要素
運用基盤の整備
現在のレベルを記入する 「ポリシーレベル」
2009年 InternetWeek 「運用方法論」より
Sphinx ならできるよ

65.
JAWS-UG CLI勉強会 #24 (7/20 茅場町)
• 設立1周年記念イベント
• Sphinx-Users.jpとの共催
• 午前: Sphinxで構造化記法を使ってWebコンテンツ作成
• 午後: AWS CLIを利用してS3上に静的Webサイトを構築します。

66.
Operation Lab
運用設計ラボ
Let s buy
Sphinx連載は4月号からですけど

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

68.
Operation Lab
運用設計ラボ
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)入門

69.
JAWS-UG CLI勉強会 #21 (5/25 茅場町)
• ハンズオン中心の相互勉強会
• コワーキングスペースを利用 (ドロップイン費用1000円)
• 後半は、雑談タイム。(今回はIAM RoleのLT)
AWS Config入門

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