2015年9月、新しいAWSのユーザーグループ「Ops JAWS」の第一回、Ops JAWS #1が 開催されました。
会場は目黒のアマゾンデータサービスジャパン本社、受付の奥にあるおしゃれスペースです。階段式の椅子にみんなで座るとなんだかほっこりしますね。

オープニング

今回の司会担当、宮越さんよりオープニング。「会ったことないんですけど…」と今回のOpsJAWSの立ち上げに協力してくださったオペレーションじょうずの比企さんと、JAWS-UG 吉田さんのご紹介。

ちなみにJAWS-UGの各支部はオリジナルの鮫ロゴを持っていることが多いですが、Ops JAWSはまだないそう。

このスライドの左下は、宮越さん作の仮ロゴ。「もうこれでいいのでは？」との声も当日ありましたが、「パワポで作ったんで、近づいたらめっちゃ荒いんです…」と宮越さん。ロゴを作ってくださる方、運営のみなさまへぜひご一報を。

AWSの運用管理コミュニティについてご紹介→アウトプッターを募集しています！とのこと。指摘も大歓迎です。

OSC2015にも、OpsJAWSが参加します！

今後も継続して勉強会を開催予定です。

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

本編、トップバッターは運用設計ラボの波田野さん。

今日のタイトルは「オンプレからクラウドで何が変わるのか」。なんと資料が51ページ。熱いです。

以下ダイジェスト版でお送りします。

1.カネが変わる

• 保有→利用が目的へ
• 資産から費用へ（資産から売り上げ原価へ、コストセンターから売り上げ原価へ）

2.時間が変わる

• リードドタイムが月単位から分単位へ
• 利用単位が年単位から時（ミリ秒）単位へ
• 最低利用期間が月前提からゼロへ（最低利用期間の縛りがなくなった）

3.やり方が変わる

• 作り込みから使い捨てへ
• 運用でカバーから設計で保証へ
• アーキテクチャで落ちないことを保証しましょうという世界へ

「運用」の本質とは何か？

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

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

クラウド時代のサービスとは＝利用者の課題を解決すること

サーバ屋さん…「落とさなければいい」が本音。手段には注力するが、その手段が何に使われるかを意識していないことが多い。これからはお守りでなく、専門性や基盤で支援することができなければ生き残りは難しいかも？

• 「運用」とは「サービスデリバリ」である
• 「運用」を「サービスデリバリ」として捉える

AWSがまさにそう。IaaSをサービスデリバリし、PaaS、SaaSを提供している（上位に対してサービスをデリバリ。Iaas→Paas→SaaS）

サービス価値とデリバリの価値を掛け合わせて＝運用現場の価値

リソースは有限なので、目的（サービス価値＝経営や実務、そして売り上げ）と手段（デリバリ価値＝エンジニアリング価値（生産工学＝売り上げ原価））が大切。どちらかだけでもだめ

サービス価値がないと、運用の価値を提供できない…自前主義の終焉　全てのプロセスについて自力でセキュリティを守ることは不可能　全てのレイヤを自前で用意することが割に合わなくなってきた

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

運用の本質は「価値の提供」…価値を提供できれば手段は何でもない

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

非公開資料部分では、OpsOps/OpsDevの未来について、お話がありました。
波田野さんからの喝を希望（？）の方は、ぜひ次回OpsJAWSへ。

cloudpack MSP運用の表と裏

二番目のメイン登壇は、cloudpack新谷さん。タイトルは「cloudpack MSP運用の表と裏」。「裏はあまり話せないかもしれませんが…」と濁しつつも、

現在、設計・構築をcloudpackでやってくれないかという話も多くなってきているという状況とのこと。その場合どうやってやっていくか、クラウドでこういう運用をしたほうがいいのではという話をしているそう（運用で必要なものの提示をする等）

cloudpackのセクション説明からスタートし、MSPの役割についてのご説明。24/365でアラート対応はしているが、依頼対応は営業時間内で行っているそう。

なぜcloudpackでSOC2運用を行うのか

• クラウドってセキュリティ大丈夫なの？というお客様　→AWSなどが担保してくれる
• クラウド運用のセキュリティ大丈夫なの？→ここは自分たちで担保しないといけない。品質保証もそう。

MSP運用する場合のSOC2対応は主にこの2つ

• 障害対応
• システム変更対応

SOC2では必ず承認が必要となる（品質は上がるが、スピードは遅くなる）

SOC2では必ず作業をトレースできるようにログを残す必要あり

AWSのコンソールについては、個人で何をやったのか残す必要があるので、Backlogで管理。IAMを発行してCloudTrailを利用。S3に保存。

踏み台サーバ　→どのような作業をしたかは自動でS3に保存される仕組み

LDAPで認証　→どのような作業をやるかと作業履歴が対になるようにしている

MSP運用で使っているツール（自社サービスのadminpack、pagerdutyなど）

「各々の連携では苦労している…」と語った新谷さん。メンバーのみなさんの努力があるのだろうな、と少し垣間見えた気がしました。

非公開資料の部分では、「運用において、全ての情報をwikiに記載することは不可能」と前置きし、運用中の顧客要望の変更、システム設計に関する考え方の違い（MSPと設計構築での違い）、アラート対応（これもお客様により要望は違う）についてお話しされました。

（人海戦術で）対応します！という言葉と共に、垣間見えたメンバー同士の「助け合い」。Slackでのやりとりで、声をかけあって…など、「結局は、人の手に頼らざるを得ない」という言葉での締めくくりとなりました。

運用視点でのAWSサポート利用Tips

ラストとなる三番目の登壇、ADSJの関山さん。「supportを叩くと私が呼び出されますw」と明るい（？）自己紹介。

AWSサポートの概要、AWSサポートの提供内容について説明。全サービスがサポート対象。

サポート起票時のポイント2つ

• 「緊急度」は「ビジネスインパクト」を基準に選択する。
• 調査に必要な情報を明記する　→例：ログや画面キャプチャは省力せずにそのまま記載を…！とのこと。メモ。

運用とAWSサポート

AWS Support API、Trusted Adviserを運用に活かす、運用に組み込む

AWS Support API Tipsは以下

• Trusted Adviserのチェック項目を確認する
• イベント発生時にサポートケースを自動起票する
• 過去のケース履歴をエクスポートする

Support APIの裏側では恐ろしいことが…

サポートケースの奥に人がいることを忘れないで・・・と、まさに中の人の声を聞くことができました。

勉強会の裏側で

実は当日、最初っからお酒、お食事が用意されている豪華バージョン勉強会（参加費は1000円でした）。お仕事後に駆けつけた参加者をもてなしてくださいました。運営、ご登壇のみなさま、ありがとうございました！

最後は記念撮影

撮影者はADSJのイケメンSA、酒徳さんでした。

P.S. ドラ・パイご利用の際はお申し付けください(^^)