2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

KLab EngineerAdvent Calendar 2024

Day 23

スマートフォンゲーム(を始めとするシステム)の障害対応について語る

Last updated at Posted at 2024-12-23

こんにちは
この記事はKLab Engineer Advent Calendar2024の記事です

来年1月に大学のサークル内で登壇する予定がありまして、するそこで話そうと思う内容を簡単に書いてみます。
(まだスライドなどは作っていないですが、、)

私の仕事内容について

スマートフォンゲームの開発、運営の仕事をしています(オンライン中心のゲームを作っています)
スマートフォンゲームが実際にPFストア(App Store, Google Play Store)上で公開されるなどの形でリリースされる前の開発の仕事もしていますが、リリース後の運営の仕事も経験しています。本記事では実際にリリースされた後の話を書きます。
(私がスマートフォンゲームの開発、運営の仕事をしているため、その中での話として書いていますが、書かれている内容としてはシステム開発で一般的にどこでも言えるような話だと思います。)

リリース後の話

実際にスマートフォンゲームがリリースされると、多くのユーザーさんがプレイされるわけですから、ユーザーさんの意見がネット上に大量に溢れることになります。そうすると、ゲームを運営しているスタッフ内では気づかなかった不具合が見つかることもあります。(もちろん、スタッフ内でゲームをプレイしている際や、リリース中のデータを見た際に不具合が見つかることもあります。)
そういった不具合に対し、スタッフ内ではどのように対応しているか、という話を書きます。

障害とは?

まず、障害とは何かの話をします。障害自体は「あることをするのに、さまたげとなるものや状況」を意味する一般的な言葉っですが、それを具体化して、本記事では、
「実際にユーザーさんが遊んでいる環境(本番環境)でシステム(ゲーム)が正常に実行(プレイ)できない状態」を指すこととします。
例えば、以下のような事象が考えられます。

  • 誤表記
    • お知らせの内容が間違っていた
    • イベントのルール説明文が間違っていた
    • カードのスキル説明文が間違っていた
  • 意図しない動作
    • インゲーム(例えば、クエスト)の特定箇所に行くとクラッシュする
    • いわゆる「ガチャ」(カードの抽選)が回せない
    • 課金ができない

障害には重さに応じて、「ランク」をつけて管理することがあります(重大度を管理し、PJごとに障害数を管理することで、横断的に障害数を比較することができます)

  • ランクS
    • 多くのゲームプレイユーザーに影響を与える障害
    • (ゲームの)サービス全体の停止が必要
    • 課金が出来ない、もしくは課金機能に関する障害
    • 法令違反が疑われる障害
  • ランクA
    • 一部のゲームプレイユーザーに影響を与える障害
    • アイテムなどの補填が必要であるもの
  • ランクB
    • ユーザーにとって軽微な問題である障害

では、実際に障害になった際に、どのように対処すれば良いでしょうか。

障害発生時の対応

実際に障害になった際の手順としては以下があります。
a. 報告

  • 障害の報告は、ある日突然やってきます
  • 障害というのは、一定ゲームの新機能や新イベントが始まった際など、何かしらゲームに変化がおきた際に起きやすいという「傾向」はあるとはいえ、突然やってくることもあります (例えば、インフラの要因で突然サーバーダウンを起こすはず)
  • 障害は何が起きるかは予想つきません

b. 調査

  • 何が起きているのか、現象を把握し、影響範囲を調べていきます
    • 調査する上では「正確さ」と「早さ」が大事です
    • SNS上で特定のユーザーがAという現象が起きている、と報告していたとしても、別のユーザーがBという別の現象が起きていることもあり、正確に現象を把握することがこの後の対応の正確さを上げていくことが大事になります
    • 正確な調査を怠ると、二次災害(障害対応を行った際の対応でさらに障害が発生すること)につながっていく可能性も有り得ます

c. 対応の検討

  • 調査を元に、他メンバーとも相談の上、対応方針を決定していきます。(自分の判断、一人の判断で突っ走ってはいけません)
  • 重大な障害であり、かつ、現在もその不具合がユーザーが遊ぶことに起きてしまう場合、被害を拡大させないためにゲームの一部もしくは全体をメンテナンスにいれることも考えられます

d. リリース

  • 開発環境(テスト環境)で修正を行い、その修正が正しく問題ないかを確認した後、実際に本番環境(ユーザーさんが遊んでいる環境)に展開します

e. ユーザー対応

  • 前の手順とも並行する部分もありますが、ユーザーコミュニケーションを大事になります
  • 障害が起きている状態はユーザーさんにとっては「運営大丈夫かな?」というように心配するタイミングでもあります。そのため、障害がすぐ直せない場合は、現状を説明するために「不具合内容の対応予定」についてお知らせで説明したりすることも考えられます。(逆に、すぐ直せる場合は直したと同時、もしくは少し後に「不具合を対応した内容のお知らせ」を事後で出すこともある)

f. 振り返り

  • 直してすぐ障害対応は終わり。というわけではなく、なぜ障害が起きたのか、を振り返っておくことも大事です。経緯、原因や、自分たちで考えられる対策を提示し、その後、対策については二度と同様の障害が起きないように対策していくことが大事です。

大事なこと

障害対応で大事なことは、 障害が起きた際は、一旦は起きてしまったことは仕方ない、と考え、 自分の判断で勝手に対応を進めず、チームみんなで対応をしていく ことだと思います。
自分たちの判断で勝手に進めてしまうと、チームとしての一体感がなくなるのもありますが、焦っている状態で対応することでよりミスが誘因されやすくなりますし、他の人に確認してもらいながら対応することで、対応の精度を上げ、二次災害(障害対応を行った際の対応でさらに障害が発生すること)を防ぐことにつながります。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?