【Datadog Summit Tokyo】基調公演レポート「Workflow automation によるインシデント原因調査の自動化」

こんにちは、MSPセクションの屋部です。

今回、東京で開催された「Datadog Summit Tokyo」に参加してきました！

Datadog Summit Tokyo

本イベントの最初のアジェンダとして、Datadogの方からの挨拶とDatadogのこれからの歩み、そしてこれからの展望についてのお話をいただいた後、基調講演としてお客様の実際のDatadog活用例についてプレゼンを拝聴いたしましたので、概要についてご紹介できたらと思います！

Workflow automation によるインシデント原因調査の自動化

Degicaが提供しているオンライン決済代行サービスKomojuは10000以上の国内外のEC事業者に対して約40種類のオンライン決済の手段を提供してきました。1分1秒のダウンタイムがクリティカルな問題となるFinTechの事業において、インシデント発生時の復旧時間を改善していくことは重要な課題です。みなさんはどのような方法でこの課題に取り組んでいるでしょうか？

このセッションでは、HTTP Status Codes 5xx のエラーレスポンスレート上昇という汎用的なアラートが発火するケースを題材とし、Workflow automation によりアラートに対して自動的に重要なコンテキストを付与することで、インシデント対応者が問題を迅速に解決する方法について共有します。その際に必要となる様々なカスタムメトリクスやログをどのように充実させたのか、またどのようにDatadog”への”データの取り込みとDatadog”から”のデータ取得を切り分けているのかの戦略についてもお話します。あなた自身のチームがインシデントからの復旧時間改善のために次に取れるアクションについて学ぶことができます。

https://www.datadoghq.com/ja/summit/tokyo24/agenda/customer_4/

公演内容

サービスにおいて障害が検知した際に、検知〜解決までにかかる手順をDatadogのWorkflow automationの機能を使って短縮化を図るという内容でした。

設計した監視モニターでアラートを検知した際に必要になる原因調査の方法が手順として確立していれば、それをRunbookとして落とし込み、Workflow automationの機能を用いれば、アラート検知〜解決までの時間を短縮することができるかもしれません。
更に、Workflow automationを使うことで調査〜対応を人間ではなく機械が行うものとなりますのでヒューマンエラーを減らすことも可能になってくるとのこと。

また、全ての監視モニターでWorkflow automationを使って対応をする必要はなく、本当に自動化する価値があるものかどうかの選定もしっかり行う必要があるとのことでした。

感じたこと

私たちMSPセクションでは、日々監視しているサーバーのアラートに対して対応していますので、この公演の内容はとても魅力的だなと感じました。

弊社でも、多くのサーバーを監視するために一部は監視を自動化して行なっているのですが、その対応が全てDatadogのみでできるのか！という新たな発見、学びとなりました。