アイレットが提供するクラウドの導入設計から構築、監視、運用保守までをトータルでサポートする「cloudpack」。
その中でも数多くのお客様にご活用いただいているサービスの一つが、「24時間365日有人による監視運用」です。
このサービスを担う Managed Service Provider（MSP）チームは、さらなるサービス品質の向上と業務効率化を目指し、PagerDuty の導入や一次対応を自動化する仕組みの開発などに取り組んできました。
MSP はこれまでどのように進化し、これから何を目指すのか？
MSP セクション セクションリーダーの蓮沼 翔悟に話を聞きました。
（聞き手：iret.media 編集長 一筆 太郎）
クラウドインテグレーション事業部 MSP セクション
セクションリーダー
蓮沼 翔悟 SHOGO HASUNUMA
2015年アイレット入社。2019年に東京拠点の MSP セクションのセクションリーダーに就任。2021年からは大阪拠点の MSP セクションのセクションリーダーも兼任。運用における障害発生時の一次対応グループや、障害以外の運用全般や業務効率化などの改善を担う二次運用グループなど、複数のグループを統括し、人材の育成や新しいサービスの企画などに従事している。
スタートは、社内のスタッフが24時間365日 『人力の泥臭い』有人監視・障害対応
はじめに、cloudpack の監視運用サービスの特徴を改めて教えてください。
cloudpack ではお客様がご契約されたインスタンスに対して、ディスク使用量、プロセス数などのリソースや SSH の監視を行ない、障害発生時には事前に登録いただいた緊急連絡先にご連絡し、早急な問題解決につなげています。監視、障害対応は24時間365日、保守は平⽇10〜19時で対応しています。サーバ1台からご契約が可能で、煩わしい運用負荷からお客様を解放しながら、インフラ環境や IT システムの安定運用を実現するサービスです。
改めて聞くと、24時間365日ってすごいですよね。自動化が進んでいるとお聞きしたのですが、サービス開始当初から自動化していたのでしょうか？
いえ、最初は完全に人力でした。社内のスタッフがアラート発生時のメール通知を1件1件クリックして対応するという。
はい。もちろん、交代制ですけれど（笑）。常時複数人が対応にあたり、たとえば、「このアラートは私で対応します」とか、「このアラートは自分の手に負えないので助けてください」と、メールの件名などを添えて、Slack でエスカレーションしていました。
運用としては成立していましたが、やはり案件が増えていくにつれて業務負荷が大きくなることはもちろん、メールだと処理状況が他の人から見えにくいという課題も生じていました。どんな種類のアラートが、どのタイミングでどれくらい発生しているのかという全体感もひと目では把握できず、各アラートの対応に費やした時間も管理できないため、業務効率化やサービス改善が難しい状態だったんです。
その課題解決に向けて、自動化に取り組み始めたのですか？
最初に取り組んだのが PagerDuty の導入です。PagerDuty はシステムのインシデント対応を一元化するプラットフォームで、これを活用することでインシデント発生状況の一元管理とデータ分析ができるようになりました。発生率が高すぎるアラートはないか、対応に時間がかかりすぎているアラートはないかなどの観点から分析することで、データに基づいた運用改善を実現しています。
次世代監視システムの開発が、一次対応スピードの飛躍的な向上とヒューマンエラーを削減
PagerDuty を導入したことで、運用上の課題は解決したんですか？
業務効率化やサービス改善に対する効果は間違いなくありました。一方で、事業拡大に伴って新たな問題も生じてきたんです。
当時の監視業務フローを簡単にご説明すると、まずアラート発生時の一次対応として予め定められた動作確認や報告に必要な情報を収集した上で状況に応じて復旧対応を行ないます。その結果をお客様にご報告したり、二次対応担当者にエスカレーションしていました。すなわち、監視対象のシステム数増加に比例して一次対応の負荷も増えてしまうんです。それに、人の手による対応スピードには限界がありますし、ヒューマンエラーも完全になくすことはできません。その後、インシデント管理の観点から発生したアラートを お客様に通知する標準的な運用にアップグレードしたことも、業務負荷増大に拍車をかけました。
なるほど。事業がスケールするにつれて、いよいよ手動での対応に限界が生じてきたんですね。
はい、それまでも MSP チームでは業務効率化を目的としたさまざまな社内向けサービス開発に取り組んでいたのですが、「自動化」に向けて本格的に始動し始めたのはその頃からですね。
一次対応のどのあたりを自動化しようと考えたんですか？
具体的にはアラートのオープン、手順書確認、動作確認・情報取得、復旧対応・復旧確認、エスカレーション、アラートのクローズといった監視業務の一次対応を全て自動化するシステムを目指しました。
2018年に「次世代監視基盤 AMS（Advanced Monitoring System）」を自社開発しました。AMS がアラートを解析し、予め定義しておいたシナリオに基づいて動作確認・情報取得・ 復旧対応・復旧確認・エスカレーションまでを自動で実行してくれます。未定義のアラート等は、AMSが一次対応担当者にエスカレーションします。エスカレーションを受けた一次対応担当者が人力で対応し、必要に応じて二次対応担当者に引き継ぎます。完全自動化ではないのですが、有人による監視＋システムによる自動監視という二重化した体制で、よりクオリティの高い監視業務が可能となりました。
すごい、ほぼ自動化ですよね。これは大きな効果がありそうですね。
はい。単純に人的コストが削減されたので、リソースをよりフレキシブルな対応や調査などに当てることができました。手動による作業スピードの限界を超えられるのでさらなる事業スケールにも対応できますし、ヒューマンエラーが減ったことでサービス品質の向上にもつながりました。
<直近数年間の一次対応実績>
|
アラート件数 |
一次対応時間平均 |
AMS対応率 |
| 2021年 |
376,540 |
492.0秒 |
44.34% |
| 2022年 |
884,495 |
246.2秒 |
81.45% |
| 2023年 |
680,230 |
141.7秒 |
86.14% |
（注）2023年は6月25日時点
でも、これって自動化するためのシナリオの定義がすごく大変じゃないですか？
大変でしたよ。ただ、cloudpack にはこれまで何千台レベルの監視運用を手動で対応してきたノウハウがたっぷりと蓄積されていたので、そのおかげで比較的スムーズに進められたと思います。また、AMS 開発をきっかけにアラート対応の定義が曖昧だった部分も標準化できたので、対応内容のブレがなくなったことも非常に良い効果だと感じています。自動対応と手動対応の分岐点も明確になったので、人手による対応スピードもどんどん上がっています。
ちなみに、シナリオは全てのお客様に活用できるものなんですか？
基本的にはテンプレートで運用し、ご要望に応じてお客様と協議しながら定義をカスタマイズすることもあります。
たとえば、平日や土日の特定の時間帯に連絡をしないで欲しいというご要望があった時、人力で対応すると間違いが発生する可能性があります。そこで AMS と PagerDuty を組み合わせて、連絡不要の時間帯はアラートをご報告しない仕組みを実現したことがありました。
なるほど、お客様のご要望に合わせて自動化する内容を変えているんですね。
はい、さまざまなご要望を実現する上で、「自動化できる方法はないか？」を常に考えています。一次対応のシナリオが複雑で人がやると15分かかってしまう対応について、そのうち10分は AMS で自動化し、残り5分を担当者が引き継ぐ方法を策定し、スピーディーにエラーなく対応している例もあります。
年間数千プロジェクトの実績とノウハウを生かし、さらなるサービス品質向上を目指す！
AMS は導入開始以降、順調に運用できているのでしょうか？
はい、ただし一度開発して終わりではなく、さらなる品質向上と効率化を目指して改善や改良を重ねています。たとえば、部署ごとに AMS の導入状況を把握し、導入支援が必要な部署の特定や運用上のボトルネックを発見すべく、運用分析プラットフォームを自社開発しました。その結果、部署単位での AMS 導入率が調査できるようになり、AMS 導入が進んでいない部署に対して、どのような課題があるのかをヒアリングや分析をするのに役立っています。
さらに、この運用分析プラットフォームでは、お客様のアカウントごとに運用負荷が高いアラートや、プライオリティの高いアラートの発生状況を特定し、各アラートの対応状況も可視化しています。そのデータをもとに振り返り、課題抽出と改善策を打ち出すことで、サービス品質の向上に継続的に取り組んでいます。このように、MSP における一次対応の業務効率化によって生じたリソースをサービス改善にあてることで、お客様に対する MSP のサービス品質向上にもつながっています。
業務効率化だけにとどまらず、cloudpack のサービス品質向上も実現しているところが素晴らしいですね。
ありがとうございます。いずれのサービスやシステムも、これまでに年間数千ものプロジェクトを展開してきた実績、開発パートナーとしてお客様と向き合う中で蓄積されたノウハウから生まれたものです。だからこそ、業務効率化だけでなく、お客様にとっても価値のあるサービスにつなげられているのだと思います。
ところで、なぜ全て自動化せず、有人監視とのハイブリッド体制なんでしょうか？
はい、技術の進展に伴ってシステムのアーキテクチャが複雑化する中で、ユーザー体験を含めたシステム全体を観測する『オブザーバビリティ』の重要性が高まっています。この変化に対して従来の決まった項目を監視するインフラ監視では MSP として限界があると考えています。
ですので、これまでの数千台の監視運用で培ったインフラ監視の自動化の強みと、まだ自動化の難しいオブザーバビリティの強化を両輪で行なっていけるハイブリッドの体制としています。
AMS を含む自動化システムがなんらかの要因で動作しなかったとき、人手による介入が可能なことも有人体制としている理由の一つです。
AMS をはじめとする社内サービスは、まだまだ発展途上で、改善・進化の余地があると思っています。マルチクラウドに対応するなど、これからも世の中のニーズやお客様の課題解決につながるようなサービス開発に注力していきたいです！
