進行をストップした深夜メンテナンスとこれから

こんにちは。はっさん (@hassasa3) です。

今回はとある日に深夜メンテナンスを行ったものの、途中で進行をストップした話を書きます。このような決断に至るまでに学びが多くあったので、一つの経験談として読者に共有します。

前提

今回はデータベースの再作成を伴うアップデートをする予定でした。修正は Terraform を経由して行います。ダウンタイムが発生するため、メンテナンス画面に切り替えての作業になります。

これまでのメンテナンス作業は AWS に詳しい方にお願いしており、他の人が担当するのは初めての試みでした。他の人が担当するため、詳しい方には見守り係として参加いただく予定でしたが、体調を崩されて参加が難しくなりました。この時点で若干雲行きが怪しいものの、当日は予定通りに決行することになります。

当日の流れ

あらかじめ想定される手順書を共有しました。

ざっと書くと以下になります。

1. Web/アプリ共にメンテナンスモードに切り替える。(CloudFront で切り替えています)
2. DB のスナップショットを取得する
3. 監視系の通知を停止
4. アップデートの修正が入ったブランチを本番環境にマージする
5. Terraform の実行ログを確認しつつ、進捗を見守る
6. 修正が反映されているか確認
7. 監視の通知を元に戻す
8. メンテナンスモードを外す
9. 一通りの動作確認する
10. 問題なければ解散

誰がどの作業を担当するかを明記し、各作業者には事前に準備してもらいました。そして、手順に沿って着手前と完了後に報告しつつ進めましょうということを共有し、作業を開始しました。

想定外だったこと

・terraform apply が一度コケた

terraform apply 時に以下のエラーが発生しました。どうやら plan が失敗したようです。いつもは失敗しないのに！

stat .terraform/terraform_production.tfplan: no such file or directory

plan の結果を見ると以下のようなエラーが発生していました。

Get https://cloudfront.amazonaws.com/xxxx-xx-xx/distribution/XXXXXX: read tcp xxx.xxx.xx.x:xxxx->xx.xxx.xx.xx:xxx: read: connection reset by peer​

結果的に retry で解決しました。たまに CloudFront への接続に失敗することがあるようです。発生頻度が少ないエラーがこういう時に出るのは何の因果でしょうか。

・terraform apply でメンテモードが外れてしまう

再度、当日の流れを見てください。terraform apply する前に手動でメンテナンスモードに切り替えています。なので、terraform plan でメンテ画面への切り替えの差分が出てしまいました。なんてこった！このまま apply すると DB の再作成と共にメンテモードが外れてしまいます。この差分に気付けたことは、今回最大の幸運でした。

・ 手動でコンソールから修正をすることに

上記の理由から一旦は手動でデータベースへ修正をかけて、terraform の方は後日修正することにしました。しかし、やりたかったアップデートは手順が多く、このまま続けて問題が発生した時に正常にロールバックできるか不安がありました。手動で修正する際の想定はしていなかったので、継続する場合は調べつつになります。

この時点で、一旦チームメンバーでオンライン通話することに。状況を整理し、修正の優先度とリスクを天秤にかけ、作業を中止する決断をしました。

主な理由をまとめると、以下の三つです。

・想定外のことが多く発生していた。
・メンテナンス時刻を超えそうであった。
・問題が起こった場合のリスクが大きいと判断した。

やって良かったこと

作業は中止になりましたが、やって良かったこともあります。

・手順をドキュメント化して関係者に展開していたこと

作業をドキュメント化していたので、大体の流れについてチームが把握した上で行動することができました。

・作業の開始前、開始後は報告をし、コミュニケーションを取っていたこと

メンテナンス画面へ切り替える前、切り替えた後、スナップショットの取得前、取得後など、報告しつつ作業を進めました。誰が何をどこまでやっているのか共有しつつスムーズに進めることができました。

・予めの復旧プランを考えていたこと

今回幸いにも使うことはありませんでしたが、予め復旧のプランをいくつか考えていました。データの欠損があった場合は、スナップショットから復旧。アプリケーションから DB に接続できない場合は、エラーの内容を見て問題を切り分け、対応する。最悪は修正を revert することも考えていました。問題が発生したらかなり慌てるので、このような準備は冷静な判断をするための良い材料になります。

これから先どうするか

・手順書のレビューをする

詳しい方に手順書のレビューを依頼しましょう。チーム内ではしていたのですが、冒頭の詳しい方に意見は聞けずだったので、予め聞いておけば今回の問題にも気付けたかもしれません。また、今回のデータベースへの対応は手動ではなく、 terraform apply 時に特定のリソースだけ反映する方法もあったので、想定外の事が発生した場合の対応について多角的に話し合いができたら良かったです。

・継続か撤退かのジャッジ時間を予め決める

今回は恐らく手順通りにやったら上手くいくけど、リスクがある。といった状況で、雲行きが怪しくなってから継続するか撤退するか悩みました。チームとしてのゴールが宙に浮いてしまうので、継続か撤退かのジャッジ時間を設けて、ジャッジ時間を超えたら撤退する。という判断をできるようにしたいです。

・深夜メンテの作業ログを毎回ドキュメント化する

これは今回やった方が良いと強く思ったことです。CAMPFIRE では過去に幾度かメンテナンスをしたことがあります。過去に起こった問題に対して、どう解消したか、次回ならどうするかといったノウハウがない状態で作業に当たったのが問題の一つでもあります。今回の CloudFront でメンテモードにした差分が terraform apply で消えてしまうなどは過去にもあったはずで、防げた問題だったと思います。

まとめ

今回の問題を一般化すると、属人化している作業は、別の人がやった時に完遂することが難しいという点です。そのため、日頃からノウハウをドキュメント化しておく事がスムーズに物事を進める上で重要であると再認識しました。

CAMPFIRE では何かインシデントが発生した際にポストモーテムを書く文化があります。メンテナンス作業においても、作業ログをドキュメントに残しておき、将来同じ問題を繰り返さないことが大切です。