データ基盤の障害状況をTableauで可視化した話

Loading...

こんにちは!Integrated Data Service部の塚本です。

普段「大した話でなくとも情報発信をしていこう」とメンバーに言っているのですが、自らがファーストペンギンにならないと続きづらいだろうということで投稿することにしました。

この記事を3行でまとめてみる

  • 現象: データ基盤では、連携するシステムや取り扱うデータが多いため様々な障害が起こる
  • 課題: 短い期間に複数の障害報告を受け取ると、報告を受けた側は「また障害が起きたのか」と過剰な心配や注意をしてしまいかねない
  • 解決方法: データ基盤の障害状況をTableauで可視化することで、定量的に判断ができるようにした

背景

Integrated Data Service部では、KADOKAWAグループに対してデータ基盤を提供しています。このため、ポータル(主にニコニコ)事業や出版事業、EC事業、管理部門といったKADOKAWAグループにある様々なシステムと連携し、データを受け取っています。

連携するシステムや取り扱うデータの数が増えると、どうしても不具合や障害が発生する確率が高まります。私たちが管理しているデータ基盤で障害が発生することは勿論ですが、連携先のシステム(データソース)側の障害がこちらの不具合に繋がることもありますし、取り扱うデータの数が増えることでデータ仕様を担当者が把握しきれずデータモデリングの際にバグを混入してしまうということもあります。

不具合や障害の発生する確率が高まると、偶然、障害が頻発することが起こります。原因は全く別なのですが、偶々、連日障害が発生するということが起こったりします。

私は、データ基盤の責任者およびデータスチュワードとして、事業部門の方々にデータ基盤に関する障害を報告する立場にあるので、障害が頻発すると説明に困ります。短い期間に連続で障害が発生すると、「データ基盤は障害が多い」というイメージがついてしまいます。

これに対して、何とかしようとマイクロマネジメントに走っても効果はありません。同じ失敗を繰り返しているのであればテコ入れも必要かもしれませんが、個々に原因が異なるのであれば、先立って対応しようがありません。

取り組んだこと

「データ基盤は障害が多い」というイメージ(定性)を払拭するには、定量的な検証が一番です。

このため、障害状況を可視化するダッシュボードを作ることにしました。ダッシュボードの仕組みを簡単に表現したのが以下の図です。

図1: 障害報告可視化の仕組み

障害の報告は、サービスのオーナーからSlackのワークフローで行うようにしていた(図2)ため、このSlackのワークフローの入力をGoogle Sheets for Workflow Builderを使って、会社のGoogle Sheetsにも書き出すようにしました(図3)。

slack.com

図2: 障害報告のためのSlackワークフロー

 

図3: スプレッドシートにコピーされた障害報告データ(加工前)

 

ここでの地味な工夫ですが、今回のダッシュボード作成を受けて、報告者による表記揺れを抑えるために、Slackワークフローの入力を自由記入からリスト選択に変更しています。表記揺れを無くす処理は川上で行っていた方がいいので、できる限りSlackワークフローで行います。

次に、この書き出したデータをApps Scriptなども使いつつ、他のシートでTableauが読み込みやすいデータに変換します(図4)。

図4: スプレッドシートにコピーされた障害報告データ(加工後)

ここはいけていない部分なのですが、障害状況は部署内の誰でも確認できるようにしたいため、このスプレッドシートは共有ドライブに保存されています。しかしながら、Tableauは、共有ドライブにあるスプレッドシートを読むことができないため、IMPORTRANGE関数を使って、マイドライブにあるスプレッドシートに内容をコピー・同期させ、データソースとしています。

Tableauのデータ接続は、抽出を選択し、私のGoogleアカウントの接続情報を埋め込むことで、Tableau Serverにワークブックをアップロードした場合でも、部署内のメンバーが見ることができるようにしています。

この方法ならば、私が何らかの形でいなくなったとしても、共有ドライブにあるスプレッドシートを使って、新しいメンバーがデータソースを置き換えれば同じように動作させられるので、いいものとしています。

ダッシュボードはまだ模索中ですが、以下のような構成にしています(図5)。

図5: データ基盤の障害状況を可視化したダッシュボード

サービス毎に色分けされた面グラフを使い、サービスのオーナーが障害状況を意識できるようにしています。また、パラメーターとリファレンスラインを使い、四半期毎の(下回りたい)目標値を設定し、現在の進捗率も表示するようにしています。そして、傾向線を使い、今のままで目標を達成できるのか否かがわかるようにしています。

ここでの地味な工夫ですが、障害発生件数を成果指標としてしまうと、ユーザー影響の少ない障害が数多く発生した方が悪く見えてしまうため、障害の影響規模に応じてレベリングを行い、そのレベルに応じて重みをつけた障害ポイントというものを導入しています。障害ポイントの重み付けの正しさを説明するのは難しいですが、一旦、レベルが上がる毎に指数的に(1, 2, 4…)ポイントを増やすことでそれらしくしています。

いけていない部分として、Tableauはデータが存在しないとグラフ描画できないので、障害が発生していないと傾向線や進捗率の値が、直近で発生した障害時点のままになってしまいます(解決法を模索中)。図5では、あっという間に目標値を超過してしまいそうに見えますが、表示時点から7月末まで障害は全く起こっていないため、グラフから受け取るイメージと実態はかなり異なっています。

ただ、障害が発生していないということは、このダッシュボードを見る必要がない好ましい状態なので、これも妥協しています。

まとめ

高度な内容ではないですが、やはり定量的に物事を捉える癖はデータ活用を推進する部署としてつけておく必要があるなと再認識した事例でした。

今後は、運用を続けながら、部署の内で起きた障害と外で起きた障害のどちらが影響を与えているのか、システム障害とデータの不具合のどちらが影響を与えているのかの分析を続け、対策を講じていければと思っています。

懸念点として、このように障害状況が可視化されると、サービスのオーナーに悪意がなくても、障害の報告が遅れたり、障害レベルを引き下げて報告したりする方向に無意識の圧がかかるものだと思っています。ですので、この運用を続けるためには、障害報告を賞賛する文化も併せて強くしていかなければならないと感じています。

この辺りは、(KADOKAWAの書籍ではないですが)現場が動き出す会計 ―人はなぜ測定されると行動を変えるのかに色々書かれているので興味があればどうぞ。

bookmeter.com

それでは、また次の機会にお会いしましょう!

KADOKAWA ConnectedやIntegrated Data Service部に興味を持っていただけたのであれば、採用ページもご覧ください!

kdx.co.jp

P.S.

他社の書籍だけをお薦めするのはどうかと思ったので、角川書店の『確率思考の戦略論 USJでも実証された数学マーケティングの力』も最後にダイレクトマーケティングしておきます。

bookmeter.com