非開発者のための IT 常識 #4 バグ、ホットフィックス、ロールバック — 開発者が障害に対応する方法
前の記事で、開発者が作ったコードをサーバーに載せてユーザーに公開する仕事をデプロイと呼ぶ、とお話ししました。そして最後に、一つの質問を残しました。デプロイしたコードに問題があったらどうなるのでしょうか。間違った変更が本番環境に出ていった瞬間、ユーザーはすぐに影響を受けます。決済が止まったり、画面が崩れたり、アプリがまったく開かなくなったりすることもあります。
こうした状況をよく障害と呼びます。そして障害が起きると、開発チームのチャットに聞き慣れた言葉が登場します。「障害が起きました」「ホットフィックスを出します」「とりあえずロールバックしました」。今回の記事では、バグ、ホットフィックス、ロールバックという三つの単語を通して、開発チームが問題にどう対応するのかを見ていきます。
今回のシリーズは 非開発者のための IT 常識 の全 5 編で構成されます。
- #1 ウェブサイトは何でできているのか — フロントエンド・バックエンド・データベース
- #2 API とは何か — サービス同士が会話する約束
- #3 サーバー、クラウド、そしてデプロイ
- #4 バグ、ホットフィックス、ロールバック — 開発者が障害に対応する方法 ← この記事
- #5 Git とバージョン管理 — 複数人で一つのコードを直す方法
バグは意図と違う動きをすることです #
バグとは、プログラムが作った人の意図と違う動きをすることを言います。1,000 ウォンを決済したのに 1,100 ウォンが引き落とされたり、確かに押したのにボタンが反応しなかったり、リストがおかしな順番で出てきたりするのが、すべてバグです。コード一行の小さなミスが、ユーザーの画面では大きな問題に見えることもあります。
バグという言葉が、どういうわけで虫という意味を持つようになったのかは、それ自体が面白い話です。気になる方は、「バグ」という言葉はどこから来たのか — 最初のコンピュータバグの話 の記事を別に読んでみることをおすすめします。
大切なのは、バグといってもみな同じバグではない、ということです。文字の色が少しずれた程度のささいなバグもあれば、決済がまったくできなかったり、個人情報が誤って漏れたりする深刻なバグもあります。そこで開発チームは、バグを見つけるとまず重要度を見極めます。今すぐサービスを止めるほど急ぎなのか、次の定期デプロイのときにゆっくり直してよいのかによって、対応はまったく変わります。
ホットフィックスは急場をしのぐ緊急修正です #
ホットフィックスは、文字どおり熱い状況を冷ます緊急修正です。ふつう新しい機能は、十分に試して検討したうえで、決められたスケジュールでデプロイします。しかし、決済が止まるような、今まさにユーザーが被害を受けている問題なら、そのスケジュールを待ってはいられません。
このとき開発チームは、問題になった部分だけを狭く直して、いつもより速くデプロイします。こうして正規のスケジュールを飛ばし、緊急で出す修正がホットフィックスです。「ホットフィックスを出します」という言葉は、今の急ぎの問題を食い止めるために、緊急修正をデプロイしているという意味です。
ただし、ホットフィックスもタダではありません。急いで直すと、十分に試せないまま出てしまうことがあり、そのせいでまた別の問題を引き起こすこともあります。だからこそホットフィックスは、速くしつつもできるだけ狭い範囲で、どうしても必要な部分だけに手をつけるのが原則です。
ロールバックは以前の正常なバージョンに戻すことです #
ホットフィックスが前に進んで直す方法なら、ロールバックは後ろに戻す方法です。たった今デプロイした新しいバージョンが問題を起こしたなら、原因をゆっくり探す前に、まず直前のちゃんと動いていたバージョンに戻すことができます。これがロールバックです。
ロールバックの利点は速さです。新しいバージョンの何が間違っていたのかを分析するには時間がかかりますが、問題が起きる前のバージョンに戻すことは、ずっと速いです。ユーザーが受けている被害を先に止めておき、原因はその後で落ち着いて探すのです。「とりあえずロールバックしました」という言葉は、新しいデプロイを取り下げて、直前の安定した状態にサービスを戻したという意味です。
ここで一つ、疑問が浮かびます。以前のバージョンに戻すといいますが、その以前のバージョンは、いったいどこに保管されているのでしょうか。この話は、次の記事で扱う Git とバージョン管理につながります。
障害対応はおおよそこんな順序で進みます #
障害が起きたとき、開発チームはたいてい次の順序で動きます。
- 検知: モニタリングツールが異常を知らせたり、ユーザーの報告で問題に気づいたりします。
- 応急処置: 原因を深く掘る前に、ロールバックやホットフィックスで、ユーザーの被害をまず止めます。
- 原因分析: 急場をしのいだあとで、何がなぜ間違ったのかを落ち着いて探します。
- 再発防止: 同じ問題が二度と起きないように、点検の手順やテストを補強します。
最後の段階で、開発チームはしばしば振り返り(ポストモーテム)を残します。誰のせいかを問うよりも、何が問題を可能にしたのか、どう防ぐのかを整理する過程です。よいチームほど、障害を非難ではなく学びの機会として扱います。
なぜ非開発者が知ると仕事が楽になるのか #
障害対応の流れを知ると、問題が起きた瞬間に、より落ち着いて正確に動けます。
- 状況を正確に読めます。 「今ロールバックして、原因を見ているところです」という言葉を聞けば、ユーザーの被害はとりあえず止まり、分析が進行中だという意味として理解できます。
- バグをうまく報告できます。 何がどう間違ったのかとあわせて、決済のような急ぎの問題なのか、表示の不具合のようなささいな問題なのか、重要度も一緒に伝えれば、対応の優先順位が速まります。
- 「なぜ今すぐ直せないのですか」の答えを理解できます。 ホットフィックスも間違って出るとより大きな問題を招くため、急ぎの中でも最低限の確認は必要です。とにかく速くではなく、安全に速くが目標です。
まとめ #
この記事では、障害状況の三つの単語を見てきました。
- バグ は、プログラムが意図と違う動きをすることであり、重要度によって対応が変わります。
- ホットフィックス は、急ぎの問題を食い止めるために、正規のスケジュールを飛ばして狭く直して出す緊急修正です。
- ロールバック は、新しいデプロイが問題を起こしたときに、直前の正常なバージョンへ素早く戻す応急処置です。
ロールバックができるということは、つまり以前のバージョンがどこかにきちんと積み上げて保管されているという意味です。複数の開発者が同じコードを直しながらも、バージョンを失わずに管理する方法 — 次の記事では最後のテーマである Git とバージョン管理 が何なのかを見ていきます。