M&Aクラウドで実践している不具合対応フローをご紹介します

f:id:tsukahara1991:20210709173755j:plain
不具合対応中

こんにちは、塚原(@AkitoTsukahara)です。

サービス開発を続けていると対策していても大なり小なり不具合が発生してしまいます。そのため、早期に不具合を発見して、少ない被害に抑えることが大切になります。(もちろん、不具合が発生しないことが一番!)

弊社では不具合を早期発見できるように2つの仕組みを用意しています。
1つは以前もご紹介したRollbarを利用したアラート検知する仕組みです。
Rollbarについて詳しく知りたい方は、こちらの記事をご覧ください。 tech.macloud.jp

もう1つは、非エンジニアでも不具合をSlackから報告できる仕組みです。今回はこちらの仕組みについて、ご紹介します。
弊社では非エンジニアでも不具合を報告できる「バグかもしれない報告」というSlackチャンネルを用意しています。ここでエンジニアは報告を受け取り、不具合を解消していきます。

不具合と言っても、サービスが停止してしまうような大規模障害もあれば、一部のユーザにのみ影響する不具合もあります。 緊急度に応じて対応方針が変わってくるのですが、その都度チーム間で対応方針を相談することでコミュニケーションコストが高くなり、障害対応の初動が遅れてしまう問題がありました。

そのため弊社では、不具合発生時の対応フローをまとめ、スムーズな対応ができるようにしています。

対応フロー

下の図は実際に弊社で共有されている対応フローになります。

f:id:tsukahara1991:20210712004022p:plain
不具合フロー

ポイントになるステップを補足させていただきます🙋‍♂️

「バグかもしれない報告」をSlackで受け取る

Slackのワークフロー機能を活用し、一定のフォーマットに沿って報告をしています。

f:id:tsukahara1991:20210711233414p:plain
バグかもしれない

ユーザ影響の調査を行う

不具合の影響度によって、早急に対応が必要なものかどうかをエンジニアが判断します。 影響度のポイントは「後戻りのできないユーザ影響なのかどうか?」
もう少し具体例を加えて説明させていただくと、

  1. サイト外に影響して取り返しのつかないもの
    ・ユーザへ重要な通知が届かない
    ・データベースに登録されるデータが欠損する etc

  2. ユーザ行動に影響する
    ・入力フォームの不具合で申し込みが進まない
    ・ログインできない etc

上記の2つが主な指標になります。 この判断が難しい場合は、他のエンジニアに相談するようにしています。

ユーザ影響高の場合

この場合は即日対応を行います。通常差し込みタスクが発生した場合はPMに対応すべきか確認するルールになっていますが、ユーザ影響高の場合は、エンジニア判断で不具合修正を進めて良いことになっています。エンジニア側で影響度を見極めて対応できることで、不具合発生時の初動を早めることが可能になっています。

まずはフローに沿って、早急にPMに不具合に関する情報共有を行い、報告を行ったエンジニアは取り掛かり中のタスクを一旦そのままにして不具合の対応に入ります。

ユーザ影響高ではない場合

この場合は対応タイミングをPMと確認することが必要になります。 弊社は2週間を1スプリントとして、毎週火曜と木曜をリリースタイミングにしています。 報告された不具合の程度によって、次のリリースまでに行うのか?現在のスプリント中に行うのか判断していきます。 ユーザ影響あるものは「2nd Priority」の方針に従って極力早いタイミングでの対応が奨励されています。

2nd Priorityについてはこちら。 tech.macloud.jp

報告者への対応完了報告

不具合が解消されたことを報告します。 同じ障害が起きない安心感を与えたり、似たような不具合が再発した時に再度報告してもらうことができます。

このような形で弊社では不具合の共有を行い、対応フローを整備しておくことで初動までのコミュニケーションコストを抑えて、スムーズな対応を可能にしています。このフローではコミュニケーションを減らすのではなく、不具合対応までの初動を早めることを目的としています。不具合発生時は常に報告・共有が重要なので単にコミュニケーションを減らせば良い訳でないので注意したいですね。

弊社では、一緒にサービス開発をしてくれる仲間を募集しています。 興味のある方はぜひご応募ください。

www.wantedly.com