ふたりで考える、仕事の話AI活用 / 切り戻しの準備
「戻せます」を、戻してから確かめる。
バックアップがあるから大丈夫。その一言で更新を始めてよいのでしょうか。こはるとりんが、PHPの修正準備から、切り戻しの試験と公開を再開する判断を考えます。
バックアップはある。戻したことは？
こはる更新に失敗しても、バックアップがあるから戻せます。そう聞くと安心しますが、実際に戻したことがあるかは、あまり聞いていませんでした。
りん保存できたことと、戻して動いたことは別ですね。PHPの脆弱性対応でも、修正版の試験だけでなく、前の構成へ戻す試験まで組み込みました。
こはる新しいほうを試す前に、戻し方もつくっておくんですね。
りんはい。今回の個別対応の手順では、古い実行ファイルと設定を残し、新しいものを別の場所に置きます。切り替える場所を絞って、戻す対象をはっきりさせています。
こはるでも、前のものには脆弱性が残っているんですよね。戻せたら、そのまま営業再開とはいかなさそうです。
りんそこが大事です。元の構成に戻したあとも、外部から危険な処理へ届かない状態は維持します。動作を戻す判断と、公開を再開する判断を分けます。
何を戻して、何を戻さないか。
こはる「前の状態に戻す」なら、データも全部、更新前に戻すのでしょうか。
りん今回の手順では、PHPの切り替えに失敗したからといって、データベースや利用中のセッションを一緒に巻き戻しません。新しく受けた仕事まで消してしまう可能性があるからです。
こはるサイトは直ったけれど、受け付けた内容がなくなった。それでは仕事として戻っていませんね。
りんだから、戻すファイル、戻す設定、維持するデータを先に分けます。変更した箇所だけを戻せるように、作業前の状態も記録します。
切り戻しで、一緒に戻してはいけないものがある
- 実行ファイルと設定
今回変えた箇所を確認し、以前の構成へ戻す。
- 業務データ
更新前へ一括で戻さず、別の判断として扱う。
- 外部からのアクセス制限
未修正の構成へ戻しても、保護は外さない。
- 公開を再開する判断
技術確認と業務確認を終え、改めて決める。
こはるバックアップを取る範囲も、同じように考える必要がありそうです。
りんはい。例えばAWSのサーバーイメージを保存しても、別サービスにあるデータベースまで含まれるわけではありません。どこまで戻せる保存なのか、分けて確かめます。
AIに「バックアップを取って」で終わらせない。
こはるAWS CLIでAIに頼むと、バックアップの確認も進めてもらえるんですね。
りん作成を依頼したあと、完成したか確認するところまでつなげられます。作成の受付番号が返ったことと、使える状態になったことは違いますから。
こはる処理中の表示なのに、次の更新へ進んでしまうのは避けたいです。
りんその条件を手順に入れます。対象が一致している、バックアップが完成している、必要な試験を通っている。そろわなければ進まないようにします。
こはるコピーを取っただけで「復旧試験も済み」と報告されないことも大事ですね。
りんええ。切り替えを戻す試験と、保存したイメージから環境をつくり直す試験も別です。どこまで試したかを、結果の名前まで分けて残します。
戻す練習があるから、変更を進められる。
こはるテストを増やすと遅くなりそうですが、失敗してから相談を始めるより、早く動けそうです。
りん問題が出たときに、何を見て続行か切り戻しか決めるのか。その条件が先にあれば、AIにも確認を任せやすくなります。
こはる「動かなかったら適当に戻して」ではなく、「ここが違ったら止めて、この範囲を戻して」と頼むんですね。
りんはい。そして、戻したあとにも実際に動いているものと設定を確認します。コマンドが成功しただけでは、想定どおり動いているとは限らないので。
こはる私が業務確認をする時間も、最初から予定に入れてほしいです。技術の人だけが終わったつもりにならないように。
りんそこまでを一つの更新作業にしましょう。AIに任せるほど、試験結果と担当者の判断がつながっていることが重要になりますね。
