持続可能なDevOpsへ

はじめに

https://zenn.dev/dely_jp/articles/9082f13c0ee8cf

上記のポストでクラシルリワードでSREチーム立ち上げるまでの経緯や体制の変遷についてご紹介しました。

今回は続編として、
「適切なレベルの信頼性の担保と持続可能なシステム運用を組織でどう実現していくか」という観点から実施している施策をご紹介します。

それぞれの施策がどのような背景で生まれ、どんな効果があったかや今後の展望についても触れながら解説していきます。

これまでのシステム運用における課題

これまでのシステム運用においては、大きく以下のような課題がありました。

機能開発と比べたシステム運用への動機の低さ

• 組織文化として「最速で機能をリリースすること」が重視されており、システム運用に取り組んでも成果として評価されづらい
• システム運用の重要性や必要性が十分に認識されておらず、運用負荷が高まってもそれを課題として捉える意識が薄く、改善に向けた動きが生まれにくい・文化的に動けない

属人化と燃え尽きの問題

• システム運用に関わるタスクが一部のメンバーに集中し、過度な負荷がかかることで燃え尽きる
• システム運用の経験やノウハウ・スキルがチーム内で共有・継承されず、組織全体としてのシステム運用スキルが底上げされない

システム全体の複雑性の増加

• サービスの拡張に伴って複数のシステムが連携して動作する構成となり、システム全体の運用が複雑化してきた
• システムによっては専任チームが存在しないため、責任の所在が曖昧で当事者意識が薄くなり対応が後手に回る

これらの課題を踏まえ、SREチームではいくつかの施策に取り組んでいます。

現在取り組んでいる施策の紹介

システム運用における評価基準の整備・運用

背景と目的

システム運用は、サービスの安定性や信頼性を支える重要な活動です。しかし、その貢献は開発のように目に見える成果として評価されにくく、どうしても「目立ちにくい貢献」として埋もれてしまいがちです。

このような課題を踏まえ、運用に関する取り組みが適切に評価されるように明文化された評価基準の整備を進めました。加えて、メンバーごとのスキルやドメイン知識の差異を考慮しながら段階的にチーム全体の運用スキルを底上げしてチームでフルサイクルエンジニアリングが実践できるような体制を目指しています。

取り組み

• 運用スキルを段階（Tier）ごとに定義し、それぞれに必要な知識・スキル・行動を明文化
• Tierに応じて、本番環境の権限を段階的に付与できるようにロールを設計・整備
• CTOやEMと合意形成を行い、人事評価や目標設定に反映

以下が各Tierの具体的な内容です。

Tier 1: 運用サポート（Operational Support）
- ドメインやアーキテクチャなど、システムの基礎知識を理解し、システム運用に協力する。
- 障害発生時には、アラートや障害の発生を速やかに認識し、必要な情報を関係者へ共有・エスカレーションする。

【巻き込み・合意形成】
ドメイン・アーキテクチャを理解するため、関係者と連携して必要な情報を吸収する機会を自ら創出し、業務遂行に必要なコミュニケーションを図る。

【課題解決・付加価値創出】
ドメイン・アーキテクチャを理解し、同様にサポートを受けながらシステム運用に協力する。

【自己成長】
担当業務を通じてドメイン・アーキテクチャを理解し、システム運用プロセスを担える人材となることを実現する。

*上位Tierへ移行する条件
Tier2が担う役割を理解し、一次対応（ログやメトリクスの調査・確認、影響範囲の確認、情報整理）を自ら行えるようになる

Tier 2: 運用実践（Operational Execution）
- システム運用を理解し、サポートを受けながら担当する課題を解決する。
- 障害発生時には、ログやメトリクスの調査、影響範囲の確認、必要情報の整理を通じて、初動対応を実施し、必要に応じてエスカレーションを行う。

【巻き込み・合意形成】
システムを継続的に運用可能な状態へ移行・維持するための活動を十分に理解・実践できるよう、業務遂行に必要なコミュニケーションを自ら図る。
また、障害発生時には一次対応を正確に実施し、上位Tierや関係者へ適切に共有・エスカレーションする。

【課題解決・付加価値創出】
システムの継続的運用状態への移行・維持活動を理解・実践し、上位Tierと協働しながら担当業務を遂行する。

【自己成長・人材育成】
担当業務を通じてシステムの継続的運用状態への移行・維持活動を担える人材となることを実現する。

*上位Tierへ移行する条件
Tier3が担う役割を理解し、正確な一次対応（ログやメトリクスの調査・確認、影響範囲の確認、情報整理）およびシステムの継続的運用状態への移行・維持活動を、Tier3と同程度に遂行できるようになる。

Tier 3: 運用自走（Operational Autonomy）
- 本番環境のシステムを変更できる権限をもつ
- システム運用上の課題に対し、効率的な解決策を策定して改善を自走して実行する。
- 障害発生時には、正確な原因調査を行い、適切かつ迅速な復旧対応を実施する。

【巻き込み・合意形成】
障害対応およびシステムの継続的運用状態への移行・維持活動をサポートし、関係者およびTier4と合意形成を図る。

【課題解決・付加価値創出】
障害対応およびシステムの継続的運用状態への移行・維持活動を理解し、解決策を策定・実施することで、担当システムにおける障害時間の短縮およびシステム信頼性が定められた基準を達成する。

【人材育成】
Tier1およびTier2に対して、システムの継続的運用状態への移行・維持活動やプロセスを共有し、システム運用に関する知見を提供・サポートする。

*上位Tierへ移行する条件
Tier4が担う役割を理解し、システムの継続的運用状態への移行・維持活動やプロセスを主導することができるようになる

Tier 4: 運用管理（Operational Management）
- 本番環境のシステムを変更できる権限をもつ
- システムの運用状況を継続的に把握し、課題を分析した上で改善計画を策定・推進する。
- 障害発生時において、リーダーシップを発揮し、適切な意思決定と正確な原因調査、適切かつ迅速な復旧対応を実施する。

【巻き込み・合意形成】
障害対応およびシステムの継続的運用状態への移行・維持活動を推進し、関係者と合意形成を図る。

【課題解決・付加価値創出】
障害対応およびシステムの継続的運用状態への移行・維持活動を理解し、解決策を策定・実施することで、複数のシステムにおける障害時間の短縮およびシステム信頼性が定められた基準を達成する。

【人材育成】
組織全体として、システムの継続的運用状態への移行・維持活動やプロセスを他メンバーに共有し、オンボーディングを実施するとともに、システム運用に関する知見を提供・サポートする。

今後の展望
本取り組みはまだ運用を開始したばかりであり、目立った成果はこれからですが、以下のような初期効果が見られています。

• 評価基準の明文化によって、メンバーが「どのようにシステム運用に関与すればよいか」を明確に意識できるようになった。
• 評価・目標設定に連動させることで、システム運用への主体的な関与が促されつつある。

今後は実際の運用を通じて改善を重ね、より実効性のある仕組みへと進化させていく予定です。

機能開発メンバーのDevOps/SREローテーション

背景と目的
システム運用における属人化は、長期的な信頼性の維持を困難にします。
特にシステム運用に関しては関与するメンバーが限られており、ノウハウの蓄積や共有が進みにくいという課題がありました。

そこで、機能開発に携わるメンバーにもDevOpsやSREの考え方を体験的に学んでもらう取り組みとして、DevOps/SREローテーション制度を導入しました。

この施策には、以下のような目的があります。

• システム運用への関与機会を提供し、ノウハウを共有する
• SREチームに依存せず、機能開発メンバー自身が信頼性を意識した開発を実践できるようにする
• 属人化を防ぎ、持続的に運用可能な体制・文化を作る
• インフラや障害対応など、普段の開発では得られにくい経験を提供し、視座を高める
• システム全体の構成を俯瞰的に理解し、より良い設計や改善提案ができるようにする

運用方法
ローテーションは6ヶ月を1サイクルとし、対象となる機能開発メンバーがSREチームの一員として以下のようなタスクに取り組みます。

• AuroraやElastiCacheなどのミドルウェアのEOL対応・メンテナンス
• 障害発生時の ログ調査・一次対応・復旧・恒久対応
• 新規サービスのインフラ構築
• トイル削減を目的とした自動化や改善施策の実施

SREメンバーのサポートを受けつつも機能開発メンバー自身が主体となって実務を担うことで、実践的にスキルと知識を獲得できるようにしています。

導入後の変化と課題

• これまでSREに依存していた AuroraやElastiCacheのEOL対応・メンテナンスを機能開発メンバーが実施できるようになった
• 実際の運用タスク・障害対応に関わる中で、「インフラやシステムへの理解が深まった」との声が聞かれた
• SREメンバーのサポートを受けながら、新規サービスのインフラ構築を行うまでに成長した

Production Readiness Check（PRC）の策定と運用

背景と目的

本番環境で安定したサービス運用を継続して実現するためには、設計段階から非機能要件を意識し適切に備えておくことが重要です。しかし、以下のような課題がありました。

• システム設計時に考慮すべき要件が明文化されておらず、チームや実装者によって認識が異なる状態だった
• 適切なレベルの信頼性が明確でないため、基準がわからない
• 本番運用が始まると非機能要件の改修や改善が後回しになりやすい

こうした背景から、主に非機能要件における基準を明文化 し、システムの信頼性を継続的に確認・改善する仕組みとして Production Readiness Check（PRC） を策定・運用し始めました。

取り組み

• 本番運用に必要な観点・非機能要件をリストとして明文化
• PRCは6ヶ月に1回のペースでSRE主導のもと実施
• 各システムの担当者と連携し、運用状況の棚卸しと改善点の抽出を行う
• 抽出した改善点にはSREが優先度を設定し、次回チェックまでに対応が完了するように進捗を管理しサポートする

PRCには以下のような観点を含めています

• バックアップとリストア（定期的なバックアップの取得とリストア手順の整備）
• キャパシティ管理（リソース使用状況の把握とスケーリング戦略の明確化）
• 監視とアラート（システム全体に対する監視・アラートの整備や管理）
• 障害対策・インシデント対応（RunBookの整備、振り返りと再発防止策の運用）
• セキュリティ（最小権限設計・脆弱性管理・秘密情報の適切な取り扱い）

今後の展望
こちらもまだ運用を開始したばかりであり、目立った成果はこれからですが以下のような初期効果が得られました。

• PRCを策定したことでこれまでに認知していなかった運用上の考慮しなければならない事象が把握できた
• 信頼性に関して守るべき基準を整備でき、計画的に足りない部分の改善を進められる仕組みや体制が整った

一方でチェックが大変だったり、共通化・自動化できる部分が多く実施にあたっての負担感があると感じているので今後も改善を重ねていく予定です。

今後取り組むこと・目指していく理想像

今回紹介した施策はいずれも、現時点での課題に対する有効なアプローチでしたが、理想とする持続可能な運用体制の実現にはまだ道半ばです。今後は以下の3つの方向性を軸に、さらなる改善と仕組み化を進めていきます。

システム運用のサイクルを自然に回せる文化の醸成

制度や仕組みを整えるだけでなく、それを日常的に回し続けられる文化の醸成が不可欠です。
特定のメンバーだけが運用改善を担うのではなく、チーム全体として「信頼性もプロダクトの一つの機能」という意識を持てるように振り返りや仕組みの継続的見直しを行っていきます。

共通化・再利用性の向上

サービスごとに分断されがちだったシステム構築・運用の仕組みを可能な限り横断的に設計・共通化し、再利用性の高い方法を模索していきます。
これにより、新しいサービス追加時の立ち上げコストや運用負担を抑えつつ、チーム全体の生産性を底上げできると考えています。

属人化しないためのナレッジとプロセス整備

属人化は長期的にシステム運用の持続性を大きく阻害する要因だと考えています。
対応プロセスやノウハウの文書化・仕組み化を継続的に行い、誰が対応しても一定のクオリティを担保できる体制づくりを目指します。

さいごに

システム運用は、SREチームだけが担うべき活動ではなく、組織全体で取り組むべき重要な活動です。今回の取り組みを通じて、機能開発を行うメンバーにも積極的に運用に関与してもらうことの意義と必要性を改めて実感しました。
そのためには、会社組織全体に対して「なぜシステム運用が重要なのか」を伝え、システム運用の価値や必要性を理解してもらうための継続的な働きかけが欠かせません。
運用に関わるメンバーが増えることで負荷の分散だけでなく、より多角的で健全な運用体制が築けると考えています。
それが結果として持続可能なDevOpsへつながると信じています。