それはいつも突然に

昼休み後半で軽く食事を取ろうと思っていたら、担当システムからアラートが鳴りました。社内のSlackにも通知されています。程なくして、アラートコールが鳴りました。メイン担当なので、1年前からファーストコール(システムアラートが発生した時に24時間/365日で1番最初に電話を受ける担当)です。その後、もう1本かかってきました。

「○○(システム名)で致命的なアラートが発生しました。」

「知っている」と思いながら受付済のダイヤルトーンを押しました。メイン担当になって1年と少し、見たことがないパターンで複数の通知が来ていました。メインの監視サービスは Datadog です。担当している期間中に1度、Datadog 自体が大規模障害で通知が止まり、自動化されるコトのありがたみを実感しました。いつもお世話になっています。

「タイミングが悪かった。」

数年前から担当してくれているベテランメンバーが、丁度午後休みで退勤した後でした。今まで何度も見たコトがあるアラートも含まれていたので、順を追ってデータの正常性と業務影響を確認しようと思いました。

チームでは、確認者が着手する時にSlack上でリアクションする運用ルールにしています。PM兼SEではありますが、システム詳細の奥の奥まで把握しているのは、チーム内で1番経験があるベテランメンバーです。自分の知っている・覚えている範囲で判断するのは、危険だと直感しました。アラート通知にひと言、書きました。

"いつもと出方が違うようです。調べてみます。"

切り分けと優先順位付け

実際はもっと複雑ですが、平たく言えば優先順位は以下ように整理できます。

業務が止まるような大きな影響
データ不整合がおきる影響
軽微な業務影響

アラートは複数クライアントのひとつから特定時間に立て続けに発生している状況でした。以降は発生していません。その時点で1.は除外できました。

2.は、タイムウィンドウ内にデータのリカバリーが必要になります。つまり、急ぎリカバリーが必要なデータ不整合が発生していないか、確認が必要になります。アラートを切り分けると、複数種類の事象が確認できました。

ここでポイントになるのが、調査の優先順位付けです。これまで自分の経験や積み上げてきた手順からは、短い時間で判断できませんでした。Slackでサポート可能だったベテンランメンバーにアドバイスを仰ぎました。チャット内での議論を通して、普段あまり異常終了しないプロセスを優先的に調べた方がリカバリーが必要な場合は初動が早められる、と結論が得られました。

Datadog で通知された AWS Lambda の第1優先対象アラートからリクエストID(キー情報)で Cloud Watch の実行ログを解析しました。リトライ状況、終了状況を確認、影響がないコトが判断できました。ただ、いくつかあるアラートひとつ目なので継続調査です。

限られた時間の中で

続いて、良く発生しており、2.3.のケースも含まれるアラートの解析です。1,2分の間に立て続けに十数件発生してました。レアケースです。コレは Cloud Watch, DynamoDB, 内部DBを業務的なキー情報を元に横断的に調査する必要があります。つまり、時間を要するコトが判断できました。

調査・エビデンス取得・整形のプロセスがありますが、時間を要するのは整形のプロセスです。こちらを簡略化し、一覧にまとめる形で調査サイクルのスピードを上げる方針としました。一覧に落とし込んだ項目は以下の通りです。

対象	説明
LambdaリクエストID	ログからの取得
業務キー	システム内のキー情報
DynamoDB値	一次処理結果
内部DB値	最終処理結果
リカバリ要否	調査結果

十数件全て調査を終え、ひと目で確認できる一覧にし、Slackでも連携しました。時間はかかりましたが、タイムウィンドウ内で余裕をもって対処できました。数をこなすうちにスピードアップした実感もありました。

まとめ

簡単ですが、アラートを通して得られた気付きを残しておきます。

サポートを求める場合は早めが大事

なんとかひとりで対応しようとして、手を動かす時間が止まるコトは、対処が間に合わないリスクを増大させます。チームで取り組む意識で取り組むと良いと思います。

伝達は「客観性」と「正確さ」

テキストでの伝達は「客観性」と「正確さ」な伝達に特に注意が必要です。情報の受け手は、調査者が見えてるAWSマネージドコンソールは見えていません。調査者が気付いていないポイントに気付く場合があります。必要に応じて、スクリーンショットの共有も大変有効です。

切り分けと優先順位

物事には適切な優先順位があります。対処する時はつねに念頭に置いて、時間経過を踏まえて判断して行きましょう。今回はチーム内で完結できるケースでしたが、エスカレーションが必要なケースは特に初動が重要です。責任のレイヤーによっても方針が変わるケースも少なくありません。

タイムウィンドウに向き合う

決まった手順があり、確かに後から見る場合は分かりやすいなどの緊急の場合には必ずしも必須ではないケースはあります(無論必要な調査は全てします)。なぜ、その手順になっているのか、本来の目的を理解して簡素化できる部分、つまりスピードアップできる部分がないか意識して調査にあたりましょう。

今回、ベテランメンバーにアドバイスを求めて、自分自身で検知・調査・結果報告をやり切って、今後のためにログを残しておくコトにしました。何かの気付きになれば、幸いです。

以上です。