シンプレクス様事例

1997年の創業以来、高度な金融技術を強みに、日本を代表する金融機関のテクノロジーパートナーとしてビジネスを展開してきたシンプレクス株式会社。現在では、金融領域で培った豊富なノウハウを活用し、金融機関以外の領域でもソリューションを展開しています。同社が多くのお客様に支持される理由は、ビジネスとテクノロジーの両方に精通したプロフェッショナルがワンチームとなり、コンサルティングから運用保守まで、一気通貫でソリューションを提供できる点にあります。稼働後も長期的なパートナーシップのもと、24時間365日体制のシステム運用監視や、トラブル時の対応・復旧活動を支援。システムの安定稼働と品質の向上に欠かせないインシデント管理をPagerDutyが支えています。

ビジネスの拡大と共に対象システムが増え厳しいSLA要件を順守するための負荷が急増

　金融機関のコア業務を支えるシステム構築や、新しいユーザー体験をもたらす金融サービスの開発などを数多く手がけるシンプレクスは、国内大手の銀行や証券会社、生命保険会社のビジネスパートナーとして絶大なる信頼を獲得しています。同社が提供するシステムの多くが金融機関向けであることから、その運用保守は極めてミッションクリティカルであり、高い可用性・信頼性が求められます。たとえば、証券会社が運営するFXサービスひとつをとっても、24時間365日の運用体制が必須であり、ひとたびトラブルが発生して復旧が遅れようものなら取引に大きく影響します。小さな火種が大きなビジネスインパクトに直結するため、厳しいサービスレベルをクリアする必要があり、オペレーションミスは絶対に許されません。イベント管理およびインシデント管理の対象も、金融業界を支えるさまざまな商用システムに加え、それらが稼働する共通基盤システム、開発・保守を行うための社内システム、さらにはAWSをはじめとするクラウド環境や、データセンターに構築されたオンプレミス環境など多岐にわたります。その数はプロジェクト数にして70 以上に上ります。(※導入当時40 程度)

　同社では、ビジネスが拡大し対象システムが増えるにつれ、月間2,000 ~ 3,000だったインシデント対応件数が2 ~ 3倍に膨らみ、発生するイベントメッセージも多様化。オペレーターの業務負荷が高まるだけでなく、お客様ごとにSLAが異なるために優先度の判断が難しく、オペレーションミスの誘発も懸念されていました。

　2018年当初、サービスデスクで運用保守業務にあたっていた宮本氏はこう振り返ります。「イベントの発生からトリアージを行う業務を手作業で行っていたことも業務負荷が膨れた原因の一つです。具体的には、プロジェクトごとにナレッジとしてのワークアラウンドをまとめたスプレッドシートからマッチングする条件を探し、既知のワークアラウンドを特定するという作業です。エスカレーションが必要な場合は、連絡網をもとに誰かが電話に出るまでかけ続けるという泥臭い方法でした。共通基盤システムに問題が発生した場合などは、関連する全プロジェクトに対しオペレーターが一斉に電話連絡にあたる場面も見られました。その間に一次対応が可能なケースでも、優先すべき電話連絡にリソースを占有されて身動きが取れません。」

1シフトあたり4 ~ 5名を割り当て、24時間365日の監視体制を組んでいましたが、月間約20名の人件費に加えて、担当者の変更、新しい要件の発生に伴う教育コストや整備コストもかさんでいたと言います。

業務改善では根本的解決が困難と判断し手動オペレーションの自動化に着手

　増大し続ける負荷に人的リソースで対応していくには限界があるとして、同社は不要な業務プロセスの削ぎ落しやVBAを使ったトリアージルールの正規化など、業務の標準化や定型化による効率化への取り組みからスタートしました。しかし、「業務負荷は軽減されても、人による操作が介在する限りオペレーションミスをゼロにはできません。業務スピードを高めていくためにも、ここから先は自動化するしかないと判断しました」と宮本氏。
　そこで、イベント管理およびインシデント管理の自動化に向けて新たなツールの検討を開始。技術者からの勧めもあり、 PoCを通じて世界のデファクトスタンダードとなっているPagerDutyの採用を決定しました。導入にあたっては、システム変更によるお客様への影響を回避するため、既存のメール通知の仕組みを残しつつ、PagerDutyを発報先の宛先に追加することで並行稼働を実現。

PagerDutyの導入に携わり、その後宮本氏からプロジェクトマネージャーを引き継いだ嶋田氏は、「PagerDutyの導入が引き金となり、通知されるべきものが通知されなかったとなれば、大規模な障害につながりかねません。最悪の事態に備えて切り替えが可能な環境を残すことにしました。当社都合のシステム刷新ですから、慎重には慎重を期したというわけです」と説明します。
　また、AWSで開発したトリアージ機能をPagerDutyとAPIで連携。イベント発生後、しかるべき担当者へのエスカレーションがされている間に、PagerDuty上のノートにワークアラウンドが記載されるようにしたほか、サービスデスクが手動で行っていた本番環境へのアクセス権開放のプロセスを簡素化。エスカレーションを受けた担当者が速やかに対応に着手できるよう、アラートに応じた適切なアクセス権申請をPagerDutyからボタン操作一つでリクエストできるようにしました。

検知から初動対応までの自動化を達成サービスデスクの初期対応時間が10分の1に

　PagerDutyの導入により、同社は主に3つの大きな成果を手にしています。1つは大幅なコストカットです。サービスデスクでは、発報を受けてのトリアージや、電話連絡、本番環境へのアクセス権開放の作業が不要になり、業務工数が10分の1以下に削減。少ないリソースで対応できるようになったことで人件費36%削減に成功しました。PagerDutyのライセンス費用を含めても31%の削減を達成しています。

　2つ目は対応スピードの向上です。PagerDutyによる自動化への取り組みによって、イベント発生から既知のワークアラウンドの確認までが、人の手を介すことなくリアルタイムに行えるようになりました。また、本番環境へのアクセス権開放に関わる初動対応時間が10分の1に短縮されたことで、対処方法がわかっていながら待たされる不満も解消されています。
「PagerDutyでアラートを検知してから初動対応までの自動化は概ね達成したことになります。オペレーションミスを回避できるようになったのは大きな成果です。」(宮本氏)

　3つ目は、質の高い緊急体制の構築です。複数のイベントが同時発生した場合に、オペレーター数名で数十プロジェクトの担当者それぞれに順次電話連絡を行うといった業務は不要になりました。各チームへの一斉通知が可能なPagerDutyでは、速やかに問題解決を促すことで広域への影響を最小化できます。

PagerDutyの能力を最大限に活用しさらなる品質向上と負荷軽減に挑戦

「今後は、レスポンダー目線での自動化と効率化に重きを置き、インシデント対応の品質向上と負荷軽減の2軸で施策を実施していきたい」と語る嶋田氏は、具体策をこう説明します。「PagerDutyが提供するAIベースのトリアージ機能を駆使してアラートのノイズ低減とトリアージの完全自動化を実現し、本当に対応すべきインシデントに注力できる時間を捻出します。また、定常的なオペレーションを伴う特定のワークアラウンドに関しては、PagerDutyで指定したアクションを自動で呼び出せるようにするなど、手動オペレーションを極力排除していく考えです。その先には、PagerDutyをハブとして、過去事例検索や事後分析などの周辺機能をシームレスに連携し、高度なインシデント管理プロセスの構築を見据えています。」

　こうした計画の背景には、PagerDutyの機能や拡張性を最大限に活用することで、最終成果としての対応品質・速度の向上につなげる狙いもあります。PagerDutyには、共にインシデントプロセスを作っていくビジネスパートナーとして、さらなる進化への期待が寄せられています。