Cloud Loggingの設定不備を題材にポストモーテムしてみる
はじめに
本記事では、Google SRE のポストモーテムの考え方を参考に、実際に発生したインシデントを題材として分析を行う。
特定の人や組織の責任を追及することが目的ではなく、ポストモーテムの考え方を整理することを目的として記載する。
また、実際の運用や組織によって最適な判断は異なるため、「自分ならどのようにポストモーテムを実施するか」という観点で整理していく。
ポストモーテムとは
ポストモーテムとは、障害発生後に実施する振り返りである。
目的は「誰が悪かったか」を特定することではなく、
- 何が起きたのか
- なぜ起きたのか
- なぜ発見できなかったのか
- どうすれば再発を防げるのか
を整理し、組織として学びを得ることである。
本記事でもこの考え方に沿ってインシデントを分析していく。
インシデント概要
背景
別チームより、GCP Cloud Logging のログルータに設定されている除外フィルタについて、条件を追加したいとの依頼を受けた。
対象のフィルタは既存運用中の設定であり、今回は既存条件に条件を追加する形で対応を実施した。
発生した事象
変更を検証環境およびステージング環境へ展開した後、本番環境へリリースした。
リリースから約2週間後、依頼元チームより「追加した条件に該当するログが除外されていない」との連絡を受けた。
調査の結果、追加した除外条件が意図した通りに評価されていないことが判明した。
影響
- 想定していたログが除外されなかった。
検知
- 依頼元チームからの問い合わせを契機として事象が発覚した
本記事で分析すること
本インシデントについて、以下の観点からポストモーテムを実施する。
- 何が起きたのか
- なぜ起きたのか
- なぜ検知できなかったのか
- どうすれば再発を防げるのか
技術的な原因
調査の結果、Cloud Logging の Log Query Language（LQL）における条件式の評価方法について認識違いがあったことが判明した。
今回の変更では、既存の除外フィルタに条件を追加する対応を実施した。
その際、演算子の優先順位を誤って認識していたため、意図とは異なる条件式として評価されていた。
実際の条件式を簡略化すると、以下のような構成である。
A AND B OR C
実装時は AND が OR より優先して評価されることを前提とし、以下のように評価されることを想定していた。
(A AND B) OR C
しかし、LQL では演算子の優先順位が一般的な論理演算子とは異なる。
そのため実際には以下のように評価されていた。
A AND (B OR C)
期待していた条件式と実際に評価される条件式が異なった結果、除外対象となるはずのログが条件に一致せず、Cloud Logging 上に保存され続けた。
図で表すと以下のようになる。
想定
(A AND B) OR C
│
├─ AかつB
└─ またはC
実際
A AND (B OR C)
│
├─ A
└─ かつ
├─ B
└─ またはC
つまり今回のインシデントは、
設定した条件式が
意図しない形で評価されていた
ことによって発生した。
技術的な観点だけで見れば、
LQL の演算子優先順位を誤認し、
意図と異なるフィルタ条件を設定した
ことが直接原因である。
なぜ検知できなかったのか
技術的な原因は、LQL の演算子優先順位を誤認していたことである。
しかし、ポストモーテムの観点では、
なぜそのミスが本番環境まで到達し、
約2週間発見されなかったのか
を分析することが重要である。
今回の事象では、検証・レビュー・運用の各段階で検知の機会は存在していたが、いずれの段階でも問題を発見することができなかった。
まず、対象のログは本番環境でのみ出力されるログであり、検証環境およびステージング環境では発生しなかった。
そのため、リリース前の検証では設定内容やパラメータの確認のみを実施しており、実際にログが意図どおり除外されることまでは確認できていなかった。
結果として、
設定が正しく投入されていること
は確認できたものの、
意図した条件でログが除外されること
までは確認できていなかった。
また、変更内容に対しては AI レビューおよび人によるレビューを実施していたが、いずれのレビューでも問題は指摘されなかった。
今回の条件式は構文上の誤りを含んでおらず、一見すると自然な条件式であったためである。
さらに、レビューでは条件式の妥当性は確認していたものの、LQL 固有の演算子優先順位という観点での確認は行われていなかった。
結果として、演算子優先順位に関する認識誤りを発見することができなかった。
加えて、本番リリース後の動作確認も実施していなかった。
対象ログは本番環境でのみ発生するため、本来であればリリース後に設定が意図どおり動作していることを確認することで問題を発見できた可能性がある。
しかし、本番環境での確認には一定のコストが伴うことから、動作確認は実施されなかった。
その結果、設定不備は依頼元チームからの問い合わせを受けるまで発見されず、約2週間継続することとなった。
今回の事象は、
担当者が設定を誤った
だけではなく、
検証で見つからなかった
↓
レビューでも見つからなかった
↓
本番確認でも見つからなかった
という複数の要因が重なった結果、長期間継続したものと考えられる。
改善策
今回の事象を踏まえ、以下の改善策を実施する。
条件式の記載ルールを明確化する
演算子優先順位の解釈に依存しないよう、論理演算子を含む条件式には括弧を使用することをルール化する。
例えば、
A AND B OR C
のような記載は避け、
(A AND B) OR C
または
A AND (B OR C)
のように評価順序を明示する。
レビュー観点を見直す
条件式を含む設定変更については、
- サービス固有仕様の確認
- 演算子優先順位の確認
- 想定される評価結果の確認
をレビュー観点として追加する。
リリース後確認を実施する
本番環境でしか確認できない設定変更については、リリース後に動作確認を実施する。
特に今回のようなログ制御設定については、設定投入の確認だけでなく、意図した結果になっていることを確認する運用を検討する。
今回の学び
今回のインシデントを最初に見たときは、
LQL の仕様を正しく理解していなかったこと
が原因だと考えていた。
しかし、ポストモーテムを通して振り返ると、問題は設定ミスそのものだけではなかった。
仮に担当者が変わったとしても、
- 検証環境で確認できない
- レビューで評価結果を確認しない
- 本番リリース後に確認しない
という状況であれば、別の形で同様の問題が発生する可能性がある。
今回の事象から得られた学びは、
人のミスをなくすこと
ではなく、
ミスが発生しても発見できる仕組みを作ること
の重要性である。
ポストモーテムの価値は責任者を探すことではなく、同じ失敗を繰り返さないための改善点を見つけることにあると改めて感じた。
おわりに
今回は Cloud Logging の除外設定誤りを題材に、ポストモーテムを実施してみた。
技術的な原因そのものは比較的単純な設定ミスだったが、分析を進めることで検証・レビュー・運用それぞれの段階に改善余地があることが分かった。
障害対応では技術的な原因の特定に注目しがちである。
しかし、ポストモーテムの観点では、
なぜその問題を発見できなかったのか
まで掘り下げて考えることが重要である。
本記事が、障害発生後の振り返りやポストモーテムを実施する際の参考になれば幸いである。