DevOpsエンジニアのための画面録画：インシデント、パイプライン、Runbook

DevOpsの仕事はスピードが求められ、チームは分散しており、常にページャーの通知に作業を中断されます。深夜3時に障害を診断したエンジニアと、翌朝それをレビューするチームとの間では、コンテキストが失われがちです。画面録画はそのギャップを埋めます。一瞬で消えてしまうターミナル操作、ダッシュボードでの調査、パイプラインのデバッグを、チーム全員が学べる資産に変えてくれます。誰かが記憶を頼りに何が起きたかを再構築する必要はもうありません。

なぜDevOpsチームにはログだけでなく動画が必要なのか

ログやメトリクスは「何が起きたか」を教えてくれます。しかし、エンジニアが「どのように」問題を調査したか——最初にどのダッシュボードを確認したか、どのコマンドが決定的な手がかりを示したか、なぜ見当違いの原因候補を除外したか——を記録することはほとんどありません。そして、その思考プロセスこそ、次にオンコール対応するエンジニアが必要としているものです。

DevOpsでよくある活用例:

• インシデント調査: 事後の再現ではなく、実際に起きているライブのデバッグプロセスを記録する
• CI/CDパイプラインの解説: ビルドが失敗している理由と、修正がどう機能するかを示す
• Infrastructure as Codeレビュー: TerraformやPulumiのプランをマージ前に一通り確認する
• オンコール引き継ぎ: 長い文書での引き継ぎではなく、数分で次のエンジニアに未解決の問題を伝える
• デプロイのデモ: 新しいロールアウト手順を他チームに引き継ぐ前に記録する
• ポストモーテムの証拠: インシデント発生時のダッシュボードの状態を、振り返りのために正確に残す

インシデント調査を記録する

録画に最適なタイミングは、問題を修正した後ではなく、まだ診断している最中です。ライブの調査を録画すれば、行き止まりの試行も含めた実際の思考プロセスを捉えることができ、それは往々にして洗練された要約よりも参考になります。

インシデント調査を録画する方法:

1. 根本原因がわかる前でも、調査を始めた時点ですぐに録画を開始する
2. 仮説を声に出しながら進める: 「14:02にレイテンシが急増、14:00のデプロイと相関しているか確認中」
3. 実行するすべてのダッシュボード、ログクエリ、コマンドを記録する
4. 根本原因が判明したら、後でタイムスタンプを参照しやすいようにカメラの前ではっきりと述べる
5. 修正と検証が終わるまで録画を続ける

その後、ポストモーテム用に重要な部分だけに編集した動画を作成しますが、完全な未編集版もアーカイブしておきましょう。同様のインシデントが再発したとき、ハイライト版よりも役立つことが多いためです。

CI/CDパイプラインの解説

パイプラインの故障は、DevOpsエンジニアにとって最もよくある中断の原因の一つであり、解決後にドキュメント化しやすいものでもあります。

パイプラインのデバッグセッションを録画する:

• 失敗したビルドログは省略せずに全体を記録する——ノイズに見える部分に手がかりが含まれていることが多い
• 最後に成功したビルドと失敗したビルドの差分を示す
• どのステージが失敗し、なぜ失敗したか(依存関係の解決、テストの不安定さ、タイムアウト、権限エラーなど)を説明する
• 修正内容を実演し、カメラの前でパイプラインを再実行してグリーンになることを確認する

こうした録画をパイプライン設定と一緒に保存しておけば、同様の障害に遭遇した次のエンジニアは、ゼロから再デバッグする代わりに、数秒で修正方法を見つけられます。

Infrastructure as Codeの変更をレビューする

TerraformのプランやKubernetesマニフェスト、CloudFormationテンプレートをプルリクエストのコメントでレビューするのは難しく、レビュアーはリソースグラフ全体を頭の中で保持しなければなりません。短い動画による解説があれば、変更の影響範囲が一目で明らかになります。

効果的なIaCレビュー動画の作り方:

1. 何かを説明する前に、まずplanやdiffの出力全体を示す
2. 作成・変更・削除される各リソースを一つずつ確認していく
3. リソースの再作成(リプレイス)をトリガーする変更があれば指摘する(多くの場合、最もリスクの高い変更である)
4. モジュールのバージョンを固定した理由など、自明ではない判断の背景を説明する
5. apply後に必要な手動作業(シークレットのローテーション、DNSの伝播、キャッシュのウォームアップなど)があれば伝える

本番のネットワーク構成やIAMポリシーに関わる変更では、diffの読み違いが大きな影響を及ぼしかねないため、この方法は特に有効です。

ミーティングなしでオンコールを引き継ぐ

書面によるオンコール引き継ぎ資料はすぐに古くなり、ライブでの引き継ぎ通話はタイムゾーンをまたぐとスケールしません。5分程度の録画がちょうどよい落としどころになることが多いです。

引き継ぎ録画に含めるべき内容:

• 未解決のインシデントとその現在の状況
• 発報されたがフォールスポジティブだったアラート(次のエンジニアが再調査しなくて済むように)
• 注視しておくべきダッシュボードと、それらの「正常」な状態がどう見えるか
• 次のシフト中に予定されているデプロイや変更
• 無視しても問題ない、不安定な既知のチェックやノイズの多いアラート

シフトの終わりにこれを録画し、チームの引き継ぎチャンネルにリンクを共有しましょう。次のエンジニアはコーヒーを淹れる時間で視聴できます。

ダッシュボードとターミナル出力を見やすく記録する

オブザーバビリティツールとターミナル出力は、それぞれ動画にする上で異なる可読性の課題を抱えています。

• ダッシュボード: 視聴者が混雑したレイアウトの中から自分で該当のグラフやパネルを探す必要がないよう、ズームエフェクトを使って議論しているグラフやパネルを強調する
• ターミナル: フォントサイズを16pt以上に大きくし、高コントラストのテーマを使うことで、通常の再生速度でもコマンド出力を読みやすくする
• 複数画面: 一方のモニターでメトリクスダッシュボードを、もう一方でターミナルを操作するような調査の場合は、デスクトップ全体を録画するのではなく、ウィンドウキャプチャを使ってきれいに切り替える
• 時間のかかるコマンド: kubectl rollout statusの待機や長時間のterraform applyなど、何も起きていない時間は編集時に早送りまたはカットして、録画の焦点がぼやけないようにする

共有前に機密データをマスキングする

インフラ関連の録画には機密情報が含まれることがよくあります。直属のチーム以外に共有する前に、以下を確認してください。

• 録画を外部に共有する場合、内部のホスト名、IPレンジ、アカウントIDにはぼかしやトリミングを施す
• 認証情報、トークン、接続文字列を映したままにしない——秘密情報を入力する前に録画を一時停止する
• ダッシュボードの録画に、ログやトレースに含まれる顧客データが映り込んでいないか確認する
• 書面のインシデントレポートと同様に、組織のデータ分類ポリシーを録画にも適用する

ポストモーテムとRunbookのライブラリを構築する

単発のインシデント録画は一度だけ役に立ちます。しかし、それらを検索可能なライブラリとして整備すれば、SREやプラットフォームチーム全体の力を何倍にも高めることができます。

録画の整理方法:

• サービスまたはシステム別(payments-api、プライマリデータベース、ingressコントローラーなど)
• インシデントの重大度別にして、重大な調査をすぐに見つけられるようにする
• 根本原因のカテゴリ別(デプロイ関連、キャパシティ、依存関係の障害、設定ドリフトなど)

各録画をポストモーテムのドキュメントとRunbookのインデックスからリンクしておけば、新しいインシデントを調査するエンジニアが、過去に似たようなことが起きていないかをすぐに確認できます。

まとめ

DevOpsの知見は失われやすく、再構築するにはコストがかかります。画面録画は、インシデント対応やパイプラインの修正、インフラの変更の裏にある思考プロセスを、それが起きているまさにその瞬間——最も低コストで記録でき、次にそれを必要とする人にとって最も価値がある瞬間——に捉えます。次のインシデントから始めてみましょう。答えがわかる前に、録画ボタンを押すのです。

Happy recording!