調査中に手がすべる瞬間
一言でいうと
調査中に何かを変えると、それ以降に見るすべての値が、元の値なのか私たちが作った値なのかわからなくなります。どうしても変える必要があるなら、変える前の状態をまず固め、変え、確認し、元に戻します。
なぜ必要なのか
顧客企業の調査は、たいてい読み取り権限から始まります。ところが、半日もたつと、必ずこんな瞬間が来ます。「この設定値だけちょっと上げてみれば、すぐわかるはずなのに」。実際、そのとおりです。その値を上げれば、5分で答えが出ます。問題は、その5分後の世界です。
変えたあとには、3つのことが同時にぼやけます。1つ目に、いま見えている症状が元の症状なのか、私たちが作った症状なのかがわかりません。2つ目に、顧客がその間に見たログと指標が汚染されます。3つ目に、あとで「いつからこうなったのですか」と尋ねられたとき、私たち自身が答えの一部になってしまいます。
ここで、よくある誤解が1つあります。「小さな変更だから大丈夫」というものです。小さな変更ほど、元に戻すのを忘れます。そして、元に戻したと信じることと、元に戻したことが証明されていることは別です。
どう動くのか
順序は4つのステップです。
1 굳힌다 바꾸기 전 상태를 지문으로 기록한다 (파일 해시·크기·권한)
2 바꾼다 한 건만, 무엇을 왜 바꾸는지와 되돌리는 명령을 함께 적고
3 확인한다 바꾼 것이 의도한 효과를 냈는지 값으로 본다
4 되돌린다 되돌린 뒤 1번의 기록과 견주어 다르지 않음을 보인다
1つ目が最もよく抜けます。固めておかなければ、4つ目で証明するものがありません。「元どおりに戻しました」という言葉は検証できない文で、顧客はその言葉を信じることも信じないこともできません。一方、「元に戻したあとスナップショットと比較したところ、内容が違うファイルは0個です」は、確認できる文です。
固める記録には何を入れるべきでしょうか。ファイルの内容のフィンガープリント(sha256)とサイズと権限は必ず入れます。更新時刻も入れますが、比較するときは別に扱います。元に戻したファイルは、内容が同じでも更新時刻が違うからです。これは失敗ではなく、私たちが手を触れた痕跡です。痕跡を消そうとせず、レポートに書きます。
しかし、それより先に問うべきことがあります。本当に変えなければ答えが出ないのか。多くの場合、同じ質問に読み取り専用で答える道があります。設定ファイルを開いて値を読み、データベースを読み取り専用で開いて数え、ログを数え、すでにある照会ツールを実行してみます。この道を30分ほど探してから、変えると決めても遅くありません。
読み取り専用かどうかを自分でごまかさない方法は、使ったコマンドを記録することです。
固める範囲も決めなければなりません。サーバー全体をフィンガープリントで取ると時間がかかり、その間にもログが増えるので、次の比較が真っ赤になります。逆に、変えるファイル1つだけを取ると、その隣で連鎖して変わったものを見逃します。実務では、変える対象が属するディレクトリの1階層を取ります。設定ディレクトリごと固めておけば、エディターが作ったバックアップファイルや一時ファイルが残ったときも、そのまま表に出ます。ログのように増え続ける場所は、範囲に入れて比較時に別に扱うか、最初から範囲の外に置いて、その事実を書いておきます。
固めたファイル自体も、安全な場所に置きます。調査対象のディレクトリの中にスナップショットを作ると、そのファイルが次の比較で「新しくできたファイル」として検出され、さらに悪いことに、私たちが顧客のサーバーにファイルを1つ残したことになります。スナップショットと記録は私たちの作業ディレクトリに置き、引き渡すときに一緒に渡します。答えごとにどのコマンドで得たのかを書いておけば、その中にUPDATEやリダイレクトが混ざっていないかが目に見えます。書かなければ、「照会しかしていない」という記憶だけが残ります。
現場での姿
1つ目に、変えるのは一度に1つだけです。2つを同時に変えると、効果がどちらから来たのかわかりません。そして、元に戻すときも1つずつ戻して初めて、何が残ったのかがわかります。
2つ目に、元に戻すコマンドを、変える前に書きます。変えたあとに書こうとすると、元の値を記憶に頼ることになります。3だったのか30だったのかは、30分後には驚くほどぼやけます。
3つ目に、承認を文で残します。調査中の一時的な変更も、誰かの同意を得ます。「運用チームのチェ課長が13:40に口頭で承認」の1行で十分です。この行がなければ、あとでその変更は私たちがこっそり行ったことになります。
4つ目に、元に戻したことを証明するとき、更新時刻の違いは隠しません。内容が同じで時刻だけ違うなら、そのまま「内容は同一、更新時刻のみ変更」と書きます。時刻まで元に合わせてしまうと、そのときから、私たちが痕跡を消したことになります。
5つ目に、これは承認された変更作業とは別の話です。計画を立て、中止基準を決め、顧客の承認を得て反映する変更には、別の規律があります。ここで扱うのは、その前の段階、つまり調査中に手が滑る瞬間についての、最初の週の規律です。
実務で本当に大切なこと
- まず読み取り専用で答えられる道を探します。使ったコマンドを書いておけば、自分をごまかさずに済みます。
- 変える前に固めます。固めておかなければ、元に戻したことを証明できません。
- 一度に1つだけ変え、元に戻すコマンドを事前に書いておきます。
- 元に戻したことは、言葉ではなく比較した結果で出します。残った痕跡は消さずに書きます。
次のラボですること
(架空の)スウォンペイの運用サーバーを手にします。まず5つの質問に読み取り専用の手段だけで答え、使ったコマンドを一緒に残します。そのあと、ディレクトリの状態をフィンガープリントで固めるツールを作り、そのツールに比較機能を追加します。採点ツールは、ファイルの追加、削除、内容の変更、権限だけの変更、時刻だけの変更の場所を作って、作成したツールが5つを分けられるかを見ます。そして、どうしても変える必要がある設定1行を、承認と元に戻すコマンドとともに変更し、照会ツールで効果を確認し、実際に元に戻して、スナップショットと内容が違うファイルが0個であることを証明します。