hey Product Blog

こだわりを持ったお商売を支えるプラットフォーム「STORES」の開発チームによる技術ブログです。

STORES EC での障害振り返りの取り組み

はじめに

STORES EC で SRE のエンジニアをしている秋元と申します。

サービスを運営していく上で障害の発生は避けて通れないところかと思います。 障害が発生しないように努力することはもちろんですが、今後も同様のことが起こらないようにしっかりと振り返りを行い対策を実施することも非常に重要になってきます。

今回は、EC 開発チームでの障害振り返りの取り組みについてご紹介させていただきます。

障害振り返りの取り組み

EC の開発チームでは、障害の振り返りや対応策の実施の目的として以下を設定しています。

楽にサービスレベルの高い状態をキープできるようにすること

これは、サービスレベルが高い状態を、開発効率をなるべく落とすことなく保てるようにしたい、という意味合いが込められています。

不具合が発生しなければサービスレベルは低下しないし障害の対応などで開発効率が落ちることもないので、どうしたら不具合を減らせるかを議論し対応を考えたりしています。
さらに、障害をより早く発見できていれば同じ対応工数でもサービスレベルが高い状態を保つことができるので、どうしたらもっと早く不具合やサービスレベルの低下に気付けるようにできるか、といったことも議論しています。

では具体的にどういうことに気をつけて振り返りや対応策を考えているかを下記にまとめようと思います。

問題発見のシフトレフト

振り返りでは障害の根本原因と発見の経緯を確認しています。
問題の発見を根本原因が発生したタイミングに近づけることで、より楽に高いサービスレベルをキープすることができると考えています。 (これは QA でよく使われる「シフトレフト」の考え方を参考にしています。)

f:id:akmtr:20210909104347p:plain
問題の発見をシフトレフト

例えば、開発時の考慮漏れにより発生した不具合であれば、開発時のレビューや開発環境での動作確認で気づけていればサービスレベルが低下することもないし、障害の対応などで開発効率が落ちることもありません。 そのため、仕様を周知するようなドキュメントを整備したり、今後同様の不具合が発生しないように自動テストを整備したりしています。
また、リリースを行ってから時間が経ってから不具合が発見されたような場合だと、不具合の発生の防止だけでなく、なぜ不具合の発見が遅れたかを振り返り発見を早くするための対応を考えたりもしています。

開発効率とサービスレベルのバランスを考える

例えば、同じような障害を発生させないためにリリース前の QA 項目を増やす、といった対応策を立てる場合もあるかと思います。 QA 項目を増やすこと自体は悪いことではありませんが、増やし過ぎると逆にリリースを遅めてしまう、などの問題があります。

サービスレベルを大きく落とすような障害に対しては開発効率を犠牲にしても対策を打つ必要があると思いますが、あまりサービスレベルが低下しないようなことの対応として開発効率を大きく落とすようなことは「楽にサービスレベルをキープできる」ではないので、問題の原因となった不具合の修正のみ行うなど最低限の対応にとどめたり、自動テストを追加したりすることで、開発と運用のバランスを取るようにしています。

もちろん障害を起こさないようにすることは重要ですが、機能追加などをしてどんどんサービスが便利になっていくこともユーザーにとっては嬉しいことなのかなと思っています。 そのため、障害を起こさないようにするだけではなく、リリースを速くしていくことも重要であり、バランスを取っていくことが重要と考えています。

日々の開発と対応策のバランスを考える

せっかく対応策を立てても実施されないと効果はありません。 一方で、日々の開発もあり、どんな対応策でも実施できるわけではありません。
ですので、大きな障害でなければ、日々の開発とのバランスをとって改善が進められるよう対応策を考えています。

まとめ

EC 開発チームでの障害振り返りの取り組みについてご紹介させていただきました。

EC の SRE チームでは、EC のサービスを使ってくださるユーザーの方がより快適にご利用できるよう、日々改善を進めています。
採用も積極的に行っており、Hello hey というイベントを定期的に行っていたり、カジュアル面談なども可能です。 もし興味をもってくださった方がいましたらフランクにお声がけいただけるとありがたいです。

hey.jp

hello.hey.jp