見出し画像

Product SREs for Backlogの日常的なタスクの取り組みを紹介- プロダクトバックログの改善や生成AIなど幅広くチャレンジ -

Tsuyoshi Yamasaki

はじめに

Product SREs for Backlogチームの山崎です。このブログでは、Backlog SREの選考プロセスで実施するカジュアル面談において頂くご質問のうち、「一日のスケジュール」や「タスクへの取り組み」などについて私やチームの例を紹介します。

あわせてこちらの記事も参考にしていただければと思います。

一日の流れ

私は福岡本社に所属し自宅も福岡県内ですが、自宅からオフィスまで徒歩と電車で1時間30分ほどかかるためフルリモートで勤務しています。東京オフィスに勤務していたころと通勤時間は変わらないのですが、福岡だと割と遠い印象です。
リモートワークのおかげで往復にかかる時間を家事や勉強に充てられるので、とても有意義に過ごせています。そのぶん、運動不足が気になりますが...

私のエンジニア経歴や海のそばでの暮らしなどについては、こちらのブログをご覧ください。

ヌーラボにはコアタイム無しのフルフレックス制度があるため、私は基本的な勤務時間を10:00 ~ 19:00としています。
 
10:00 ~ 10:30
Backlogや監視システムからの通知を確認することから一日が始まります。他に、チームメンバーからのコードレビュー依頼や、AWSリソースを利用するためのIAMポリシーの更新申請の対応などを行います。

10:30 ~ 11:00
チームメンバーとのスタンドアップミーティングに参加します。月曜日から木曜日のこの時間帯に短いミーティングを行い、タスクの進捗状況の確認や、今日の動き、困りごとの相談などを行います。
スタンドアップミーティングは、Cacooで描いたボードに共有事項やタスク内容を記入したカードを並べて行います(図1)。Cacooは共同編集が行えるので、それぞれ画面を開きカードを動かしたり追加したりしながらミーティングを進めます。
カードはBacklogの課題やボードにリンクしているので、Backlog上で詳細を確認できるようになっています。

図1: Cacooで作成したスタンドアップミーティング用ボードを一部抜粋

金曜日はスタンドアップミーティングはなく、チームメンバーがそれぞれ改善タスクやプロジェクト外のタスクに取り組める日として確保されています。もちろん、プロジェクトのタスクに集中することもできます。

11:00 ~ 12:30
担当するプロジェクトのタスクに取り組みます。

12:30 ~ 13:30
猫たちといっしょにランチタイム。

猫たちのランチタイム
人見知りの激しい子は椅子の下に隠れてランチ
猫たちのランチタイム
互いのご飯をつまみ食いするので、しばらく見守ります

13:30 ~ 19:00
引き続き、担当するプロジェクトのタスクに取り組みます。日常的な運用業務や他のチームからの相談にも対応します。私が参加するミーティングの多くは14:00~16:00に設定されており、この時間帯で部内の週次ミーティングやAWS TAM(テクニカルアカウントマネージャー)との定例会などに参加します。

また、夜間メンテナンス(22:00 ~ 24:00)を担当する場合は、18:00頃から21:30頃まで休憩し体力を温存します。

障害対応や急を要するものがない限り残業はありません。時間を忘れてついつい勤務時間が超過することもありますが、その場合は別日で時間調整をします。

チームメンバーで取り組んでいること

Product SREs for Backlogチームでは主に以下の項目に取り組んでいます。

  • サービスにおいて信頼性を損なう可能性のある問題をプロダクトバックログとして整理する。期中に対応するものをプロジェクト化し、改善サイクルに従って年間計画のなかで改善・解決する。

  • トイルの削減。手作業で繰り返し行われ、属人化しそうな作業の自動化あるいは半自動化。

  • 日常的な運用作業。AWSのコンピューターリソースの調整や、外部要因により発生するアラートログやメールサーバのレピュテーションのチェック、AWSのコスト最適化など。

これらの取り組みについて、いくつか例を挙げてみます。

プロダクトバックログの整理と改善

プロダクトバックログには、”開発チームと協業するもの”、”ISMSやJ-SOXなど管理部門と協業するもの”、”SREで立案し改善まで進めるもの”など様々な課題が積まれます。プロジェクト規模も様々で、数ヶ月から年単位でかかるものも珍しくありません。代表的なものは、以下のプロジェクトが挙げられます。

  • EOLにともなうEC2インスタンスのAmazon Linux 2移行

  • Aurora MySQLのマイナーバージョンあるいはメジャーバージョンのアップグレード

  • メール配信サーバーの信頼性向上(SPF, DKIM, DMARC対応)

  • 内部統制の改善のため、開発チームごとに割り当てるAWSポリシーの細分化や運用体制の構築

このようなプロジェクトは、開発チームと協力しながら立案から完了まで数ヶ月かけて取り組みます。SREチームでは、以下の図2にある改善ループを定義しプロダクトバックログの改善に取り組んでいます。

図2: プロダクトバックログの改善ループ

前述のプロダクトバックログの例のひとつ、”メール配信サーバーの信頼性向上”は2022年4月ごろに開始したプロジェクトです。様々な課題をチームで解決しながら2023年5月ごろSPF, DKIM, DMARCの運用を開始しました。2023年10月にGoogleが公表した メール送信者のガイドライン は大きな話題となりましたが、Backlogではすでに対応を終えていたため大きな混乱はありませんでした。

トイルの削減

運用作業のなかには、実施頻度が年に数回程度しかないため自動化されず手作業で対応しているものもありました。その一つがAWSのリザーブドインスタンス(以下、RI)の購入です。BacklogではRIを購入する機会を年に3回設けています。従来は以下のような作業を実施していました。(レビュープロセスの記載は省略しています)

  1. 稼働するインスタンス(EC2, Aurora, OpenSearch, Elasticache)のインスタンスタイプや稼働数と有効なRIをスクリプトで収集

  2. 集計結果をスプレッドシートに切り貼りし、過不足を手動で修正

  3. リザーブドインスタンスの購入を行う複数のコマンドをAWS CLIで都度作成

  4. リザーブドインスタンスの購入予約や購入を実施

手順書に従ってスクリプトやスプレッドシートを使っているものの、手順書の内容は古く、RIの種類や数の調整など様々な判断が特定のメンバーの経験に依存する状況でした。プロダクトの成長とともに必要なリザーブドインスタンスのタイプや数が変化するため、集計やレビューにかかる負担の増加や誤購入による損失も課題となりました。そのため、いちど立ち止まって改善に取り組みました。
その結果、現在では以下のように変化しています。

  1. RIの購入時期に手順の見直しを行い、最新の状況に応じて手順書やスクリプトを更新する。資材はGitで管理

  2. インスタンス情報、有効なRI数と期日、購入コマンドに必要なOffering IDなどをスクリプトで収集

  3. スプレッドシートに収集結果を入れ、RIの過不足数、RIの期限、購入要否の判定、購入コマンドなどをまとめて出力。結果の修正が必要であれば、 手動修正は行わず2.に戻ってスクリプトを修正

  4. 機械的に出力した購入コマンドでRIの予約や購入を実施

いままでの手順書には表れなかった「担当者の経験に基づく判断や手順」を言語化し手順書に反映したことで、特定のメンバーに依存していた作業がなくなりました。特に、集計を行うスプレッドシートは大幅に改良され、購入月と有効期限をもとに必要な情報が計算されるようになりました。その結果、人の判断は「プロジェクト計画にもとづいた購入数の調整」のみとなり、大幅な負担軽減へと繋がりました。

日常的な運用

日常的な運用には、Backlogの安定稼働や信頼性維持・向上を支える作業が多数存在します。ここでは2つの例を挙げます。

  • EBSの拡張・増設、性能調整

  • メール配信サーバの信頼性を監視

EBS拡張・増設、性能調整

Backlogでは様々な機能を提供しています。そのなかでも、「課題」や「Wiki」でのファイル添付」、「ファイル」、「Subversion」や「Git」に欠かせないEBSについて取り上げます。

Product SREs for Backlogチームでは、日々増加するデータ量やディスクアクセスに対して一定の閾値を設けてEBSの拡張や増設、性能調整を行っています。

EBSの拡張や増設に対応する運用作業においては、大きなディスクサイズを確保しておけば作業頻度を下げることができ作業コストの削減に繋がります。しかし、EBSは確保したサイズに対する費用が発生するため、必要以上のサイズを確保するとEBS費用が増加します。
一方、ぎりぎりのサイズを確保するとEBS費用は抑えられるものの運用作業の頻度が上がり作業コストが増加します。EBS費用は運用費用の中で大きな割合を占めるため、EBS費用と作業頻度のバランスを意識しながら運用を行います。
また、EBSにはボリュームあたりのサイズが最大16TB(ボリュームタイプがgp3の場合)という制約があります。こちらも一定の閾値を設け、上限に達する前にEBSの増設を行い容量を確保します。

もう一つの運用作業が性能調整です。定常的にIOPSやThroughput性能が不足する場合や過剰な性能値となっている場合に性能調整を行います。これはあまり頻繁に行うものではありませんが、重要な項目として監視しています。
EBSの運用は地味ですが、障害や作業ミスがデータロストに繋がりかねないため慎重な判断と作業が求められます。

メール配信サーバの信頼性を監視

Backlogユーザーには課題の更新通知やコメントのお知らせなどをメールで受信したり、サマリーメールをもとに進捗管理を行っているユーザーが多くいらっしゃいます。そのため、Backlogから配信したメールが届かなかったり、企業のセキュリティシステムでブロックされたり、迷惑メールと誤判定されたりするとユーザーの業務に大きな影響を与えることになります。

そこで、Product SREs for Backlogチームでは外部サービスを利用したメール配信サーバの信頼性監視を行っています。ブロックリストサービスなどに登録されていないか、あるいは誤ってスパム送信者と判定されていないかを監視し、必要に応じてブロックリストからの除外申請や送信間隔の調整などを行います。外部サービスだけでは判定できないパターンもあるため、併せてメール配信ログの監視も行います。メールが配信先サーバーにブロックされたことを検知すると、監視システムがアラートを発報する仕組みです。

メールがユーザーに届かない原因は、ブロックリストやスパム誤判定だけではありません。Backlogに登録されているメールアドレスが誤っていたり、退職や組織改編などでメールアドレスが無効になっているケースもあります。恒久的に届かない宛先に配信し続けることはメール配信サーバの信頼性低下につながります。そのような場合は、Backlogサポートチームと連携し、ご契約者様への連絡と対処依頼を行います。
このように、日々数十万件のメールを安定して配信するために、Product SREs for Backlogチームでは様々な監視と調整を行っています。

メインのプロジェクト以外で取り組んでいること

Product SREs for Backlogチームでは「50%ルール」を設けて業務に取り組んでいます。50%ルールとは、年間計画の中でプロジェクトに使う時間は50%に制限し、抱えているトイルの削減や、割り込みの対応に時間を使えるようにするというものです。前述のトイルの削減や、突発的な依頼にもしっかり対応できるようこのようなルールを設けています。私はこの50%ルールを利用し、生成AIチームとともにBacklogサポートチームをサポートするAIチャットボットの試作に取り組んでいます(図3)。

カスタマーサポート分野は生成AIが最も威力を発揮する分野ともいわれており、生成AIの導入によりカスタマーサポートの質・生産性・満足度が向上するそうです。(今井翔太, 2024年,『生成AIで世界はこう変る』,SBクリエイティブ,P121)

そこで、サポートチームがBacklog ヘルプセンターから目的のページを探したり回答文を検討する際に「ベテランでも経験の浅いメンバーでも負担なくお問い合わせに対応できれば」と考え、AIチャットボットを試作してみました。

まずは社内で活用できるものを生み出し、ゆくゆくは製品に反映できるような知見を生成AIチームや開発者とともに蓄積できればと考えています。
※このチャットボットは社内向けの試作であり、製品開発を前提としたものではありません。

図3: ヘルプチャットボットが質問に回答する様子

おわりに

このブログでは、”一日のスケジュール”や”タスクへの取り組み”などについて私やチームの例を紹介しました。Product SREs for Backlogチームは、BacklogのSREとしての取り組みに注力しながらプロジェクト外の取り組みにも時間を割くことができます。
国内外170万人のユーザーが利用するBacklogの開発や運用改善に興味を持たれた方は、ぜひ下記リンクからお問い合わせください。


この記事が気に入ったらサポートをしてみませんか？