Category
DevOps

ウォルマートのようなリテーラー（ 小売業者）の増加に伴い、eコマースとリテーラーの間の戦いが収束しつつあり、Amazonのようなeコマース企業の多くはオフラインでのプレゼンスを確立しています。この2方向の展開をサポートするため、リテーラーとeコマース企業は、優れたオムニチャネルカスタマーエクスペリエンスを提供することを目指しています。

リテールの世界のオムニチャネル

顧客は、店舗内、Webサイト内、モバイルアプリ内、またはソーシャルメディア内の全チャンネルでシームレスな体験ができると期待しています。世界最先端のリテールブランドはトレンドに乗っており、たくさん成功事例があります。以下は、オムニチャネルのリテール体験を提供しているブランドの好例です：

ディズニー：ディズニーランドでの休暇を計画するのは大変です。しかし、ディズニーのWebサイトやモバイルアプリのおかげで、レストランや観光スポットなど、休暇全体をオンラインで計画することができます。また、各アトラクションの待ち時間を知ることもできます。

スターバックス：スターバックスの特典カードを使えば、コーヒー代でキャッシュを使い切ることはありません。モバイルデバイスから簡単に特典カードを取り出して、いつでもカウンターで使えます。

ノードストローム：ノードストロームは、顧客がiPhoneアプリで行う注文を店内のスタッフが補助することで、優れたカスタマーエクスペリエンスを提供しています。各スタッフはアイテムの在庫を確認でき、特定のアイテムが在庫切れの場合、すぐにiPhoneで予約して顧客の家に届けることができます。顧客はオンラインで商品を購入して店頭で持ち帰ることもでき、返品も簡単です。

これらのチャネルでのエクスペリエンスをサポートするためには、深くよく統合されたバックエンドと、一貫したフロントエンドインタフェースが必要です。しかし、これは以前よりもずっと簡単になりました。従来のインフラストラクチャ、ツール利用、そして開発プロセスを放棄して、リテールアプリケーションを構築するための最新のDevOpsアプローチに移行すればよいのです。顧客は絶えず新しい機能や体験を求めており、そのために頻繁になる更新は、安定性を損なうことなくアジャイルさと正確さを最大化する方法で展開する必要があります。これは、デジタルチャネルと物理チャネルをシームレスに統合したエクスペリエンスを構築するために不可欠です。何千もの日常的なやりとりは破綻を生じやすく、また、人気ブランドはサイバー攻撃の目標とされやすいです。何百万人ものユーザーをサポートするためには堅牢なシステムが必要です。システムの可用性とセキュリティを確保する必要があります。これは簡単な仕事ではありません。

いかにしてDevOpsチームがオムニチャンネルリテーラーをサポートするか

インフラストラクチャ層から始めて、アプリケーションスタックまで移動し、オムニチャネルのリテールアプリケーションを構築する際に、DevOpsチームが留意べきことを理解しましょう。

クラウドに移行する

モバイルは、オムニチャンネルのリテールを考える際に最も重要なメディアです。これは、顧客にアプローチする最も個人的かつ強力なチャネルです。どこにいても、お客はあなたの会社とやりとりして、都合のいいときに買うことができます。しかし、ほとんどのリテールアプリは、過去に使われていたクライアントサーバモデルをベースにしていて、現代の最先端の消費者をサポートすることはできません。複数のデバイスやモバイルオペレーティングシステム用のアプリケーションを構築するには、クラウドテクノロジーを活用する必要があります。しかし、いくつかのクラウドツールをあなたのレガシーなスタックに投入するだけでは足りません。AWS EC2などのクラウドサーバでアプリケーションを実行したり、AWS S3などのブロックストレージにデータを格納したり、Sauce Labsなどのクラウドベースのテストプラットフォームを使ったり、Prometheusなどのクラウドネイティブな監視ツールを使ったりする場合は、全システムをクラウドで稼働させるか、少なくともそこへの移行を開始しなければなりません。

マイクロサービスモデルにゆっくりと移行する

マイクロサービスは、単一のモノリシックなアプリケーションを、小規模なクロスファンクショナルチームによって開発・管理される小さなサービスに分解するアプローチです。このタイプの複合型のシステムにより、新しい機能をより早くリリースできます。さらに、あるサービスに障害が発生しても、システム全体をダウンさせることはありません。しかし、マイクロサービスへの移行は、一度に1ステップで行う必要があります。最初のバッチが安定した後に、いくつかの機能を切り分けてください。マイクロサービスアプリは、従来のツールセットを使用する場合に限り、管理が難しくなります。幸いにも、DockerやKubernetesのようなコンテナ技術は、マイクロサービスの管理を容易にしています。

VMからコンテナへの切り替え

クラウドへ移行することが最初にやるべきことです。クラウド内にもう移行していても、アプリをコンテナで実行することが重要です。マイクロサービスモデルに移行すると、サーバインスタンスごとにハードウェアハイパーバイザとOSのオーバーヘッドがアプリのパフォーマンスを低下させます。マイクロサービスアプリケーションを拡張するには、コンテナにコードをパッケージ化する必要があります。コンテナ化すると全く新しいツールセットを使うことになります。たとえば、Kubernetesのようなオーケストレータを活用して、数千のコンテナを管理する必要があります。幸いなことに、コンテナ周辺のツール事情は昨今急速に成熟しました。今日、多くの世界クラスのアプリは、コンテナを使用して確実かつ安全に稼動しています。業界は、クラウドネイティブコンピューティングファウンデーション（CNCF）が認めた標準規格を整理統合しているところです。

分散データストア

インシデント管理でシステムを保護する

現代のマイクロサービスベースのコンテナ駆動型システムでは、多くのパーツがあり、これらのパーツはしばしばフェイルします。DevOpsの呪文の「早く進んで前向きに失敗する」とは、これらの失敗にすばやく反応し対処できる必要があることを意味します。パフォーマンスとセキュリティの両方が、オムチャンネルのリテールアプリの最大の課題です。サイバー犯罪者は多数のユーザーを持つアプリに引き寄せられますが、リテールアプリは名前、住所、クレジットカード情報などの価値のある重要なユーザーデータを数十億単位で持つことが知られています。システム障害やサイバー攻撃から守るには、データポイントを集中管理し、問題に応じて適切な対応者をリアルタイムで把握するインシデント管理システムが必要です。

大規模なDevOpsチームでは、重要な通知が失われる可能性があるため、適切なメッセージが適切な人に届くようにルーティングシステムが必要です。インフラストラクチャの複雑さが増し、大量のデータを処理する必要があるため、機械学習を活用してデータを理解し、重要なポイントに人々が集中できるようにするソリューションが必要です。オムニチャネルリテール向けのインシデント管理ツールは、システム全体にわたる監視、チケット発行およびその他のデータソースを相互に関連付け、集中化することができます。最先端のインシデント管理プラットフォームにより、疑わしいパターンを特定し、インシデントがエスカーレートする前に適切な人材を確保できます。

オムニチャネルのリテールは単純ではないので、完璧なシステムを構築するためには数年以上の時間が必要です。ただし、ここに記載されている方法とツールは、DevOpsチームにオムニチャネル体験を提供するための手がかりを与えることになります。クラウドへの移行、マイクロサービスの活用、コンテナの採用、データストアの分散化、またはインシデントの予見的な管理など、次世代のコンピューティングテクノロジーが今や利用可能です。リテールビジネスに必要なのは、計画を立て直す準備を整えた開発チームだけです。

監視ツールはDevOps チームの人生を楽にします。正しいDevOps 監視ツールを選択することで、効率的なワークフローとエンドユーザーの幸せを手に入れることができます。

多様なDevOps監視ツール

ほとんどの開発チームのための通常の監視ツールキットには、次のものが含まれます（ただしこれに限定されません）。

インフラ監視ツール アプリケーション・パフォーマンス・モニタリング（APM）ツール ログ解析ツール

各レイヤーに目を通し、あなたのDevOps監視プロセスにどこにフィットするか見てみましょう。

インフラストラクチャとネットワークの監視

これらのツールは、サーバ、ルータ、スイッチなどのインフラストラクチャとネットワーク全体を監視できます。インフラストラクチャ監視ツールは、重要なビジネスプロセスに影響を与える前に、ITインフラストラクチャの問題を特定し解決するのに役立ちます。また、古いシステムで障害が発生する前に、アップグレードの計画を立てるのに役立ちます。インフラストラクチャとネットワークの監視ツールは、メンテナンスの停止がユーザーに与える影響を最小限に抑えます。

インフラストラクチャの健全性を監視することで、インフラストラクチャ上で実行されているアプリケーションの正常性を把握できます。ただし、これらのツールはアプリケーションを完全な一連のサービスとして監視しません。その意味で、今日のクラウドアプリケーションには適していない従来の監視方法を採用しています。

例：Nagios、Zabbix

アプリケーションパフォーマンスの監視

アプリケーション・パフォーマンス・モニタリングツールは、その名前が示すように、アプリケーションのパフォーマンスを監視します。アプリケーションの動作を可視化し、ユーザーに影響を与える問題を検出し、それらの問題を迅速に解決するのに役立ちます。エンドツーエンドのアプリケーションフローを監視し、コードレベルの詳細を含むトレースを提供します。APMツールの診断には深い洞察が含まれており、パフォーマンスの低下や障害の原因となる可能性のある正確なコード行を見つけられます。

APMツールはパフォーマンスの向上、処理速度低下とダウンタイムの防止に役立ちますが、APMだけでは解決できない、さらに深いトラブルシューティングが必要な問題もあります。これらの問題には、ログファイルのインデックス付けと検索が必要です。残念ながら、APMツールはログファイルを分析せず、セキュリティ攻撃を検出できません。この種の分析には、ログ解析ツールが必要です。

例：AppDynamics、New Relic、

ログ解析

ログ解析ツールは、ログファイルを格納しインデックス付けするスケーラブルで信頼性の高い方法を提供します。ファイルをすばやく検索し、ログデータに基づいて詳細な分析を作成し、セキュリティ違反やサイバー攻撃を監視することができます。ただし、エンドツーエンドのアプリケーションパフォーマンス監視は提供されず、コードレベルのトレースを明らかにすることもできません 例：Splunk、Elastic Stack

これらのツールは、エンドツーエンドの監視のためのものではありません。インシデントが発生したときにこれらのツールのいずれか1つだけを使うと、解決の鍵となる部分が欠けることがあります。

監視ツールにはさらにその監視が必要

監視のためにこれらのツールを全て採用したとしても、インシデントが発生したときに混乱を招く可能性があります。これらツール全てからの警告は、重複するデータをたくさん提供します。これにより、あなたはツール間を行き来してあちこち見回することになり、チームだけでなく顧客にも多くの不満を引き起こす原因になります。ツールセット全体からのデータのオーバーロードに直面するので、MTTRは長くなります。インシデント管理での監視を簡素化が必要なのです。

監視ツールを集約する単一のインシデント管理プラットフォームが必要

ITチームやDevOpsチームは、互いに深く統合されたベスト・オブ・ブリード（複数ベンダーの組み合わせ）のツールを使用した監視を長年受け入れてきました。これらの全ての監視ツールを使用すると、矛盾する情報と膨大なアラートが表示されることがあります。その全てを管理し、問題の概要を把握するためのセンターハブが必要です。PagerDutyのようなインシデント管理プラットフォームは、インシデントが発生した際の混乱から秩序を回復するために不可欠です。

インシデント管理ツールは、優先度の低いアラートを抑制し、適切な人に適切なタイミングで優先度の高いアラートを表示することで、ノイズからシグナルを引き出します。インシデント管理ツールは、その他の監視システムと深く統合されているため、あらゆるDevOpsチームが必要とする真のエンドツーエンドの監視が可能です。十分に錬られた通知オプションを使用すると、PagerDutyなどのインシデント管理ソリューションはチームに自分たちへの通知方法を選択させることができます。さらに、これらのプロセスを自動化することで、解決までのの時間を大幅に節約し、全体的なMTTRを削減できます。

全ての監視ツールにはそれぞれ独自の機能が用意されていますが、全体を管理していないと混乱が生じます。1つで全てをカバーできるDevOps監視ツールはありませんが、1カ所から全ての監視ツールを管理して、送られてくるデータをフィルタできるPagerDutyのようなソリューションを使えば、完璧に一歩近づくことができるでしょう。

「オペレーションルームに歩いて行く – もうこれ以上何もする必要はないと思う」

開発者のための最新の機能のリリース（訳注：英語サイトに飛びます）で、PagerDutyのシニアエンジニアDavid Yang氏と私は、私たちの内部アーキテクチャが単一のモノリシックなコードベースから数十のマイクロサービスの組み合わせにまで進化していくのを見てきました。

彼は、8000人以上のPagerDutyの全顧客にアラート通知を送信するサービスを所管するIncident Management – Peopleチームのテクニカルリーダーです。私たちは座って、彼らのサービスの運用について彼のチームがオーナーになるよう切り替えた後の生活について話しました。 私たちが見た利点と欠点に関するいくつかの観察を紹介します。

今はチームがサービスのオーナーになっています

開発者がサービスのオーナーになるモデルに移行して以来、開発者の独立性はますます高まっています。副作用は、インフラストラクチャのプロビジョニングと管理の難しさを最小限に抑えられたことです。現在、チームは邪魔と障害を最小化するように最適化したいと考えています。 インフラをサポートするチームは、人間の介入の必要性を最小限に抑えるために優れたセルフサービスツールを提供することに重点を置いています。

開発者がコードのオーナーになると、サイクルタイム、つまり「これは問題だ」というメッセージがどこかで表示されてから実際に問題を解決するまでの時間が短縮されます。これは非常に価値があります。

文化面での変化は

人々がより多くのコードのオーナーになり、自分たちが運営するシステムのために一般的にはより多くの責任を負うようになると、道を邪魔するものを排除することを重視する文化が広がります。各チームは、 「自分が今まで、あるいは将来ブロックされていないことを確認するにはどうするか」という考え方に向かって最適化されます。ブロックされるともっとはっきり分かります。以前は、ホストをプロビジョニングするたびに私は毎回運用チームに問い合わせなければなりませんでした。 私のチームは他のチームの障害物で隠されていないため、自分たちの障害物をよりはっきり見ることができます。

私たちには、エンドツーエンドの顧客価値を提供するプロセスのすべてを所有することに重点を置いたチームがあります。これは非常に貴重です。

インシデント対応プロセスではどうに役立つ?

サービスのオーナーシップの境界が明確になっています。運用の問題が発生した場合に、影響を受けるチームを簡単に特定できます。そして、自分が従うべき正しい手順、例えばそれは「これがそのチェックリストです」という客観的な手順ですが、それを知っているということが大事です。 これによって問題の解決に100％集中し、インシデント前後のコミュニケーションに集中することができます。

それほどうまくいかなかったことも

サービスのオーナーになっていても、そのサービスに問題が発生しないとは限りません。当社のサービスの運用維持に専念するためには、そのためだけに使う時間が必要です。 これが結局はチームの時間の多くを占めます。特に知識のギャップがあるレガシーサービスで問題になります。 当初は、私たちのスプリントでの作業性を守るために十分なガードレールを設置していませんでした。 これは客観的な意思決定を可能にするためにKPI（特定のスケーリング目標や運用負荷レベルなど）を活用することで改善されています。

将来は?

[業務関連のワークロードと機能開発ワークのバランスをとるため]各チームは、メトリックによって客観的な意思決定を推進するために、次のように問い続けています。「私はこうした道具を日常的にどう活用していますか？ どのようにして客観的な意思決定を行うのですか？」と。

組織内の業務の中で変更を実行しようとすると、多くのコラボレーションが必要になります。 適切なメトリックが何であるかを把握し、それらのメトリックについて議論することも必要です。

継続的インテグレーションのポイント は、ビルドとテスト を自動化し、効率と品質を開発パイプラインにもたらすことです。しかし、継続的インテグレーションプロセスに伴って頻繁な更新が行われると、状況が悪化してしまうことがあります。

重大なインシデントや何か悪いことが起こるとパニックになります。それがインシデント管理のよくある風景です。しかし、何かが起きた後に常にそうなるでしょうか。初めからインシデント管理を継続的インテグレーションプロセスに組み込むことで、アカウンタビリティ、可視性、透明性を全く新しいレベルに引き上げることができます。

ここでは、いかにしてDevOpsへの深い監視を行い、それがアプリケーション開発方法を変革するかについて説明します。

コードの品質に対する責任は 継続的インテグレーションフェーズから始まります

DevOpsの目標は、開発チームと運用チームの協力を促進し、お互いのニーズを理解し、状況が悪化したときでも相手の責任を追求するのではなく共に解決することです。稼働時間の向上は必ずしもOpsチームだけの役割ではありません。DevOpsでは、新たに加わった開発者でさえ稼働時間に責任を感じ、ダウン時には協働することができるはずです。

継続的インテグレーションを実装する大きなメリットのひとつは、開発チームと品質管理チームの両方が出荷品質のコードに対して責任を負うことです。新しいビルドがコミットされるたびに、一連の自動ユニットテストによってコードが検証されます。インシデント管理がこのレベルで実装されていれば、何か不具合が発生した場合には適切なデータが手元に残るため問題を効果的に解決できます。こうして、誰も責めずに、パニックに陥ることもなく迅速にトラブルシューティングを行うことができます。インシデント管理を導入すれば高い品質を求める文化が醸成され、開発チームと品質管理チームは互いに可用性に責任を負うようになります。

緊急医療チームと同じように、責任者が現場に到着する前に最初に働く初心者のエンジニア、つまりオンコールエンジニアを待機させることも良いでしょう。この責任の文化を醸成するには、監視データをチーム間で見えるようにするモニタリングとオンコール管理システムが必要であり、公平なシフトに基づいて計画外の作業を分担する必要があります。

開発チームと運用チーム間の可視性

チーム全体の取り組みと進行状況を把握することで、誰もが自分の仕事に集中できるようになります。多くの企業は、悪い事が起こったときやインシデントが発生したときにのみ、Opsチームに新しいコードの実装を任せます。結果として、Opsチームは不信のために変更を控えていると非難され、更新が遅くなります。

Devチームが計画段階から変更点についてOpsチームに情報公開を行っている場合、それがビジネス全体にどのように役立つかを理解することができます。Opsチームに開発フェーズから新しいアイデア、今後の機能、考えられるリスクを認識してもらうことは、チーム全体の意識を高めます。Opsチームは何かあってもいいようにいつも準備ができているため、安心していられます。

早い段階でインシデント管理を実装することで、アプリケーションの健全性と問題が発生したときに何をすべきかを誰もが理解できるようになります。誰もが大きな図式を知っており、より迅速にトラブルシューティングを行うことができます。

透明性には統一された指標が必要

チーム全体が、危機の間お互いの責任を認識しているほど、彼らはより効果的に動き、より速く正常に戻すことができます。

複数のソースからデータを収集し、相関させ、分析することにより、DevとOpsは継続的な洞察を得ることができます。しかし、そのデータは実用的になった場合にのみ価値があります。インシデント管理ソリューションを使用すると、適切な人に問題の全体像を提供し、最終的にはアプリを壊してしまう可能性のある問題をゼロにすることさえできます。

最後に、インシデント管理ツールが問題が起きている時にリアルタイム通知を提供することで、実際に役立つことを確認してください。さまざまな重大度の問題の経路を決めるプロセスを定義することは非常に重要です。データを捨てようとは思いませんが、手元の問題を解決することに貢献しない無意味なメトリックを通知されることは望みません。

DevOpsへのトランスフォーメーションに成功するためには、継続的インテグレーションとインシデント管理が不可欠です。チーム全体にとってたのもしいリリーフとなり、ダウンタイムに対するより迅速な対応が可能になります。インシデント管理によってDevOpsエンジンは故障することなくスムーズに回転するようになります。

セキュリティ専門家として長年過ごしてきた私は、Datadogのような企業が、変化するセキュリティ環境にどう対応しているかに常に関心を持っています。 昔はセキュリティ組織がセキュリティの責任を完全に負っていて、ビジネスの周縁（perimeter）を保護することに重点を置いていた、ということも思い出せます。しかし、クラウド、モバイル、Webアプリケーションの出現で、周縁は消えてしまいました。 それと並行して各企業は、セキュリティとは開発チームと運用チームの中で共に責任を担い 、統合されるべきだと認識するようになっています。

それに向き合いましょう：Webアプリケーションに対する攻撃はMenace(脅威。ファントム・メナースから)となっており、毎年急速にデータ侵害が増加しています。 Rogueアクターは、インフラ、ソフトウェア、およびプロセスの弱点を悪用しています。私たちはこれに対してどのようにしてStrikes Backしますか？ New Hopeをここに…DevSecOps！

お分かりでしょうが、私は子どものころからスターウォーズの熱狂的なファンです。いつもこの話題のシリーズの新作が発表されるたびにワクワクしています。最新版は私にこの、遠く遠く離れた銀河の（原文はa galaxy far, far away ）の教訓がDevSecOpsに関して私に教えてくれたことを思い出させました。

“覚えたことは全て忘れるのじゃ” – ヨーダ

賢明なJedi Masterが言ったこの言葉を言い換えると、あなたがずっと真実だと思っていた知識のいくつかは、いつか偽に変わることもある、と言っていたはずです。DevSecOpsについて言えば、それはトランスフォームの成功を邪魔することもあります。時代遅れのツールとプロセスを使うことで、セキュリティチームが物事を停滞させる可能性があるのです。セキュリティは、組織内のセキュリティのマインドセットを変える一部として調整が必要であり、より新しいツールやプロセスがどれだけ良きパートナーになるかを知っておく必要があります。クラウドアプリケーションの監視サービスであるDatadogは、ツールとプロセスを更新する必要があると認識した企業の1つです。 そのセキュリティチームは開発部隊から学び、PagerDutyをアラートとレスポンスに使用し始めました。 PagerDuty Securityチームの一員として私は、ビジネスに自前のサービスを生かすこと（Eat Your Own Dog Food）も 自分のプラットフォームをセキュリティ業務の一環として使うこともできます。 しかし、なぜでしょうか？

“こいつはケッセルまで12パーセクで飛べた船だ！”- ハン・ソロ

PagerDutyでは、私たちは即応性と応答性を備えたモデルを志向しています。 例えば、セキュリティイベントが発生していたりリソースが準拠していないことをどれぐらい早く発見できるでしょうか？あるいは起きた問題を収めるためにどうに迅速に対応できるでしょうか？ といったことです。DevSecOps一部は、セキュリティについてスピード面でスケールする自動化された決定をすることです。 ミレニアム・ファルコンが光速で飛ぶほどは速くないかもしれませんが、迅速に対応できることは、潜在的なコスト削減とリスクの削減につながります。 スピードが要（かなめ）なんです！

すべてのリリースが100％安全で、100％稼働率を達成していると言えればよいのですが、現実にはありえません。現実では問題が起こり、どのくらい迅速に対応できるかが収益に影響します。 2017 Ponemon Cost of Data Breach Study は、インシデントレスポンスチームを組織することで、レコードあたり最高19ドル分の損失を削減できることを示しました。 適切な人にアラートして迅速に関与させることが重要です。

PagerDutyでは、クラウド内でマルチテナントのSaaS（software-as-a-service）プラットフォームを運用し、さまざまなツールを使用してインフラストラクチャを監視および保護しています。 これらのツールは、私たちが採掘してフィルタリングできる多くのシグナルを生み、PagerDutyプラットフォームとのインテグレーションにより、関連するセキュリティイベントとアラートをまとめることができます。 これにより、イベントに即応して、 インシデント対応プロセスを開始し、迅速に対処と復旧ができるようになります。

これはセキュリティインシデントに限りません。 開発者がコードを所有している環境では、クラウドインフラ内のリソースがコンプライアンスから逸脱したり、セキュリティリスクが発生したりする事態を迅速に判断することもできます。 迅速に対応して開発者と協力して問題を修正し、最善のセキュリティプラクティスについての早急なフィードバックを提供し、以後のプロセスを改善することができます。

“やるか、やらないかじゃ。試しはない ” – ヨーダ

DevSecOpsのアプローチを実装するのは、難しい作業のように思えるかもしれません。また成功するためには、組織内のセキュリティの考え方を変えるなど、多くの課題があります。 それ自体は、ジェダイの精神的なトリックを使うべきだと思えるかもしれません。しかし、あなたはプロセスにコミットし、その後に自分の間違いから学び、また過去に同じことをした他の人から学ぶ必要があります。DevOpsと同様に、DevSecOpsは反復学習と改善のプロセスでなければなりません。 DevSecOpsは、迅速なフィードバックを提供するためにセキュリティプロセスを自動化するための適切なツールを選択することでもあります。PagerDutyを活用すれば、そのトランスフォーメーションを助けられると思います。

あなたの組織でDevSecOpsをうまく実装する方法の詳細を知りたいですか？ Datadogの導入事例をチェックしてください。

本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

あなたの考えていることをずっと追いかけていて、あなたの計画の実行を助ける、そんな小さな ロボット があったら素晴らしいでしょう。もし、あなたがインシデント監視インフラストラクチャを担当する管理者なら、それは存在します。チャットボットと呼ばれる彼らは、インシデント管理ワークフローを最適化するための鍵です。

ここではチャットボットとChatOpsを使うのが、DevOps手法を採用している組織にとってとても重要な理由について説明します。

チャットボットの定義

「チャットボット」は人によって異なるものを意味します。大まかに定義すると、チャットボットは、人間と「会話」をするプログラムです。チャットボットはずいぶん昔から存在しています。あなたがAOL（注：America Online）がまだインターネットを支配していた時代に育ったなら、例えばSmarterChildというAIMインスタントメッセージングサービスのためのチャットボットを覚えているでしょう。

インシデント管理とインフラストラクチャの監視の分野でいうチャットボットは、もっと狭い意味を持ちます。彼らは人間の言うことを理解し会話をするだけでなく、人の代わりにアラートを監視しインシデントに対応します。

言い換えれば、この意味でのチャットボットは、SlackやHipChatなどのコミュニケーションプラットフォームと統合され、人間の入力に応答してコマンドを処理するプログラムです。コマンド自体は、多くの場合、バックグラウンドで動作するサーバで実行されていますが、管理者が行う必要があるのは、何をするかチャットボットを教えることだけで、残りは事前に定義された手順に基づいて自動的に処理されます。

チャットボットとChatOps

チャットボットは開発業務におけるツール、プラットフォームであり、ChatOpsと呼ばれます。彼らは開発者と運用チームに以下のような利益をもたらします。

コマンドを実行するための便利なインタフェースを提供する

すでにSlack、HipChatや他のコミュニケーションプラットフォームをすでに使っている場合、なぜコマンドを実行するために異なるインタフェースに乗り換えるのでしょうか。チャットボットならばあなたがコマンドを実行する必要はありません。チャットインターフェイスから直接実行させることができるので、ずっと素早く実行できます。

チーム全体を可視化

あなたがチャットボットとの対話を公開していれば、参加するすべての人があなたが実行したコマンドを確認することができます。これは、あなたのチーム全体を可視化し、チームメンバーが同じコマンドや矛盾したコマンドを実行していないことを確認できます。そして同時に、チーム全体が学習する機会も提供します。

リアルタイムなアクションを促進

伝統的に、チームは集まり、計画を立て、別れて、実行します。チャットボットとChatOpsを使うと、コミュニケーションと操作インターフェースが統合されているので、対話と実行が同時に可能です。重要なオペレーションを実行する前、計画を立てるための時間が要らないとは言いませんが、例えばインフラの障害に対応しているときのように時間が最重要である場合、計画とオペレーションが同時に行えるのは大きな利点です。

チャットボットとChatOps、DevOpsチーム

これらの利点は、ほぼすべてのタイプの組織に有用です。組織がDevOpsチームスタイルのワークフローに移行しつつある現在、これは特に重要だといえるでしょう。

それはなぜか。DevOpsチームの2つの原則は、シームレスなコミュニケーションとオペレーションの俊敏性であるためです。ソフトウェアの継続的デリバリー（と透明性と公開性）を求める場合は、チームメンバー間のコミュニケーションギャップを回避する必要があります。また、インシデント対応時に継続的デリバリーのパイプラインを壊さぬよう、迅速かつ容易に行動できる必要があります。

同じ論理は、監視とインシデント管理にも適用されます。監視チームを継続的に活動できるようにしたい場合、リアルタイムでインシデントを特定し解決するため、瞬時に可視化されたコミュニケーションが可能な手段が必要です。素早いアクションと効率的かつ協調的な方法でチームメンバー間に責任を持たせるための方法です。チャットボットはこのすべてを可能にします。そのため、チャットロボットはDevOpsの世界を席捲しているのです。

DevOpsは、ソフトウェアの提供とインフラストラクチャの変更のプロセスを自動化および加速しながら、ソフトウェア開発者とIT運用の専門家の間のコラボレーションとコミュニケーションを強調する文化、ムーブメント、実践手法です。 DevOpsプラクティスを実装するには、人、教育、ツール、組織の調整など、いくつかの種類の投資が必要です。しかし、これらの投資から組織が受け取るリターンを判断するのは難しい場合があります。効果測定では何を重視しますか？　どうやって投資を価値あるものにしますか？

DevOpsがROIに与える影響

DevOpsのない世界では、ソフトウェアリリースの頻度は低く、以前のリリース以降に開発チームによって構築されたすべての新機能、更新、および変更が含まれています。ビルドされたが次のリリースまで出荷されないコードは、ビジネスには何の価値も生み出しません。コードのユーザーへの配信を加速するということは、ジャストインタイムの製造のようなものであり、完了後すぐに価値を生み出します。そして、今日の継続的なデジタルトランスフォーメーションの世界では、新しい機能をデプロイし、競合他社よりも早く問題を解決する能力が、市場での優位性につながるのです。 DevOpsの主な目標の1つは、ソフトウェアリリースを頻繁に、定期的に、自動化することです。1日に複数回リリースする能力がある場合、個々の本番環境へのプッシュはたいしたことではありません。リリース頻度の低い「ビッグバン」スタイルの体制、つまり全員が臨戦態勢で、土壇場でのトラブルシューティングに追われ、やり遂げるまで深夜も週末も作業する運用チームを必要とするような体制と比較してください。デプロイの失敗によるダウンタイムを解決するために髪を振り乱すのではなく、より幸せで休息の取れた運用チームが次の問題を積極的に解決することの方が、組織にとって明らかにはるかに大きな価値があります。

あなたのチームはあなたの最大の資産です

DevOpsを実装する最良の方法は、解決が必要な問題に権限と責任の両方を集中させることです。最前線のチームは、時間が無駄になっているところ、隠れた非効率性がどこにあるのか、どこに最適化の機会があるのかを知る最適な立場にあります。プロセスに自動化を導入することについての最大の誤解のひとつは、それが必然的にチームから仕事を奪うということです。むしろ、面倒な手作業を自動化に置き換えることで、チームはより価値の高い活動に集中できるようになるのです。 結局のところ、あなたのビジネスをあなたのチームよりよく知っている人たちはいません。人件費にどれだけ投資したかを考えてください。チームの生産性を最大化することは、DevOpsを実装することによるROIの大きな改善点です。重要な問題の解決に時間を費やしてもらうことで、ビジネス全体の成果の量と質が向上し、面倒なエラーが発生しやすいタスクがToDoリストから削除されるため、リスクが排除されます。

ROIをビジネスの目標に結び付ける

では、DevOpsプラクティスを採用するためのビジネスケースを検証するために、ROIの適切な指標をどう選択すればいいでしょうか？　これはビジネスにとって大変重要なことです。デジタルトランスフォーメーションが広がるにつれ、新しいビジネスモデルと顧客との新しい対話方法が、あらゆる業界で生み出される価値を根本的に変えています。成功を測定するための鍵は、ユーザーに提供する独自の価値を理解し、それを達成するために指標を結び付けることです。顧客が目標を達成するために費やす時間を最小限に抑える、ユーザーあたりの収益を最大化するなど、DevOpsへの投資を主要なビジネス指標の改善に直接関連付けることができるはずです。

			時は金なり
			鍵は効率化
			柔軟に最適化を
		
	
	
		
			チームがより価値の高い問題に時間を費やすことができれば、あなたのビジネスにより多くの価値をもたらすでしょう。
			ボトルネックを防ぐために、問題に近い現場に権限と責任を持たせましょう。	
			どんなケースでも即通用するというものではありません。ビジネスにとって何が重要かを把握し、そのために最適化を図ってください。

そして忘れてはいけないのは、何かを測定できるからといって、そうする必要があるとは限らないということです。我々は時にビジネスの目標に関係ない指標に気を取られてしまいがちです。開発者の生産性を測定するためには非常に多くのツールが利用可能であるため、記述されたコードの行数や修正されたバグの数など、実際には重要ではないあらゆる種類のデータを追跡できます。計算や最適化は簡単かもしれませんが、ユーザーのために生み出そうとしている価値とは実際には関係のないことです。

「数えれられることすべてが大事なわけではないし、大事なことすべてが数えられるわけではない。」（ウィリアム・ブルース・キャメロン）

ビジネスへの教訓

DevOpsの変革とは、ITの流れを加速することを目的としたプロセスの変更がすべてです。つまり、ROIを測定する際の最大の課題は、DevOpsが提供するさまざまな種類のメリットを理解し、それらのメリットをビジネス目標に結び付けることができるかどうか、ということなのです。 配信されないソフトウェア在庫の山の削減から、手作業による障害リスクの削減、生産性と従業員の満足度の向上まで、DevOpsプラクティスを実装することの価値はすぐに得られます。今日のデジタル環境で競争力を維持しようとしている企業にとって、DevOpsに移行する余裕があるかどうかという問題は、「DevOpsに移行せず現状のままで安泰なのか？」という問いになってきています。

ROIの決定に使用できるDevOps指標

これらをあなたのビジネス目標に当てはめてください

			指標
			詳細とメリット
		
	
	
		
			1日／週／月あたりの本番環境へのプッシュ数
			本番環境への展開の頻度を増やすことで、ユーザーにビジネス価値を提供する速度を上げ、「倉庫の在庫」コードを減らすことができます。
		
		
			1か月／年あたりのダウンタイムの分数	
			自動化が進むと、アプリケーションのダウンタイムが削減されます。これは、ユーザーの満足度と収益に直接関係します
		
		
			自動テストカバレッジ	
			自動化を広範に使用すればするほど、手動エラーの可能性が少なくなり、移動が速くなります。
		
		
			新入社員がコードを本番環境にデプロイするのに必要な時間	
			新入社員が迅速に対応できるようにするためのフレームワークとプロセスを構築することで、新入社員の生産性が向上し、既存のチームの生産性も向上します。
		
		
			新しいイニシアチブと既存のプロセスの実行に費やされた従業員の時間	
			手動プロセスを自動化することで、チームは既存の問題に対処するのではなく、ボールを前進させることに時間を費やすことができます。
		
		
			従業員の幸せ	
			作業に忙殺されるのではなく貴重な問題に時間を費やしている幸せな労働者は、生産性が高く、長期間にわたって戦力となってくれます。これは、NPS（Net Promoter Score）を介して直接測定することも、トラブルシューティングに追われる夜と週末の数を介して間接的に測定することもできます。