- はじめに
- SREチームの課題
- 課題改善の取り組み
- Step 1: 対応リクエストのワークフロー化とタスクのDB化
- Step 2: ダッシュボード作成による対応リクエストの集計と可視化
- Step 3: 自動化・セルフサービス化推進による対応リクエスト数の削減
- 今後の展望
- まとめ
この記事はenechain Advent Calendar 2024の16日目の記事です。
はじめに
こんにちは！enechainでSREチームのマネージャーを務める杉田 (@sug1san) です。
enechainのSREチームは、プロダクトの信頼性向上をミッションとしています。
しかし、歴史的な経緯から、SREチームは日々様々なチームからの多様な対応リクエストを受けており、これがSREチーム、そして依頼するチームの双方にとって業務上のボトルネックになっていました。
今回は、この課題を改善するための最初のステップとして取り組んだリクエスト対応の管理改善・状況可視化と、その次のステップとして現在取り組み始めている自動化、セルフサービス化推進によるリクエスト対応削減の取り組みについてご紹介します。
SREチームの課題
enechainでは今年、SRE、Platform Engineering、セキュリティと広範な領域の責務を担ってきたSREチームの体制見直しを行い、ミッションの再定義とそれに基づくチーム分割を行いました。
その背景や狙いについては、CTOである須藤 (@sutochin26) の記事をご参照ください。
この分割に伴い、新生SREチームでは、「Team Topology」におけるイネイブリングチームとして、プロダクト開発チームへのコラボレーション・ファシリテーションを通じたすべてのプロダクトの信頼性向上にフォーカスしていくことになりました。
しかし、enechainでは当初SREチームが中央集権的にクラウドインフラを管理してきた歴史的経緯があり、各種ツールのアカウント作成や権限付与、新規プロダクト立ち上げ時の環境構築や設定等、様々な場面でSREチームへの対応リクエストが必要 (権限的にも、スキルやナレッジ的にも) な状況となっていました。
これによって、特にセキュリティやガバナンスの面で得られていたメリットがあった一方で、以下のような課題がありました。
- SREチームの対応待ちが発生し、プロダクト開発のボトルネックになることがあった
- 日々アドホックに発生するリクエスト対応に追われた結果、計画的にSREチーム本来のミッション推進に取り組んでいくことが困難だった
1については、組織の拡大やプロダクト数の増加によって、直近課題がより顕著になってきています。2については、他チームのOKRの達成がSREチームの対応に依存する状況も発生しており、SREチームとして設定しているOKRもある中で、日々の全体最適でのタスク優先度判断にコストが割かれてしまっていました。
課題改善の取り組み
課題解消のためには、セキュリティやガバナンスとのバランスを取りながらも、権限的、そしてスキル・ナレッジ的にSREチームに依頼しなければならないタスクの数を減らしていく必要があります。そのために、次の3つのステップで改善に取り組みました。
- Step 1: 対応リクエストのワークフロー化とタスクのDB化
- Step 2: ダッシュボード作成による対応リクエストの集計と可視化
- Step 3: 自動化・セルフサービス化推進によるリクエスト対応数の削減
ここからは、各ステップについて、詳しく説明していきます。
Step 1: 対応リクエストのワークフロー化とタスクのDB化
まずは課題に対する暫定対応として、足元の対応リクエストを適切に管理できるようにする必要がありました。そこで、次の2つの取り組みを行いました。
ワークフロー導入によるリクエストチャネルの統一
SREチームへのリクエストチャネルが明確に定まっておらず、依頼者が迷ったり、依頼の見落としが発生していました。また、特定のメンバーにDMで依頼が来ることもあり、状況把握が困難になっていました。
そこで、バラバラだったチャネルをSlackのワークフロー経由に1本化しました。
ワークフローで使用する依頼フォームの項目は以下の通りです。
このフォームを送信すると、その内容が専用チャンネル内にポストされるとともに、SREチームメンバーにメンションが飛ぶようになっています。
期待される効果は以下です。
- 依頼者がどこでリクエストすべきか迷うことがなくなる
- リクエストの見落としがなくなる
- リクエストが一箇所に集約され、可視化される
- リクエストのフォーマットが定型化され、管理しやすくなる
ワークフローの利用はすでに浸透しており、上述の効果が現れています。
リクエスト対応タスクのデータベース管理
受けているリクエストの数が多い場合や、対応が数日にまたがる場合等、タスクのステータス把握が困難でした。また、Slackだけでタスクを管理する場合、どんどん情報が流れていってしまい、過去のリクエスト対応の記録を貴重なデータとしてストックすることが出来ていませんでした。
そこで、Slackのワークフローで対応リクエストを受け付けた際、同時にその内容がNotionのデータベースにタスクとして登録されるようにしました。
ワークフローとNotionの連携は、Google Spreadsheetを経由してGAS (Google Apps Script) からNotion APIを利用することで実現しています。
ワークフローのアクションから直接Notionのページ作成自体は行えるものの、2024年12月時点ではデータベースへのページ追加がサポートされていないため、この方法を採用しています。
データベースに追加されたタスクは、SREチームのデイリーMTGで毎日確認し、ステータスの確認や対応の相談を行っています。
期待される効果は以下です。
- 対応中のすべてのリクエスト対応タスクの状況が一覧化され、ステータスが把握できるようになる
- 対応を完了したものも含め、すべてのリクエスト対応の記録がデータとしてストックされる
Step 2: ダッシュボード作成による対応リクエストの集計と可視化
Step 1で足元のリクエスト対応を適切にハンドリングできるようになると同時に、過去から現在に至るすべてのリクエスト対応タスクがデータベースで管理されている状態になりました。
次に、本来取り組みたい対応リクエスト数の削減に着手する上で、手探りでむやみに取り組むのでなく、データに基づいて適切な意思決定を行える状態を整える必要がありました。
そこで、そのための仕組みとして、Notionのチャート機能を用いたリクエスト対応タスクのダッシュボードを作成しました。
ダッシュボードに含まれるチャートの一部を紹介します。
リクエスト数の推移
月別の対応リクエスト件数の推移です。
現状多い月では50〜60件近くの対応リクエストが来ていることがわかります。
このチャートを用いて、施策の効果を計測しています。
リクエスト種別の構成比
対応リクエストの内容に基づく種別とその構成比です。
現状種別の定義や仕分けは手動で行っているため精緻なデータではありませんが、対応リクエスト数削減のため取り組む施策を判断する上で重要なデータです。
リクエスト種別の中で、件数が多く、かつトイルが多いと考えられる以下の3つのトイル削減にまずは取り組み、その数を減らしていくことが最も効果的であると考えられます。
- 各種ツールのアクセス権限の付与や変更 (24%)
- 各種ツールや環境の設定 (19%)
- 各種ツールのアカウント追加・削除 (12%)
施策の効果は種別毎のリクエスト数の推移を見ることで測定しています。
希望対応期日の構成比
依頼者に依頼ワークフローで選択してもらっている希望対応期日の構成比です。
希望対応期日が”いますぐ”や”1日以内”と緊急性の高い対応リクエストについてはボトルネックが発生するリスクも高いため、リクエスト種別との掛け合わせで内容を集計し、優先的に改善に取り組んでいきます。
Step 3: 自動化・セルフサービス化推進による対応リクエスト数の削減
Step 2でデータに基づいて取り組むべき施策の優先度を判断し、その効果を計測できる準備が整いました。
現在は、自動化やセルフサービス化の推進によって対応リクエスト数を削減していく段階に入っています。
まずは、合わせると全体の半数弱を占めていたアカウント作成や権限付与に関する依頼について、自動化・セルフサービス化の取り組みを行っています。
これらはTerraformで管理できるようにすることで、コード管理およびプロダクト開発チームのセルフサービス化が可能となるものです。
その中でも最も依頼数の多かったGithubリポジトリのアカウント招待や権限付与についてはすでにTerraformでの管理に移行し、新入社員の入社やチームメンバーの異動等があった際は、プロダクト開発チームのEMが対応できるようになっています。これにより、以前は毎月5件近くあったGitHubのアカウント・権限に関する対応リクエストは現在ほぼ0件となっています。
今後の展望
ここまででご紹介した取り組みの結果、この半期はSLOの導入・運用やオンコールツールの導入・運用を全プロダクトに横展開するための仕組み作りという、本来のSREチームのミッションとOKRに紐づく活動をこれまで以上に前進させることができました。
しかし、まだまだ足元のリクエスト対応、そしてその数を削減するための自動化・セルフサービス化の取り組み共に、課題や改善すべき点が多く残っています。
特に対応リクエスト数削減の施策については、取り組み始めたばかりの状況のため、まずはここからの半年以内に現在の半数以下まで減らすことを目標に、施策の計画と実行を推進していきたいと考えています。
具体的には、PAM (特権アクセス管理) の導入による時限付きアクセス権限制御や、セルフサービス化のためのドキュメントやガイドラインの整備等を進めていきたいと考えています。
まとめ
今回はSREチームがインフラに関する様々なリクエスト対応の数を減らしていくために行った改善活動を3つのステップに分けて紹介しました。
これからもセキュリティ、ガバナンスとバランスを取りつつインフラに関するリクエスト対応の自動化・セルフサービス化を推進し、プロダクトの信頼性によりフォーカスしていけるよう取り組みを続けていきます。
enechainでは、共にSREやPlatform Engineeringに取り組み、enechainのプロダクト開発と事業の基盤を支えてくれる仲間を募集しています。
