アイレットが提供するクラウドの導入設計から構築、監視、運用保守までをトータルでサポートする「cloudpack」。
その中でも数多くのお客様にご活用いただいているサービスの一つが、「24時間365日有人による監視運用」です。

この “24365”を担う Managed Service Provider（MSP）チームは、さらなるサービス品質の向上と業務効率化を目指し、PagerDuty の導入や一次対応を自動化する仕組みの開発などに取り組んできました。

“24365”はこれまでどのように進化し、これから何を目指すのか？
MSP チームへのインタビューを通してお伝えします。

第2回は次世代監視基盤 AMS（Advanced Monitoring System）の開発を担当した MSP 開発セクションの高橋 修一に話を聞きました。
（聞き手：iret.media 編集長　一筆 太郎）


クラウドインテグレーション事業部 MSP 開発セクション
第一グループ グループリーダー
高橋 修一 SHUICHI TAKAHASHI
専門学校卒業後、 SES 企業で携帯電話のテスターやテストの設計・管理、携帯電話やカーナビの開発に携わる。2016年アイレット入社。クラウドインテグレーション事業部にて開発エンジニアとして、 AWS や Google Cloud を利用した社内サービスの開発と運用を担当。
2023 Japan AWS Ambassadors / 2023 Japan AWS Top Engineers

お客様の課題やニーズに応えるべく、既存サービスにない部分を積極的に自社開発で補う

前回は MSP 運用セクションリーダーの蓮沼さんに、24365監視運用の歴史や一次対応の自動化によって何が変わったのかをお聞きしました。今回は AMS 開発者である高橋さんの視点から色々と教えていただきたいと思います。

よろしくお願いいたします。
改めて、AMS 開発の経緯を教えてください。

当時、プロジェクト数の増加につれて、監視運用における一次対応の業務負荷増大が大きな課題となっていました。そこで、MSP 開発セクションでは一次対応を効率化する社内サービスを試行錯誤しながら立ち上げていたんです。実は、AMS 以外にもさまざまなサービスを開発し、社内で利用しています。

どんなサービスを作ったんですか？イチ推しのサービスはありますか？

そうですね、たとえば「Resource Visualizer」はクラウド環境のリソース情報を取得し、Backlog 等に自動で定期出力するサービスです。手動による記入ミスや更新漏れなどを防ぎ、常に最新のリソース情報を Backlog で確認できるようになります。また、AWS だけでなく Google Cloud や、マルチクラウドにも対応している点もポイントです。

「Direct Connect VIF 監視」もすすめです。これは、Direct Connect の仮想インターフェースを監視するもの。AWS の標準サービスだけでは難しい仮想 IF 単位の監視・リマインド・復旧通知を可能にするもので、よりきめ細かな監視・通知が必要なケースで重宝されています。

バックアップ系のサービスも割と充実しています。たとえば Backlog に障害・メンテナンス等が発生した時に備えて Backlog の Wiki を自動でバックアップするものがあります。24365は非常に高い品質を追求しているので、特定のサービスに不具合等が発生した際も対応できるように、冗長化はかなり注力しているポイントです。

なるほど、既存のサービスでは足りない部分であったり、より強化できる部分を自社開発で補っているんですね。

まさしくそうです。お客様の課題やニーズに合わせて、既存サービスでは補えない領域を積極的に自社開発して対応しています。それゆえに、自社開発したあとに AWS の機能アップデートによって標準サービスで対応できるようになり、そちらを推奨するようになったケースもあります。また、お客様の課題解決につながるものであれば、AWS や Google Cloud 以外の SaaS も積極的に取り入れています。

進化したサービスもあれば、クローズしたサービスもある、と。

そうです。通知系のサービスに関しても、イレギュラーなメールを検知したら PagerDuty に通知するもの、AWS からの警告メールを自動的に Backlog に起票するものなど、いろいろとありました。ただ、システムがバラバラに乱立していて効率が良くなかったので、こういった通知系のサービスは「メール通知統合システム」というシステムにまとめるなど改善を繰り返していました。

業務効率化に向けてさまざまな開発を試行錯誤する中、一次対応の全業務自動化を目指す

お客様の課題解決や自社の業務効率化を目指して自社開発する文化が根付いていると感じたのですが、その中で AMS はどのようなアイデアから生まれたのでしょうか？

そうですね。AMS に関しては「すでに手順が決まっている一次対応を自動化できれば、人間にしかできないことにリソースを集中できるのではないか？」ということで、試作から始まったプロジェクトになります。具体的には、アラートのオープンから確認作業、情報収集、復旧対応、エスカレーション、アラートのクローズまでの工程のうち、80〜90％の業務を自動化できると考えました。

具体的にはどうやって自動化を実現するのでしょうか？

ざっくり説明すると、アラートのタイトル等に含めているキーワードを解析し、事前に設定済みの一次対応シナリオを特定して自動的にシナリオを開始します。シナリオでは動作確認や情報取得、必要に応じた復旧対応、復旧確認、エスカレーション、アラートのクローズといった作業を自動で実行します。その処理状況や処理結果を API 連携で PagerDuty にフィードバックすることで、一次運用担当者は自動処理の状況や結果を確認することができます。

開発から導入まではスムーズに進みました？

MSP 開発の基本方針として、まずはスピーディに開発し、実際に使いながら改善点を見つけて修正していくという手法を取っています。AMS もとりあえず動くものを作ってみて、最初は数件のプロジェクトに導入しながら改善を繰り返していきました。

とはいえシステムを大きく変えるというよりも、ユーザーインターフェースをより使いやすい形に整えたり、導入が簡単にできるような仕組みを作るという観点での改善が多かったかもしれないですね。

おかげさまで徐々に導入数が上がってきて、今では特に理由がなければ AMS を導入するぐらい浸透しています。全アラートの80%以上に対して、何かしら AMS が動いています。

さらなる自動化・効率化はもちろんデータ活用にもチャレンジしたい

現在、MSP 開発で取り組んでいることを可能な範囲で教えていただけますか？

新しい取り組みとしては利用している各種サービスの状況を細かく把握することです。たとえば監視サービスの状況自体を独自にモニタリングしています。利用している監視サービスに何かしらの障害や傾向が発生した時に、ステータスページより早く細かに状況をキャッチできるような仕組みを構築し運用しています。

先ほどお話しいただいたバックアップ系のサービスと同じ考え方ですね。

そうです。24365監視運用のさらなる効率化を目指して、「運用分析プラットフォーム」を開発・運用しています。これは MSP チームや AMS による一次運用の状況を可視化することで、業務効率やサービス品質をもう一歩上のレベルに高めることを目的としています。

MSP 開発では、これらの自動化や効率化以外にも、「請求代行+ Organizations」といった顧客向けサービスのリリース、DevOps コンピテンシーの取得など社内サービスの開発以外にもチャレンジしています。

今後もどんどん便利なサービスが誕生しそうですね。
新しいサービスが完成したら、またぜひ教えてください！