cloudpack MSP 運用の表と裏

2015.9.1cloudpack

MSP セクション 新谷　充

OpsJAWS#1

自己紹介

☁新谷　充（あらや　みつる）☁アイレット株式会社 cloudpack 事業部 MSP セクション– セクションリーダー

☁ AWS 認定ソリューションアーキテクト – プロフェッショナル☁ AWS 認定 DevOps エンジニア – プロフェッショナル

☁好きな AWS のサービス　 RDS

アジェンダ

☁cloudpack の技術系セクション説明及び連携

☁MSP セクションの役割☁MSP 運用と SOC2 対応☁MSP 運用で使っているツール☁実際にどのように運用しているのか

cloudpack の技術系セクション説明及び連携

☁設計・構築運用セクション→ 設計など長期スケジュールの構築＊エンタメ系、エンプラ系など複数セクションに分かれている

☁MSP セクション→24/365 の運用や短納期系の構築を担当

☁開発セクション→ アプリ・ API 開発などを伴う案件を中心に担当

☁社内インフラ・ Security ＆ NW セクション→ 顧客対応は DirectConnect や DeepSecurity を担当

cloudpack の技術系セクション説明及び連携

☁原則運用は MSP にて行う→ 他セクションは運用に乗せるまで

☁各セクションは引継ぎ資料を MSP に提出→Backlog の wiki を活用☁引継ぎ資料に無い対応はエスカレーション→ お客様への一次連絡は MSP にて行う

アジェンダ

☁cloudpack の技術系セクション説明及び連携

☁MSP セクションの役割☁MSP 運用と SOC2 対応☁MSP 運用で使っているツール☁実際にどのように運用しているのか

MSP セクションの役割

☁定例業務→ 定期動作チェック、定期監視チェック、レポート作成など

☁アラート監視→ お客様連絡、一次対応（障害切り分け）など

☁環境構築→ 短納期（キャンペーン系など）の構築

☁通常依頼対応→ ユーザ追加、設定変更など

☁運用設計→ 既に構築済で運用から cloudpack に依頼する場合の設計及び環境整備

cloudpack ではアラート（障害）対応は 24/365 で行っているが依頼対応は原則営業時間帯の受付となっている

MSP セクションの役割

☁シフト通常シフト ： 10:00 – 19:00早シフト ： 8:00 – 17:00遅シフト ： 14:00 – 23:00夜間シフト ： 23:00 – 8:00

＊土日祝日は通常シフトは無し

アジェンダ

☁cloudpack の技術系セクション説明及び連携

☁MSP セクションの役割☁MSP 運用と SOC2 対応☁MSP 運用で使っているツール☁実際にどのように運用しているのか

MSP 運用と SOC2 対応

SOC2 ってご存知ですか？→ 受託業務に係る内部統制の保証報告書（ SOC 報告書：Reporting on Controls at a Service Organization ）の事を言います。 cloudpack がお客様へサービスを提供する際に、このサービスを提供する cloudpack の内部統制のデザインや運用状況について、監査法人や公認会計士が独立した第三者の立場から客観的に検証した結果を記載したものです。報告書では、一定の基準やガイダンスに基づく合理的な保証（絶対的ではないものの、相当程度に高いレベルでの意見）が表明されます。

参考：http://blog.cloudpack.jp/2015/07/15/what-is-soc2-type1-report-for-cloudpack/

MSP 運用と SOC2 対応

なぜ cloudpack で SOC2 運用を行うのか☁クラウドってセキュリティは大丈夫なの？→ クラウド自体のセキュリティは AWS などクラウドベンダーが担保してくれます

☁クラウド運用のセキュリティは大丈夫なの？→ ここは自分たちで担保する必要があります。セキュリティのみでなく品質などのサービスレベルも第三者に検証して貰う事でお客様の安心を頂く事を狙いとしています。

MSP 運用と SOC2 対応

MSP 運用する場合の SOC2 対応は主に下記の二つとなります。☁障害対応☁システム変更対応→全てにおいてお客様・作業者・管理者にて証跡を残しています。

MSP 運用と SOC2 対応

☁SOC2 では必ず承認が必要となります→品質はあがりますが、スピード的には遅くなります

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

→莫大なログの保管と調査可能な仕組みが必要となります

という事で人的にもサーバリソース的にも多大なコストがかかります。

MSP 運用と SOC2 対応

下記の仕組みにより人的コストは減らしています

☁AWSコンソール作業→個人単位 IAM アカウントでコンソールにログインしCloudTrail にてログを S3 に保存

☁サーバ作業→個人単位OS アカウントにて踏み台サーバにログインし作業ログを自動で S3 に保存

各ログインは LDAP 認証で行い、ログインの前に Backlog の課題番号を登録が必須

アジェンダ

☁cloudpack の技術系セクション説明及び連携

☁MSP セクションの役割☁MSP 運用と SOC2 対応☁MSP 運用で使っているツール☁実際にどのように運用しているのか

MSP 運用で使っているツール

MSP 運用で使っているツール

アジェンダ

☁cloudpack の技術系セクション説明及び連携

☁MSP セクションの役割☁MSP 運用と SOC2 対応☁MSP 運用で使っているツール☁実際にどのように運用しているのか

実際にどのように運用しているのか

作業依頼・障害対応を wiki に掲載されている内容に従って、顧客連絡及び対応を行っています。

以上

実際にどのように運用しているのか

そんな簡単にいくわけありません！

cloudpack では数百の案件、数千のサーバ（インスタンス）を運用していたりしますお客様の要望には（基本的には）全て応えます！まさにクラウドコンピューティングだからできる事です

実際にどのように運用しているのか

☁運用○設計・構築運用が wiki に案件情報を記載　■顧客情報、システム構成、障害対応手順　→全ての情報を記載するのは難しい○運用中の顧客要望の変更　■運用レベルの見直しは MSP にて対応　→ MSP にて顧客調整も実施　■顧客要望によるシステム変更　→既存影響などあるため、設計・構築運用にエスカレーション

実際にどのように運用しているのか

システム設計に関する考え方も MSP と設計構築で違います。例） DB に関する設計・ MSP の希望→冗長化・バックアップなどがマネージドされている RDS を使ってほしい・設計構築の希望処理速度や短時間フェイルオーバーを考えて EC2上に MySQL を構築してデータはエフェメラルディスクを使用して MHA による冗長化

当然お客様ありきの話です。 cloudpack では性能のみでなく運用負荷や障害復旧、データ消失のリスクを各セクションの意見をもって提案しています。

実際にどのように運用しているのか

☁アラート対応○アラート連絡レベル　■アラート全部　■サービス影響あった場合のみ　■一次対応の手順渡すので、まずは対応してほしい○連絡方法　■メールで連絡してほしい　　・ Backlog への連絡によるメールで問題ない　　・緊急連絡用のメーリングリストに連絡してほしい　■電話してほしい　　・出なかったら留守電で問題無い　　・複数人に順番で出るまで連絡してほしい

広範囲に影響が出ている障害時にシフト当番では厳しい場合もある。

実際にどのように運用しているのか

☁脆弱性対応○連絡までは一斉通知で可能　■個別に作業タイミングの調整　→場合によっては夜間帯や休日の対応　■お客様の環境による前提の違い　→個別に調査・手順書の作成

お客様の規模により 100台以上の規模のシステムもあれば 1台で LAMP 構成などもあり。→単純に構成管理ツール（ Chef や Ansible など）で対応できない

実際にどのように運用しているのか

運用・アラート対応・脆弱性対応など多数のパターンがあるためMSP のみでは厳しい場合が多々あります。

セクション関係無く（人海戦術で）対応します。

営業時間外→担当に電話及び slack で全体通知そうするとこんな感じでフォローが入ります。

実際にどのように運用しているのか

実際にどのように運用しているのか

システム化できる部分はシステム化し、標準化できる部分は標準化します。（アラート検知の仕組み、定例作業簡易化など）

ただ、結局は

人の力に頼らざるを得ません