これは SRE Advent Calendar 11日目の記事です。
こんにちは、Backlog の SRE を担当している吉澤（Muzi と呼ばれている人）です。
本記事では、SRE Lounge #5 で講演した際に、時間の都合で省略した「ヌーラボ社内での Backlog のサービスレベル計測とその結果の活用」についてご紹介します。
長年運用されてきたサービスを改善するために、SRE ができる取り組みの一例としてご参考ください。
目次
SRE とは？
SRE とは、Site Reliability Engineering の略です。これは Google で初めて提唱された概念で、その提唱者自身は著書「SRE サイトリライアビリティエンジニアリング」（いわゆる「SRE 本」）のなかで以下のように述べています。
Google 内で規定されることになったサイトリライアビリティエンジニアリングとは、いったい何なのでしょうか。私の説明は単純明快です。SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。
また、SRE はこのようなエンジニアリングを担当する職種（Site Reliability “Engineer”）の略としても使われます。これ以降で SRE という場合は、主にこのエンジニアを指す用語として用います。
SRE の業務に関する明確な定義は、SRE 本のなかでは特にされていません。個人的には、以下の条件を満たすものすべてが SRE の業務範囲になると考えています。
- ソフトウェアエンジニアとしてのスキルをもって、プロダクトの信頼性を一定以上に保つ
- 信頼性を保つために、従来はオペレータやインフラエンジニアなどが担当していた業務＋αを期待されることが多い
- インフラとアプリ両方の理解が必要
過去の発表のサマリ：Backlog の成長とともに私たち SRE が直面した課題
以前、9/26に開催された SRE Lounge #5 にて、「Backlog における SRE の事例 〜プロダクトの成長のために SRE はなにをすべきか〜」と題して、私たちがプロダクトの成長とともに直面した課題と、現在の取り組みについてご紹介しました。
今回の話の前置きとして、この発表を軽く振り返ります。
エンジニア組織が小さいうちは、全員が開発と運用を兼ねることもできますが、プロダクトの成長とともにそれも難しくなります。
Backlog では、利用者数が増加してきた2015年からインフラ専任のエンジニアを採用し始め、2016年に初めて SRE と名のつく「SRE チーム」が作られました。
SREチームが作られた時期のユーザー数の伸び
参考：プレスリリース：Backlog、ユーザー数が100万人を突破 — 業務改善を目的に、より多様なシーンで利用されるように | ヌーラボ
一般に、SRE はインフラとアプリ両方の理解が求められがちです。そのような SRE の性質上、その業務範囲は放っておくと再現なく広がってしまいます。
例えば、データベースの負荷が上がった場合、その原因はデータベースの性能不足でしょうか？ それとも、スキーマの設計や、アプリが発行する SQL に問題があるのでしょうか？
これはインフラとアプリの両方にまたがる問題のほんの一例で、同様の問題はたくさんあります。
SREが実際に担当したタスクの一例
Backlog でも、SRE チームが拡大した2017年末〜2018年初頭に SRE の職務範囲が広がった結果、SRE の作業量が増え、運用ミスが増加するという問題が起きました。また、SRE に運用業務を任せがちになり、Dev と Ops の分離が進んだ結果、障害発生から解決までの時間（Mean Time To Repair、MTTR）が長くなるという問題も起きました。
このままではいずれ大規模な障害に繋がりかねないという危機感から、Backlog プロジェクトでは、SRE をマトリックス的に配置する組織への変更を行いました。これにより、Dev と Ops の間でのコミュニケーションが改善され、運用ミスの低下、MTTR の短縮に繋がりました。
現在の組織体制
アプリ寄りのSREに期待される役目
インフラ寄りのSREに期待される役目
この発表内容に興味のある方は、上記のスライドに加えて、質疑応答の内容などをまとめたイベントレポート（SRE Lounge #5 にて Backlog における SRE の事例について講演しました – 無印吉澤）をご覧ください。
ヌーラボ社内における Backlog のサービスレベル計測
Backlog の SRE が直面している問題を正しく理解し、SRE 以外の関係者にも伝えるために、これまでにサービスレベル指標（Service Level Indicator, SLI）の計測方法を何度か見直してきました。前述した SRE の組織体制の見直しも、SLI の計測結果をきっかけに行われたものです。
ここからは、Backlog プロジェクトでこれまでに試してきたサービスレベル指標と、それぞれについて私たちが感じたメリット・デメリットをご紹介します。これは、決して理想的な方法ではなく、あくまでも長年運用されてきたサービスを少しずつ改善していく地道な試みの一例としてご参考ください。
稼働率
弊社が提供するサービスについては、Service Status Updates サイト にて過去12ヶ月間の稼働率を公開しています。
この稼働率は、対象期間（過去12ヶ月）から、一部のサービスクラスタに属するユーザーが、特定の機能を利用できない状態だった時間の割合を引いたものです。
Service Status Updates
上のスクリーンショットの例では、12/5 に一部のユーザーが Git 機能を利用できませんでした。この時間は主に Nagios での監視結果から計測し、自動計測できなかったものは手入力で一部補足しています。
稼働率は、プロダクトの安定性をユーザーの皆様にお伝えするための重要な SLI です。
しかし、SRE の活動を社内で見直すための SLI としては足りない部分があります。というのも、この稼働率には「サービス影響は出なかったが、システム内部で起きている問題」が現れないからです。
例えば、アプリケーションサーバ1台が急に Out Of Memory（OOM）エラーでダウンしたとしても、サーバは冗長化されているのでサービス影響はありません。
しかし、OOM が発生するたびに SRE の作業（再起動や原因調査といったトイル）が発生しているなら、その活動は何かしらの方法で計測し、根本的な対策を進める必要があります。
社内向けの SLI の整備
Backlog では、2017年の後半から、社内向けの SLI の整備を徐々に進めてきました。
Backlog は長年に渡って開発が進められてきたサービスで、課題管理からファイル共有にまで、幅広い機能を提供しています。これらの機能ごとにレスポンスタイムやエラー率などの SLI を計測しようとすると、見るべき SLI の数が膨大になってしまう恐れがありました。
そのため、まずはインシデントに関する SLI に対象を絞り、SRE チームでそれらを1ヶ月に1回「インシデントレポート」としてまとめました。これを定例ミーティングで開発者に共有しつつ、SLI の計測方法の見直しを行いました。
私たちが最初に整備した SLI は、以下の2種類に大別できます。
- SRE が受信したアラートの数
- 実際に対応したインシデントの数
アラートの数とインシデントの数は、サービス品質が向上すればいずれも減るはずです。また、アラートの数とインシデントの数を比較することで、誤報の数（言い換えると監視の適切さ）がわかるのではないかと考えました。
SRE が受信したアラートの数
私が2017年に入社した時点では、監視システムから通知されるアラートには、受信したらすぐ対応しなければならないものと、無視してよいものが混在していました。
また、SRE へのアラートの通知手段が、メールとTypetalk（チャットツール）の2種類に分かれており、重要なアラートに気づくのが遅れることがありました。
この点を改善するため、まずは PagerDuty を導入し、アラートの通知手段を PagerDuty に一本化しました。そして、重要でないアラートを徐々に削減していきました。
PagerDuty導入後の監視システムの構成図
PagerDuty が通知した過去のアラートは、”Analysis” のページから CSV ファイルとしてエクスポートできます。この CSV を使って、SRE が実際に受信した（言い換えると、SRE のスマホが鳴った）アラートの傾向を分析できるようになりました。私たちは、以下の SLI を3つの分析軸ごとに集計しました。
- SLI
- アラート数
- MTTR
- 分析軸
- サービスクラスタ毎
- アプリケーション毎
- アラートメッセージの種類毎
実際に対応したインシデントの数
PagerDuty の導入に加えて、SRE の実働が発生した回数や、作業時間の長さを記録するために「インシデントシート」を導入しました。
インシデントは以前から Backlog の課題として管理していました（もちろん、私たちは自社のサービスをフル活用しています！）。しかし、「冗長化されたアプリケーションサーバの1台が不調のため再起動した」といった細かいトイルは管理していなかったため、専用のシートを新たに用意しました。
このインシデントシートは、以下のような列を持つスプレッドシートです。
- アラートメッセージ
- 対応した SRE の名前、人数
- 障害発生時刻
- SRE が障害に気づいた時刻
- 障害が解決した時刻
- 実施した作業の内容
- 障害によるサービス影響の有無
- 障害の影響範囲（サーバの種類、サービスクラスタ）
- 根本原因（※インシデント発生時にわかった範囲のみ）
インシデントシートのフォーマット
この記録から、月次で以下の SLI を3つの分析軸ごとに集計しました。
- SLI
- インシデント数
- MTTR
- MTTA（Mean Time To Acknowledge）
- 作業時間（Acknowledge から Repair までにかかった時間の総計）
- 分析軸
- サービスクラスタ毎
- アプリケーション毎
- サービス影響の有無
インシデントレポートの効果とその限界
これらの分析結果を含む「インシデントレポート」を毎月作成し、SRE および開発者が集まるミーティングで共有していました。この試みは、2017年12月から2018年5月まで、約半年間行いました。
このレポートを継続することで、以下のような効果がありました。
- SRE の実働時間が長いインシデントや、サービス影響の大きいインシデントが明らかになった。これにより、削減すべきトイルや、改善すべきアプリケーションの優先度を決める手がかりが得られた。
- 誤報となるアラートの数を削減できた。アラートの具体的な件数および増加傾向が明らかになったため、開発チームの協力を得やすくなった。
- SRE が障害対応に取られている時間の長さや MTTR が定量化され、関係者の間で「SRE の作業量が増加傾向にある」という課題意識が共有された。これが、SRE を含む組織体制の見直しに繋がった。
このように、上記のレポートには一定の効果があったのですが、何回か続けるうちに以下のような限界も見えてきました。これらの一部は、言い換えると SRE 主体で作成する SLI の限界でした。
- SRE の臨時対応が終わっても、根本解決までには開発チームが数日〜数週間対応することがある。このレポートの SLI からは、開発チームへの影響が分かりづらかった。
- 障害の発生回数や SRE の実働時間は、インシデントの重要性に直結しない場合があった。例えば、データ欠損に関わる問題は、発生頻度が低くても重要性が高い。
- 1ヶ月頻度の集計では開発者に伝わるのが遅く、レポートで問題に気づいたときにはすでに解決していることが多かった。
- レポートの作成を繰り返すうちに、短時間で解決できる問題はほぼ解決され、詳細なレポートの必要性が薄れた。
SRE と開発チームがサービスレベルを共同で管理する体制へ
冒頭でお話したように、Backlog プロジェクトでは2018年から、SRE をマトリックス的に配置する組織変更を行いました。
現在の組織体制（再掲）
現在は、この「改善寄りの開発チーム」のなかで、顧客影響のあった障害および不具合のみを記録したシート（発生障害振り返りシート）を管理しています。この方式は、スクラムマスターの中村さんの提案・主導により導入されました。
現在使っているこのシートでは、SRE チームのインシデントシートよりも項目を減らし、以下の改善を行いました。
- 管理する対象を、重要度の高い障害に絞った
- シートの項目をいくつか減らし、代わりに以下の項目を追加した
- 障害の重要度
- 責任チーム（どの開発チーム、あるいは SRE か）
- 原因分類（バグ、ミス、既知の問題）
この記録を元に、障害発生件数を週次で計測し、毎週の振り返りミーティングでレビューしています。以下は分析結果の一例です。
障害の発生件数（棒グラフ）および過去4週間の平均（線グラフ）
障害発生件数が目標値（赤線）より上回っている場合は、翌週は「改善寄りの開発チームは」開発よりも改善を優先する、といった判断を行っています。つまり、障害発生件数をサービスレベル目標（Service Level Objective, SLO）とした、エラーバジェットのようなものが導入されています。
このエラーバジェットは「改善寄りの開発チーム」のなかだけで運用されているので、例えば「全チームの新機能リリースを SRE の権限で止める」といった厳密な運用ではありません。それでも、現在の体制になってから、サービス品質をないがしろにして開発を進める、という状況はかなり少なくなったと感じています。
今後の課題
以上のように、現在は障害発生頻度を SLI として、サービス品質の維持・改善を行っています。しかし、理想的には、障害の予兆を事前に発見できるような SLI を、自動的に集計したいと考えています。現時点でも各機能のレスポンスタイムやエラー率の記録はできていますが、それらをサービスレベル管理に活用するところまでは至っていない状況です。
今後のサービスレベル管理の改善については、進捗がありましたらまた何らかの形でご紹介したいと思います。
まとめ
Backlog では、サービスの信頼性を向上させるために、SRE を含む組織体制を日々見直してきました。エンジニアが増えるにつれて Dev と Ops の間のコミュニケーションが難しくなりますが、SRE をマトリックス的に配置することで、そのような問題に対処してきました。
また、このように組織体制を見直すなかで、サービスの信頼性を評価するための SLI についても、SRE だけで評価する方法から、SRE と開発者が密に連携して評価する方法へと改善してきました。
Backlog は日々お客様が増えていることもあり、たびたび応答速度が悪化するなどの問題を発生させてしまい、お客様には大変ご迷惑をおかけしております。しかし、サービスの改善に向けて日々試行錯誤を続けております。今後も是非ご期待いただければと思います。
ヌーラボでは、ヌーラボの提供するサービスやシングルサインオンアカウント、社内システムの開発に興味があるエンジニアを募集しています。職種問わず、話を聞いてみたい人は是非こちらからご応募ください。
