本番作業をするときの3Step「準備」「確認」「切り戻し」

こんにちは :)
エイチームライフデザインのアドベントカレンダー2日目はエンジニアをしている @yothio が書きます

月日が経つにつれてバックエンド→フロントエンド→インフラと自分ができる領域を広げていく中で「大事だよな〜」と思った「本番作業時に行っている３STEP」について話をします

結論としては 「準備」「確認」「切り戻し」の3STEPを本番作業を行う前に用意しておくことです

ざっくりどういう事を行うのか

本番作業を行うとき「どんな作業を行って」「どうなったら問題なくて」「どんな方法で切り戻すのか」をあらかじめ策定しておきます

それらの内容を「準備」「確認」「切り戻し」という言葉でここでは扱っています

では実際にそれらはどんな事を行うのかもう少し詳しく見ていきましょう

準備

「準備」としてやるべきことは以下の通りです

本番作業の内容を準備する
「確認」で行う内容を準備する
「切り戻し」で行う内容を準備する

「準備」ではどんな作業を行うかを確定させます
また他の「確認」「切り戻し」の内容もあらかじめ記載しておきます

確認

「確認」としてやるべきことは以下のとおりです

何を確認して正常・異常となるかを判断する

切り戻し

「切り戻し」としてやるべきことは以下のとおりです

今回の変更はどうやって元に戻すのか
元に戻ったことの確認はどのように行うのか

なぜ行うのか

では次になんでやるのかについて考えてみます
すぐに思い浮かぶものとして次のことが挙がります

「誤った作業を行う」頻度を下げる
「行う作業を準備し、コピペ・手順書通りに実行するため」作業負荷が下がる
「今回の作業起因で発生した問題かどうかに気づけるため」
「作業手順をあきらかにするため、未知を既知にするため」システムへの理解が深まる

またこれらを手順書として作成してレビューを相互でし合うことにより個人の暗黙知を共有できます

具体例はどんなものか

では実際にどんなふうに行ったのか具体例を提示します
自分が所属するチームのサービスでは「CloudflareのCDNの恩恵を受けたいためDNSを移管する作業」を行いましたのでそれを例として上げます

その時の概要としては

NSレコードについては社内ネットワークを管理する部署に切り替えてもらうため
そのため切り替え当日に自分たちがオペレーションすることはあまりない
かわりに事前準備としてCloudflareDNSにあらかじめレコードを登録しておくことが必要

といった感じでした、オペレーション自体は必要ないですが切り替わったことの確認などは自分たちで行う必要があります
具体的な「準備」「確認」「切り戻し」を書いていきます

具体例の「準備」「確認」「切り戻し」

大きくは下記のことを準備します

既存のDNSレコード確認と移行対象の選定
ネットワーク管理部署に変更レコードの共有と、切り戻し用のレコードの確認
DNS確認コマンド
当日確認する項目の洗い出し
問題ない判断・切り戻す判断の予想

またDNSはアクセスする全ユーザーに影響があるので当日までの確認として

PowerDNSを利用して登録したレコードで問題なく動作するかあらかじめ確認
digやtcpdumpなどを利用して確認する手順を用意し、そのコマンドで何が確認できるか見ておく
dig実行時に複数のネームサーバーから同一の結果が返ってくることの確認

実際にレビューを出したIssue書いてあったこととしては次のようなことでした

実際にIssueにまとめていた内容(簡易版)

変更前表示確認
- 外形監視を確認しておく(newrelicの外形監視のグラフURL)
- OpenSearchを開いて1分更新にしておく
- 対象のページが表示される事を確認
  - yothio.com (※ダミー用のURL)
  - www.yothio.com
- digを実行して古いDNSのNSレコードを通っている事を確認
```
$ sudo tcpdump -vvv dst port 53
$ watch -n 1 dig @8.8.8.8 yothio.com +trace
$ watch -n 1 dig @1.1.1.1 yothio.com +trace
$ dig yothio.com +trace
$ dig www.yothio.com +trace
```
- ネットワーク管理者に切り替えてもらう旨を伝える
変更後表示確認
- 外形監視が途絶えていないか確認
- OpenSearchの表示が極端に現象していないか確認
- 対象のページが表示される事を確認
  - yothio.com
  - www.yothio.com
- digを実行してCloudflareDNSのNSレコードを通っている事を確認
```
$ sudo tcpdump -vvv dst port 53
$ watch -n 1 dig @8.8.8.8 yothio.com +trace
$ watch -n 1 dig @1.1.1.1 yothio.com +trace
$ dig yothio.com +trace
$ dig www.yothio.com +trace
```
- 個人のスマートフォン・PCからアクセスしても問題なく表示される確認
切り戻し判断
- サイトが表示できない。と判断できたら即時切り戻し
- サイトは映るが外形監視が落ちる、OpenSearchが減少している場合は頻度に応じて切り戻しを行う

切り戻し後確認

サイトが問題なく映ること
- yothio.com

digを実行して古いDNSレコードを通っている事を確認

$ sudo tcpdump -vvv dst port 53
$ watch -n 1 dig @8.8.8.8 yothio.com +trace
$ watch -n 1 dig @1.1.1.1 yothio.com +trace
$ dig yothio.com +trace
$ dig www.yothio.com +trace

インフラ以外でも使える

例ではインフラのDNSを変更する例として上げましたがWebアプリケーションの更新のときにも「準備」「確認」「切り戻し」は行います
「Webアプリケーションに対して入力に応じて最適な商品を表示してくれるような診断コンテンツを実装した」とするなら下記の通り

準備
- 確認する人は誰か(機能を依頼した人と担当したエンジニアが主)
- 確認項目と切り戻し判断と方法を策定する
確認
- サイト全体が表示されるか
- 診断コンテンツを導入したページが表示されるか
- 診断コンテンツが要件と同じ動作が行えているか
- OpenSearchなどを見て4xx,5xx系が増えていないか
切り戻し
- 切り戻し判断は↑の確認が正常に行われない場合
- 切り戻し方法は
  - 急ぐ場合: 各種クラウドコンソールから(ECSやCloudRunの)過去のリビジョンへ戻す
  - 急がない場合: git管理しているソースをリバートしたものをデプロイして切り戻す

まとめ

いかがだったでしょうか、普段はコードを交えた記事を書くことが多く考え方みたいな記事は書かないため少し拙いですが参考になれば幸いです