はじめに
こんにちは！スタイル・エッジでSREチームのPjMを担当しているpeipeiです。
私たちSREチームは、サービス全体の信頼性を向上させるべく、SRE文化の浸透やそれを支える仕組みづくりに日々取り組んでいます。
前回の記事では、AWS Security Hubの導入によるセキュリティ対策の標準化についてご紹介しました。今回は、「SREが初動からシステム障害対応に参加することで、何が変わりはじめたのか」をテーマに、私たちの取り組みと、そこから得られた学びについてお話しします。
システム障害対応はSREにとっても避けては通れない重要なテーマです。
信頼性の担保は、開発チームだけでなくSRE自身も責任を持って関わるべきだと考えています。実際、SREのバイブルとも言われる『SREをはじめよう』でも「SREも消火活動に参加すべき」と明記されており、こうした姿勢がSREに求められていることがわかります。
SREとしてシステム障害対応において感じていた課題
システム障害が起こると、クライアントへのご迷惑や機会損失に直結するのはもちろん、開発メンバーが一生懸命に築き上げてきたプロダクトの信頼も損なわれてしまいます。
こうしたリスクに向き合うために、SREとして以下の方針で取り組むことを決めました。
- システム障害発生時にSREが初動から関与し、復旧スピードを最大化させる
- 現場でシステム障害の現象を正確に把握し、再発防止策の精度を高める
- 他プロダクトにも波及するシステム障害に対し、ナレッジ展開の旗振り役を担う
本記事では、主に①の初動対応の部分について詳しく掘り下げます。②と③については、別記事でご紹介する予定です。
初動対応：SREが“駆けつける体制”へ
従来、システム障害発生時の対応はリスク委員会（社内のインシデントコーディネーター的役割を担う独立したチーム）が中心となって行っていました。SREは報告を受ける立場に留まるのではなく、現場の一次対応に関与できるようにすべく、体制を以下のように見直しました。
変更前のフロー
変更後のフロー：
この変更により、SREが初動から現場に立ち会い、復旧対応を開発メンバーと並走できる体制が整いました。
システム障害対応：SREとして“共に戦う”
SREはそのプロダクトに関するすべてのドメイン知識を持っているわけではありません。アプリケーションやビジネスロジックにおいては、開発チームの方が深い理解を持っていることが多いです。それでもSREは、冷静に状況を整理し、対応の抜け漏れやリスクを見つけ出す視点を現場に持ち込むことができます。
システム障害対応に臨む際、私たちはまず「状況の正確な把握」から始めます。システム障害が発生したという連絡を受けて集合した後は、エラーの種類やシステムメトリクスを確認し、現象を整理・理解することを優先します。
特に運用フェーズにおけるシステム障害では、直近のリリースが影響しているケースが多いため、開発チームと共にリリース履歴の確認やロールバックの要否検討も迅速に行います。
こうした状況整理において役立っているのが、あらかじめ作成しておいたFigJamのテンプレートです。システム障害の復旧対応は、時間的なプレッシャーや情報の不確実さ、心理的な焦りなどが重なり、どうしても慌ただしくなりがちです。その結果、対応漏れが発生したり、何を優先すべきか分からなくなってしまうこともあります。そのため、落ち着いて復旧対応を進めるためのガイドとしてテンプレートを用意しています。
テンプレートは、時系列で対応内容を記録できるように工夫しており、システム障害の振り返りやナレッジ蓄積にも活用しています。日々の運用を通じて、このテンプレートも少しずつ最適化を重ねています。
今期のシステム障害対応で、SREとして行った実際の作業としては次のようなものがあります。
- DB負荷の増大に伴うサーバーリソースの即時増強
- メモリ枯渇によるサーバー再起動と復旧確認
- 緊急時における切り戻し手順のレビュー
- ソースコードの確認による問題の特定と一時的な回避策の提案
私自身、開発者時代にシステム障害対応で冷静さを失ってしまった経験があります。その経験を経た今、SREという立場では、感情に流されることなく状況を整理し、冷静に判断を下すことが求められていると感じています。
また、SREには、俯瞰的な視点から状況を捉えるだけでなく、自ら手を動かし、現場の一員としてチームと並走する姿勢も求められます。
開発チームと同じ目線に立ち、同じ船に乗る仲間として、“共に復旧を目指す”ことを大切にしています。
システム障害対応から見えてきた組織の課題
SREがシステム障害の初動から関与することで、組織全体として抱える課題にも気づくことができました。
たとえば、以下のような点です。
- 非機能要件（パフォーマンス・可用性など）の検証不足
- メトリクスやログの可視化基盤の不十分さによる原因特定の遅延
- デプロイツールの知識や運用ルールの開発メンバーへの浸透不足
- 特定メンバーへの依存が大きい運用プロセス
これらの気づきは、SREとして今後取り組むべき重要な組織課題として蓄積されており、今後の取り組みの優先順位を見極めるうえでも、貴重な判断材料となっています。
もちろん、すべてのシステム障害にSREが関与することは簡単ではありません。
実際、運用を始めた当初は「この体制で本当にやっていけるのか？」という不安もありました。
それでも現場に足を運び、自分の目で見て、耳で聞いて、肌で感じた課題や気づきは、何にも代えがたい価値があると実感しています。その経験こそが、次の改善に向けた行動を後押しし、SREとしての意思決定と取り組みに確かな軸を与えてくれています。
おわりに
本記事では、SREがシステム障害対応にどのように関与しているのか、特に“初動対応”における取り組みを中心にご紹介しました。
SREがシステム障害対応に主体的に関与することで、復旧のスピードや品質だけでなく、そこから得られる学びの深さも大きく向上すると感じています。単なる「システム障害対応」にとどまらず、組織全体にとっての貴重な資産へと昇華できる取り組みにしていくことが、私たちの目指す姿です。
実際に現在は、「ポストモーテム文化の導入」や「再発防止策の横展開」など、システム障害から得た知見を組織に定着させるための仕組みづくりも進行中です。これらの取り組みについても、次回以降の記事で詳しくお伝えできればと思います。
連載予定
| 投稿日 | タイトル |
|---|---|
| 6月 | SREとしてはお休みzzz... |
| 7月 | ポストモーテム文化の醸成 |
| 8月 | システム障害の再発防止策横展開フロー |
※内容や更新予定日は変更になる可能性があります。
連載を通じて、SREチームのチャレンジや日々の気づきを発信していきます。
「SREって何から始めればいいの？」と悩む方や、自社の運用課題に向き合っている方の参考になれば嬉しいです。
一緒に働く仲間を募集しています！
スタイル・エッジでは、SRE文化の構築に向けてともに挑戦していただける仲間を募集中です。
ご興味をお持ちいただけた方は、ぜひ採用サイトもご覧ください！
recruit.styleedge.co.jp
