はじめに
開発部所属のkurosawa（kc-20190044）です。新卒として入社し二年目を迎えました。 今回はカブコムでインシデント管理に利用しているLMISを題材に開発部目線のイベントハンドリングの話をしようと思います。
LMISとは
私もLMISは使う側の人間ですので、ここは簡単にまとめます。
サービスデスク機能を主軸にしたチケット管理ツール・サービス
プラットフォームはsalseforce
当社では2019年7月から導入
製品ページ
https://www.lmis.jp/
LMISの当社利用状況
アラートのチケット化
他の多くの企業と同様に、カブコムのサーバーからは日々多くのシステムアラート*1が出ております。
これらのアラートはサーバー監視ツールによって各部署・チームに割り振られ、「重要度が高く設定されたもの監視チームから担当者への連絡」＋「アラートを知らせるメールの送信」によって我々スタッフは検知しています。
どのアラートが処理済みなのか、誰が対応しているかはメールサーバーを見てもわかりません。
LMISは各アラートを一つのチケットとして扱い、処理ステータス（所有者変更→調査→対策→承認）、所有者、調査・対策内容のメモなどのパラメータを付与します。これにより対応状況を可視化しています。
ナレッジ集積
LMISによるチケット形式の管理によって、調査や対策方法の記載がナレッジとして集積されます。 自分が開発に関わったシステムでもない限り、エラーメッセージ見てもどう対処していいかわからないことがほとんどです。 過去の対応状況や対応したスタッフを検索できることで、開発担当外のシステムも簡単なものであれば処理可能になり、複雑なものでもエスカレーションは容易になります。
1年ちょっとLMISを使ってみた所感
未対応リストをなくす意識
カブコムはお客様からお金を預かる立場上、お客様の資産を守るためインシデント対応は迅速に行わなければなりません。
ここで弊害となるのが、インシデントに直結する重要なアラートがその他のアラートに埋もれること、そして開発担当外のアラートの場合どれが重要か否かの判断が難しいことです。
自分が開発担当外のシステムアラートであっても対応可能なものは積極的に拾っていくことで、埋もれる可能性はケアすることができます。
重要度の判断に関しても、アラート対応の数を熟すことが最良の方法と考えております。日常的に発生するアラートを覚えることで、他の誰かが新規リリースしたシステムが吐き出したアラートを敏感に検知し、いつも見ないアラートが来ているということをチームメンバーに共有可能になります。
極論ですが、アラートが生じてもインシデントに繋がる前に対応すればよいのです。LMISに表示される未対応リストは極力なくしていきたいものです。
アラートを客観視して得た知見
開発担当外のアラート対応をしていると、途中で処理落ちした時に対応しやすいエラーメッセージやシステム作りを考えさせられます。
システムアラートに”xxxにnullを入れようとしています”という様なエラーメッセージを記載しただけのものや、エラー箇所すら書いてないものがたまに割り振られますが、対応できません。
エラーメッセージには調査方法や対処方法を設定するか、そうでなければ運用チームにエラーコードと対応手順を事前に知らせておくべきです。
また、カブコムのバッチやジョブは途中で落ちても頭から再実行をかければいいように設計されていることが多く、担当外のシステムのアラート対応をしているとこの類の設計思想の偉大さを感じます。二番目のバッチが落ちたら中間ファイルを削除して、最後のバッチが落ちたら再実行で、、、というような運用方法は複雑で、開発担当者しか対応できないシステムになってしまうため避けるべき、と思う今日このごろです。
ナレッジ集積ツールとしての限界
これはいわゆる暗黙知というやつなのですが、LMISの過去のチケット記載の調査方法や対策方法を読んでも対応できないことがあります。
「顧客影響なしのため静観」のような、何を判断基準にしているかわからないパターンです。
「よくよく見るとイントラサーバーから出ているアラートなので、たぶん社内スタッフが顧客情報を参照するときに入力不備があったんだろうな」というレベルのものならいいのですが、どこぞのDBを調べたうえでの判断だったりすると対応方法の踏襲不能です。
利用方法の不統一
最後におまけとしてデータ解析やスタッフの業績管理の話をします。LMISを利用しても社内スタッフの誰がどの程度アラート対応しているかを可視化することが困難になっています。 最大の理由は処理ステータスの進め方がスタッフによって違うことです。 LMISのステータス変更のタイミングは大まかに以下のパターンがあると思われます。
a.アラートが所属するチームに振られた瞬間にチケット所有者を自分に変更し、実際に調査・対策するタイミングでステータスを変更する
b.所有者は直ぐに変更するものの、ステータスを「調査」に進めず実際に調査をし、対策目処が立った時点でステータスを進める
c.対策目処が立ち（自分で対応できると判断したら）所有者を自分に変更する
今年の7月に私の所属するチームメンバーを対象にアンケートを取った結果きれいに分かれました。
アンケート調査_LMISのステータス変更タイミング
以上のように、この手のデータ解析はsalseforceをプラットフォームとするシステムの十八番のはずですが、活かしきれずにいる現状があります。
まとめ
チケット管理ツールとしてLMISを導入することで過去の対応履歴やエスカレーション先の検出が容易になりました。
カブコムはお客様のお金を預かる立場上、インシデントには特に敏感にならなけばいけません。
開発工程を工夫することでアラート対応はもっとやりやすくなるはずです。
カブコム側の開発・運用方法とLMISの利用方法の2点で課題を感じており、まだまだLMISの機能は使い切れていない部分がありますが、今後は課題を解決し、よりLMISを使いこなしていきたいと思います。
*1:この記事では、システムが吐き出したエラーメッセージを「アラート」、顧客影響のある障害を「インシデント」と記載しています。
