Cloud Payment社内勉強会、ちょうど良かったのでde:codeの話をしてみた

1. Cloud Payment社内勉強会
de:code 行ってきて感じたことを
つれづれなるままに話すLT
2016.5.24
株式会社Cloud Payment
技術アドバイザー @yoshidashingo

2. 吉田真吾
☁ バックグラウンド
証券システム基盤開発
p 基盤開発、Oracleチューニングなど
APNプレミアコンサルティングパートナー
エバンジェリスト
p 講演年間113回(2013年実績)
p AWS設計・構築・移行(2014-2015)
☁ 現在のしごと
(株)セクションナイン 社長
p AWSコンサルティング
Mobingi, K.K. VP of Eng
p サービスデベロップメント
☁ 実績等
p AWSウルトラクイズ
初代チャンピオン (2012年)
p AWS Samurai 2014
p AWSエキスパート養成読本 執筆
p AWS認定全資格(5種類)保持
p Oracle Database 11g認定 (OCP,
Performance Tuning)保持

3. de:code 2016
☁Microsoftの年次テクニカルイベント
サティア・ナデラCEO、de:code 2016基調講演に登場
http://cloud.watch.impress.co.jp/docs/event/20160524_758822.html

4. キーワード
☁Apps, Not Infrastracture – Keynote –
☁Cloud, Automation, Culture – DevOps –
☁Developers Community
☁Cognitive, AI, Chat bot…

5. 1. Apps, Not Infrastracture.
☁エンタープライズの課題に「モジュールとし
てのプラットフォーム」ではなく「アプリと
してのプラットフォーム」を提供するという
スタンスを感じた
– Bridgestone Toolbox Touch デモ
– Excel Online + E2D3 デモ
– Power BI (Desktop) デモ
– Microsoft Cognitive Services

6. 2. Cloud, Automation, Culture
☁「カイゼン」「カンバン」「アジャイル道場」…
言葉を産んだのは日本なのに最もアジャイルが浸
透していない国＝日本
☁アジャイルもDevOpsもカルチャーが大事
☁Don't ask for permission, beg for forgiveness
– 実践を通じた「成功体験」の積み重ねが大事
→頭ではわかっても、体で理解するための成功体験

7. DevOpsって具体的になに？
Devのモチベーション
☁ たくさんの機能
☁ 手間なくどんどんデプ
ロイしたい
☁ 環境をすぐ調達したい
Opsのモチベーション
☁ サービスの継続性
☁ パフォーマンス
☁ 作業の手間、メンテの少
なさ
☁ 複雑性の少ないシステム
☁ 品質のよいアプリ
etc…

8. NOT OPS, BUT SERVICE MANAGEMENT
ITサービスマネジメントの文脈からDevOpsを理解する

9. ITサービスマネジメントとは
☁顧客のニーズに合致した適切なITサービスを提供
するマネジメント活動全般(ITIL)
☁ITサービスマネジメントの各種規格は、組織が
サービスマネジメントシステムを計画、確立、導
入、運用、監視、レビュー、維持するためのサー
ビス提供者に対する要求事項を規定した規格
☁必要な能力はITスキル標準(ITSS)や情報システム
ユーザースキル標準(UISS)にて明確化・体系化さ
れている

10. ITSMSの運用プロセス
n 設計及び移行
– 新規サービス又はサービス変更
の設計及び移行
n サービス提供プロセス
– サービスレベル管理
– サービスの報告
– サービス継続及び可用性管理
– サービスの予算業務及び会計業
務
– 容量・能力管理
– 情報セキュリティ管理
n 関係プロセス
– 事業関係管理
– 供給者管理
n 解決プロセス
– インシデント及びサービス要求
管理
– 問題管理
n 統合的制御プロセス
– 構成管理
– 変更管理
– リリース及び展開管理

11. Cloud, why?
☁ 構成管理/変更管理
– Infrastracture as Code
☁ リリース/展開管理
– Blue-Green Deployment
– ペット→家畜
☁ サービスの継続性
– グローバルなインフラ
– 動的な調達モデル
☁ 可用性管理
– マネージドなHA構成
☁ セキュリティ管理
– 責任分担モデル
☁ 容量・能力管理
– 容易なリソース制御
☁ サービスの予算業務
– コストがコントローラブ
ル

12. Automation, why?
☁月1回/8時間のリリースメンテ vs
1日10回のリリース、ダウンタイムゼロ
– 自動化でOps側のメンテコストをダウン
– リリース回数に関わらず「作業品質を担保する
ための自動化」
– つまりサービス品質の向上とコストダウンは両
立可能

13. Culture, why?
☁サービスマネジメントのアプローチから
考えると、DevとOpsのモチベーションは
両立できる→両立するために何が必要か、
一緒に考える姿勢が大事

14. “ソフトウェアシステムの一生の圧倒的大部分を
占めるのはそれを利用している期間であり、設計
したり構築している期間ではありません。なのに
なぜ従来の多くの知識体系では、ソフトウェアエ
ンジニアが大規模な設計や開発に焦点を当てるこ
とばかり主張しているのでしょうか？”
“このエッセイ・記事集では、GoogleのSite
Reliability Engineeringチームの主要メンバーた
ちが、なぜライフサイクル全体へのコミットメン
トすることが、世界規模で展開する大規模なソフ
トウェアシステムのビルド、デプロイ、モニタリ
ング、メンテナンスを可能にするかを説明してい
ます。”
Site Reliability Engineering
@Back Cover
https://landing.google.com/sre/book.html

15. 3. Developers Community
☁Don‘t repeat yourself (DRY原則)
– 似た課題にすでに取り組んでいる人がいる
– 自分が初めてなら積極的に公開する
☁技術の方向性と盛り上がり具合の確認
→積極的に参加してみよう

16. AWS Summit Tokyo 2016