JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS

JAWS Days2017 2017.3.11@TOC五反田メッセの登壇資料です。

Transcript

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

   View Slide

2. 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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. 変更を追跡可能（AWS Config）
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide