20150901 ops jaws_araya_v2

20150901 ops jaws_araya_v2

1. 1. cloudpack MSP運用の表と裏 2015.9.1 cloudpack MSPセクション 新谷 充 OpsJAWS#1
2. 2. 自己紹介 ☁新谷 充（あらや みつる） ☁ アイレット株式会社 cloudpack事業部MSPセクション – セクションリーダー ☁ AWS 認定ソリューションアーキテクト – プロフェッショナル ☁ AWS 認定 DevOps エンジニア – プロフェッショナル ☁ 好きなAWSのサービス RDS
3. 3. アジェンダ ☁cloudpackの技術系セクション説明及び連携 ☁MSPセクションの役割 ☁MSP運用とSOC2対応 ☁MSP運用で使っているツール ☁実際にどのように運用しているのか
4. 4. cloudpackの技術系セクション説明及び連携 ☁設計・構築運用セクション →設計など長期スケジュールの構築 ＊エンタメ系、エンプラ系など複数セクションに分かれている ☁MSPセクション →24/365の運用や短納期系の構築を担当 ☁開発セクション →アプリ・API開発などを伴う案件を中心に担当 ☁社内インフラ・Security＆NWセクション →顧客対応はDirectConnectやDeepSecurityを担当
5. 5. cloudpackの技術系セクション説明及び連携 ☁原則運用はMSPにて行う →他セクションは運用に乗せるまで ☁各セクションは引継ぎ資料をMSPに提出 →Backlogのwikiを活用 ☁引継ぎ資料に無い対応はエスカレーション →お客様への一次連絡はMSPにて行う
6. 6. アジェンダ ☁cloudpackの技術系セクション説明及び連携 ☁MSPセクションの役割 ☁MSP運用とSOC2対応 ☁MSP運用で使っているツール ☁実際にどのように運用しているのか
7. 7. MSPセクションの役割 ☁ 定例業務 →定期動作チェック、定期監視チェック、レポート作成など ☁ アラート監視 →お客様連絡、一次対応（障害切り分け）など ☁ 環境構築 →短納期（キャンペーン系など）の構築 ☁ 通常依頼対応 →ユーザ追加、設定変更など ☁ 運用設計 →既に構築済で運用からcloudpackに依頼する場合の設計及び環境整備 cloudpackではアラート（障害）対応は24/365で行っているが依頼対応 は原則営業時間帯の受付となっている
8. 8. MSPセクションの役割 ☁シフト 通常シフト ：10:00 – 19:00 早シフト ：8:00 – 17:00 遅シフト ：14:00 – 23:00 夜間シフト ：23:00 – 8:00 ＊土日祝日は通常シフトは無し
9. 9. アジェンダ ☁cloudpackの技術系セクション説明及び連携 ☁MSPセクションの役割 ☁MSP運用とSOC2対応 ☁MSP運用で使っているツール ☁実際にどのように運用しているのか
10. 10. 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/
11. 11. MSP運用とSOC2対応 なぜcloudpackでSOC2運用を行うのか ☁クラウドってセキュリティは大丈夫なの？ →クラウド自体のセキュリティはAWSなどクラウドベンダーが 担保してくれます ☁クラウド運用のセキュリティは大丈夫なの？ →ここは自分たちで担保する必要があります。セキュリ ティのみでなく品質などのサービスレベルも第三者に検証 して貰う事でお客様の安心を頂く事を狙いとしています。
12. 12. MSP運用とSOC2対応 MSP運用する場合のSOC2対応は主に下記 の二つとなります。 ☁障害対応 ☁システム変更対応 →全てにおいてお客様・作業者・管理者にて証跡を残 しています。
13. 13. MSP運用とSOC2対応 ☁SOC2では必ず承認が必要となります →品質はあがりますが、スピード的には遅くなります ☁SOC2では必ず作業をトレースできるよう にログを残す必要があります →莫大なログの保管と調査可能な仕組みが必要となります という事で人的にもサーバリソース的にも 多大なコストがかかります。
14. 14. MSP運用とSOC2対応 下記の仕組みにより人的コストは減らしています ☁AWSコンソール作業 →個人単位IAMアカウントでコンソールにログインし CloudTrailにてログをS3に保存 ☁サーバ作業 →個人単位OSアカウントにて踏み台サーバにログインし 作業ログを自動でS3に保存 各ログインはLDAP認証で行い、ログインの 前にBacklogの課題番号を登録が必須
15. 15. アジェンダ ☁cloudpackの技術系セクション説明及び連携 ☁MSPセクションの役割 ☁MSP運用とSOC2対応 ☁MSP運用で使っているツール ☁実際にどのように運用しているのか
16. 16. MSP運用で使っているツール
17. 17. MSP運用で使っているツール
18. 18. アジェンダ ☁cloudpackの技術系セクション説明及び連携 ☁MSPセクションの役割 ☁MSP運用とSOC2対応 ☁MSP運用で使っているツール ☁実際にどのように運用しているのか
19. 19. 実際にどのように運用しているのか 作業依頼・障害対応をwikiに掲載されている 内容に従って、顧客連絡及び対応を行って います。 以上
20. 20. 実際にどのように運用しているのか そんな簡単にいくわけありません！ cloudpackでは 数百の案件、数千のサーバ（インスタンス）を運 用していたりします お客様の要望には（基本的には）全て応えます！ まさにクラウドコンピューティングだからできる 事です
21. 21. 実際にどのように運用しているのか ☁運用 ○設計・構築運用がwikiに案件情報を記載 ■顧客情報、システム構成、障害対応手順 →全ての情報を記載するのは難しい ○運用中の顧客要望の変更 ■運用レベルの見直しはMSPにて対応 →MSPにて顧客調整も実施 ■顧客要望によるシステム変更 →既存影響などあるため、設計・構築運用にエスカレーション
22. 22. 実際にどのように運用しているのか システム設計に関する考え方もMSPと設計構築で違います。 例）DBに関する設計 ・MSPの希望 →冗長化・バックアップなどがマネージドされているRDSを 使ってほしい ・設計構築の希望 処理速度や短時間フェイルオーバーを考えてEC2上にMySQLを 構築してデータはエフェメラルディスクを使用してMHAによる 冗長化 当然お客様ありきの話です。cloudpackでは性能のみでなく運用 負荷や障害復旧、データ消失のリスクを各セクションの意見を もって提案しています。
23. 23. 実際にどのように運用しているのか ☁アラート対応 ○アラート連絡レベル ■アラート全部 ■サービス影響あった場合のみ ■一次対応の手順渡すので、まずは対応してほしい ○連絡方法 ■メールで連絡してほしい ・Backlogへの連絡によるメールで問題ない ・緊急連絡用のメーリングリストに連絡してほしい ■電話してほしい ・出なかったら留守電で問題無い ・複数人に順番で出るまで連絡してほしい 広範囲に影響が出ている障害時にシフト当番では厳しい場合もある。
24. 24. 実際にどのように運用しているのか ☁脆弱性対応 ○連絡までは一斉通知で可能 ■個別に作業タイミングの調整 →場合によっては夜間帯や休日の対応 ■お客様の環境による前提の違い →個別に調査・手順書の作成 お客様の規模により100台以上の規模のシステムもあれば1台で LAMP構成などもあり。 →単純に構成管理ツール（ChefやAnsibleなど）で対応できない
25. 25. 実際にどのように運用しているのか 運用・アラート対応・脆弱性対応など多数のパターンがあ るためMSPのみでは厳しい場合が多々あります。 セクション関係無く（人海戦術で）対応します。 営業時間外→担当に電話及びslackで全体通知 そうするとこんな感じでフォローが入ります。
26. 26. 実際にどのように運用しているのか
27. 27. 実際にどのように運用しているのか システム化できる部分はシステム化し、標準化できる部分 は標準化します。（アラート検知の仕組み、定例作業簡易 化など） ただ、結局は 人の力に頼らざるを得ません