この記事は NewsPicks Advent Calendar 2024 の12日目の記事です。
こんにちは。ソーシャル経済メディア「NewsPicks」エンジニアの桐畑です。
今回は「システム障害を素早く解決するための考え方・工夫について」というテーマでお伝えしたいと思います。
NewsPicksサービス状況・障害対応
NewsPicksも今年でサービス開始して11年を迎えました。
サービス開始から11年を経たコードやシステム構成は、その複雑性が一定以上高まっています。一方で、ここ数年にわたりデリバリーの仕組みが改善され、1日に何度も修正がデプロイされる状況となっています。
高頻度のデプロイを行う一方で、複雑性の高いシステムでは大小さまざまな障害が発生することがあります。
※もちろん、日々、複雑性の解消や、障害再発防止に向けた対応を継続的に実施しています。
※デプロイ回数改善、開発者体験向上については以下の記事を参考ください！
ちなみに、障害対応ではインシデントコマンダーを立てて、影響範囲の特定・障害状況の連携などチームで対応することが一番大切です。 今回のお話の前提としましては、障害の連絡を受け、インシデントコマンダーから1プロダクトエンジニアとして、速やかに原因特定・解決を依頼された状況を想定しております。
※弊社の障害対応・インシデントコマンダーについては以下の記事を参考ください！ tech.uzabase.com
障害の原因分類
NewsPicksプロダクトチームでは、障害発生後に原因や再発防止策のふりかえりを実施しています。振り返りで作成された数百回にも及ぶ積年のポストモーテムから障害原因を以下に大分類いたしました。
- 機能・不具合修正リリースに伴うコード / データ変更
- コンテンツ入稿・設定オペレーションに伴うデータ変更
- インフラ構成変更
- 潜在的な不具合の発現
- 外部システムの問題
実施頻度が多いということもあり、障害発生原因の大半は1もしくは2でした。
他方で、サービス変更をトリガーとしていない、4や5は発生すると原因特定や解決の難易度が高い傾向にありました。
障害の原因特定・解決までのステップ
普段の障害の原因特定・解決でやっていることを以下の3ステップで考えてみました。
1. 障害の状況確認・再現
障害連絡の内容を手元で確認・再現するかを確認します。あらゆる環境で起きる問題もあるのですが、大体の場合は再現する環境を揃える必要があります。
NewsPicksでは、例えば以下のような環境要因があります。
| 環境要因 | 項目1 | 項目2 | 項目3 |
|---|---|---|---|
| 利用端末 | モバイル端末 | タブレット端末 | PC |
| アカウント状況 | 未ログイン | 無料ユーザー | 有料購読ユーザー |
| ブラウザ | Chrome | Safari | Edge |
頻度は高くないですが、再現しない / 再現条件が不明の場合、障害解決への道のりが険しくなります。（この手の問題は、キャッシュや処理タイミングなどによるものが多い印象です。）
2. 原因特定
前項の障害の分類でありましたが、多くはアプリケーション修正か運用作業が起因していることが多いので、まずは直近の修正内容や運用作業の状況を確認します。
それでわからない場合は、障害連絡の内容やシステムログから問題の特定を試みます。最悪、何もわからない場合は探索的に原因を特定していきます。
例えば、「画面が表示されない」 という連絡が来ている場合、以下のようなステップで原因を探索していきます。
3. 解決方法の検討
原因がわかればあとは原因を取り除くだけです。障害は可及的速やかに解消したいです。
すぐさま対応できる暫定対応と、あるべき対応の恒久対応に分けて考えると、より良い解決方法が実施できるのではと思います。
本来ならコードの修正が必要だが、修正に時間がかかるので、すぐに実施できるデータ変更での暫定対応を検討など。
素早く原因特定・解決するための考え方・工夫
上記にステップは書かせていただきました。では、どうすれば各ステップを素早く実行し、解決にたどり着けるかを考えたいと思います。
障害はサービスにとって有事の事態です。1秒でも早く解決が求められる状況です。普段と比べて、正しく正確に実施するよりスピードが求められる状況です。
（もちろん、めちゃくちゃな対応でデータを破壊したり、取り返しが付かない事態はもっとも避けねばならない前提です。）
結論としては、「仮説を立てて検証する」という考え方で、アプローチすれば時間が早められるようになるのではと考えています。
- 障害連絡の内容（文章やキャプチャ画像の内容）
- 例外ログの出力状況
- 直近のアプリケーション変更状況
などからシステムで何が起きているのかの仮説を立てる。その仮説が合っているかを検証するために、ステップを実施するという考え方です。
例えば、「モバイルアプリ用のフィードAPIの直近の修正で変更で不具合が起きていそう」という仮説が立てれたとすると、
- 再現確認はモバイルアプリを確認
- 原因特定もフィードAPIから確認
ということができます。
「仮説を立てて検証する」 として、次は「如何に素早く精度の高い仮説がを立てれるか」 が重要になってきます。
この点は、
- 障害対応の経験
- ポストモーテムを読み込み
- 各機能のドメインに対する見識
といった経験と知識が必要となってくると考えます。
素早く解決するためには、経験と知識が必要ですという身も蓋もない結論になりつつはありますが...
常に仮でも良いので答えをもって考えていけると、解答に早く近づけると考えます。
おわりに
「仮説を立てて検証する」 という姿勢で日々の障害対応に取り組み、反復学習していければ、対応力が身につくようになると思います。
さらに、障害対応を通じて、未知の課題に対する心構えも鍛えられるはずです。
障害対応は困難を伴うことが多いですが、得られる経験と知見は、幅広く役立つ力になると信じております。
お読みいただきありがとうございました。
