Uso de Gemini y RAG para Diagnosticar y Resolver Incidentes en DevOps (Vertex AI)

from google import genai
from google.genai import types as genai_types


PROJECT_ID = "my-production-project"
LOCATION = "us-central1"
MODEL = "gemini-2.5-pro"

RAG_CORPUS = (
    f"projects/{PROJECT_ID}/locations/{LOCATION}"
    "/ragCorpora/my-sre-knowledge"
)


def build_rag_tool() -> genai_types.Tool:
    """
    Recupera conocimiento operativo:
    runbooks, postmortems, ADRs y documentación.
    """
    return genai_types.Tool(
        retrieval=genai_types.Retrieval(
            vertex_rag_store=genai_types.VertexRagStore(
                rag_resources=[
                    genai_types.VertexRagStoreRagResource(
                        rag_corpus=RAG_CORPUS
                    )
                ],
                rag_retrieval_config=genai_types.RagRetrievalConfig(
                    top_k=8,
                    filter=genai_types.RagRetrievalConfigFilter(
                        vector_distance_threshold=0.5
                    ),
                ),
            )
        )
    )


def diagnose_incident(
    incident: str,
    evidence: str,
) -> str:

    client = genai.Client(
        enterprise=True,
        project=PROJECT_ID,
        location=LOCATION,
    )

    prompt = f"""
You are a senior SRE incident analyst.

Your job is to reason only from the supplied incident
and retrieved operational knowledge.

INCIDENT:
{incident}

CURRENT EVIDENCE:
{evidence}

Return:

1. Most likely hypothesis
2. Supporting evidence
3. Contradicting evidence
4. Confidence from 0 to 1
5. Additional evidence required
6. Safe next investigation steps
7. Whether human approval is required

Never invent metrics, logs, deployments or system state.
If evidence is insufficient, explicitly say so.
"""

    response = client.models.generate_content(
        model=MODEL,
        contents=prompt,
        config=genai_types.GenerateContentConfig(
            tools=[build_rag_tool()],
            temperature=0,
        ),
    )

    return response.text


if __name__ == "__main__":
    result = diagnose_incident(
        incident=(
            "checkout-api latency increased above SLO "
            "after the latest deployment."
        ),
        evidence=(
            "p95 latency increased from 280ms to 1.8s. "
            "HTTP 5xx remained stable. "
            "Database CPU increased by 15%."
        ),
    )

    print(result)

Nota arquitectónica: el ejemplo ilustra el patrón de integración y no debe interpretarse como una implementación completa de producción. En un sistema real deben añadirse autenticación, gestión de errores, timeouts, observabilidad, límites de concurrencia, control de costes, evaluación y políticas de seguridad.

def get_service_health(service_name: str) -> dict:
    """
    Consulta un sistema interno de observabilidad.

    Importante:
    - El modelo NO ejecuta directamente esta función.
    - La aplicación valida autorización y parámetros.
    - El resultado se devuelve al modelo como evidencia.
    """
    return {
        "service": service_name,
        "status": "degraded",
        "p95_ms": 1840,
        "error_rate": 0.021,
        "deployment": "checkout-api:v2026.08.28.3",
    }


TOOLS = [
    get_service_health,
    # query_recent_logs,
    # query_trace,
    # get_recent_deployments,
    # get_runbook,
]


def investigate(service_name: str):
    client = genai.Client(
        enterprise=True,
        project=PROJECT_ID,
        location=LOCATION,
    )

    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=(
            f"Investigate the health of {service_name}. "
            "Use tools only when evidence is required."
        ),
        config=genai_types.GenerateContentConfig(
            tools=TOOLS,
            temperature=0,
        ),
    )

    return response

La separación fundamental es ésta: Gemini decide qué información necesita; la plataforma decide si está autorizado a obtenerla y ejecutar una acción.

Google Cloud Observability integra monitorización, logging y tracing; además, las capacidades actuales de análisis de observabilidad permiten correlacionar logs y trazas para investigaciones más profundas. Esto convierte la observabilidad en una fuente especialmente valiosa para alimentar el plano de evidencia del asistente. :contentReference[oaicite:2]{index=2}