こんにちは。開発本部 CTO 室で Platform Engineer をしている i2tsuki です。
MIXI では月に 1 回 SRE 共有会という場を開いていて、SRE に取り組むエンジニア同士でゆるっと情報交換をしています。ポストモーテムから、ちょっとした相談、TIPS、やってよかったことまで。テーマは毎回幅広めです。
SRE 共有会は取り組みを始めてから 3 年目に入りました。今回から新しい試みとして、共有会での内容を技術ブログとして発信していきます。この記事はその第 1 回です。
今月のトピック
SRE × AI
昨年から継続的に AI を SRE の取り組みにどう活かすかを持ち寄って話しています。今回の回では、いわゆる SRE Agent を作る/自動化したい という方向のアイデアが多めでした。
一方で、「いきなり万能エージェントを目指すより、作業を部品化して SKILL(スキル) として整理していくほうが現実的では？」といった話も出ました。
AI に任せる/任せないという二択よりも、AI と繋げやすい形に、人間側の手順を整備する こと自体が運用改善になるという考え方にまとまりました。
インシデント対応を SKILL 化する
インシデント対応まわりは、SKILL 化の効果が出やすそうな領域として話題になりました。
- 障害発生時の調査を半自動化する
- よく使うコマンドやスクリプトを コマンド化 して Runbook に落とす
- 初動の観点をテンプレ化して、属人性を下げる
ポイントは再利用できる形でまとめることです。初動の品質を揃えやすくなって、対応スピードも上げられそうという期待がありました。各サービスで小さく始めていけると良さそうです。
常駐 Agent から、ローカルで呼び出す支援ツールへ
これまではどこかのランタイム上で常駐して動くエージェントが流行っている印象でしたが、今後は Claude Code のように 作業者がローカル環境から必要に応じて呼び出す スタイルが主流になっていくかもという意見も出ました。
スキル化 の延長として、MCP サーバーを用意し、作業者のローカルと連携してオペレーションを自動化する構想も挙がっています。運用手順を整えたうえで実行の部分だけ安全に自動化するのは、現実的な第一歩になりそうです。
DB 高負荷時に processlist / data_lock_waits を その瞬間 取りたい
DB が高負荷になったとき、processlist や performance_schema.data_lock_waits など (実行中クエリやロック待ち) を その瞬間 の状態として押さえたい場面があります。
ただし、都度手作業で取りに行く運用だと取り逃しやすいですし、常時取り続けるのもコストやノイズの観点で難しい、という悩みがあります。
社内の例として、cron 的に 1 時間に 1 回取得しているサービスがあります。定点観測としては安定しますが、スパイク的に負荷が上がった瞬間は取り切れないこともあります。
そこでアラートを起点に、自動で processlist や関連ログを採取する仕組みを挟めないかという方向で議論しました。実装できれば、障害調査の 最初の一手 を自動化でき、初動のスピードと精度を上げられそうです。
AWS の SIP (Security Incident Response)
AWS の SIP (Security Incident Response) も話題になりました。一般的な脆弱性診断に近い話だけでなく、運用体制や手順の整備まで含めてカバーするメニューになっていて、一部サービスで試した共有がありました。
メッセージキュー監視 (Resque / Redis) ：件数だけでなく "遅延" を見たい
Resque を使ったメッセージキュー監視の相談もありました。Resque は Redis をメッセージキューとして利用します。
現状は「キューに溜まったメッセージ数」を監視し、閾値を超えたらアラート、という形です。一方で メッセージの新しさ (遅延) を監視できておらず、どれだけ遅延して処理されているかがわからないため、対応の優先度付けに使える指標がない、という課題がありました。
MIXI では Google Cloud Pub/Sub や Amazon Kinesis Data Streams のように遅延時間をメトリクスとして扱いやすい基盤も使われていますが、Resque だと同等の指標が手に入りにくいのが悩みどころです。実装案としては次のような案が集まりました。
- メッセージ投入時刻をメッセージ本体に含める
- コンシューマーが処理時刻との差分から遅延時間を計算する
- 遅延時間をメトリクスとして報告し、SLO/アラートに繋げる
今後、メッセージキューを実装したシステムにおいて、オブザーバビリティを実践する際のノウハウとなりました。
気になっているイベント・読み物
SRE Magazine 011 号が発刊されました
クラウドネイティブ会議
2026 年 5 月 14・15 日開催の共有がありました。CloudNative Days / Platform Engineering Kaigi / SRE Kaigi の合同開催とのことで、CFP 提出を目指して参加を検討しているメンバーもいます!
宣伝：SRE Kaigi 2026
明日は SRE Kaigi 2026 があります。弊社からは多羽田が下記タイトルで登壇します。ぜひご聴講ください。
IaaS/SaaS 管理における SRE の実践
また、プラチナスポンサーとして参加しております。ブースにもお立ち寄りいただけると嬉しいです。当日は MIXI の SRE メンバーも数名参加予定なので、会場でお会いできることを楽しみにしています!
このシリーズでは、社内で出た話題を「社外でも再現できる形」に整えて発信していく予定です。次回もお楽しみに。
Discussion