Summary
この文書の要点
- Sentryは復旧操作を実行する基盤ではなく、Issue、stack trace、影響ユーザー、release、traceを使って、自動化を開始・継続・停止する判断材料を提供します。
- 数秒で行う緩和と、数十分かかるコード修正を分離し、restart、Feature Flag、既知の正常releaseへのrollbackだけを低リスクな即時経路へ置きます。
- Seerやcoding agentが作る変更はPull Requestに閉じ、既存テストを弱めないCI、カナリア反映、Sentryによる再検証を通過した時だけ段階的に広げます。
- 目標は文字どおりのMTTR 0分ではなく、人の応答待ちをなくし、自動緩和までの時間と人間介入率を継続的に小さくすることです。
NoOpsは運用責任をなくすことではなく、定常時の人手を外すこと
障害対応には、検知、影響判断、一次緩和、原因分析、修正、検証、release、復旧確認という複数の工程があります。通知だけを自動化しても、深夜に担当者が起きてログを読み、再起動やrollbackを選ぶなら、実行ループには人が残っています。
一方、すべての障害をAIへ渡し、生成された修正を即座に本番へ出す設計は、速さと引き換えに権限誤用、誤修正、データ破壊、無限再試行の危険を増やします。NoOpsを安全に目指すには、人が行っていた操作をそのまま消すのではなく、機械が判断できる条件と、人へ移管する条件を先に形式化する必要があります。
本稿でいうNoOpsは、通常の既知障害では自動緩和と検証が完結し、設計変更、データ整合性、認証、未知の失敗だけが証拠付きで人へ届く状態です。運用の所有者、品質基準、停止判断までなくす意味ではありません。
- 自動化の対象: 再現可能で、影響範囲と戻し方を事前に定義できる障害。
- 人へ残す対象: データ破壊、認証・権限、migration、未知の依存障害、複数サービスの契約変更。
- 設計目標: 人間の応答時間をゼロへ近づけつつ、危険な本番変更はfail-closedで止める。
Sentryを起点にする価値は、コードと利用者影響の文脈にある
インフラ監視は、CPU、memory、HTTP応答、processの生存を捉えるのに向いています。しかし、HTTP 200を返しながら一部の操作だけが失敗する障害や、特定release、特定ブラウザ、特定のFeature Flagでだけ起きる不具合は、死活監視だけでは復旧判断につながりません。
SentryのIssueには、error message、stack trace、breadcrumbs、tag、発生回数、影響ユーザー数、最初と最後に観測したreleaseなどを関連付けられます。releaseとcommitを正しく送っていれば、変更との相関やsuspect commitも原因候補の絞り込みに使えます。Feature Flagの評価と変更追跡を設定した環境では、flag変更とerror増加の関連も判断材料になります。
重要なのは、情報が多いことではなく、自動化のpolicyへ変換できることです。productionだけで発生し、直近releaseから急増し、影響ユーザーが閾値を越え、同じstack fingerprintへ収束している場合だけrollback候補にする、といった条件を組めます。逆に、単発の未知errorや複数releaseにまたがる既存障害は、自動変更せず観測だけを続けます。
- stack traceとIssue grouping: 同じ原因と見なせるeventを一つの制御単位へまとめる。
- 発生回数と影響ユーザー: 技術的な頻度だけでなく、利用者への影響を優先順位へ反映する。
- release、commit、Feature Flag: 直前の変更と戻し先を推定する材料にする。
- trace、log、profile: 局所errorの外側にある依存サービスや性能劣化を確認する。
検知、判断、実行、検証を別の責務として分離する
安全な構成では、Sentryからのalertまたはwebhookを、直接restart commandへつなぎません。最初に信頼済みのIntakeが通知を認証し、deliveryを重複排除します。次にSentry APIからliveなIssue、最新event、release、environmentを再取得し、通知payloadだけを権威にしないようにします。
Policy Engineは、issue fingerprint、environment、影響ユーザー、増加率、直近deploy、過去の操作、cooldown、費用上限からAction Planを作ります。Executorは事前登録された操作だけを短命なcredentialで実行し、VerifierはSentryとservice healthを別に観測します。状態、入力digest、操作、結果、使用credentialのscopeはAudit Storeへ残します。
Sentryは観測と原因分析の中心ですが、container、Feature Flag、deploy、rollbackを直接制御する共通基盤ではありません。各platformやflag providerのAPIを呼ぶ制御面が別に必要です。この境界を明示すると、Sentry tokenへ本番変更権限を混ぜずに済みます。
- Intake: webhook認証、再送の重複排除、rate limit、payload保存範囲の制限。
- Enricher / Policy Engine: live情報の再取得、risk分類、許可action、停止条件の決定。
- Executor: restart、flag変更、rollback、修正jobを最小権限で実行。
- Verifier / Audit Store: 観測窓、成功判定、再発検知、操作台帳、通知。
received
-> enriched
-> classified
-> mitigating
-> observing
-> stable
|-> repairing -> ci_verifying -> canary -> observing
|-> rolled_back -> observing
|-> needs_human
|-> circuit_openalertは命令ではなく、再評価を始めるきっかけとして扱う
webhookは少なくとも一回届く前提で扱い、同じdeliveryや同じIssueが短時間に何度届いても副作用を一度しか起こさないようにします。idempotency keyには、organization、project、Issue、environment、release、action type、policy versionを含めます。処理中のchainがあれば新しいchainを作らず、最新eventを既存chainへ追加します。
自動化の入口は単一閾値にしません。たとえば『5分で100件』だけでは、同じ利用者のretryやbot trafficで誤作動します。発生増加率、影響ユーザー、productionか、直近deployとの時間差、errorがunhandledか、既知のrunbookがあるかを組み合わせます。判断に必要なtagが欠ける場合は、危険な操作へ進まずobserveへ落とします。
復旧actionはIssue名から自由生成しません。policy repositoryに、対象service、許可environment、最大回数、事前条件、post-check、rollback action、所有者をversion付きで登録します。AIの役割は候補分類と説明であり、実行可能actionの追加や権限拡張ではありません。
- payloadとlive APIが一致しない場合はstaleとして停止する。
- 同じIssueでもenvironmentとreleaseが違えば、別の影響範囲として評価する。
- runbook未登録、tag不足、影響範囲不明は、自動修復不能という正常な判定にする。
数秒の一次緩和は、元に戻せる既知操作だけに限定する
利用者影響を最短で下げるには、原因を完全に直す前に緩和する経路が必要です。processの一時的不整合が既知ならcontainerの置き換え、特定機能でerrorが急増したならFeature Flagをoff、直近releaseとの相関が強ければ既知の正常releaseへrollbackします。これらはコード修正より速く、事前に手順と戻し方を検証できます。
ただしrestartは、memory leakや下流障害を隠して再発を遅らせるだけの場合があります。Feature Flagは、そのrequestで実際に評価されたflagをSentryへ送っていなければ、推測で切り替えることになります。rollbackも、直前releaseに不可逆なmigrationや外部契約変更があれば安全ではありません。操作の種類より、適用条件と可逆性が重要です。
各actionの後には短い観測窓を置きます。新規event rate、影響ユーザー、service health、queue、主要transactionを確認し、改善しなければ同じ操作を繰り返しません。restartからflag、flagからrollbackへ自動的に昇格する場合も、事前に許可した有限の遷移だけにします。
- restart: statelessで、process置き換えにより回復する既知failureだけ。
- Feature Flag off: error eventに評価結果があり、flag ownerと復帰条件が登録済みの場合だけ。
- rollback: 直近deployとの相関が強く、既知の正常releaseとdata compatibilityを確認できる場合だけ。
- 対象外: 決済、認証、権限、不可逆migration、データ欠損、複数系統の同時障害。
Seerとcoding agentは、即時緩和の後にコード修正を進める
Sentry Seerは、Issue、trace、log、profile、接続したcode repositoryの文脈を使い、root cause、解決案、code changeを作り、Pull Requestまで進められます。自動fixの開始点と停止点を選べるため、actionabilityが高いIssueだけを対象にし、root causeで止める、code changeまで作る、Pull Requestまで開く、とriskに応じて段階を変えられます。
ここでも、Seerやcoding agentが本番branchへ直接pushする構成にはしません。Issue ID、起点release、base commit、許可repository、許可path、最大差分、禁止領域を固定し、生成物をPull Requestへ閉じます。認証、secret、workflow、infrastructure、migration、依存更新、テスト削除は、変更行数が少なくても自動release対象外です。
一次緩和で利用者影響が下がっていれば、修正経路は急いで安全境界を広げる必要がありません。Seerの結果が出るまで計算資源を保持せず、非同期状態を保存し、完了eventでCIへ進めます。原因が外部service、設定、容量、flaky testなら、無理にsource patchを作らずneeds_humanへ移します。
- Seerのactionabilityは対象を絞る材料であり、release許可そのものにはしない。
- AIへ渡すcontextは必要なIssue、trace、release、関連sourceに限定する。
- 生成patchの説明ではなく、許可差分と検証結果を次工程の入力にする。
- Pull Request作成後も、mergeとdeployは独立したpolicyで判定する。
CIは成功数ではなく、既存の品質基準を弱めていないかを見る
自動patchが通るためのCIには、lint、typecheck、Unit Test、対象Integration Test、重要経路のE2E、security scan、buildを含めます。失敗したテストの削除、skip、assertion弱体化、coverage閾値低下、snapshotの無差別更新は、greenに見えても修正とは扱いません。
検証は差分に近い順で段階化します。最初にpatch形式、変更path、credentialらしい文字列、変更規模を静的に検査し、次に対象test、最後にfull quality gateを実行します。途中でbase branchが変わった場合は、古い分析結果を自動rebaseして押し込まず、staleとして新しいCIへ判断を戻します。
CI通過後も全量releaseには進みません。少量trafficのカナリアへ出し、Sentryの新規Issue、event rate、crash-free sessionまたはuser、主要transactionをbaselineと比較します。観測窓を通過した時だけ段階的に広げ、悪化したら同じpipelineでrollbackします。
- 静的gate: path、変更種別、差分規模、secret、テスト回避、base commit。
- CI gate: 既存のlint、typecheck、test、security、buildを変更せず通す。
- release gate: カナリア、観測窓、baseline比較、段階拡大、即時rollback。
- post-release gate: 同じIssueのregressionと別fingerprintの副作用を監視する。
サーキットブレーカーは、無限ループだけでなく誤った成功も止める
完全自動化で最も重要な実装は、成功経路ではなく自己停止です。同じIssueへrestartを繰り返す、rollback後に自動deployが同じreleaseを再投入する、AI patchが新しいerrorを作って別chainを起動する、といった循環は、個別jobの回数制限だけでは見抜けません。
chainには、起点Issue、release系列、実行action、生成commit、派生Issueを関連付けます。同じfailure fingerprint、同じaction、同じrelease、同じ変更pathが閾値へ達したらcircuitをopenにし、cooldown中は本番変更を禁止します。全体kill switchとservice単位のswitchを別に持ち、制御面が不調な時は自動化をobserve-onlyへ戻します。
成功判定にも上限を設けます。error rateが下がってもtraffic自体が落ちた可能性があるため、request volume、主要transaction、queue、business healthの最低条件を併せて確認します。観測データが欠損した場合は成功と推測せず、安定性を判定できない状態として停止します。
- 最大試行回数、最大経過時間、最大費用、同一fingerprint回数をchainに持つ。
- 同じreleaseの再投入、同じpathの反復修正、派生Issueの増加を循環として検知する。
- telemetry欠損、state競合、credential異常、rollback不能ではfail-closedにする。
- global、service、action別のkill switchと、observe-onlyへの退避経路を用意する。
本番変更権限は、観測・判断・検証から切り離す
Sentryのwebhookを受けるIntake、Issueを読むEnricher、policyを評価するController、未信頼codeを実行するCI、Feature Flagやdeployを変更するExecutorは、別identityに分けます。CI中のcodeへ本番変更credentialを渡さず、Executorは対象serviceとactionを限定した短命credentialだけを受け取ります。
log、stack trace、Issue本文、repository内の文書、AI出力はすべて未信頼入力です。そこに書かれた命令でpolicy、許可path、費用上限、credential scopeを変更できないようにします。Sentryへ送る個人情報とsecretも最小化し、AI機能へ渡るdataの設定と保持方針を導入前に確認します。
監査台帳には、誰がではなく、どの自動化versionが、どのeventとlive stateを根拠に、どのpolicyで、どのactionを、どのscopeで実行し、どの指標で成功または停止と判定したかを残します。後から再現できない自動復旧は、速くても運用品質を測れません。
MTTR 0分ではなく、無人緩和までの時間と介入率を測る
障害の検知、action実行、process起動、traffic切り替えには必ず時間がかかるため、文字どおりのMTTR 0分は測定可能な目標になりません。自動化でゼロへ近づけられるのは、担当者が通知に気づいて操作を始めるまでの待ち時間です。そこで、検知から自動緩和開始まで、安定判定まで、恒久修正releaseまでを分けて測ります。
ROIも、オンコール時間を最初からゼロと仮定して計算しません。障害分類ごとの発生件数、手動一次対応時間、自動緩和成功率、誤作動率、人間移管率、再発率、運用基盤の保守時間を観測し、導入前後を比較します。低頻度の小規模serviceでは、複雑な制御面の保守費用が削減時間を上回る場合があります。
NoOpsへ近づいているかは、人が呼ばれなかった件数ではなく、安全境界内で安定復旧し、同じ原因が再発せず、危険な事象だけが十分な証拠とともに人へ届いた割合で判断します。通知を消して見かけ上の無人運用にすることとは異なります。
- 検知時間: event発生からSentry alert受付まで。
- 自動緩和時間: alert受付から利用者影響が基準内へ戻るまで。
- 恒久修正時間: 起点Issueから修正releaseの安定判定まで。
- 品質指標: 自動緩和成功率、誤作動率、人間移管率、再発率、rollback成功率。
- 費用指標: 1 chainあたりの実行費用、AI費用、制御面の保守時間、削減した一次対応時間。
observeから始め、低リスクな一種類の障害だけを自動化する
最初から本番変更まで自動化すると、誤判定がSentryの設定、policy、実行API、検証条件のどこにあるか切り分けられません。まずobserve-onlyで実eventを流し、どのactionが選ばれるか、どの条件で停止するかを記録します。次に人がactionを承認する段階を挟み、実際の判断との差を確認します。
最初の自動実行は、statelessな一serviceのrestartや、影響範囲が限定された一つのFeature Flagなど、戻し方が明確な一種類に絞ります。成功率ではなく、誤作動、再発、telemetry欠損、kill switch、重複delivery、同時障害を試験し、操作回数の上限が働くことを確認します。
その後、既知releaseへのrollback、SeerによるPull Request作成、CIとカナリア、自動releaseの順に責務を追加します。段階ごとにobserveへ戻せることを完了条件にします。自動化率を上げることより、境界外を確実に人へ渡せることが、長期的な無人運用を支えます。
- 段階1: observe-only。判断と停止理由だけを記録する。
- 段階2: 人がactionを承認し、policyとの差分を集める。
- 段階3: 低リスクな一actionを自動化し、post-checkとkill switchを検証する。
- 段階4: rollback、AI Pull Request、CI、カナリアを順番に追加する。
- 段階5: 実績がある障害分類だけ、本番releaseまで無人化する。
自動復旧に向かない障害と、Sentryだけでは埋まらない領域
Sentryはapplication errorとperformanceの文脈に強い一方、network分断、cloud control plane障害、database corruption、DNS、certificate、外部provider全体の停止を単独で完全に判定するものではありません。uptime、infrastructure metrics、queue、database、synthetic transactionなど、別の観測系と照合する必要があります。
また、Feature Flag評価、release、commit、source map、traceが正しく送られていなければ、豊富な文脈は得られません。自動化の精度はAI modelよりinstrumentationの品質に強く依存します。samplingやprivacy設定で欠けるdataも、policy上のunknownとして扱います。
Sentry Seer、Feature Flag関連機能、API、連携先の提供条件や仕様は変わり得ます。利用plan、対応repository、data region、権限、AI data handlingを導入時の公式情報で確認し、experimentalなAPI payloadを長期契約として固定しない設計が必要です。
NoOpsの中心は、AIではなく安全に止まる制御面にある
Sentryを起点にすると、単なる死活監視よりも、どのcode pathで、どのreleaseから、何人へ、どの条件で影響が出たかを使って自動復旧を判断できます。Seerは、その実行時文脈を原因分析とPull Requestへつなぐ役割を担えます。
ただし、完全自動オートヒールを成立させるのは、SentryやAIだけではありません。即時緩和と恒久修正の分離、許可action、冪等な状態機械、最小権限、既存品質を弱めないCI、カナリア、観測窓、サーキットブレーカーを一つの制御面として設計する必要があります。
目指すべき状態は、エンジニアを運用から消すことではなく、再現可能な一次対応を機械へ移し、人を設計、品質基準、未知の障害、再発防止へ集中させることです。NoOpsは担当者ゼロの宣言ではなく、人の判断を必要な例外へ絞るための継続的な設計です。
Sentry公式情報で機能と提供条件を確認する
この記事では、Sentryが公開している製品ドキュメント、APIドキュメント、changelogを基に機能範囲を整理しています。SeerやFeature Flag、APIの仕様と提供条件は変わるため、実装時点の公式情報を確認してください。
