Slide 1

Slide 1 text

nokuchi.sre#0 何もしなかった 障害対応 データストアを切り替えたとき、一部の書き込みが旧の方に残ってしまった話です。 直し方はありました。でも、データには手を入れませんでした。 金森 秀平 @_MoneyForest

Slide 2

Slide 2 text

自己紹介 Shuhei Kanamori / 金森 秀平 @_MoneyForest / github.com/MoneyForest 経歴 出身 金融系SE → Backend → SRE 神奈川県川崎市中原区(武蔵新城) ひとこと めちゃくちゃ地元です。 nokuchi.sre#0 2 / 12

Slide 3

Slide 3 text

※実話に近いフィクションです データストアの切り替えが終わりました 接続先を新しいクラスタに向けて、作業は完了。 サービスも、ふつうに動いているように見えていました。 アプリは新しい方を見ている 新が正。旧は用済み👋 のつもりでした。 nokuchi.sre#0 3 / 12

Slide 4

Slide 4 text

そこに、問い合わせが来ました。 👦「パブリッシュしたデータがないんですけど」 そんなはずはない...ないはずなんだ... そんな気持ちを堪えつつ調査を開始しました。 nokuchi.sre#0 4 / 12

Slide 5

Slide 5 text

切り替え時に旧の方に書いてしまっていました😭 調査の結果、切り替えの瞬間に作成・更新・削除が旧に書き込まれてしまったことがわかりま した。 新データストア 旧データストア 現状のアプリ・ユーザーが見ている側。切 り替え後の操作は、こちらに書き込まれて 切り替えの瞬間の更新が残っている。アプ います。 nokuchi.sre#0 リはもう参照していません。 5 / 12

Slide 6

Slide 6 text

障害対応開始 障害対応フローに則って調査を開始します。 幸いにもログから書き込まれてしまった内容は特定できました。 🧑💻「ではデータの復旧手順を検討しましょう!」 あれ...でもそれでいいんだっけ?? nokuchi.sre#0 6 / 12

Slide 7

Slide 7 text

結局、システム復旧はしませんでした。 最初から「何もしない」と決めていたわけではなく、話すうちにそちらに倒れていきました。 あとから振り返ると、そこには3つの学びがありました。 1 「直すリスク」と「直さないリスク」をフラットに評価する 2 基本方針を決めてトリアージする 3 システムではなく、ユーザーの状態を考える nokuchi.sre#0 7 / 12

Slide 8

Slide 8 text

学び 1 「直すリスク」と「直さないリスク」を フラットに評価する 直し方が見つかると、直せる安心感から「その方向で進める前提」になりがちです。 でも、片方のリスクだけ見えている状態で決めてしまっていないか。 直さないリスク(見えやすい) 直すリスク(見えにくい) 差分が残る。なぜそうなっているのか、説 明が必要になる。 二次被害。もう次の操作をしている人のデ ータを、上から書き換えてしまうかもしれ ない。 nokuchi.sre#0 8 / 12

Slide 9

Slide 9 text

学び 2 基本方針を決めてトリアージする 差分を1件ずつ見ていくと、時間がいくらあっても足りません。 人によって「気になる」の基準も違うので、議論が発散しがちです。 基本方針:一括の復旧・補正はしない(現状維持がベース) 例外:影響が大きく残るもの、本人では回復できないもの、 金銭や契約に関わって期限があるもの 方針は問題を切り捨てるためではなく、 本当に個別判断が必要なところに時間を使うためのものです。 nokuchi.sre#0 9 / 12

Slide 10

Slide 10 text

学び 3 システムではなく、ユーザーの状態を考える 意図しない状態でも、本人がそれを見て次の操作をしていれば、 いまの文脈ではそれが「正しいデータ」なんじゃないか。 一人ひとりに確認するのは無理なので、基本は手をつけない方が「正しさ」を保てそうでした。 ユーザー操作の不整合 非同期・バッチの不整合 本人が再操作するかもしれないし、問い合 わせるかもしれない。基本は触らない。 システム都合の処理が多いので、こちらは 慎重に。旧を起点にした処理が新を見て動 いていないか確認しました。 全部直すか、全部放置かの2択にしない。 問い合わせに応じて個別に、期限があるものだけ別に、という余地を残しておきます。 nokuchi.sre#0 10 / 12

Slide 11

Slide 11 text

で、その後 結局、どうしたかというと 差分の中に、今日中に直さないといけないものはありませんでした。 その日はサポートに差分を渡して解散。翌朝、あらためて議論して決めました。 🧑💻「今回は、データには何もしないでいきましょう」 問い合わせには、サポートから個別に案内。 対応は、ここで完了としました。 nokuchi.sre#0 11 / 12

Slide 12

Slide 12 text

というわけで、「何もしなかった」障害対応でした。 3つの学びは、ぜんぶ同じところに戻ってきます。 現在のユーザーにとって安全な状態をつくる 復旧は、過去の「正常だった世界線」を再現することではなくて、 いまのユーザーにとって安全な状態をつくること。 直せるからといって、直した方がいいとは限らない。 次に「復旧手順を検討しましょう!」となったら、一度立ち止まってもらえたら嬉しいです。 金森 秀平 @_MoneyForest