インフラ試験の観点リストと書き方｜18年の現場経験で分かった「運用で泣かない」ための極意

インフラ構築における「テスト」は、単にパラメータ通りに設定したことを証明する作業ではありません。真の目的は、「将来発生する障害を最小限に抑え、運用担当者が安眠できるようにすること」にあります。

今回は、若手エンジニアが作成するテスト仕様書に対して、リーダークラスが「どこを見ているのか」を、私の苦い失敗談を交えて解説します。

※注記： 本記事はサーバー、ネットワーク、ストレージといったインフラ基盤観点での試験に特化して解説しています。アプリケーション固有の挙動や機能試験については割愛していますが、基盤が安定してこそアプリが動くという前提で読み進めてください。

単体から運用まで：インフラ試験の全フェーズと必須観点

インフラ試験は、段階を追って「点」から「面」、そして「安全性・継続性」へと確認範囲を広げていきます。

試験区分	主な確認観点（インフラ視点）	目的
単体試験	OS/ミドルウェア設定、パラメータ突合	個々のコンポーネントが設計通りかの確認
結合試験	NW疎通、名前解決、IaCの冪等性	システム間の「継ぎ目」が正しく機能するかの確認
障害・監視試験	クラスタ切替、監視検知・通知フロー	故障時にサービスが継続し、かつ異常に即座に気付くため
性能・負荷試験	スループット、リソース飽和時の挙動	高負荷時や長期間稼働でも安定性を維持できるかの確認
セキュリティ試験	ポートスキャン、脆弱性、不要ルールの削除	外部・内部からの攻撃リスクを最小化できているかの確認
運用試験	起動停止、バックアップ、パッチ適用手順	実際の運用フェーズで「人間がミスなく維持管理できるか」

18年の現場経験から学ぶ：運用で泣かないための「失敗談」共有

私がこれまでのキャリアで経験した「痛い目」は、すべて試験観点の漏れから来るものでした。若手の皆さんに同じ思いをしてほしくないので、特に重要な2つの教訓を共有します。

① 「スイッチの沈黙」：監視のない障害試験は無意味

あるプロジェクトで「冗長化も組んだし、構築は完璧だ。監視設定は時間がないから運用後に回そう」と判断してリリースしました。

しかし本番稼働直後、通信が不安定に。監視画面には何もアラートが出ず、サーバやDBのログを数時間しらみつぶしに調べ、ようやく「コアスイッチのポートエラー」に辿り着きました。原因は、スイッチのsyslog監視設定の漏れ。

「壊れること（冗長化）」は確認していても、「壊れたことが通知されること」を確認していなかったのです。「検知して初めて、障害試験は完了する」というマインドセットを持ちましょう。

私がかつて経験した『スイッチの沈黙』による大規模障害では、試験段階での監視観点の漏れが、後にチーム全体を巻き込む8時間の死闘へと繋がりました。その過酷な現場で、技術以上に私を支えたのは『判断』と『報告』の技術です。詳細は（【実録】システム障害対応の舞台裏）で公開しています

② 「数年後の時限爆弾」：ログローテーションと保守の盲点

90日サイクルのログローテーション試験。スケジュール的に実機確認が難しく、設定値の目視確認だけで済ませました。

しかし運用開始から数年後。ある日突然、システムが全停止しました。原因は、ローテーションが正しく機能せず、蓄積されたログがディスクを食いつぶしたこと。数年前の「まぁ大丈夫だろう」という慢心が、時限爆弾となって爆発したのです。

もしスケジュール的に確認が難しいなら、「リリース後の運用フェーズで、最初のローテーションを確実に目視確認する」というタスクを運用項目に組み込むのがプロの判断です。これはOSパッチ適用や時刻同期（NTP）の試験でも同じことが言えます。

リーダーが承認する「運用受け入れ」の合格ライン

運用部門へ引き継ぐ際、これらが揃っていないと「合格」は出せません。特に重視する4大項目がこちらです。

① 起動停止試験

単に「起動・停止ができる」だけでなく、サーバ間の依存関係が重要です。

• DBが上がる前にAPが起動してエラーを吐かないか。
• 手順書を見ながら、現場のオペレーターが迷わず一人で実施できる内容になっているか。

② バックアップ・リストア試験

「バックアップが取れている」のは当たり前。本当に重要なのはリストア（復旧）です。

• ファイルが戻るだけでなく、アプリケーションが正常にサービス提供できる状態まで復旧することを確認したか。
• 万が一の際、データの整合性が担保されているか。

③ 監視試験

前述の失敗談の通り、障害と監視はセットです。

• 想定した障害に対して、正しい重要度（Critical/Warning）でアラートが飛ぶか。
• 保守作業（再起動など）の際に、不要な通知で運用者を起こさないための「静観手順」があるか。

④ ドキュメント確認

運用担当者が「これさえあれば戦える」という武器が揃っているか。

• システム設計書： 最新のパラメータが反映され、構成図と実機が一致しているか。
• 運用手順書： 誰が読んでも同じ結果になるか。起動停止手順と、バックアップ・リストア手順が重要です。
• 保守連絡先一覧： 障害時、HWベンダー等のどこに、どの保守番号で連絡すべきか即座にわかるか。

システム設計書については以下の記事も参考にしてみてください。

まとめ：試験仕様書は「未来の自分」へのラブレター

インフラ試験は、未来の自分、あるいは後任の担当者が泣かないために行うものです。

「設定通りに動く」のはスタートライン。その先にある「監視・性能・セキュリティ・ドキュメント」という盾を揃えることで、初めてシステムは「本番環境」に耐えうるものになります。

ぜひ、あなたの試験仕様書にもこれらの観点を盛り込み、「現場の守護神」として信頼される設計を目指してください。

---

テスト工程をベンダーに任せる場合でも、試験項目や実施結果の確認を丸投げにしてはいけません。万が一、本番稼働後に「テスト漏れ」が発覚した際、責任を問われるのはサービスマネージャーであるあなた自身だからです。

ベンダーを適切にコントロールし、品質を担保するための「対等なパートナーシップ」の築き方は、こちらの記事が参考になります。