EXCEL構成管理からの脱却と 次世代MSPとDevOps 2.0 ～by OpsJAWS～ 2017/03/11 JAWS days 2017 Twitter : #opsjaws

What’s OpsJAWS？ • 対象者：“運用”と言うワードに反応した方すべての方 • CDPとかアーキテクティングの話は結構よく聞きますが、 作ったものをどうやって維持・管理していますか？ • 結構独自のノウハウもっていたりする • それを共有する場 • 月に1度(程度)Meetupを開催 • MSPの運用現場紹介 • ツール＆サービス紹介 • LT大会 • AWS運用サービスハンズオン • Partner SAブログに運用Tips記事を掲載中 • やってみようシリーズなど . . . • http://aws.typepad.com/aws_partner_sa/2015/06/aws-ops.html Twitter : #opsjaws

Agenda 1. EXCEL構成管理からの脱却 1. 私なりのDevOpsの現状理解 SoEとSoR、DevとOpsみたいな観点で 2. Cloud時代のOpsに向けて 現状維持作業の効率化、補完 ＋α 2. 次世代MSP考察

DevOpsとは？ • 「開発チーム（Development）と運用チーム（Operations）がお互いに 協調し合うことで、開発・運用するソフトウェア／システムによってビジ ネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ 迅速にエンドユーザーに届け続ける」という概念 • Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割 は“システムの安定稼働”である。そのため、Devが新しい機能を追加した くても、Opsはシステムの安定稼働のために変更を加えたがらない、とい う対立構造が作られてしまっていた • 「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr（1日10回以上のデプロイ： Flickrにおける開 発と運用の協力）」

SoE？？　SoR？？ • スタートアップ、Web系企業 • ビジネスの価値に直結するようなシステム、サイトがほとんど • 細かい機能追加・カイゼンがビジネスに直結していくので、 リードタイムを短縮することが至上命題 • エンタープライズ（≒基幹系） • もともと（事務的な）業務効率を上げるためであり、ビジネスに直結 するようなものではないという性質 • コストカット目的

今日の対象者？ SoE SoR DevOps Dev Ops

エンタープライズでDevOps? • Web系が積極的に採用した“クラウド”が、エンタープライズへ 浸透していったことで、Web系からバズりだしたDevOpsもエ ンタープライズが興味を示し始めるようになった • 最初は単純移行した基幹システムも、クラウドの進化に合わせ て継続的な最適化が求められるように • Blackbeltでも紹介あり「失敗例を成功に変える AWSアンチパターン のご紹介 2016 」 http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-antipattern

DevとOpsの分業制は悪か？ • エンタープライズにおけるDevとOpsは別組織・別契約・別企業（の いずれか）であることが多い • しっかりとしたインターフェースを持ち、統率されている分業制は、 それはそれでのDevOps • 安全性が保たれてさえいれば、自動化・効率化がKPIにならない場合 ※求められるリードタイムが早くない場合 • ただし、中央集中型の定型業務のOpsだけでは、顧客満足を得られないケース • プラスαが必要 • システム特性や目的に合わせて、選択や融合していくのが現実解 • 大事なのは、DevもOpsも継続的によりよくしていこうという意志が存在する こと

• よりよくしようという一例としてのSystems managerの紹介

Systems manager　概要 • AWSの基本 • OSより下位レイヤーの部分はAWSで管理 • Systems managerのすごいところ • OS以上の管理ができる（ログインなしで） • 責任範囲は利用者だけど、AWSの機能を使って管理できるように • なんか構成変更されたみたいだけど大丈夫？みたいな発信ができるようになる

お見合い AP ミドル・各種SW OS周り AWSインフラ Dev Ops 誰？？？ 初期導入時はインフラ側 に任せて構築してもらっ たので、その後のメンテ もOpsでお願いできると 思いがち。 こういうところの状態管 理って、EXCELで手で更 新とかそういう文化が残 ってる 初期開発が終わり Opsフェーズに入ると、 Opsは、OS以下の安定 稼働に注力しがち…

Systems managerで解決 AP ミドル・各種SW OS周り AWSインフラ Dev Ops Systems managerで、 EC2内の各種コンポー ネント情報を管理可能

実現方法 • ソフトウェアインベントリ • AWS Configと連携、変更検知、通知可能 • 追跡だけで物足りない場合は、CLIや各種SDKで、各種コンポーネン トの状況を取得し、一覧化や可視化 • ViewerとしてのEXCELは秀逸

コンポーネントの一覧を確認可能

変更を追跡可能（AWS Config）

Snapshotから可視化 確認 顧客 AWS Config AWS Config Snapshot (json) Excel生成 AWS構成 パラメーターシート Lambda function Snapshot 取得 本番環境 Ops 複製環境 ＋ 複製

その他Systems managerでできること • Run command • OSログイン不要でOS内処理実行可能 • 複数のインスタンスに対して同時に実行可能 • パッチ管理（Windows） • ベースラインを定義し、必要なパッチが当たっているか監査可能 • パッチ適用処理は、メンテナンスwindowで自動化可能

中締め • Opsもコードを書いて手作業メンテを減らしていこう • AWSは、さまざまな情報やトリガーを提供してくれるし、 おろそかになりがちな部分を補足する機能も充実している • 地味系サービスに目を向けて！！ • Opsの価値をレイヤーと一緒に上げていこう • SoEの素養を取り入れ、Dev側との相互理解を深める • 現状維持管理の効率化　→　Systems manager（一例） • プラスα　→　次世代MSP！？