こんにちは、SREグループNRQLマスターの三橋です。
今回はNRQL実践問題集を通して組織のインシデント対応能力向上を図ろうとしている話について記載します。
なお、ここでのインシデントとはシステム障害によるものを指し示します。
想定読者
- オブザーバビリティの文化醸成をしていこうと考えている方
- インシデント対応スピードの改善に取り組もうと考えている方
- New Relicスキル向上施策を検討中の方
- ヤプリの裏側に興味がある方
背景と課題
今回の取り組みを行うにあたっての背景と課題は下記の通りです。
組織レベルでの話
- 数年前からオブザーバビリティツールとしてNew Relicを採用しており、APMの導入が進められてきた
- ライセンスの都合上APMのデータを見れる人間は限定されている
- New Relicの提供するオブザーバビリティレポートhttps://qiita.com/ktst79/items/505599ba60bd6f8ef815にあるように、弊社においてもインシデント対応はログファーストで行われることが多い
- システム構成は年々複雑になってきており、ログではどうしても状況を追うことが難しく、経験や勘に頼った対応が行なわれることが増えてきた
- オブザーバビリティにフォーカスが当てられるようになってきたが、具体的にこの先何をやっていくのか決まっていなかった
- どのようにオブザーバビリティの文化を浸透させていくか、どのように個々の理解度を測るかということに課題感があった
参考
qiita.com
個人レベルでの話
- 1年ほど好奇心の赴くがままにNew Relicを使用し、New Relicに対する知識がかなり身についた
- オブザーバビリティに対する解像度が増し、何が課題なのか、何をすべきかという方針を立てられるようになった
- インシデント発生時にNRQLを活用して様々な調査ができるようになってきた
- 個人レベルでは限界があるため、組織レベルでのスキルアップに取り組んでいく必要があると感じていた
NRQL実践問題集という手段
なぜNRQLなのか
オブザーバビリティとは「システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度」であると神本 O'Reilly Japan - オブザーバビリティ・エンジニアリング には記載があります。
NRQLとはNew Relic上に保存されたテレメトリデータに対し質問を投げるためのクエリです。New Relicのデータと対話するためにはNRQLが必要なのです。
NRQLを使えるメンバーを増えるということは、システムに自由に質問できるメンバーが増えるということです。システムに自由に質問できるメンバーが増えれば、インシデント発生時の調査等にかかる時間を削減することができます。
New RelicのGUIやNew Relic AIによるNRQL生成ではダメなのか
New RelicのGUIは非常に見やすく、直感的に事象を理解することができます。しかし下記の理由からNRQLを扱えた方が良いと考えています。
- GUIでは細かい粒度でデータを見ることができない
- 弊社の場合はアプリプラットフォームを扱っているため、特定のクライアント企業様が扱っているアプリのデータに絞って調査したい場合がある
- エンドユーザ様に提供する用のアプリとクライアント企業様が手元で動作確認を行うためのプレビュー用のアプリの2種類があるため、それらを区別して見たい場合がある
- トレースデータ周りをGUIから見ることができるユーザは限られている (ライセンスの都合上)
- ログデータ検索周りのGUIの表現力が乏しい
またNew Relic AIによりNRQL生成が楽になりましたが、こちらも下記の理由からNRQLを扱えた方がよいと考えています。
- AIに複雑なクエリを書いてもらうには適切な質問をできる必要がある
- AIが生成したクエリが意図した通りのものか判断できる必要がある
なぜ問題集のスタイルなのか
一番良いのは実際のインシデント発生時にNRQLを使って調査をすることです。これに勝るものはありませんが、インシデントは頻繁に発生するわけではないのでチャンスが限られています。また単純な座学形式の場合、受動的になってしまうためあまり身になりません。
問題集形式であれば時間を選ばず誰でもチャレンジできますし、特定の目的があるため試行錯誤を行う過程でさまざまな知識を身につけることができます。
実際に作成した問題集
自分が実際にインシデント対応等で書いたクエリを掘り起こし、類似した問題とすることで実践的な内容に仕上げました。現在のところ下記の3問しかありませんが要点を学べる内容となっています。1は分散トレーシングの問題、2はLogs in Contextの問題、3はログ検索の問題となっています。
- 過去一週間でポイントカード機能の平均応答時間が長かったアプリを特定せよ。またそのアプリのリクエストの中で応答時間が長かったリクエストを一つ選び、どのシステムの何という処理で時間がかかっていたか特定せよ。
- 過去一週間でXXXというサービスで最もエラー率が高い処理を特定し、その処理に関する特定のリクエストのログをすべて表示せよ。
- 過去一ヶ月でXXXというサービスで発生したエラーの中で最もエラー数の多いログと期間を特定し、その期間中にそのエラーに遭遇したアプリの数を算出せよ。また対象のアプリ一覧をCSVで取得せよ。
またそれぞれの問題には複数のヒントを設けており、サポートとしてNew RelicやNRQL、オブザーバビリティの基礎(特に馴染みの薄いトレース周り)が学べるドキュメントも用意しています。
期待する副次的な効果
オブザーバビリティの文化醸成にあたっては、やはりそのメリットを享受することが重要だと考えています。実際に「トレース計装などを行うことによって何が嬉しくなるのかよくわからない」といった声をいただくこともあります。
今回作成した問題は実際のインシデント発生時に書いたクエリをベースにしているため、これらを解くことでどのような効果が得られるのか体感できるような内容になっています。この体験を通して計装に対するモチベーションが向上することを期待しています。
これから
今はコンテンツ類を整備している段階ですが、将来的にはこれらのコンテンツを使った学習のサポートや定着度の評価もできるようにしていく予定です。
MIXIさんの「受け身な施策はまず使われない」という言葉を肝に銘じ、単に作成して終わりにするのではなく、クイズ大会を開くなど、より積極的な施策を順次展開していきたいと考えています。
