はじめに

こんにちは。ﾃｸﾉﾛｼﾞｰ本部ﾌﾟﾛﾀﾞｸﾄ開発部 SREのkoizumiです。最近、すっかり暑くなってしまいましたね。

さて、今回はAWS Security HubやSnykで検知された脆弱性の課題項目や、AWS Healthで通知されるメンテナンス情報の管理方法ならびにその自動化について取り上げます。弊社では、週一でプロダクトチームとのふりかえり会というものを開催しており、SLO達成状況やアラート発生状況、セキュリティ指摘項目がないかなどの確認を行っています。以前までは、議題に上がったアラートやSLI/SLOの対応はスプレッドシートで管理をしていました。

tech.gunosy.io

具体的には、以下のようなインフラ面における課題項目（以降、インフラ課題）をスプレッドシートで管理していました。

AWSメンテナンス情報（ハードウェアメンテナンス、必須パッチ、EOL等）
頻発しているDatadogアラート、重篤なDatadogアラート
Security Hub、Snyk、kubebenchで指摘されたセキュリティ項目

この度、弊社ではこれらの項目をJiraボードでチケット管理するように移行しました。今回はその移行に至った背景、方法、移行して得たメリットについて取り上げていきます。

これまでのインフラ課題の管理方法およびその課題点

これまで、以下の図のようにインフラ課題を管理していました。

以上のようなこれまでの管理方法には、SREチームと開発チームにとって、以下のような様々な課題点がありました。

手間がかかる
- SREチーム
  - ふりかえり資料への記載とスプレッドシートへの転記が必要
  - ふりかえり時にそれぞれのスプレッドシートを確認し、必要であれば更新する必要があった
- 開発チーム
  - 対応チケットを起票して、スプレッドシートに転記する必要があった
伝達漏れがある
- SREチーム
  - AWSのメンテナンス情報（H/Wメンテナンス情報など）の連絡が漏れやすい
    - メールから通知情報を拾っている人力運用が原因
    - もっと以前（2021年）は再起動系のメンテナンスイベントは拾っていなかった
- 開発チーム
  - 起票した指摘の対応を、別チームに依頼する場合に起票漏れや伝達漏れが発生しやすい
対応項目および対応状況の確認
- SREチーム
  - ふりかえりを実施していないチームへの指摘の完了確認が難しい
  - 開発チームの対応状況が一目見てわかりづらい
- 開発チーム
  - 自チームが対象で、今すぐ対応すべき項目かがわかりづらい
  - 自チームの対応状況（残タスクなど）が一目見てわかりづらい
期限管理が難しい
- SREチーム
  - メンテナンス対応（再起動、EoL等）の期限管理が難しい
  - AWSのH/Wメンテナンス情報等の連絡が遅れてしまう
    - スプレッドシート管理、Slackでのアナウンスが人力なため、期限直近での連絡となってしまうことがある

それぞれのチームの要件

以上の様々な課題を解決していくにあたって、開発チームとSREチームにおける要件をまとめました。

SREチーム
- メンテナンス情報、セキュリティ対応、アラート対応をまとめて管理できるようにしたい
- 対応すべき項目について自動でタスクが切られるようにしたい
- 開発チームに対応がMustな情報を届けたい
- 開発チーム側のタスクチケットの対応状況が追いやすい
- チームごとの情報が管理しやすい
開発チーム
- 期限が迫っている情報を知りたい
- 対応がMustな情報を知りたい
  - 概要や詳細、対象リソース、Suggestがわかる
- 自チームが対象の情報を知りたい

現在の管理方法

これらのそれぞれのチームの課題と要件を踏まえて、インフラ課題をJIRAチケットで管理するようにしました。現在の管理方法を図にすると、以下のようになります。

それぞれのポイントについて、説明していきたいと思います。

AWS Health Eventを用いたJIRAチケットの自動起票

これまで管理に手間がかかっていた課題点については、以下のように改善しました。

インフラ系の課題をまとめて管理するインフラ課題JIRAボードを作成
- 色々なスプシをメンテしなくてよくなった
AWS Health Event（AWSメンテナンス情報）をDatadogに流し、Monitorで検知し、インフラ課題JIRAにチケットを自動で起票する
- DatadogのJIRA Integration設定を行い、Issue Template（自動起票するチケットのテンプレート）を作成する

Slack通知の自動化

これまで伝達漏れが発生してしまっていた課題については、以下のようにSlackで自動通知がなされるように改善しました。

JIRAチケットで担当チームを明示する
担当チームが割り振られた際に対象Slack部屋に通知
別チームに対応を依頼する場合は、担当チームフィールドの変更またはインフラ課題のチケットをCloneする
- 担当チームが変更になった際も、そのチームの対象Slack部屋に通知がいく

JIRAチケットの関連付け

以前のスプレッドシート管理では、それぞれの開発チームでの対応状況を把握することが難しかった課題がありました。現在は以下のように、JIRAチケットの関連付け機能を用いて、現在の開発チーム側の対応状況を確認しやすくしています。

開発チームにはタスクJIRAを切った際に、プロダクトチーム側のタスクJIRAとインフラ課題JIRAとの関連付けをしてもらう
- 進捗状況はプロダクトチーム側のタスクJIRAに記載されているため、関連付けされているチケットの対応状況がインフラ課題チケットからわかる

JIRAチケットでの期限管理

スプレッドシートの使用方法上、一目見て期限がわかりづらかった点に課題がありました。また、複数のスプレッドシートを管理していたことから期限管理も難しかったです。現在は以下のように、それぞれのインフラ課題をひとつのJIRAボードで管理することで期限管理がしやすくなりました。

インフラ課題チケットのフィールドに期限を追加
JIRAボード上から期限を確認可能
期限が迫っているものを抽出可能

現在の運用フロー

以上を踏まえて、現在の運用フローは以下の図のようになっています。

図だけだとわかりづらいかと思うので、現在のそれぞれのチームでの作業内容の詳細を説明します。

SREの作業

SRE側の作業内容は以下の通りです。

インフラ課題のチケットが起票されたらSRE部屋に通知されるので、SREがトリアージ
- 対象リソース、期限等の情報をチケット記載、担当Teamを設定し、ステータスをToDoに変更
- 対応不要なものはステータスをキャンセルまたは完了に変更
週１で開発チームと開催しているふりかえり会の場や定期的にAssigned、Cancelledのチケットを確認し、完了したものは状態をDoneに変更
- インフラ課題JIRAチケットをベースにして期限や対応状況（タスクチケット発行有無とその状態、対応予定の有無、問題点）を確認します。

開発チームの作業

開発チーム側の作業内容は以下の通りです。

ToDoになったチケットや担当Teamが変更されたチケットが、開発チームのSlack部屋に通知されるので、チケットを確認
- チーム別のボードでフィルタリングして確認が可能
対応が必要なものはタスクチケット起票して、インフラ課題JIRAチケットに関連付け
- チケットを関連付けすると自動でステータスがAssignedに変更される
- 対応不要なものは、その理由をコメントに記載し手動でステータスをCancelledに変更
  - 例）「devなので、手動でのリブートは行わず、勝手にリブートされるのを待つ」等
自チームの対象ではないチケットは、担当Teamを変更
- よくわからない場合や迷う場合はSREに変更
自チーム以外のリソースが含まれている場合は、チケットをCloneして、担当チーム、対象リソースを変更

移行してみて感じたメリット

この管理方法に移行して、これまでの作業が大幅に効率化された実感がありました。具体的には以下のようなメリットがありました。

H/Wメンテナンス情報やEoL情報も自動でチケット起票がされることで、早期の対応が可能になった
日常的な課題管理のしやすさ
- SREチームでの朝会で、期限が近いものをJIRAボードを見ながら確認できる

現在は、RIの期限情報などもJIRAチケットで管理するようにしています。

今後の課題

AWSのメンテナンス情報については、JIRAチケットの自動起票を実現できましたが、Security HubやSnykで検知されたセキュリティ項目は手動でチケットを作成しています。課題項目をひとつのJIRAボードにまとめられたので、管理はしやすくなったものの、SREが一定手動でトリアージを行う必要があります。また、セキュリティ項目はリソースごとに検知されることが多いため、その検知項目をそのままJIRAチケットにしてしまうと、検知されているリソース数分だけチケットが自動起票されてしまいます。対応する側としては、チケットが大量に積まれてしまうと、どれから手をつけていいかわからず、形骸化につながりかねません。

そのため、現在はSREでセキュリティ項目のトリアージを行い、まとめて対応ができるものについてはひとつのチケットにまとめるように対応しています。

以上のような課題はありますが、セキュリティ項目のトリアージからJIRAチケットの起票までも自動化できれば、さらに運用管理がしやすくなると思います。そのためには、現在のトリアージやチケットの作成作業の型化を行うことにより、自動化を実現できればと考えています。