TL;DR

こんにちは、SRE の @masartzです。
メルカリには Go Bold、 Be Professional、All for One という3つの行動指針（Value）があります。今回はこれらのValueを元にメルカリでインシデント対応をどのように行っているかを紹介します。

インシデント対応とは

本エントリでは、いわゆるハードウェアやネットワークなどのインフラにおける不具合や故障だけでなく、プロダクトひいては会社活動全般における非日常的な状況に対する対応をインシデントと定義して進めます。

何をやっているか

インシデント対応は、障害の発生から根本解決までの過程で大きく2つの段階に分けられます。

• 障害発生から一旦の収束まで
  • 発生した障害を監視システムなどで検知します
  • あらかじめ用意された専用のSlackチャンネルに共有し、対応を開始します
  • 状況の把握と早期の復旧に務めます
    • 機能のリリースに関わる場合はリリースした内容の巻き戻しなどを行います
  • 通常のサービス運営ができる状態に戻ることを一旦のゴールとします
• 障害報告の記入と再発防止策による根本解決
  • 障害の内容をドキュメントにまとめます。メルカリでは同時編集などの利便性を考慮して、Google Docsに集約しています
  • 記載した障害報告を定期的に振り返ります
  • 再発防止策を実施します

障害報告とは

ここで記載する障害報告とは、オライリー社から出版されている「SRE サイトリライアビリティエンジニアリング」の中で ポストモーテム として記載されています。

www.oreilly.co.jp

この中で書かれている原則に

• 批判を行わない
• 特定の個人やチームを糾弾することなく、インシデントに影響を及ぼした原因を特定することに集中する

とあります。この事からも障害報告は決して始末書ではなく、過去の経験を未来に活かす「資産」であると言えます。

何故やっているか

このようなインシデント対応はもちろんやるべきことですが、
改めて 何故やるのか を述べるならば以下の理由があります。

プロダクトとお客様に向き合い、サービスをより良くしていくために

メルカリは日頃より多くのお客様に利用され、お問い合わせも数多くいただきます。
またそのスピードも時に監視システムの検知より早い場合すらあります。
それは本当にありがたいことであり、お客さまがサービスに向き合ってくださっている証拠です。
サービスを提供する側としても同じように向き合い、サービスをより良くしていかなければいけません。

楽しく前向きに仕事をしていくために

一見すると過去を振り返り良くない結果を見返すのは後ろ向きであり、楽しくも思えません。
しかし、人間の行う作業にミスはつきものです。どんなに優秀な人でもミスはします。

失敗を受け入れられない土壌では、失敗をしないようにあるいは失敗を隠すようになります。
またエンジニアリングにおいては、 気をつけたり、確認を繰り返したりといった本来の開発に集中できない状況になってしまいます。

一方で、メルカリの大事なValueに Go Bold があります。これを大きな一歩を踏み出す時の姿勢に例えるなら、
より歩幅を広げるには軸足を置く場所が固い足場となっていることが重要です。

そういった足場を見直すことがつまり失敗を受け止めること、仕組みで失敗の再発を防止することです。
具体的にはテストを書く・自動検知/復旧する、などの機械的な対処をするエンジニアリングです。

どうやっているか

現状、以下のようなスタイルで実施されています。

• 週に1度1時間
• Slack上でオンライン開催
• 参加者は任意（会話を追うだけの参加も可)
• 進行は複数人で持ち回る

ここでのポイントは Slack上でオンライン開催 かと思います。
実際、以下のように進めています。

これにはいくつか理由があり

• 物理的に大人数が入る会議室の確保コスト排除
• 進行がそのまま議事録になる
• 原因コードや、再発防止策のテストコードなどへのリンク共有がスムーズ

などの点を目的としています。
議事録はTimezoneが異なるために参加ができないメンバーにも有用です。
また障害報告の目的である 批判をせず、原因究明に集中する ためにもコードを主語として話すことは重要です。
オフラインのMTGで、実際に起案者が障害報告を読み上げるようなスタイルでは、余計な感情が混じってしまいがちです。

進行役も複数人で持ち回りするようにしています。
最初は私がメインで進めていましたが、冗長性を持ってスケールさせていくために他の参加者とも協力して運営しています。
進行役は必ずしも正しい答えに導く能力が必要な訳ではなく、できるだけ多くの意見を集めて最終的に妥当な再発防止策に着地することが重要です。

再発防止策は各自が専門性を持ち寄って検討します。
エンジニアにおいては、仕組み化による解決を目指します。
テストを書く・自動化する、など機械的な取り組みを主眼にしています、これは Be Professional そのものです。

再発防止策はチケット管理しており、作成済みであればあらかじめ報告に記載しておきます。
振り返りMTGの場で挙がったものについては、その場で即座にチケット化します。
このようなアクションもSlackの会話の流れで、シームレスに行えるような仕掛けもしてあります。

またこの振り返りMTGは障害を起こした人だけでなく、皆で一丸となって課題に取り組んでいます。
そこにはエンジニアだけでなく、プロデューサー、QA、CS、など職種の壁はありません。
お客様になんらかの影響を与えてしまったことを皆が自分ごとと捉え改善に取り組む姿勢は All for One を体現しています。

まとめ

このようにメルカリでは Go Bold を保つために Be Professional な取り組みで All for One にインシデント対応を行なっています。

私が入社する前からメルカリには「障害報告を書く」という文化がありました。
今回主に紹介したのはその後の「書いた障害報告を振り返る」というインシデント対応のほんの一部分です。
多くの企業でも、「障害を出さないように」を目標にしていたり、実践されているかもしれません。
しかし、「障害を出さないこと」を目標にすると、大胆な開発ができなくなったり、あるいは事故を隠蔽する文化にもなりかねません。
それよりも誤ちを認めて、次への糧にすることでより大きな挑戦をする権利が得られるのだと思います。

そのような文化は一朝一夕では作られません、これまでのようにこれからも実際の活動をもって「障害報告は資産」ということを伝えていければと思っています。