Yandex Tech has detailed an OpenSRE integration that lets AI-based SRE agents investigate incidents using Yandex Cloud data without modifying infrastructure. The September 10 publication is a technical case study rather than a same-day launch: the first integration-tools pull request entered OpenSRE’s main branch on August 18, followed by inclusion in releases v0.1.2026.8.19 and v0.1.2026.8.27.
OpenSRE is described as an open tool for building agents that work inside infrastructure to investigate production incidents. Its proposed roles include explaining how an environment is organized, suggesting hypotheses during an investigation and performing initial triage after an alert. The project remains in public alpha, however, and its maintainers do not guarantee safe operation. Yandex Tech advises using an account without roles that can modify infrastructure.
The integration covers managed databases, allowing an agent to retrieve cluster health, host roles, operation history and database logs. Nine additional tools span metrics, Cloud Logging, Compute Cloud and health checks for network and application load balancers. A generic reader can search an index and call 951 approved read endpoints across 69 services. Access is limited to GET requests and an allowlist of paths.
Four authentication modes are available, including a virtual machine’s metadata service. Models can connect to Yandex AI Studio through OpenSRE’s standard OpenAI-compatible provider. The integration author lists Managed Service for Kubernetes, serverless services, auditing and an onboarding wizard as planned work rather than currently available capabilities.
For its test scenario, Yandex Tech used a Kubernetes application connected to Managed Service for PostgreSQL and forced a database master failover. The application could still read data but could not write because its ConfigMap pointed to the former master, which had become a replica. OpenSRE correlated Kubernetes resources, PostgreSQL host roles and database logs, where it found an error stating that an INSERT could not run in a read-only transaction.
The author ran nine measurements: three each with qwen3-235b-a22b-fp8, gpt-oss-120b and deepseek-v4-flash. Session context was cleared and memory disabled before every run, and the models received no advance explanation of the project’s structure or resources. In the published results, deepseek-v4-flash produced the correct solution on its first attempt in all three runs.
Practical context: The integration’s practical value is its ability to bring Kubernetes and cloud-service telemetry into one investigation while withholding infrastructure-changing permissions. Read-only access does not eliminate diagnostic risk: the author says ambiguous tool responses sometimes led models to confident but incorrect conclusions. At this public-alpha stage, the evidence therefore supports treating OpenSRE as an engineering assistant rather than an autonomous incident-remediation system.
| Model | Average time | Result across three runs |
|---|---|---|
| qwen3-235b-a22b-fp8 | 4 minutes 15 seconds | Two solutions were correct; one run identified the correct read-write and read-only sFQDNs |
| gpt-oss-120b | 3 minutes 52 seconds | All three runs succeeded; none proposed the sFQDN solution |
| deepseek-v4-flash | 2 minutes 30 seconds | All three runs produced the correct solution on the first attempt |
OpenSRE security limitations
OpenSRE is in public alpha, and its maintainers do not guarantee safe operation. Yandex Tech advises users to review the permissions carefully and not assign infrastructure-modifying roles to the account running OpenSRE.
Sources
Event date: 2026-09-10. Primary source date: 2026-09-10.
