10,000時間以上アラート対応の削減？！事業部の垣根を越えた運用改善！

はじめに

こんにちは。クラウドインテグレーション事業部MSPセクションの塩谷です。

突然ですが、これはなんの数字でしょうか。。。。

これはとある案件から発砲されたアラートをMSPが処理するのにかかった時間が、去年に比べてどれぐらい削減できたのかを表した数字です。

日付に変換すると約500日。かなり膨大な数字ですが、サービス障害に直結しない不要なアラートの削減や運用設計を見直すことで、一次対応品質に関するサービスレベル指標（アラート発生から一次対応完了までの完了率 *後述）の向上にも繋げることができています。

今回はどのようにして一次対応時間の削減、品質向上を実現する事ができたのか、今期のMSPの取り組みを紹介したいと思います。

<登場人物>

MSPとは

私が所属するMSPでは、24時間365日、日々お客様の代わりにサーバーの監視・運用・保守を行っています。

特に要となるのが一次運用と呼ばれる部隊で、お客様のサーバで異常が発生し、アラートを受け取った際に、お客様へのご連絡や、復旧作業を行います。

MSPで対応出来ないアラートやイレギュラーが発生した場合は二次運用に連携をし対応を引き継ぎます。

二次運用は各事業部のサポートセンターに属しており、一次運用(MSP)＋二次運用(サポートセンター)の体制で日々運用を実施しています。

MSP、特に一次運用の部隊はcloudpackのサービスの第一線であり、約10,000台のサーバーを運用する手前、日々かなりの数のアラート対応をしています。

とはいえ、発砲されるアラートを粛々と対応し続けているわけではありません。

MSPでは発砲されたアラートを分析し、不要なアラートが垂れ流しになっていないか、対応手順に事故のリスクが潜んでいないかなど、サポートセンターと連携しながら日々運用の適正化を行う活動を実施しています。

そんな中でもアラートを対応するうえでの一次対応時間、特に有人対応時間(アラートが発砲されてから着手、対応完了までの一次運用メンバーが実際に手を動かした時間)は運用適正化にとって重要なKPIであり、改善の機会が眠っている指標でもあります。

不要な有人対応時間を削減する事で、緊急を要するアラートが発砲された際でもいち早く対応する体制を確立でき、MSP、cloudpackサービスの品質向上に繋がります。

 

MSPでは全てのアラートをインシデント管理プラットフォームであるPagerDutyで集約し対応を行っています。

PagerDutyの情報をオープンソースのウェブアプリケーションRedashに連携し、様々な角度から対応時間等を集計・分析しています。

以下のグラフは前年度の各サポートセンターが担当している案件から発砲されたアラートの有人対応時間の割合を示しています。

前年度で特に割合の大きかったエンタープライズ事業部(以下EC事業部)に焦点を当てる事で、全体に対して大きな影響削減効果が見込めると判断し、EC事業部にコンタクトを取りました。

こんにちは。EC事業部の久保田と伊波です。

私たちが所属するEC事業部についてご紹介いたします。

EC事業部とは

アイレットは、東京・大阪・名古屋と3拠点存在しており、そのうち名古屋は元々名古屋事業部という一つの事業部でした。
ただし、名古屋事業部には名古屋の社員に限らず東京在住の社員も在職しておりました。今では名古屋・東京に限らず全国に拡大してきていることから、名古屋事業部からエンタープライズクラウド事業部と名称を変更し、略してEC事業部となりました。

EC事業部では開発・インフラ構築・運用と、一つの事業部内で開発から運用までワンストップで対応できる体制を構えております。

そのため、EC事業部では開発・構築・運用と密に連携し、お客様の環境をサポートできるため、技術的にも信頼的にも高品質な対応を維持できるといった強みがあります。

その中で、私たちは運用セクションに所属しており、運用構築や二次運用を行っております。

MSPには一次運用をお願いしており、MSPからエスカレーションを受けたアラートについて我々のほうで対応しております。

現在、運用セクションでは60弱のプロジェクトを運用しておりますが、運用構築も複数案件、常に対応しており、運用対象のプロジェクトは増え続けております。

 

MSPから今回の取り組みを相談された時

EC事業部はアラート数が多く、MSPの一次対応時間の割合の多くをEC事業部で占めていました。

EC事業部側でもアラート削減の運用改善の取り組みをしているため、MSPから本取り組みの話があった時、これはチャンスだと思いました。

活動の主軸となる一次対応時間の削減はEC事業部だけではできません。

MSPの現場の声を聞かないと、どこがボトルネックになっているかわからないからです。

普段からアラート対応でお世話になっていますが、大きな取り組みを事業部の垣根を超えて実行するのは初めてだったので不安とワクワクがありました。

 

削減計画と共通目標の設定

まずは計画を立てる所から始めました。

他の事業部の兼ね合いもある為、詳細は割愛しますが、削減目標は去年より有人対応時間を2割削減する事にしました。

合わせて四半期事の削減目標、計画を建て、EC事業部との共通目標としました。

削減計画の内容

• 前年分のアラート分析
  • アラート単位での分析
    • 去年1年間でEC事業部の案件から発砲されたアラートの有人対応時間を多い順にリストアップ
      • 何故対応時間が長いのかを分析し課題化
        • 暫定対処と根本対策に分けてアプローチを検討
• 最新のアラート分析
  • 直近で増加傾向にあるアラートに関してもリストアップを行い、同様に分析、対応を行っていく
• プロジェクト単位での状況共有
  • プロジェクトごとに状況の共有を行うことで、共通認識を持って目標達成に向けて取り組むこが可能に
• 定例会の実施
  • 隔週で目標に対して現在の達成率を確認
  • 上記の分析・暫定対処・根本対策に関しても定例の場で進捗を確認
  • アラート以外にも、お互いの現場の困りごとなどを共有し、運用改善に繋げられないか会話する時間も確保
• 四半期毎の振り返りの実施

定例

隔週でEC事業部との定例の場を設けました。

定例の様子

• 極力顔出しで参加し、コミニケーションが円滑に進むように配慮しました
• 司会をMSP、EC事業部で交代で実施したりなど、お互いの事業部が自分毎として取り組む事が出来ました

課題管理

共通のBacklogを使用し、定例の場で課題の進捗を確認しました。

• 担当者のアサイン
• 現在のステータス(対応中、完了など)
• 期限日の設定

Backlogは上記が簡単に設定でき、可視性にも優れている為、プロジェクト管理が円滑に進みました。

EC事業部の動き方について

クライアントに動いてもらう前に、まずは現場の声を聞かなくてはなりません。

MSPリーダーの塩谷さんを中心に現場メンバーが何に困ってるのかをヒアリングしていただきました。

ヒアリングした結果、一次対応手順実施時に時間がかかってしまっているところ、手順の簡略化できるところなどを把握することができました。

EC事業部で一次対応手順の修正、簡略化をクライアントと調整しながら進めていき、定例で一次対応時間がどれだけ削減したかを計測していきました。

上記のサイクルをMSP、EC事業部で回していくことにより、一次対応時間が大幅に削減していきました。

MSP内でのSLO改善サイクルの取り組み

MSPではMSP内部で一次対応の品質を評価する指標を設けており、品質管理の指標として適用しています。

PagerDutyにて集約されるアラートは内製化の仕組みで重大度に応じてプライオリティ(優先度)が自動で付与される仕組みが導入されています。

今回の取り組みでは以下のプライオリティに応じた対応完了率をSLOとして測定しました。

・（P2）アラート検知から30分以内の一次対応完了率：97%以上

・（P3）アラート検知から45分以内に一次対応完了率：97%以上

有人対応時間削減の取り組みはSLOを順守し品質を向上させる取り組みの一つになります。

また、Amazon AthenaやLookerを使用し自動でSLO未達のアラートが発生した場合に、現場の一次運用メンバーがSLO未達の原因を Google AppSheat に記載していく運用を今期から開始しました。

以下にその流れを図で示します。

SLO未達の改善サイクル

1. PagerDutyのインシデント情報をAmazon S3に保存
2. S3のデータを Amazon Athenaを利用してテーブル化
3. Google スプレッドシートにデータベース化
4. Google AppSheat で可視化
5. 現場の一次運用メンバーがSLO未達原因の記入
6. MSP x EC事業部で未達原因を分析し、改善方法の検討
7. クライアント様に改善提案・状況をご報告

SLO達成状況のレポート

1. PagerDutyのインシデント情報をAmazon S3に保存
2. S3のデータを Amazon Athenaを利用してテーブル化
3. Looker を利用して、可視化
4. レポート機能を使ってSlackチャンネルに達成率を定期レポート

後日の分析ではなく、当日中に対応超過の原因を記載出来る為、記憶の乖離がなく新鮮な情報がすぐに手に入ります。

AppSheetはEC事業部にも権限を付与し、現場のリアルな状況を共有しました。

クライアントとの月次定例にも参加

クライアントとの月次定例にMSPが参画した経緯

お客様の環境を運用するにあたって運用セクションではSREとして活動をしておりました。SREでは最初にSLI/SLOの設定が必要です。お客様とSLI/SLOを定義する際に、二次運用だけでなく、一次運用のSLI/SLOも設定することとなりました。その際、MSPも一緒に活動しているため、報告の場に参加してもらうことにしました。

 

上記SLO順守の取り組みを元にクライアントの案件に絞ったデータで測定し共有しました。SLO順守、一次対応時間の削減によりMTTR、アラート数も減少し、クライアント側の対応負荷も軽減され、品質面で安心感を感じてもらう事が出来きました。

一次運用が直接クライアントに報告する機会はあまり多くなく、MSPの活動を知っていただく貴重な機会となりました。

 

四半期ごとの振り返り

計画通りに進んでいるか、計画の修正は必要かなどを四半期毎に振り返りを行いました。

また、半期事にEC事業部(名古屋)に足を運び、オフラインで振り返りを行いました。

 

オンライン＋オフラインでの交流について

これまで、MSPとはslackでのテキストベースや、電話でのやりとりが多く、この活動が始まってから、GoogleMeetでミーティングするようになり、少しずつ距離感が縮まってきておりました。その後、名古屋にMSPに来ていただき、直接顔を合わせてから、より親密になり、これまで以上に気軽に会話できるようになりました。

また、アラート削減に対する苦労話の共有や、エスカレーションが来た際に素早く反応できない裏話など、それぞれ打ち明けられていなかった心境などを会話することで、お互いの事情を把握できたことで、歩み寄った目標値に設定することができ、活動がよりやりやすくなりました。

目標達成以外のメリット

上記に記載のお互いの事業部の距離が縮まった事で、目標達成以外にも様々なメリットがありました。

相談しやすくなった事で、普段の運用時でも気軽に相談出来るようになり、MSPのオペレーションもスムーズになり、運用引き継ぎ前の新規案件の手順レビューにMSPの意見を反映したりなど、お互いアイデアを出し合って日々の運用適正化に向けて動けるようになった事が一番のメリットではないかと感じています。

 

今回の取り組みのナレッジ化、横展開

今回の取り組みは継続していくと共に、他の事業部との取り組みにもそのまま流用出来る為、来期は他事業部との取り組みにも広げていく予定です。

 

まとめ

最終的にお互いに協力し合って目標としていた一次対応時間の削減と品質向上を達成する事が出来ました。

改めて思う事はMSPと他の事業部がよりよい関係を築く事が、結果としてcloudpackの品質が向上し、お客様への価値向上に繋がると感じました。

iretには今回のEC事業部以外にも様々な事業部が存在し日々切磋琢磨しています。

来期は今回の取り組みをシェアし、他の事業部との連携強化、cloudpackの価値向上に努めていきたいと考えています。