失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」

人間は失敗するものです。エンジニアもまたしかり。Retty株式会社の樽石CTOが考える、失敗を学びに変える考え方とノウハウを紹介します。

失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」

はじめまして。Retty株式会社でCTOを務める樽石将人1@taru0216です。Rettyにおける技術の責任者として不確実性の高いシステム開発を成功に導くよう牽引したり、メンバーが働きやすくなるような仕組みづくりを行ったりしています。

子供の頃からパソコンに親しみ、新卒一期生でレッドハットに就職して、Rettyに入社するまでGoogleや楽天を経てきました。エンジニアとして活動して約30年。日々失敗し続けていますし、過去には大規模サービスを止めてしまったこともあります。

人間である以上、バグやエラーは必ず起こるもの。エンジニアは失敗を繰り返す仕事です。

失敗を糧として成功に変える秘訣(ひけつ)は、障害報告書を書く習慣をつけることです。私も仕事する上で実践していますし、Rettyのメンバーにも勧めています。とくに若手エンジニアにはぜひ身に付けてほしいと考えています。

この記事では、私が失敗の基準としている考え方と、障害報告書によって失敗を学びに変えるノウハウをお伝えします。

どこからが失敗なのか?

仕事に対して「完璧な達成」を目指す人は多いのではないでしょうか? まず、その思い込みを捨てましょう。ほとんどのWebサービスは「完璧」でなくてよいのです。

細かいバグがあったとしても、サービスを利用するユーザーさんが望む体験を提供できていれば、問題は起こりません。ユーザーさんに大きな影響がない状態にしておくことが大切です。

失敗とは何でしょうか? 私がその基準としているのは、品質レベルです。

コードを書けば、エラーやバグがあるものです。運営していると、想定外の問題も発生します。皆さんもプログラムが正しく動かなくて、ソースコードと格闘し、問題を解決するという日々を繰り返していると思います。

コードが間違っていても、品質レベルを保てているならば「失敗」ではありません。それでは、品質とは何でしょうか?

サービスレベル目標とサービスレベル指標

企業では、サービスレベル目標SLO:Service Level Objective)として、具体的な稼働率を数値目標に使うケースが多いと思います。「稼働率〇〇.〇%」「レイテンシー〇〇msec以内」「エラーが発生した割合%以内」といった条件で表されます。

SLOを設定するために、サービスレベル指標SLI:Service Level Index)を使います。これは、SLOの前提となる具体的な数値です。例えば、サービスの現在の稼働率が99.99%だったとすると、「99.99%」という数値そのものがSLIです。

このとき「稼働率が99.9%以上」がSLOだとすると「99.9%<99.99%(SLI)」となることから、現在のサービス状態は「SLOを達成している」と判断できます。

SLOの設定自体が、CPUやメモリといったシステム指標になっていないでしょうか。目的と手段を履き違えることにつながります。品質担保はあくまでユーザさんのためにあるもの。ユーザーさんへの影響にフォーカスして考えましょう。

私が自分の仕事の品質を客観的に判断する際には、成果物(開発したコードや担当サービスなど)SLO未達のときに初めて「失敗」と呼び、品質レベルを保っている限り、小さなバグやエラーがあっても「失敗」とは考えないようにしています。

ミスは起こるものなので、「少ない工数で品質基準を満たす」ことができる方法がないかを考えます。

致命的なミス(例えばユーザーさんの個人情報が流出)を防ぐ設計は、必ず必要です。守るべきものをしっかりと定義し、そうでないものはSLOに大きく影響するページ(=多くの人が訪れるページ)の品質を担保するよう丁寧な開発を心掛け、テストを細かく設定しましょう。

そうはいっても、どういった機能や技術コンポーネントがSLOに大きく影響しやすいかをバランスよく判断するには、経験が必要です。そこでオススメなのが、実際に失敗した後に「障害報告書」を書くことです。

障害報告書を書く2つの効果

障害報告書を書くことには、2つのメリットがあります。

まず1つ目は、自ら報告書を書くことで、周囲からの信頼回復の効果があること。私自身の失敗談でも触れますが、失敗が前向きな終わり方になります。障害報告書の完成度が高いほど周囲から敬意を持たれ、失敗前よりも信頼が得られる可能性もあります。

若手のエンジニアは、小さな失敗でも「失敗しました」とチームに宣言した方がよいでしょう。個人的には、いわゆる奇麗なソースコードよりも、品質の高い障害報告書を短時間で作成する方が圧倒的に重要と考えています。Rettyでも障害報告書を高い品質で、しかも迅速に書けるエンジニアを求めています。

もう1つは、障害報告書を書くまでの分析と調査によって学びがあり、同じ失敗をしなくなる効果があること。言語化することで経緯や対応策が整理され、今後同じ轍(てつ)を踏むことは防げるでしょう。

普段の業務では触れない部分も整理して言語化しなければいけないため、アーキテクチャやシステムの勉強にもなります。ぜひ、失敗した後の儀式として取り組むことをオススメします。

私自身の失敗と学びの体験

昔、大きなサービスを止めてしまったことがあります。

入社して研修を終え、本番環境を触れるようになった初日。ある実験をしようとして、サーバにコマンドを打ち込んだところ、本番環境の基盤になるプライベートクラウドを壊してしまいました。その基盤で動いていたサービスがすべて動かなくなってしまったのです。

自動復帰はしたものの、5分ほど止まり、100万リクエストが失われたと記憶しています。

原因は、サーバに打ち込んだ情報取得用のコマンド自体にバグがあったこと。軽い気持ちで「どのノードでどんなサーバが動いているか」という構成情報をDBサーバから取得しようとしたところ、コマンドが仕様通りに動かず、サーバが停止。サービスの動作も止まってしまいました。

今まで自分で大きな失敗をしたことがなかったので「これくらいでは壊れないだろう」と油断していた部分もあり、今だから笑い話にできるものの、そのときは肝が冷えました。

自動復旧して正常に戻ったことを確認した後、すぐに障害報告書を書きました。そして、問題が起きたことの報告と対処方法、次回以降の防止策をチームに共有しました(障害報告書の書き方は後で紹介します)

かつては、失敗が起きるとチーム内の雰囲気が悪くなったそうです。しかし、私の報告を受けた当時のチームリーダーは「人間が失敗しても壊れないようなシステムにすべきだよね」とメンバーに言い、障害対応を終えたチームの雰囲気が少しだけ和やかになったのを覚えています。

Googleで学んだ障害報告書の意味

私が障害報告書を書いたのは、尊敬する優秀な先輩の失敗後の対応方法に感銘を受けたからです。

Google時代、失敗なんてしそうにない大先輩が、サービスを止めてしまったことがありました。失敗したことにも驚きましたが、もっと驚いたことが、先輩が障害報告書を書き上げる速さとその精度です。

エラーの発覚から数時間で障害報告書が社内に展開されました。報告書の内容は次の3つです。

  1. 根本原因の分析
  2. 再発防止策
  3. 時系列で、どんな行動をしたか

この失敗は、サーバの数が足りず、通信負荷に耐えきれなかった結果、サービス自体が落ちたというものでした。

報告書では、原因がキャパシティ計算にあったことを突き止めただけでなく、発生したエラーとその対応策をすべて時系列にまとめ、対応ノウハウを共有。メンバーが今後生かせるように情報をまとめてありました。

この失敗したときの効果的な対応方法を目の当たりにしてから、失敗しても大丈夫だと思うようになりました。

障害が起こっても障害報告書を書けばすべて丸く収まるという意味ではありません。障害そのものの原因を突き止め、再発防止策を考え、実行することに意味があるのです。

再発防止策を考えるのは、復旧が終わってからにしましょう。障害が復旧しなければ、ユーザーさんがサービスを快適に使うことができません。まずは事象を応急処置によって救済することが大事です。復旧しなければSLO未達の状態は回避できませんし、障害発生後の事後処理に取り掛かってよいのかも判断できません。

問題を隠さない文化とエラーバジェット

この先輩をはじめとして、Googleには問題が起きたことを隠さない文化がありました。

  • 問題の根本となる原因を調べ、再発しないことを障害報告書で宣言し、実行する
  • 障害報告書によって、チームに共有する
  • 対応ノウハウを共有するほか、失敗を隠さず容認しあう文化をつくり、チームがより良くなる

Googleでは、障害報告書をポストモーテム(postmortem:事後分析)と呼び、チャレンジのために許容可能なエラー量を、エラーバジェット(Error Budget)と言いました。

エラーバジェットの数値は、エラーが起こるたびに減ります。エラーバジェットが残っているうちは、「チャレンジしてもよい」ことを意味します。

エラーバジェットを基準とする運用ルールは、例えば下記のように自分たちで決めることができます。

エラーバジェットなし
障害報告書を書く
チーム全員でサービスをリリースする
エラーバジェットがあるうちのSLO未達
軽微な失敗として、障害報告書は書かない

このあたりのノウハウを学ぶ上で、他社の前例や指標を活用することはおすすめです。Googleでのシステム管理とサービス運用の方法論は『SRE サイトリライアビリティエンジニアリング』という書籍にまとまっています。

この本には障害報告書の書き方も掲載されています。ぜひ一度読んでみてください。

原著は、Webで無料公開されています。

Google - Site Reliability Engineering3

現在のRettyで進めている施策

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く