こんにちは、SRE チームマネージャーの Yamaguchi（@yamaguchi_tk ）です。

概要

今回は対応期限があるインフラ、セキュリティ領域の課題を、自動で JIRA にまとめたら運用が最高になった話をします。

前提

Gunosy では主に AWS を利用しています。 AWS では定期的にメンテナンスや、必須パッチの適用によるサービス・インスタンスの再起動や、冗長系の切り替えが発生します。また、利用しているマネージドサービスのサポート終了も定期的に発生します。

これらについては、AWS からは事前にメールで通知されるようになっていますし、EventBridge による Slack 通知も簡単に行えます。

また、 SRE チームは Snyk を使用した脆弱性スキャンの結果をトリアージし、その結果を基にインフラ課題を JIRA に起票してプロダクトチームへ対応を依頼しています。

SRE チームの課題感

AWS のメンテナンス情報についての課題

メンテナンス情報から発生する作業を事前にスケジューリングできていなかったため、以下のように予定外の緊急作業が発生していました。

AWS リソースの強制再起動が発生するメンテナンス情報を拾えていなかったことが原因でオンコールが発生した
夜間に DirectConnect の冗長系で切り替えが発生したので、翌朝調査してみたら先週メンテナンス通知があった
明後日発生するスケジュール変更ができない AWS リソースの強制再起動あるのに気づいたので、急いで夜間作業の調整をして対応した

Snyk の脆弱性情報のトリアージについての課題

SRE チームの負担が大きくなりすぎて、作業領域を拡大したりトリアージする範囲を広げたりができない状態でした。

実施した内容

自動で JIRA のチケットを起票する仕組みを、AWS のメンテナンス情報と Snyk の脆弱性情報のそれぞれで構築しました。

AWS のメンテナンス情報

AWS の HealthEvent を Datadog の HealthEvent Integration で取り込み、それを Datadog の Monitor で抽出し、閾値を超えたら JIRA Integration で JIRA にチケット起票をするだけです。

Snyk の脆弱性情報

Snyk の機能の JIRA Integration で脆弱性指摘単位の JIRA 起票はできるのですが、それだと細かすぎるので GAS で Snyk の ReportAPI を叩いて、ECR 単位、GitHub リポジトリ単位で JIRA チケットを起票するようにしました。

ECR 単位、GitHub リポジトリ単位で JIRA チケットを起票する理由

コンテナ化しているアプリケーションの場合、脆弱性指摘の大部分がコンテナの BaseImage が古いことによる指摘でした。そのため、BaseImage を最新版に更新するだけで大部分の脆弱性指摘が解消されますし、脆弱性単位のチケット管理だとチケットの数が多すぎて JIRA ボードの視認性が悪くなり、作業効率にも影響がでてきます。

加えて、Snyk の脆弱性指摘のトリアージを以下のような基準でおこなっているため、コンテナ単位・アプリケーション単位で対応の優先度を決めたい、プロダクトチームに対応を優先して欲しいという事情もあります。

	Critical + 攻撃コードが Mature	それ以外(Critical)
Internet-facing	できるだけ早く対応	四半期を目処に対応
Internal	1 ヶ月以内を目処に対応	任意のタイミングで対応

インフラ課題 JIRA の設定

プロダクトチーム単位にカンバンボードを作成し、以下のようなスイムレーンを設定しています。

名前	用途	起票の自動化
最優先	期限が短いとか最優先で対応して欲しい時用（現在未使用）
Alert	WARN, ERROR に対する対応して欲しいチケット
Security k8s	EKS に対するセキュリティ指摘対応チケット
Security AWS	AWS のリソース、設定に対するセキュリティ指摘対応チケット
Security Snyk 優先度 1（次のスプリント）	Internet-facing かつ Critical + 攻撃コードが Mature	⭕️
Security Snyk 優先度 2（1 ヶ月以内）	Internal かつ Critical + 攻撃コードが Mature	⭕️
Security Snyk 優先度 3（四半期）	Internet-facing かつそれ以外(Critical)	⭕️
Security Snyk 優先度 4（任意）	Internal かつそれ以外(Critical)	⭕️
Maintenance	AWS のメンテナンス情報	⭕️（RI 以外）

以下のタイミングで JIRA の自動化設定でプロダクトチームの Slack 部屋に通知しています。

課題が作成された
担当チームが変わった
- 同じ AWS アカウントに違うチームのリソースが存在している関係で、チケットの担当チームを変更したり、チケットをチームごとのリソースで分割したりする場合に発生します
期限の 2 週間前
- 通知時にラベルを付与することで何度も通知されないようにしています
期限の 5 日前
- 通知時にラベルを付与することで何度も通知されないようにしています

インフラ課題 JIRA の運用フロー

インフラ課題 JIRA そのものの状態繊維は以下のようになっています。

プロダクトチームのインフラ課題 JIRA の運用作業

プロダクトチームのインフラ課題 JIRA の運用作業は以下のようになります。

起票されたチケットおよび担当 Team が変更されたチケットが、開発チームの Slack 部屋に通知されるので、チケットを確認
1. 対象リソース、期限等の情報（AWS のメンテナンス情報は期限が本文に入っているので自動でチケットに入力できない）をチケット記載、ステータスを ToDo に変更
2. 対応不要なものはステータスを完了に変更
対応が必要なものはタスクチケット起票して、インフラ課題 JIRA チケットに関連付け
1. チケットを関連付けすると自動でステータスが Assined に変更される
2. 対応不要なものは、その理由をコメントに記載し手動でステータスを Cancelled に変更
自チームの対象ではないチケットは、担当 Team を変更
1. よくわからない場合や迷う場合はプロダクトまたがりでバックエンドエンジニアが集まる会議で相談
2. 自チーム以外のリソースが含まれている場合は、チケットを Clone して、担当チーム、対象リソースを変更
ふりかえりの場や定期的に Assined、Cancelled のチケットを確認し、完了したものは状態を Done に変更
ふりかえりの場で、様子見となったチケットの状態を Waiting に変更

SRE チームのインフラ課題 JIRA の運用作業

なし

解決できた課題

解決できた課題は以下の内容です。

AWS のメンテナンス情報の拾い漏れがなくなった
AWS のメンテナンス情報の期限管理ができるようになった
SRE チームのトリアージで発生していた Toil 作業がなくなった

が、一番大きい収穫はプロダクトチームごとの JIRA のカンバンを見るだけでメンテナンス系の作業漏れが無くなるという状態を作れたことです。

解決できなかった課題

AWS のメンテナンス情報で通知される期日は、手動で JIRA に入力する必要がある
AWS のメンテナンス情報で通知されるタイトルに upcoming と付いているものは基本的に再通知なのですが、期限が極端に短いものは最初の通知が upcoming で通知されるものがあり、重複した通知内容を単純に除外できない