本番作業のダブルチェックで確認する項目|接続先・手順・切り戻し

ダブルチェッカーは「隣で見ている人」ではありません。接続先、コマンド、切り戻し、出力。止めるべき点を項目ごとに整理します。

作業者とチェッカーの二重確認。バックアップと切り戻しを作業開始前に確認
作業者とチェッカーの二重確認。バックアップと切り戻しを作業開始前に確認

本番環境での作業を 2 人で行い、1 人が実行し、もう 1 人が確認する。この「ダブルチェック」は多くの現場で使われていますが、確認する側が何を見ればよいかは、教わらないと分かりにくいものです。画面を一緒に眺めているだけでは、作業者と同じ思い込みをしたまま Enter を見送ってしまいます。ベテランのチェッカーは、見る項目と止める条件を決めて臨みます。この記事では、その項目を作業の流れに沿って整理します。

接続先が本番か検証かを最初に確かめる

最も重大な事故の 1 つが「検証環境のつもりで本番に実行した」「本番に入れるつもりで検証環境に入れて、本番は直っていなかった」という接続先の取り違えです。ターミナルのタブやウィンドウを複数開いていると、どれが本番かは見た目では区別しにくくなります。コマンドの中身がどれだけ正しくても、実行する場所が違えば結果は誤りです。

hostnamewhoamipwdpsql -c 'SELECT current_database(), inet_server_addr();'mysql -e 'SELECT DATABASE(), @@hostname;'
接続先を画面に出してから作業を始める

チェッカーは、プロンプトや上記のような出力に表示されたホスト名・データベース名を、手順書の対象と照らし合わせます。「db-stg-01」と「db-prd-01」のように 1 文字から数文字しか違わない名前も多いため、一部ではなく全体を読みます。作業者に「今どこに入っていますか」と聞き、答えを画面の表示で確かめるのが確実です。

手順書と実際のコマンドを 1 文字ずつ突き合わせる

作業者は手順書からコマンドをコピーするか、手で打ちます。どちらの場合も、手順書と実際に入力された内容がずれることがあります。コピー時に末尾が欠ける、全角スペースが混ざる、ID の桁を打ち間違える、前回の作業のコマンドが履歴から呼び出されている、などです。チェッカーは手順書を見ながら、入力されたコマンドを左から順に読みます。

  • ホスト名、パス、テーブル名、ID などの固有の値が手順書と一致しているか。
  • オプションの有無と向き(-n の付け忘れ、--dry-run の外し忘れ、> と >> の取り違え)。
  • 引用符の閉じ忘れや、変数が展開される場所かどうか。
  • 手順書の順番どおりか。前の手順を飛ばしていないか。

手順書そのものが誤っていることもあります。突き合わせ中に「手順書のパスが実際の構成と違う」と気づいたら、その場で手順書を読み替えて進めるのではなく、作業を止めて手順書の作成者や責任者に確認します。手順書に無い操作を「ついでに」行うのも同じ理由で避けます。軽微に見える変更でも、事前のレビューを経ていない操作は、影響を誰も見積もっていないからです。

バックアップと切り戻しを始める前に確認する

切り戻し(ロールバック)とは、作業前の状態に戻すことです。本番作業は、失敗したときにどう戻すかが決まって初めて始められます。チェッカーは作業開始前に、次の 3 点を確認します。バックアップを取る手順が、変更を加える手順より前にあるか。バックアップが実際に取れたこと(ファイルの存在やサイズ、件数)を確認する手順があるか。戻す手順が具体的なコマンドで書かれているか。

バックアップの手順が変更の後ろにある手順書

「1. カラムを削除する 2. テーブルをバックアップする」のように順番が逆になっている手順書は、上から順に実行すると取り返しがつきません。手順の中身だけでなく並び順も確認対象です。

実行前に読み上げ、チェッカーの合図で Enter を押す

危険度の高いコマンドは、Enter を押す前に作業者が声に出して読み上げ、チェッカーが手順書と照合してから「どうぞ」と合図する方法がよく使われます。読み上げると、目で追っているだけでは見落とす空白や記号に気づきやすくなります。また、作業者が一人で判断して先に進むことを防げます。リモート作業でも、通話をつないで同じ流れで行えます。

  1. 作業者が手順番号と、これから実行するコマンドを読み上げる。
  2. チェッカーが手順書と画面の入力を照合する。
  3. チェッカーが期待する結果(出力、件数、所要時間)を口に出して共有する。
  4. チェッカーの合図の後に作業者が Enter を押す。

想定外の出力が出たら止める

コマンドを実行した後は、出力が手順書の想定と一致するかを確認します。警告が出た、件数が想定と違う、想定より時間がかかっている、表示されるはずのファイルが無い。こうしたときに「たぶん問題ない」と判断して次に進むと、後続の手順が誤った前提の上で実行され、影響が大きくなります。原因が分かるまで止め、必要なら切り戻すのが基本です。

確認項目見る場所止める例
接続先プロンプト、hostname、DB 名手順書は stg なのに prd に接続している
コマンド手順書と入力の突き合わせID の桁が違う、オプションが欠けている
切り戻し手順書のバックアップ・戻し手順バックアップの手順が無い、変更の後ろにある
出力件数、終了コード、警告更新件数が想定の 3 件ではなく 3000 件
範囲手順書に無い操作の有無ついでの設定変更、別のサーバーでの実行

止めるのは失敗ではありません。止めずに進んで影響が広がるほうが、作業者にも利用者にも負担が大きくなります。新人のチェッカーは先輩に遠慮して止めにくいものですが、止める条件をあらかじめ決めておくと、相手の経験に左右されずに判断できます。経験の長い作業者でも、思い込みや疲れによる誤りは起きます。

記録を残し、完了を確認する

作業中は、実行したコマンド、時刻、出力の要点を記録します。script コマンドでターミナルの出力をファイルに残す、作業用のチャットに貼る、チケットに書くといった方法があります。記録は、問題が起きたときに「何をいつ実行したか」をたどる手がかりになり、次回の手順書の改善にも使えます。最後に、手順書に書かれた完了確認(サービスの応答、件数、画面の表示)を行い、両者で完了を確認してから作業を閉じます。

チェッカーが陥りやすい失敗

ダブルチェックが形だけになる原因は、チェッカーの側にもあります。よくあるのは、作業者の画面を追いかけるだけで、手順書を自分では読んでいない状態です。この状態では、作業者が手順を飛ばしても、チェッカーは画面の流れに違和感を持てません。チェッカーは手順書を手元に開き、「次はこの手順のはず」と先回りして待つ位置に立ちます。

  • 作業者の説明を聞いて納得し、画面の表示で確かめていない。
  • 時間が押しているため、確認を「後でまとめて」に回してしまう。
  • 前回同じ作業が成功したので、今回も同じだと思い込む。
  • 自分が誤りに気づいても、相手が先輩なので指摘を遠慮する。

どれも、2 人で作業しているのに実質 1 人で判断している状態です。チェッカーの役割は、作業者と同じ結論に同意することではなく、作業者とは独立に確認して、同じ結論になるかを確かめることです。

ダブルチェックのチェックリスト

  • 作業開始前:手順書を通読し、バックアップと切り戻し手順があることを確認した。
  • 接続直後:ホスト名、ユーザー、データベース名が手順書の対象と一致している。
  • 各コマンドの前:手順書と入力を 1 文字ずつ突き合わせ、読み上げを聞いた。
  • 各コマンドの後:出力、件数、終了コードが想定どおりで、警告が出ていない。
  • 作業全体:手順書に無い操作をしていない。想定外のことが起きたら止めた。
  • 作業終了時:完了確認を行い、実行したコマンドと時刻を記録した。

ダブルチェックは、2 人目が同じものを見ることではなく、作業者とは違う視点で確認することに意味があります。下の問題では、実際の作業場面でチェッカーとしてどこで止めるかを試せます。

問題で確かめる

この記事の内容を、制限時間つきの問題で確かめられます。

参考

よくある質問

ダブルチェックでは何を確認すればいい?

接続先が手順書の対象と一致しているか、入力したコマンドが手順書と一致しているか、バックアップと切り戻し手順があるか、出力が想定どおりか、手順書に無い操作をしていないかを確認します。

ダブルチェッカーが止めるべきなのはどんなとき?

接続先や入力が手順書と違うとき、手順書自体に誤りや抜けがあるとき、出力や件数が想定と違うとき、手順書に無い操作をしようとしているときです。原因が分かるまで次の手順に進まないのが基本です。

先輩の作業をチェックするとき、止めてもいい?

止めてかまいません。経験の長い作業者でも思い込みや疲れによる誤りは起きます。止める条件を事前に決めておくと、相手の経験に左右されずに判断できます。

読み上げ確認にはどんな効果がある?

声に出して読むと、目で追うだけでは見落としやすい空白や記号、桁の違いに気づきやすくなります。チェッカーの合図を待つことで、作業者が一人で先に進むことも防げます。