Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • このドキュメントを読む前に
  • このドキュメントの使い方
  • そもそもの開発において
  • 本番環境に問題が生じた時
  • 対応で考えること
  • 一つ前の Deployment の状態に戻す
  • 古い commit を deploy し直す
  • Revert する
  • 思ったことは何でも言う
  • 対応後
  • Post Mortem
  • この文化を維持するために必要なこと
  • これからオンコールを担当する人に掛ける言葉
  • 障害を起こしてしまった人に掛ける言葉
  • 誤報を出した人に掛ける言葉

役に立ちましたか?

  1. 第一部:開発チームへの案内

障害対応の心構え

前へカレンダー次へ効率的な社内知識の調べ方

最終更新 1 年前

役に立ちましたか?

このドキュメントを読む前に

このドキュメントはインシデント発生前に予防として読んでおくことを想定しています。 緊急時は 及び を確認してください。

インシデント対応について がより網羅的かつ真とするドキュメントです。 このドキュメントでは上記のドキュメントの内容を補足する内容として特に new joiner が認識しておくべき情報を抽出/加筆したものです。 もし上のドキュメントとこの章に食い違いが生じる場合は上のドキュメントを真としてこの章を編集してください。

このドキュメントの使い方

各チームで new joiner を受け入れるときにこのドキュメントを一律に共有することで共通認識を得ることを目的にします。 このため主に障害対応経験が少ない人に向けた最低限の心構えを共有するものであり障害対応に関する情報を網羅的にまとめたものではありません。

障害対応経験者は障害対応を誰かに任せる場合にはこのドキュメントの内容を把握しているかどうかを確認してください。

そもそもの開発において

本番環境にバグを入れる可能性をゼロにはできないということを受け入れましょう。 もちろん良い設計、テスト、レビューなどでその可能性を下げることが望ましいですが完全にゼロにすることは現実的に不可能です。 また、完全にバグがゼロという状況はサービス運営企業としてはリスクが取れていなさすぎるとも考えられます。

ウォンテッドリーは失敗を受け入れる文化を持っているので、バグを出すことを恐れて開発スピードを遅くする必要はありません。 テストやレビューを頑張っても不安が消しきれない場合はバグが生じてもユーザー体験が落ちにくい工夫をすると良いでしょう。 例えば「特定の query param があるときだけ新実装が使われる」「まずは社員にだけリリースされるようにする」「何かあったら古い実装に fallback するようにしておく」などの手法があります。

一人で考えるとリスクをすべて自分で背負ってしまう気持ちになることあるので、そういう場合は周りの人を捕まえて一緒にどうするかを考えると建設的に進むことがあります。 失敗が起こることを受け入れ、チームで助け合いながら開発を進めていきましょう。

本番環境に問題が生じた時

まずは過剰反応である可能性を一切忘れて、どんな小さな問題だと思ったとしてもどんな時間であっても大声で人を集めましょう。 自分一人で判断しないことが大事です。 ウォンテッドリーのメンバーは必ず協力してくれます。 問題を過小評価しないことがいちばん大事なので、過大評価することを恐れる必要はありません。 具体例として「深夜にたまたま少し挙動がおかしい可能性に気づいた」というような場合にすでに就寝している自分のリーダーを起こす、というようなことがあっても構いません。 仮にそれが誤報であったとしても「勇気を持ってレポートしたこと」は称賛されるべきです。 繰り返しになりますが過剰反応になること一切恐れず、逆に一切過小反応にならないようにしましょう。

また、誰の Pull Request が原因であったとしても ウォンテッドリーは失敗を受け入れる文化を持っているので隠す必要はありません。 個人の感性で問題ではないかと思ったらまずまわりに協力を求め、そこで判断の精度を上げつつ、必要ならもっとまわりを巻き込んでいきましょう。

対応で考えること

ここでは主に Kubernetes に deploy されているコンポーネントにおける障害の緊急対応方法を記述します。 これに該当しない Mobile アプリなどは修正にかかるリードタイムが長くなるため分単位のタイムロスを考慮する必要がないためです。

一つ前の Deployment の状態に戻す

Incident には様々な原因がありえますが、最も多いものの一つに deploy があります。 つまり本番環境に入ったコードの変更に起因するものです。 このような場合は「とにかく早く想定通りに動いていた version に戻す」というアクションが有効です。

kube prod history

この操作でいつどの commit が deploy されたのかを把握することができます。 この中で一つ前のものを deploy してみましょう。 重要なこととしてここの表示され一つ前とはる必ずしも git における一つ前の commit ではないということです。 複数の Pull Request の merge がまとめて deploy された場合にどれが原因かわからないということもありえるので、 「一つ前の commit」ではなく「一つ前の deployment 状態」に戻す操作が有効なケースが多いでしょう。

古い commit を deploy し直す

一つ前の deployment にしても問題が継続する場合にはもっと古い version を deploy することを検討しましょう。 コードベースを修正するのにはどうしても数分~数十分の時間が必要です。 push された任意の commit に対応する docker image が container registry に push されているので基本的には任意のタイミングの commit の状態に 1 分程度で戻すことができます。 コードの修正を行う前にこれが実現可能かを確認しましょう。

# <commit hash> の状態を deploy する
kube prod deploy <commit hash>

これを行う際は「戻しすぎると他の場所が壊れることがある」という点に注意しましょう。 典型例としては「DB migration が入っているため戻すと DB との整合性が取れないので戻せない」「リリース済みで動作するべき他の機能が未リリースに戻ってしまう」などがあります。

また自動 deploy によりバグがもう一度 deploy されてしまう可能性があるので自動 deploy を止める lock を行いましょう。

# production への deploy を 1h 禁止する
kube prod lock 1h

Revert する

バグ修正を試みると想定以上の時間がかかったり新たな問題を生んでしまったりすることもあります。 原因の PR が特定できる場合はその PR の revert ができないかを考えましょう。

基本的には revert の PR の作成は早ければ早いほうが良いです。 古い commit を deploy するという対応が取れない場合、 最速の復旧方法は「Revert の PR を master に merge せずに deploy する」というアクションになります。 この deploy が可能になるタイミングは Revert を作成してからその PR に対する docker build の作成が完了する時間に依存します。 Revert を過剰に作りすぎることのコストは無視できるので、怪しい PR があったら何よりも早く Revert PR を用意しましょう。

思ったことは何でも言う

障害対応経験が浅いタイミングで実際の障害対応に入ると、 「自分が思っていることはみんなわかっているだろう」と思ってあまり発言をしないこともあるでしょう。 しかし障害対応中は少なからず焦っているので当たり前のことに気づいていないこともあります。思ったことは何でも発言していきましょう。

対応後

Post Mortem

この文化を維持するために必要なこと

ポストモーテムの取り組みが長期間続いていることもあり、近年ウォンテッドリーではますます障害発生がレアな事象になりつつあります。 この状況下でこの障害対応に対する心構えの文化を維持するためにはこれから障害に関わる人にこの文化を伝播していく姿勢が重要です。 ここではいくつかの例とともにこの文化を維持する方法について述べます。

これからオンコールを担当する人に掛ける言葉

これからオンコールを担当する人にはこのドキュメントを読んでもらいましょう。 そしてこのドキュメントで示されているポイントを自分の言葉でも説明してください。 その際に「自分も xxx のようなケースで深夜に人を起こしたことがある」「昔大騒ぎしたけど誤報で笑い話になったことがある」 というような自分のエピソードを話すと良いでしょう。 もし自身にそういった経験がなければ他のメンバーに話を聞いてみると良いかもしれません。

障害を起こしてしまった人に掛ける言葉

障害を起こしてしまった人は誰よりも落ち込みます。 しっかりとした再発防止は多少時間が経ってからでもできますが、 本人が感じる過度な自責の念と緊張感の払拭は即時でないとできないことがあります。 はじめて障害を起こしてしまった人には「はじめての障害おめでとう」と冗談をいうくらいでも丁度よいです。

誤報を出した人に掛ける言葉

まずは報告してくれたことに対する感謝を伝えましょう。 加えて「誤報で良かった」ことを伝えましょう。 スタンプなどで「よかった」「ありがとうございます」などを押すだけでも 報告者の心理的障壁が下がります。

話を聞きに行きたい

もっと知りたい

基本的には でコメントすると人が集まります。 このチャンネルでは任意の投稿に対して通知を受け取るにしている人が多いので簡単に気づいてもらえます。 簡単に気づいてもらえる反面、簡単に注意を引いてしまうので投稿する場合は「とにかく緊急で助けてほしい」「すでに対応に十分な人員がいる」などの情報を共有するようにしましょう。 また、最終手段として に主要な人に到達できる電話番号が書かれています。

インシデント対応後は post-mortem を書きます。 詳しくはを確認してください。

Slack: ,

Incident Response (internal)
#war_room (internal)
Incident Response (internal)
#war_room (internal)
緊急時の連絡先 (internal)
ポストモーテムの取り組み
#war_room
#sre
ポストモーテムの取り組み
wantedly/post-mortems (internal)
仕事の進め方 (internal)
インシデント対応時チートシート (internal)
緊急時の連絡先 (internal)
Incident Response (internal)