はじめに

以前投稿した「エンジニアなら知っておきたいトラブルシューティングのセオリー」では、トラブルシューティングの基本的な流れを7つのステップにコンパクトにまとめて解説しました。

ステップ1「事象を把握する」
ステップ2「問題発生箇所を特定する」
ステップ3「暫定対処を実施する」
ステップ4「事象を再現し、発生条件を特定する」
ステップ5「原因仮説を立てる」
ステップ6「仮説を検証し、原因を特定する」
ステップ7「恒久対処を実施する」

しかしコンパクトにまとめた分、注意点として述べていることの意図や背景が伝わりづらい部分もあったかもしれません。

そこで本記事では、アンチパターンの形で、セオリーを守らないことで起こり得る具体的な失敗事例を8個ご紹介します。各事例がどのセオリーに違反しているかを明示しながら解説します。

本記事を読むことで、以下の知見を得られます。

トラブルシューティングにおけるよくある落とし穴を把握できる
セオリーを守ることの重要性を具体的なシチュエーションから理解できる
実際の障害対応時に役立つ教訓として活用できる

ぜひ、以前の記事と併せてお読みいただき、トラブルシューティングスキル向上の一助としてください。

アンチパターン1: 影響範囲の調査を行わず、一部分だけ対処して他領域の障害を見落とす

シチュエーション
在庫管理モジュールのバグで「在庫数が負の値になる」という報告があり、モジュール修正を実施した。しかし、実は関連する販売管理システムでも既に不正データを書き込んでおり、顧客請求処理が滞って顧客クレームが続出した。

問題点

システム連携やデータ整合性を考慮せず、「ここだけ直せばOK」と単独対応をした。
他サービスへの影響を確認しないまま、報告のあった部分の修正だけを実施した。

違反したセオリー
ステップ1「事象を把握する」

アンチパターン2: エラー画面だけ見てフロントエンドに問題があると決めつける

シチュエーション
ECサイトで「購入」ボタンがエラーになる事象が発生したため、運用担当はフロントエンドのJavaScriptコードに問題があると判断し、フロントエンド担当に調査を依頼した。フロントエンド担当は、ブラウザのDevToolsや簡易テストでコードの不具合を探したが、問題は見つからず時間だけが過ぎていった。
実際にはバックエンドAPIで在庫情報取得時にタイムアウトが発生していたことが後から明らかになった。

問題点

運用担当がAPIログやメトリックを確認しておらず、ユーザインターフェース上のエラーだけを頼りに「フロントエンドの問題」と決めつけた。
フロントエンド担当が担当領域以外の状態について確認を促すことなく、依頼されたコード内の調査のみを行った。

違反したセオリー
ステップ1「事象を把握する」
ステップ2「問題発生箇所を特定する」

アンチパターン3: ECABの承認プロセスを飛ばして暫定対処を実施

シチュエーション
APIサーバ不具合時、API開発担当者が急ぎ原因と特定し、暫定対処としてキャッシュ設定を変更しデプロイを行った。このとき、「特定した原因に確証があったこと」と「ユーザから復旧を急かされたこと」により、独断で緊急変更諮問委員会（ECAB : Emergency Change Advisory Board）の承認手続きを省略しデプロイしていた。
デプロイ後、関連する他サービスとのキャッシュ整合性が崩れ、別サービスでも障害が発生した。

問題点

ECABによる承認プロセスを省略したため…
- 暫定対処に伴うリスク評価や周辺影響調査を怠った。
- 暫定対処の妥当性や影響評価がシステム統括者視点で行われなかった。
- 他サービスの担当チームとの連携不足が生じた。

違反したセオリー
ステップ3「暫定対処を実施する」における、責任者の承認取得

アンチパターン4: 本番環境で原因調査のため、DEBUGログ出力し別障害発生

シチュエーション
特定条件下で発生する不具合について詳細調査するため、本番環境でDEBUGレベルのログ出力設定を有効化した。すると大量のログデータが生成され、ディスク容量不足によってアプリケーション全体が停止した。

問題点

本番環境で直接調査作業を行い、大量ログ出力によるディスク圧迫を引き起こした。
テスト環境やステージング環境で再現条件特定から始めるべきだった。

違反したセオリー
ステップ4「事象を再現し、発生条件を特定する」における、本番環境以外での事象の再現

アンチパターン5: 原因仮説を立てる際にサポート窓口へ問い合わせず、解決が長期化

シチュエーション
外部ベンダー製のライブラリを使った機能で不具合が発生し、一般公開されているドキュメントやフォーラムの情報だけで何とか独力で解決しようと試行錯誤を続け、3日経過した。
どうにも手がかりが掴めないため、ようやくサポート窓口に連絡したところ、「そのライブラリは既知のバグがあり、最新パッチで修正済み」と瞬時に回答され、あっさり解決に至った。

問題点

サポート窓口への問い合わせを視野に入れず、内部調査だけにこだわった。

違反したセオリー
ステップ5「原因仮説を立てる」における、製品サポート窓口への問い合わせは最初に行うこと

アンチパターン6: 検証で要素を切り分けずまとめて対策し、原因特定を怠る

シチュエーション
高負荷時にAPIレスポンスが著しく遅くなる障害が発生した。原因仮説としてDBインデックスが張られていない・ネットワーク帯域不足・APIサーバリソース不足が挙げられた。そのため、DBインデックス改善・ネットワーク帯域拡張・サーバ性能UPを全て同時に実施した。
その結果、APIレスポンス速度は改善したため、障害対応を終了した。
数カ月後、ネットワークやサーバが過剰スペックな故にランニングコストが予算オーバーしていることが発覚し、コストカットのため障害の原因特定をやり直す羽目になった。

問題点

複数の対策を同時に実施し、効果があった施策を特定しなかった。

違反したセオリー
ステップ6「仮説を検証し、原因を特定する」における、検証する要素は一つずつ切り分けること

アンチパターン7: 暫定対処でサービスが動くようになったため、障害対応終了

シチュエーション
製造したアプリで定期的にメモリリークが発生し、アプリ停止することが判明した。対処として、アプリの定期再起動を組み込み、メモリリーク問題を解消した。
しかし、ユーザ増加に伴い、定期再起動の間隔よりメモリリーク間隔が早まったことで障害が再発し、初回トラブル時より多くのユーザに迷惑をかけた。

問題点

「とりあえず動いているから大丈夫」という思い込みで根本原因の調査を怠った。
アプリ定期再起動は、ユーザ数が少ない場合のみ有効なワークアラウンドだった。

違反したセオリー
ステップ7「恒久対処を実施する」

アンチパターン8: なぜなぜ分析で組織やプロセスの問題を洗い出せず、個人のミスのみを対処

シチュエーション
大規模サービス障害が発生し、調査した結果「サーバ管理担当者が本番環境と検証環境の設定ファイルを取り違えた」ことが表面的な原因だと判明した。そこでなぜなぜ分析を行ったものの、担当者がミスした理由については「注意不足」と結論づけ、「担当者に二重チェックを義務付ける」という対処策が恒久対処として決まった。
しかし実際には、設定ファイルのレビューフローが存在せず担当者任せで設定変更が行われる状況や、運用手順書で環境差異の記述が曖昧であることが真の原因であった。組織やプロセスの課題を洗い出さないまま「担当者の注意力だけに依存する対処」に留まったため、同じようなミスが違う担当者でも再発した。

問題点

なぜなぜ分析が形骸化しており、個人のミスとして片づけてしまったことで、組織的な承認フローや運用プロセスの抜け穴を深掘りしていない。
導出した対処策が「担当者の二重チェック」など属人的な範囲に留まっている。

違反したセオリー
ステップ7「恒久対処を実施する」における、なぜなぜ分析で組織やプロセスの問題も視野にいれること

まとめ

本記事で紹介したアンチパターンの多くは、私自身が過去に犯してしまった失敗や、周囲のプロジェクトで目撃した事例を元にまとめています。いずれも、前回の記事で紹介したセオリーを踏まえずに省略や思い込みをしてしまった結果が招いたものばかりでした。

トラブルは避けられないものですが、発生時の対応でクライアントからの信頼度が大きく変わります。

ぜひ本記事を参考に、トラブルシューティングのスキルを身につけ、落ち着いてセオリー通りに問題対応を行ってください。正しいプロセスを踏むことで、再発防止策とあわせ、システムの安定運用を継続できるはずです。

はじめに

アンチパターン1: 影響範囲の調査を行わず、一部分だけ対処して他領域の障害 を見落とす

アンチパターン2: エラー画面だけ見てフロントエンドに問題があると決めつける

アンチパターン3: ECABの承認プロセスを飛ばして暫定対処を実施

アンチパターン4: 本番環境で原因調査のため、DEBUGログ出力し別障害発生

アンチパターン5: 原因仮説を立てる際にサポート窓口へ問い合わせず、解決が長期化

アンチパターン6: 検証で要素を切り分けずまとめて対策し、原因特定を怠る

アンチパターン7: 暫定対処でサービスが動くようになったため、障害対応終了

アンチパターン8: なぜなぜ分析で組織やプロセスの問題を洗い出せず、個人のミスのみを対処

まとめ

アンチパターン1: 影響範囲の調査を行わず、一部分だけ対処して他領域の障害を見落とす