Internet Infrastructure Review（IIR）Vol.51
2021年6月30日

3. フォーカス・リサーチ（2）

スピードが求められる障害対応に、IIJ独自開発「Barry（バリー）」

3.1 Barry導入の背景

IIJが高品質で安定したサービスを提供するためには様々な運用作業を必要とします。中でも重要なものとして障害対応が挙げられます。サービスを提供するシステムがハードウェアやソフトウェアの障害により正常な稼働状態を維持できなくなった場合に正常に回復するための作業です。IIJは障害対応時に利用する運用システム「Barry（バリー）」を社内で開発し運用を行っています。ここではこのBarryの仕組みと効果を紹介します。

その前に、Barry導入以前の障害発生時の対応プロセスについて触れておきます。通常、提供サービスは設備や提供機能に異常がないかを常に監視しています。サービスに異常が発生するとアラートを発出して障害対応を促します。対応行動としてまず行うのが、その時対応可能な担当者の確保です。IIJではこれをエスカレーションと呼んでいます。次に、担当者はサービスを正常な状態へ戻す作業を開始します。対応内容は担当サービスによって異なりますが、一般的には作業者間でコミュニケーションを取り、事象の調査や記録のために様々なツールを利用しながら問題解決に取り組みます。

IIJでは以上のような流れで障害に対応してきましたが、これらの仕組みには問題点もありました。これを見直し、障害対応をスムーズに行うために開発したのが、運用システムのBarryです。

従来の問題点とは、主に次の2点です。

問題点① 担当者の確保と内容の正確な伝達

担当者の確保には迅速さが求められます。障害対応の候補者に連絡し、対応可能であることを確認する手段は現在も電話を用いています。理由は継続的に呼び出しを行えるという利点があるからです。メールなどによるメッセージもエスカレーションに用いることができますが、通常メッセージは発生したタイミングでのみ候補者への通知が行われます。一方、電話なら対応者が見つかるまで継続的に呼びかけ続けることができるため、目的とする担当者の確保の達成率が高くなります。その半面、人手により電話をかけ続ける場合は、担当者が見つかるまでかける側が拘束されるという問題があります。この点は自動架電のシステムを利用することで解消できますが、音声による一方的な連絡になるため、内容の確認が難しいという問題と、自動架電システムのコストの問題が残ります。加えて、同時に呼び出せる人数についても制約があります。

また、電話の場合は聞き逃しや聞き間違いの恐れがある上、英略語や記号の伝達が難しいという点が問題です。一方でメールによるエスカレーションはテキストによって行われるためこの問題はなく、内容が複雑でも伝えやすいという利点があります。

以上を踏まえ、継続的な呼び出しと内容の正確な伝達を実現したいという課題を設定しました。この問題を解決することで、障害対応における初動の迅速化が見込まれます。

問題点② 担当者の負担軽減

呼び出された担当者が実施する障害対応業務には数々の負担があります。簡単な障害は自動処理による復旧が考えられますが、ここで取り上げている障害対応はサービスを熟知した担当者が状況に応じて柔軟に対応する必要のあるものです。従って、サービスに関する高度な知識と対応スキルが求められます。加えて、休日夜間の対応もある点と、早期復旧が求められている点も担当者にとっては負担です。また、障害対応自体の難易度が高い上に、関係者への連絡や情報共有などの作業も必要です。

このような状況から、システムによっては特定の人員に作業が集中することも多く見られました。しかしながら、どの程度偏りがあるのか正確に把握することは困難でした。障害対応に集中して取り組めるように、それ以外の作業に関してはできる限り簡単に対応できるようにするという課題を設定しました。

3.2 問題解決の方法

こうして、迅速な対応の確保、対応者の負担軽減を解決する運用システムの検討がなされました。既存ツールの利用も選択肢にはありましたが、IIJ独自の対応フローの事情を踏まえるとそのまま使えるものはなく、社内業務への最適化も考慮し内製のシステム開発を決断しました。開発のコストは必要ですが、都合に合わせて継続的に改善できるメリットも大きいと考えています。

まず、担当者確保の問題解決に向けては、スマートフォン向けのアプリケーションとして実現するアイデアがありました。電話呼び出しのUIを模倣し、応答を確認後にテキストでメッセージを表示することで両方の利点を活かしたまま呼び出しをしてはどうかという発想です。メッセージの利点であるテキストによる伝達と、電話による利点である継続的な呼びかけを同時に実現します。また、電話という制約もなくなるため、エスカレーションの順序や同時に呼び出せる人数などのカスタマイズが可能になるというアイデアも出ました。運用チームの形態に合わせた柔軟な呼び出しが実現できると考えました。

担当者の負担軽減の面では、担当者が不便に思っている点を認識する必要があると考え、複数の運用担当者に対し、スマートフォンを利用した呼び出しのアイデアを伝えた上でヒアリングを行いました。その結果、多く出た意見は情報共有の不便さでした。障害対応においては障害内容の把握、対応時の情報共有、インシデント管理をしています。ヒアリング時点では、対応時のリアルタイムな情報共有はIRC（Internet Relay Chat）やSaaS型コミュニケーションツールなど、運用チームごとに採用しているツールが異なっていました。発生した障害をインシデントとして記録する手段も、メールやWiki/チケットシステムなど様々でした。また、PCが近くにない場合は障害の発生を知ることができても対応状況が分からないなどの不便さがあり、チームでの対応の難しさに繋がっていました。これらを踏まえ、エスカレーションを受けた担当者の情報共有や管理を統合的に行う必要もあると考えました。ツールの使いやすさも対応の効率に大きく影響するためです。新しい運用システムでは担当者の意見を取り入れながら、使い勝手を重視することとしました。

3.3 Barryの機能

拡大する

図-2 BarryのWebフロントエンド

機能① 柔軟な呼び出し

また、エスカレーションの開始は自動と手動の2パターンを用意しています。先に紹介したサービスの監視アラートからエスカレーションを自動的に発生させることができます。アラート以外にも緊急時の呼び出しを想定した手動によるエスカレーションの開始をサポートしています。

機能② 統合的な情報管理

障害対応において様々なツールの利用が担当者の負担になっている点を問題として挙げていました。Barryではエスカレーションからインシデントの管理までを統合的に行えるような機能を提供しています。担当者の呼び出し機能に加え、インシデント管理の仕組みを実装しました。機能的には課題管理システムと同等のもので、発生した障害の情報を記載し対応状況の管理ができるツールです。

具体的には、障害を1つのインシデントとして表現し、対応状況を更新しながら運用チームでコミュニケーションを行いながら解決までの記録を残します。発生したアラートをインシデントと関連付けて記録できます。インシデントを記録することで、過去の事例を参照しながらの障害対応が可能となります。

この機能を実現することで、障害の発生から対応完了までを1つのツールで完結できるようにしました。また、Barryは利用できる環境としてWeb ／モバイルアプリをサポートしていることから、対応者は移動中なども状況の確認やコメントができるようになりました。

使いやくするための工夫

様々なツールを統合的に利用できる機能を実現しても、効率が落ちてしまえば効果は限定的になってしまいます。このため、Barryではツールとしての使いやすさも重要視しています。

システムの設計段階で担当者からのヒアリングを行い、認識の共通化のためにモックアップを作成して意見を求めました。このプロセスを繰り返し行うことで、必要とされている機能が明確になり、使い勝手の面でも早期にフィードバックを得られました。細かな機能の作り込みも多く行ったため、代表的なものを順に紹介します。

活動記録の表示機能

まず、事象の発生頻度を分かりやすくし、障害対応の作業量を把握するために統計と可視化の機能を実装しました。これは発生したアラートや、利用者ごとの活動記録を時系列にグラフ化して表示する機能です（図-4）。アラートを時系列に表示することで、障害発生状況の分析を効率的に実施できます。また、運用チームの活動記録を分かりやすくすることで、従来よりも管理者による正確な状況把握が可能になりました。

拡大する

図-4 アラート発生頻度のグラフ化

タイムライン表示は、出来事を発生順に表示する機能です。Barryを利用する上ではアラートの発生やインシデント/コメントの新着を多く目にします。利用者は複数の運用チームをかけもちしていることも少なくなく、多くの出来事が発生している場合は把握が難しいケースもあります。タイムライン機能では発生したイベントを利用者ごとに時系列表示しており、容易に出来事を把握できます。

スタンプ機能

アバター機能

アバターは利用者や運用チームごとに画像を設定する機能です。これもソーシャルネットワーキングサービスなどで多く利用されている機能で、視認性の向上に役立ちます。利用者と運用チームに対して自由に設定できるようにすることで、ミスの予防などを目的としています。

Webhook

また、提供機能は自動処理を念頭に置いています。画面操作によって実現できることはすべてAPIを提供しており、利用者はソフトウェアによる自動化を選択肢に持つことができます。これ以外にも自動処理専用の仕組みも設けており、代表的なものとしてWebhookと呼ばれる仕組みも利用者要望をきっかけに実装しました。WebhookはWebアプリケーションが外部システムへ情報を送信する仕組みで、多くのWebサービスなどでも採用されているものです。Barryがこの情報送信の受信側として機能し、アラートの受信やエスカレーションの開始をサポートします。具体的にはGrafanaなどのWebhookと連携をすることで、既存のシステムと追加開発なしに連携ができるようになりました。このほか、コマンドラインツールも作成・提供しており、簡単なスクリプトによるBarry利用も実現しています。障害対応における業務の自動化において、これらの機能が用いられることを想定しています。

3.4 Barryを使った障害対応

次に、Barryを導入した場合のシステム運用の流れを追ってみます。

Barryは社内向けに提供する運用システムであり、サービス運用者は事前準備として以下を行います。

1. サービス監視のアラート送信先をBarryに設定
2. エスカレーションの際、誰をどの順番で呼び出すかのルール定義
3. 障害対応の担当者はスマートフォンにBarryモバイルアプリをインストール

これらの準備ができた状態でサービスの監視アラートが発生すると情報はBarryに送信されます。Barryはアラートを受け取ると、内容を保存し運用チームを特定してエスカレーションを開始します。エスカレーションでは運用チームごとに定義された呼び出しルールに従い、対応可能な担当者が見つかるまでスマートフォンを鳴動させます。

利用者はスマートフォンの鳴動によりエスカレーションの発生を知り、発生した呼び出しの理由を確認します。内容にはアラートの詳細までが含まれ、対応可能であればモバイルアプリから対応開始と回答します。システムはここで呼び出しを停止し、対応者の決定がグループ内に通知されます。

エスカレーション機能はここで役目を終え、以降は統合的な情報管理を提供するインシデントの機能が中心的に利用されます。担当者は受け取ったアラートの情報から出来事を整理しインシデントとして情報をまとめ、その後の障害対応の内容をコメントとして残しながら対応を進めます。追加されていく情報はモバイルアプリへの通知を含めてリアルタイムに運用チーム内で共有され、必要に応じて対応者以外もコメントを追加していきます。担当者が1人で対応できない場合は追加の人員呼び出しも可能です。

障害対応が終わると、インシデントを完了として更新することでBarryによる対応を終えます。記録したインシデント情報やエスカレーションの履歴はシステム内に記録が残ります。検索機能も備えているため、障害対応中に過去の類似アラート発生時の対応内容を参照するようなこともできます。

3.5 運用

Barryは様々なサービスの障害対応時に必要とされるシステムであるため、高い可用性が求められます。当然ながらBarry自体に障害が発生する可能性もあるため、障害の発生を前提に設計・運用しています。

システム構成としては独立した3拠点を利用し、うち2拠点で1つのBarryシステムを冗長する構成を採用しました（図-6）。残る1拠点では別系統のBarryを動作させています。これはBarryの運用者が利用するもので、Barry自体に障害が発生した場合はこちらを用いて障害に対応します。

拡大する

図-6 Barryのシステム構成

それぞれの拠点では独立したKubernetesクラスタが稼働しており、BarryはKubernetes上で動作しています。Kubernetesの機能を活用する構成により、Barryの運用はハードウェアなどの故障を意識する必要がなくなりました。

また、トップレベルドメインの障害などが起きると、Barryが正常に動作していても名前解決できないことでアクセス不可に陥ることもあります。この問題に対しては提供ドメインを複数用意して、アクセスするための手段を冗長化しています。

システム障害とは少し異なりますが、モバイルアプリに不具合がある場合の対応も行っています。サーバ側では不具合発生時に運用者が切り戻しなどを実施できますが、個々人の端末にインストールされたアプリに関しては対応ができません。致命的な不具合があると呼び出しの仕組みが機能しなくなるため、アプリの配布も2系統で行っています。具体的には随時アップデートを行う通常版のアプリの他に、安定した動作が確認できている緊急用をインストールできるようにしています。

3.6 導入と効果

Barryは2020年の7月に社内向けにリリースしました。障害対応の仕組みを一斉に置き換えるのは現実的でないため、このリリース後から利用を希望するサービスごとに個別切り替えを行う方針をとっています。利用者側ではアラート送信の仕組みなどを置き換える必要はありましたが、各サービスの協力により切り替えが進んでいます。特に新規に運用を開始するサービスにおいてはBarryが採用しやすい状況です。

Barry利用者により作成されたツールも存在しており、API公開を前提とした方針が利用者の業務自動化・効率化に貢献できていると感じています。

また、電話に似た継続的な呼び出しを実現しつつ、テキストによる連絡が同時に行われることで情報の伝達が効率的になりました。自動化によって呼び出しという単純な処理をBarryに任せられるようになっています。加えて、運用体制によっては呼び出しの並列度を上げることで候補者へ一斉に連絡できます。電話の逐次的呼び出しにおいては、候補者のうち一部が対応可能な場合は初動の遅れが発生していましたが、この点も解消できました。解決したい課題として設定していた初動の迅速化に繋がっています。

現在利用ユーザは633、運用チーム数は190です。リリース後、利用者に対してBarry利用に関するアンケート調査を実施しました。設問は利用頻度や導入によって業務が改善された点、更に改善を求める点を設けました。この内容について紹介します。

導入により業務が改善された点については、解決したい課題として設定していた初動の迅速化、状況の把握が挙がりました。架電をシステムが担うことによる負荷の軽減に加え、アラートからエスカレーションまでを自動化したことにより、障害発生を早く知ることができるようになりました。また、コミュニケーションに関する内容もありました。運用チーム内で障害対応状況がわかりやすくなったことで、共同作業に取り組みやすくなりました。Barry導入により前向きな改善の意見が得られたことで、運用業務の一助になったと考えています。

一方で、Barryに対して改善が求められる内容もありました。1つは既存のシステムとの連携の簡易化です。APIを提供して様々なユースケースに対応できる設計としていますが、Barryの利用にあたっては既存のシステム側の改修が必要です。既存の運用システムになるべく手を加えずBarryを使い始められるような仕組みを求める意見がありました。IIJ固有の事情に対応するべく設計したシステムなので、個別の要望に柔軟に対応していく予定です。

もう1つは安定稼働についての懸念です。先に紹介したとおり、Barryは障害時に使われるシステムであることから安定した運用が求められます。利用者が採用を検討する際の指標として稼働実績が挙げられますが、Barryはまだリリースから日が浅いため実績は不足しています。安心して利用されるようなシステムにするためにも、Barry提供における重要事項として安定した運用を積み重ねていきます。

社内での利用開始という大きなマイルストーンを達成しましたが、まだまだ取り組むことがあります。今後も継続的にアップデートすることでIIJサービスの品質維持・向上のために貢献していきます。

3. フォーカス・リサーチ（2）スピードが求められる障害対応に、IIJ独自開発「Barry（バリー）」

• 3.1 Barry導入の背景
• 3.2 問題解決の方法
• 3.3 Barryの機能
• 3.4 Barryを使った障害対応
• 3.5 運用
• 3.6 導入と効果