|
1 | 1 | --- |
2 | 2 | title: Complete Your First AI SRE Investigation in 15 Minutes |
3 | | -description: Start with a real incident and get your first AI SRE investigation — grounded in context, backed by evidence, and open to follow-up questions — then build team knowledge and connect real data sources as needed. |
4 | | -keywords: ["AI SRE", "Quickstart", "incident investigation", "/init", "knowledge base", "MCP", "BYOC Runner"] |
| 3 | +description: Start with a real incident and get your first AI SRE investigation — grounded in context, backed by evidence, and open to follow-up questions — then get every new incident analyzed automatically, build team knowledge, and deploy a BYOC Runner to reach real data sources. |
| 4 | +keywords: ["AI SRE", "Quickstart", "incident investigation", "automatic incident analysis", "/init", "knowledge base", "MCP", "BYOC Runner"] |
5 | 5 | sidebarTitle: Quick Start |
6 | 6 | --- |
7 | 7 |
|
@@ -34,7 +34,7 @@ For actively investigating an issue, digging deeper, or building up knowledge. G |
34 | 34 |
|
35 | 35 | ### Automations |
36 | 36 |
|
37 | | -For work that shouldn't need a human watching it — scheduled inspections, weekly insight reports, alert-noise cleanup. Go to **AI SRE → Automations** and create one from a built-in template (Alert Noise Analysis, Incident Response Review, Weekly On-call Insights, and more) or build one from scratch. Each run happens in a hidden session in the background, and the result lands in the run history where you can open the full trail any time. → See [Automations](/en/ai-sre/automations) |
| 37 | +For work that shouldn't need a human watching it — scheduled inspections, weekly insight reports, alert-noise cleanup. Go to **AI SRE → Automations** and create one from a built-in template (On-call Incident Analysis, Alert Governance, Weekly Insights, and more) or build one from scratch. Each run happens in a hidden session in the background, and the result lands in the run history where you can open the full trail any time. → See [Automations](/en/ai-sre/automations) |
38 | 38 |
|
39 | 39 | ### IM (@ Mentions + Automatic War Room Diagnosis) |
40 | 40 |
|
@@ -82,15 +82,40 @@ If you don't have an incident on hand right now, skip ahead to "Growing It Into |
82 | 82 |
|
83 | 83 | --- |
84 | 84 |
|
85 | | -Your first investigation is just the starting point. How well AI SRE diagnoses depends on how much it knows about your systems and how much real data it can reach — both are things you build up over time, not all at once. |
| 85 | +Your first investigation is just the starting point. From here you can make analysis automatic, and keep sharpening its diagnoses — the latter depends on how much it knows about your systems and how much real data it can reach. All of this builds up over time, not all at once. |
| 86 | + |
| 87 | +### Get every new incident analyzed automatically |
| 88 | + |
| 89 | +Once manual investigations feel routine, make them the default: go to **AI SRE → Automations**, create a rule from the built-in **On-call Incident Analysis** template, enable the **On-call incident** trigger card, and pick the channels and severities to watch. From then on, every matching new incident gets an automatic investigation, and AI SRE writes one summary comment back to the incident — conclusion first, full session link at the end — delivered through the incident's existing notification channels, so responders see the first analysis right in IM. Configuration details: [Automations · On-call Incident Trigger](/en/ai-sre/automations#on-call-incident-trigger). |
| 90 | + |
| 91 | +This is independent of war room auto-diagnosis: this path fires for every matching new incident and writes back to the incident itself; war room diagnosis runs when you open a war room for an incident and posts into the war room group (see [IM](/en/ai-sre/im)). |
86 | 92 |
|
87 | 93 | ### Build a team knowledge base |
88 | 94 |
|
89 | 95 | If the agent has to guess "what service is this," "who owns it," and "how was this handled last time" on every investigation, it won't get much sharper. Type `/init` in a session and the agent interviews you to map out your services, runbooks, on-call routing, and more — confirming each write before it saves anything, and loading it automatically in future sessions. See the full interview flow in [Setup (/init)](/en/ai-sre/init) and the knowledge base structure and best practices in [Knowledge](/en/ai-sre/knowledge). |
90 | 96 |
|
91 | 97 | ### Connect real data sources |
92 | 98 |
|
93 | | -By default the agent only sees Flashduty's own data. To let it query your actual systems — logs, metrics, code repositories, internal databases — connect an MCP server or deploy a BYOC Runner. Publicly reachable services (observability platforms, GitHub, and similar) install and authorize in one click from the MCP directory; VPCs, internal databases, or local commands need a Runner deployed on a machine that can reach them. See [MCP](/en/ai-sre/mcp) and [Environments](/en/ai-sre/environments). |
| 99 | +By default the agent only sees Flashduty's own data. To let it query your actual systems — logs, metrics, code repositories, internal databases — connect an MCP server or deploy a BYOC Runner. Publicly reachable services (observability platforms, GitHub, and similar) install and authorize in one click from the MCP directory — see [MCP](/en/ai-sre/mcp); VPCs, internal databases, or local commands need a Runner deployed on a machine that can reach them — about three minutes, below. |
| 100 | + |
| 101 | +### Deploy a BYOC Runner (~3 minutes) |
| 102 | + |
| 103 | +<Steps> |
| 104 | + <Step title="Create a self-hosted Environment"> |
| 105 | + Go to **AI SRE → Environments** and click **Create** on the **Self-hosted** tab. The name is optional (the first heartbeat fills it in with the machine's hostname); pick account or team scope. |
| 106 | + </Step> |
| 107 | + <Step title="Run the install command on the target machine"> |
| 108 | + After creation, the **setup guide** opens with install commands that already include your Token — a Linux one-liner (needs sudo; registers a systemd service), plus Docker and macOS variants. Copy it onto a machine that can reach your target resources and run it. |
| 109 | + </Step> |
| 110 | + <Step title="Wait for the status to flip to Online"> |
| 111 | + Back in the list, the status goes from **Pending** to **Online** once connected. Heartbeats are evaluated on a ~90-second cycle, so give it a moment after installing; if it stays Pending, the machine almost certainly can't reach the connect URL shown in the guide (outbound traffic blocked by a firewall). |
| 112 | + </Step> |
| 113 | + <Step title="Use it in a session"> |
| 114 | + When starting a new chat, the environment picker at the bottom of the composer defaults to **Auto** — it prefers an online Runner when one is available; you can also select this self-hosted Environment explicitly. Note that the environment locks once the session starts and cannot be changed afterwards. |
| 115 | + </Step> |
| 116 | +</Steps> |
| 117 | + |
| 118 | +Permission rules (limiting what the agent may do on that machine), upgrades, and uninstallation: see [Environments](/en/ai-sre/environments). |
94 | 119 |
|
95 | 120 | ## What's Next |
96 | 121 |
|
|
0 commit comments