「障害」なのにテンションが上がる—強いSREチームが持つ仕組みとマインドセット
読者のみなさまは、深夜にけたたましいアラート音で叩き起こされた経験はありませんか。鳴った瞬間ハッと目が覚め、心拍数が上がる。まだモヤがかった頭でアラートの内容を確認した後、Slackを開き、赤く染まったダッシュボードを見て嫌な汗が出る。SREやインフラエンジニアなら、一度は通った道ではないでしょうか。
多くの人が、このような障害は起きて欲しくないと願っているものです。しかし世の中には、障害が発生しても「よし、来た」と構え、淡々と対処し、終わったあとに「今回もいい学びがあったね」と振り返るチームが存在します。彼らは何者なのでしょうか。生まれ持った能力差？ 技術力の違い？ それともツールの違いでしょうか。
本記事では、インシデント管理を、場当たり的な消火活動から貴重な学習機会へと再定義するための考え方を解説します。ツールを導入する前に、まずエンジニアが手に入れるべき平穏な夜と誇りある運用の考え方を示していきます。
どうして障害なのにテンションが上がるのか
障害が起きても平然と対応出来るチームは一体何なのでしょうか。彼らは障害対応中、楽しそうにすら見えます。もちろん彼らだって、障害がおきて嬉しいわけではありません。サービスの安定稼働が使命ですから、障害が起きないに越したことはありません。でもひとたび障害がおきると、燃え上がる目とあふれ出るアドレナリンという感じで、テキパキと対応していくのです。
普通のチームと、障害に強いチーム。この二つを分けるのは、一言でいうと自信の差です。自信があるからこそどっしりと構え、いざ事が起きても効率よく対応ができます。
しかし、自信という表現はいささかフワッとしています。気持ちの問題とも読めてしまいますし、どうやってその自信を培っていけばよいのかよく分かりません。なので、もう少し分解して考えてみましょう。筆者は、自信にあふれるチームは次の3点ができていると考えています。
- 疲弊しない仕組み作り
- チームワーク
- 学びのチャンスという発想の転換
それぞれについて詳しく見ていきましょう。
無駄に起こされていませんか？ その緊急対応、本当に必要ですか？
障害対応に自信が無いチームは、総じて疲れて果ててしまっています。一方で強いチームはエネルギーに満ちあふれ、いつでも来いという構えができています。そこの差は、疲弊しない仕組み作りにあります。
全通知が招くアラート疲れと、新人が陥るパニックの正体
SREとしてチームに配属されたばかりの新人がはじめに直面するのは、アラートの洪水です。障害の際、Slackの通知チャンネルには毎分のようにアラートが流れ、どれが本当に重要で、どれが無視してよいのか判断がつきません。
全部見なきゃいけないのでは、という不安が、アラート疲れを引き起こします。みなさんはオオカミ少年の逸話はご存じでしょう。少年が嘘を繰り返した結果、本当にオオカミが襲ってきた際に信用してもらえず、大惨事になるという話です。毎日100件のアラートが鳴り、そのうち99件が対応不要な状況が繰り返されると、人間の脳は「また誤報だろう」と学習してしまいます。そして101件目の本物の障害を見逃します。
新人がパニックに陥る原因のひとつもここにあります。技術力が足りないのではなく、何が本当に重大で、何がそうでないかを判断する基準を持っていないためです。基準がなければ、すべてのアラートが等しく脅威に見えます。すべてが脅威に見える状態で、冷静な対応ができるはずがありません。
つまり新人に必要なのは、もっと勉強しろというアドバイスではなく、何を無視してよいかを明確にする仕組みです。
サービスが死んでいないなら、それはイベントに過ぎない
ある日の深夜3時、またしてもアラートが鳴りました。内容を見てみると、CPU使用率が80%を超えているようです。あなたは飛び起きてPCを開きます。しかし、ユーザーからの問い合わせは一件もありません。サービスは正常に動いているように見えます。
この場合、あなたが起きる必要はありませんでした。
インシデント管理において最も重要な概念の一つが、イベント・アラート・インシデントの区別です。たとえばPagerDutyでは、モニタリングツールから送られてくるデータをイベントとして受信し、そのイベントからアラートが生成され、アラートからインシデントが作成されてオンコール担当者に通知されるという階層構造になっています。CPU使用率が80%を超えたという情報はイベントとして届きますが、それをアラートとして起票するか、抑制するかはルールで制御できます。さらに、アラートからインシデントを作るかどうかも制御可能です。
つまり、モニタリングツールが検知したすべてのシグナルが、自動的に人間を叩き起こすインシデントになるわけではありません。この階層構造を理解せず、すべてを一律に障害として扱ってしまうと、エンジニアは不要な深夜対応を強いられ、本当に重要なインシデントへの集中力を失っていきます。
ここで必要となるのは、アラートを捨てる勇気です。これは、このアラートは本当に今すぐ人間が対応すべきかと冷静に問い直す勇気のことです。翌営業日に対応しても問題ないアラートを深夜に鳴らすことは、チームのリソースを浪費しているだけではありません。エンジニアの睡眠を奪い、健康を損ない、最終的には離職を招きます。
SLOに基づいた重要度の設定
このアラート、本当に鳴る必要がありますか？ という問いに対して、属人的な感覚で答えてはいけません。必要なのは、チーム全員が合意できる客観的な指標です。
そこで登場するのがSLO（Service Level Objective：サービスレベル目標）です。SLOとは、たとえばこのサービスは99.9%の時間、200ms以内にレスポンスを返すといった形で、サービスの品質目標を定量的に表現したものです。
SLOの策定は、まずCUJ（Critical User Journey：クリティカルユーザージャーニー）の定義から始まります。ユーザーがサービス上で行う操作のうち、特に重要なものは何かを考えるのです。たとえばECサイトであれば、ログイン→商品検索→カートへの追加→決済、という流れがCUJにあたります。このCUJをもとにSLI（Service Level Indicator：サービスレベル指標）を実装し、その目標値としてSLOを設定するという流れです。
ここで重要なのは、SLOの数値はエンジニアだけで決めるものではないという点です。SLOが満たされることはユーザーにとってもビジネスにとってもハッピーな状態でなければ意味がありません。99.9%（月間約44分の停止を許容）にするか、99.99%（月間約4分）にするかは、ユーザーの期待、ビジネスのインパクト、そして達成にかかるコストのバランスから導かれます。ECサイトの決済機能とヘルプページでは求められる信頼性がまったく違いますし、0.09%の差を埋めるためのエンジニアリングコストが、そのサービスのビジネス価値に見合うかという議論が必要です。
SLOの真の力は、関係者間の景色を揃えることにあります。経験10年のベテランと入社3ヶ月の新人が、同じ基準でアラートの重要度を判断できるのです。誰かの勘ではなく、チームの合意で動ける。これがSLOの持つ本質的な価値です。
