> For the complete documentation index, see [llms.txt](https://docs-embed.anyflow.jp/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs-embed.anyflow.jp/policy/incident-response.md).

# 障害時の対応

### 監視体制

Anyflow Embedでは、サービスの安定稼働のために以下の監視を常時実施しています。

#### 監視の種類

* **メトリクス監視**: 各サーバーのCPU・メモリ・ディスク等のリソース使用状況を継続的に監視
* **ログ監視**: アプリケーションおよびインフラのログを収集・分析し、異常パターンを検知
* **外形監視**: エンドユーザー視点でのサービス到達性・応答性を定期的に確認

監視情報は長くとも 2分以内の間隔で収集されており、異常を速やかに検知できる体制を整えています。

#### ステータスページ

サービスの稼働状況は、ステータスページにてリアルタイムに公開しています。

👉 [Anyflow Embed ステータスページ](https://anyflow-embed.statuspage.io/)

Anyflowシステムの障害情報は5分ごとに更新されており、ステータスページの「SUBSCRIBE TO UPDATES」からメールまたはSlackでの障害状況に関する通知を受け取ることも可能です。

### 障害検知時の対応プロセス

#### Anyflowのシステム障害

障害が検知された場合、以下のプロセスで対応を行います。

1. **検知・初動対応**: 監視アラートにより異常を自動検知し、内部運用チームへ速やかに通知
2. **影響調査・復旧**: 障害の影響範囲を特定し、復旧作業を実施
3. **顧客への通知**: 2と並行して影響のあるベンダー様へ、障害の発生状況・影響範囲・復旧見込みをご連絡
4. **事後報告**: 復旧後、原因と再発防止策をまとめてご報告

障害通知プロセスはインシデント対応フローとして社内で定義・運用されています。

#### 連携先のシステム障害

Anyflowのシステムではなく、連携先のシステムで障害が発生した場合、一部のソリューションでエラーが発生することがあります。

連携先の障害を検知後、該当のベンダー様にAnyflow CSが個別にご連絡します。

### 復旧体制

* **バックアップ**: 日次でフルバックアップを取得し、複数世代を保持しています
* **高負荷時の対応**: サーバーのオートスケーリングにより、負荷増大時にも安定した処理性能を維持します

サービスレベル（稼働率目標等）の詳細は [サービスレベル／稼働率](https://docs-embed.anyflow.jp/policy/service-level) をご参照ください。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs-embed.anyflow.jp/policy/incident-response.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.