14. La Automatización como Producto#

Seis meses antes de la conversación que cambió la manera de trabajar del equipo, el equipo de plataforma de red había entregado algo genuinamente impresionante. Dos años de esfuerzo constante habían producido una plataforma de provisioning que gestionaba el onboarding de sucursales de extremo a extremo: una interfaz de autoservicio para solicitudes de sedes, un flujo de trabajo de validación en bucle cerrado que detectaba errores de configuración antes del despliegue, y un panel operativo que hacía seguimiento de la salud del servicio en trescientas ubicaciones. El equipo había pasado de ventanas de cambio de veinticuatro horas a despliegues automatizados de cuarenta minutos. Estaban orgullosos de ello, y con razón.

Entonces, el equipo de desarrollo de negocio finalizó la adquisición de una cadena de tiendas. Ciento veinte nuevas tiendas necesitaban conectividad de red en seis meses. El responsable de infraestructura envió un único correo electrónico: “Contamos con la plataforma de automatización para esto. ¿Cómo empezamos?”

La primera respuesta interna del equipo de plataforma de red fue confiada: podían automatizarlo. Los flujos de trabajo existían. Las plantillas existían. Las herramientas estaban probadas.

Su segunda respuesta, cuando intentaron contestar el correo, fue menos confiada. El responsable de infraestructura no estaba preguntando si la automatización era técnicamente posible. Estaba haciendo un conjunto de preguntas diferente: ¿Cuál es el SLA para el onboarding de tiendas, concretamente el compromiso de cuándo una tienda obtiene conectividad después de enviar la información del lugar? ¿Quién es el camino de escalada cuando un despliegue falla a mitad? ¿Hay una página de estado o un panel que el equipo del responsable de infraestructura pueda monitorizar sin preguntarle directamente al equipo de red? ¿Cuál es la capacidad de la plataforma: puede gestionar veinte despliegues simultáneos, o habrá que procesar las solicitudes por lotes? Y la pregunta más incómoda: ¿qué pasa con las tiendas que hicieron el onboarding durante un incidente de plataforma, se remedian automáticamente o alguien tiene que auditarlas una por una?

El equipo de red tenía automatización. No tenía respuestas (en términos de negocio y de producto).

Esta brecha, entre “hemos construido automatización que funciona” y “proporcionamos un servicio del que otros equipos pueden depender y planificar”, es el tema de este capítulo.

Este es un tema que me apasiona. Una sesión que impartí en Autocon3 cubre esto desde una perspectiva de automatización orientada al diseño y es una referencia complementaria a este capítulo.

14.1 De Capacidad a Producto#

El Capítulo 13 describió cómo los equipos transforman sus personas, sus roles y sus formas de trabajar para construir la automatización como capacidad organizativa. Esa transformación es necesaria. No es suficiente.

Una capacidad es algo que el equipo puede hacer. Un producto es algo de lo que otros equipos (o eventualmente, entidades externas) pueden depender. La distinción no es sobre calidad técnica: la plataforma de onboarding de la cadena de tiendas era técnicamente excelente. La distinción es sobre la relación entre el proveedor y el consumidor. Una capacidad existe para sus autores. Un producto existe para sus usuarios.

La producción del equipo de red ha cambiado. Antes de la automatización, la producción era la configuración de dispositivos: un router provisionado, una VLAN extendida, una ACL aplicada. El consumidor de esa producción era el propio dispositivo, y la evidencia del éxito era un ping que respondía o una aplicación que funcionaba. Con la automatización, la producción cambia: el producto del equipo de red es un servicio de red consumido por otros equipos. Cada interacción con la red, provisionar una sede de sucursal, expandir un segmento para una nueva aplicación, aplicar una política de seguridad, conceder temporalmente acceso de conferencia a una VLAN, añadir una conexión de peering en un intercambio de internet, se convierte en una solicitud de servicio en lugar de un ticket de cambio. La configuración del dispositivo es el detalle de implementación. El servicio es el artefacto.

Este es el patrón Servicio de Red como Producto (Network Service as Product): el servicio es el artefacto primario, y la red subyacente es la implementación. Esto no es nuevo en la ingeniería de software: las APIs abstraen la infraestructura, y el llamante no sabe ni le importa qué servidores gestionan la solicitud. Sin embargo, es un cambio significativo para los equipos de red que históricamente han organizado su trabajo alrededor de dispositivos, proveedores y protocolos. El ingeniero que definía su identidad alrededor de la habilidad de configuración de routers ahora se le pide que defina su identidad alrededor de la capacidad de entrega de servicios. Ese reencuadre conecta directamente con el Dilema del Artesano del Capítulo 13, sección 13.1: el experto en el oficio antiguo es la persona que necesita hacer el reencuadre de manera más urgente, y el ingeniero que lo hace completamente se vuelve más valioso, no menos.

El hogar técnico de este producto es el bloque de Presentación descrito en el Capítulo 8. La interfaz de autoservicio, la superficie de API, la integración de webhooks, el modelo de acceso basado en roles: aquí es donde el contrato de servicio es visible para los consumidores. El Capítulo 14 hace zoom hacia afuera desde la interfaz técnica hacia el modelo organizativo y de negocio que la rodea. ¿Qué compromisos vienen con la interfaz? ¿Quién es el propietario cuando falla? ¿Cómo evoluciona el servicio? ¿Quién decide qué hace a continuación?

14.2 Definiendo el Producto#

Dos modos de fallo aparecen de manera consistente cuando los equipos intentan convertir la automatización de red en servicios.

El primero es la sobreexposición: la interfaz revela detalles de implementación, y los consumidores deben entender las interioridades de la red para usarla. Un servicio de provisioning de sucursales que pide un ID de VLAN, una máscara de subred y un número de área OSPF no es un servicio: es un CLI con un formulario web. El consumidor, que es un coordinador de instalaciones de la cadena de tiendas, no sabe qué es un área OSPF y no debería necesitar saberlo.

El segundo es la sobrerestricción: la interfaz es tan limitada que solo gestiona los casos de uso exactos que el equipo de red anticipó. Cualquier solicitud que se desvíe de la plantilla requiere un proceso de excepción. El coordinador de instalaciones que necesita provisionar una tienda temporal con un requisito de conectividad diferente al de una ubicación minorista permanente no puede hacerlo en autoservicio. Abre un ticket. El ticket va al equipo de red. El beneficio de la automatización no ha llegado a ese consumidor.

El Patrón de Contrato de Servicio (Service Contract Pattern) resuelve ambos modos de fallo haciendo la definición de la interfaz explícita, versionada y deliberadamente delimitada. Un contrato de servicio tiene tres componentes:

• Superficie de entrada: lo que proporciona el consumidor, expresado en términos de negocio, no en términos de red (perdón por la insistencia, pero esto es clave). Una solicitud de sede de sucursal toma un nombre de ubicación, una dirección física, un nivel de sede (estándar, pequeño, temporal) y una fecha de activación. No toma un ID de VLAN. El contrato traduce la intención de negocio en implementación de red internamente, y esa traducción es responsabilidad de la plataforma de automatización. Las definiciones de nivel no son permanentes: un nivel temporal definido para un quiosco minorista temporal no cubrirá un espacio de eventos temporal con requisitos de conectividad diferentes. La superficie de entrada debe revisarse con los equipos consumidores con la misma cadencia que el roadmap, de modo que los niveles reflejen casos de uso reales en lugar de los casos de uso que el equipo de red anticipó cuando se escribió por primera vez el contrato.

• Superficie de salida: lo que observa el consumidor, incluyendo tanto la finalización exitosa como el fallo. Una superficie de salida bien diseñada no expone “el despliegue ha fallado en el paso 7 de 14: el push de gNMI fue rechazado con el código de error 400”. Expone “la activación ha fallado: el circuito físico en esta dirección aún no ha sido provisionado por el operador. Fecha estimada de finalización: [fecha del SoT]. No se requiere ninguna acción por su parte; el sistema volverá a intentarlo automáticamente cuando el circuito esté activo”. La automatización no simplemente tiene éxito o falla: emite eventos de ciclo de vida observables en términos que el consumidor entiende.

• Dependencias internas: lo que el servicio hace seguimiento internamente y que los consumidores no deberían ver pero que el equipo debe gestionar. El estado del circuito del operador. Los servicios vecinos que comparten infraestructura con este. La relación de consistencia entre el registro del SoT de la nueva sede y los registros de inventario que impulsan el monitoreo automatizado. Cuando un circuito entra en mantenimiento del operador, el equipo de red necesita saber qué servicios se ven afectados y qué exposición de SLO crea. El consumidor puede necesitar saber el impacto en su servicio; no necesita conocer el detalle de implementación que lo causó.

flowchart LR
    classDef consumer fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef contract fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef internal fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    subgraph Consumer["Interfaz del Consumidor"]
        IN["Superficie de Entrada<br/>Ubicación, nivel, fecha<br/>Intención de negocio"]
        OUT["Superficie de Salida<br/>Estado, eventos de ciclo de vida<br/>Lenguaje de negocio"]
    end

    subgraph Contract["Contrato de Servicio"]
        TRANS["Capa de Traducción<br/>Intención a implementación<br/>VLAN, subred, área OSPF"]
    end

    subgraph Internal["Dependencias Internas"]
        CIRC["Estado del circuito"]
        SOT["Consistencia del SoT"]
        NEIGHBOR["Servicios vecinos"]
    end

    IN --> TRANS
    TRANS --> OUT
    TRANS --> CIRC & SOT & NEIGHBOR
    CIRC & SOT & NEIGHBOR -.-> OUT

    class IN,OUT consumer
    class TRANS contract
    class CIRC,SOT,NEIGHBOR internal

Con el contrato de servicio definido, la siguiente pregunta es qué ocurre con él a lo largo del tiempo.

La cuestión del ciclo de vida es donde muchos equipos invierten poco. Un contrato de servicio no trata solo el momento del provisioning. ¿Qué pasa con este servicio cuando cambia la infraestructura subyacente? Una sede de sucursal que funciona sobre un circuito que entra en mantenimiento programado del operador tiene un impacto de SLO previsto. ¿Quién sabe sobre ese impacto, quién decide si notificar al equipo de operaciones de la cadena de tiendas, y quién es el propietario de la comunicación si la ventana de mantenimiento se prolonga? Estas preguntas requieren que los servicios sean entidades de primera clase en el Source of Truth.

El SoT del Capítulo 4 describe la intención como el registro autoritativo de lo que debería ser la red. Los servicios, en el modelo de producto, extienden esa intención hacia arriba: no solo cómo deberían ser los elementos de la red, sino qué funciones de negocio entregan esos elementos y a quién. Un SoT que modela dispositivos y circuitos pero no servicios no puede responder la pregunta “¿qué tiendas minoristas se ven afectadas por este mantenimiento de circuito?” No puede alimentar los mapas de dependencias que hacen posible la gestión de cambios consciente de los servicios. El bloque de Orquestación del Capítulo 7 depende de este grafo de dependencias al coordinar la remediación: un flujo de trabajo en bucle cerrado que responde a un fallo de circuito necesita saber qué servicios se ven afectados antes de poder enrutar notificaciones y disparar la secuencia de recuperación correcta.

Esta es precisamente la abstracción que la sección 4.2.2 del Capítulo 4 formaliza como el bloque orientado al diseño: un operador proporciona una intención de alto nivel (“añadir una sucursal”) y el SoT la expande en los cincuenta o más objetos técnicos que el Executor necesita antes de tocar un dispositivo. El modelo de servicio del Cap. 14 extiende ese mismo principio un nivel más arriba, de “qué objetos técnicos deben existir” a “qué función de negocio entregan esos objetos, y a quién”. El SoT que fue diseñado para abstraer la sintaxis de dispositivos de los operadores puede igualmente abstraer las interioridades de la red de los consumidores de servicios, si los servicios se modelan como objetos de primera clase dentro de él.

La consecuencia práctica: los servicios deben modelarse en el SoT con sus cadenas de dependencias. El servicio de sede de sucursal depende de un circuito físico, que depende de un proveedor, que tiene un historial de ventanas de mantenimiento. El servicio de segmento de red depende de un conjunto de switches de acceso. El servicio de peering en el intercambio de internet depende de una sesión BGP, que depende de un puerto físico, que vive en una instalación específica. Cuando cualquier dependencia cambia de estado, el modelo de servicio se actualiza, y el consumidor afectado puede ser notificado en términos que entiende.

flowchart TB
    classDef service fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef infra fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef external fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b

    S1["Servicio de Sede de Sucursal<br/>Tienda 847"]
    S2["Servicio de Conectividad de Aplicación<br/>Sistema de Inventario"]

    C1["Circuito<br/>Proveedor X, CID-44821"]
    SW1["Switch de Acceso<br/>bldg-b-sw-01"]
    BGP1["Sesión BGP<br/>AS64501"]
    PORT1["Puerto Físico<br/>rack-14-u32"]

    S1 --> C1
    S2 --> SW1
    S2 --> BGP1
    BGP1 --> PORT1

    MAINT["Ventana de Mantenimiento del Operador<br/>2026-06-15 02:00 UTC"]
    C1 -.->|"afectado por"| MAINT

    class S1,S2 service
    class C1,SW1,BGP1,PORT1 infra
    class MAINT external

Los servicios de red que el equipo debería poder modelar de esta manera incluyen: activación de nuevas sedes de sucursal, acceso temporal de red para una conferencia o evento efímero, conectividad de aplicación con ACLs que aplican reglas de dependencia, expansión de peering de internet en un punto de intercambio, y extensión de VLAN para un nuevo segmento de proyecto. Cada uno de estos tiene un consumidor de negocio, un ciclo de vida, dependencias y una definición significativa de salud y fallo.

La mayoría de los equipos que construyen este modelo no parten de cero. La red existente ya tiene trescientas sucursales, años de cambios de configuración acumulados, y un SoT que modela dispositivos y circuitos pero no servicios. Antes de que esas sedes existentes puedan participar en el modelo de servicio, su estado real debe ser descubierto y reconciliado con lo que el SoT cree que es cierto. Una sede cuya configuración en ejecución ha derivado de su registro en el SoT no puede gestionarse de manera segura bajo el ciclo de vida automatizado hasta que se resuelva esa deriva: la automatización aplicará configuraciones basadas en la visión del SoT de la intención, y si esa visión es errónea, la aplicación empeorará las cosas. El descubrimiento y la reconciliación, leyendo el estado del dispositivo y comparándolo con los registros del SoT para identificar y resolver brechas, es el paso previo para los entornos brownfield. Este trabajo no es glamoroso y lleva tiempo, pero omitirlo significa que el modelo de servicio solo es válido para las sedes provisionadas después de que se construyó la plataforma, que normalmente es una fracción pequeña de la red.

Modelar servicios en el SoT es necesario pero no suficiente: el equipo también necesita observarlos al nivel correcto. El bloque de Observabilidad del Capítulo 6 cierra el bucle: la observabilidad a nivel de servicio, haciendo seguimiento de si un servicio es saludable desde la perspectiva del consumidor, es distinta de la observabilidad a nivel de dispositivo, haciendo seguimiento de si la infraestructura subyacente es saludable. Ambas son necesarias. Un servicio puede parecer degradado a su consumidor mientras todos los dispositivos subyacentes informan de estar sanos, si el modelo de servicio no está instrumentado al nivel correcto.

14.3 Alineación con el Negocio#

El argumento tradicional para la automatización de red se centra en la eficiencia operativa: menos tickets, provisioning más rápido, tasas de error más bajas. Ese argumento es cierto y útil para justificar la inversión inicial. No es suficiente para mantener la inversión estratégica a lo largo del tiempo.

La eficiencia operativa se mide contra la línea base actual. Un equipo que reduce el tiempo de provisioning manual de cuatro horas a cuarenta minutos ha demostrado una mejora significativa en el rendimiento. El líder de la unidad de negocio que aprobó el presupuesto hace tres años está satisfecho pero no es estratégicamente comprometido: el equipo de red funciona mejor, y eso es bueno, pero no es una razón para invertir más.

El argumento más fuerte es la capacidad: la automatización permite resultados de negocio que de otro modo serían imposibles o prohibitivamente costosos. La expansión de la cadena de tiendas es un ejemplo concreto. Sin una plataforma de automatización madura, el onboarding de ciento veinte tiendas en seis meses requiere un equipo de ingenieros de red dedicados a ese proyecto durante seis meses. Asumiendo una tasa agresiva de provisioning manual de aproximadamente una tienda por ingeniero por día (un número que varía significativamente dependiendo del tipo de conectividad, el recuento de dispositivos, el tiempo de coordinación con el operador y si los reconocimientos de sede están completados), se trata de un equipo de aproximadamente ocho personas sin otras responsabilidades. Con una plataforma de automatización madura, el mismo trabajo es gestionado por el equipo existente ejecutando flujos de trabajo automatizados en paralelo. El resultado de negocio, expansión completada en seis meses a un coste aceptable, solo es alcanzable porque existe la automatización. Este no es un argumento de eficiencia. Es un argumento de capacidad. Un argumento de negocio.

Un segundo ejemplo: una organización que ejecuta entrenamiento de modelos de IA a gran escala depende de la latencia y la fiabilidad del provisioning de interconexión. Si poner en marcha un nuevo clúster de entrenamiento requiere dos semanas de provisioning manual de red, la capacidad del negocio de ejecutar experimentos de entrenamiento a velocidad competitiva está limitada por el rendimiento del equipo de red. La automatización que reduce el provisioning de dos semanas a cuarenta y ocho horas es una entrada directa a una capacidad de negocio que la unidad de negocio considera estratégica. El equipo de red que no puede articular esa conexión está dejando influencia sobre la mesa.

Un tercer ejemplo: un proveedor de servicios cuyos ingenieros configuran manualmente routers PE, instancias VRF, sesiones BGP con dispositivos CE de clientes y políticas de QoS para cada nuevo contrato MPLS VPN empresarial tarda cuatro semanas desde la aceptación del pedido hasta el servicio activo. Ese plazo no es un problema de operaciones: es un problema de ventas. Los competidores que han automatizado la misma secuencia de provisioning, generando configuraciones consistentes a partir de una solicitud de servicio, validándolas contra la topología existente y aplicándolas a través de un flujo de trabajo probado, prometen puestas en marcha en dos semanas en las respuestas a solicitudes de propuesta. El proveedor de cuatro semanas no puede igualar ese compromiso independientemente de cuán cualificados sean sus ingenieros, porque la restricción no es la habilidad: es la naturaleza serial y manual del proceso de provisioning. La automatización que comprime la puesta en marcha de cuatro semanas a tres días cambia lo que el equipo de ventas puede prometer, lo cual cambia qué contratos la empresa puede ganar. Este no es un argumento de eficiencia. Es un argumento de ingresos, y pertenece a la conversación sobre si invertir en la plataforma de automatización.

La secuencia del razonamiento importa. La automatización diseñada desde el comportamiento del dispositivo hacia arriba, comenzando por “qué podemos automatizar de la configuración del router” y trabajando hacia “qué obtiene el negocio de esto”, a menudo no puede articular el valor de negocio porque nunca fue diseñada para entregar un resultado de negocio. La automatización diseñada desde la capacidad de negocio hacia abajo, comenzando por “qué resultados de negocio requieren servicios de red fiables” y trabajando hacia atrás a través del diseño de servicios hasta la automatización que implementa esos servicios, puede conectar su trabajo con las prioridades de negocio desde la primera conversación.

El patrón Mapa de Servicios Orientado al Negocio (Business-Driven Service Map) hace explícita esta conexión: un mapeo de servicios de red hacia las capacidades de negocio que habilitan. Para cada servicio de red, el mapa responde tres preguntas: qué procesos de negocio dependen de este servicio, cuál es el impacto de negocio si este servicio se degrada o no está disponible, y qué capacidad de negocio sería posible si este servicio fuera más rápido, más fiable o de autoservicio. Este es el documento que un Product Manager de Automatización de Red poseería, y es el instrumento primario para alinear el roadmap de automatización con las prioridades de negocio.

flowchart TB
    classDef biz fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef svc fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef auto fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    subgraph BIZ["Capacidades de Negocio"]
        B1["Expansión Minorista"]
        B2["Velocidad de Entrenamiento de IA"]
        B3["Operaciones de Eventos"]
    end

    subgraph SVC["Servicios de Red"]
        S1["Activación de Sucursal"]
        S2["Provisioning de Interconexión"]
        S3["Acceso Temporal"]
    end

    subgraph AUTO["Automatización"]
        A1["Flujo de Trabajo de Onboarding de Sede"]
        A2["Provisioning de Circuito y BGP"]
        A3["Ciclo de Vida de VLAN de Conferencia"]
    end

    B1 --> S1 --> A1
    B2 --> S2 --> A2
    B3 --> S3 --> A3

    class B1,B2,B3 biz
    class S1,S2,S3 svc
    class A1,A2,A3 auto

Este reencuadre es incómodo para muchos equipos de red, porque requiere medir cosas diferentes. Las métricas operativas (tickets cerrados, tasa de éxito de cambios, Mean Time To Resolution (MTTR)) están dentro del control del equipo y son fáciles de instrumentar. Las métricas de resultado de negocio (tiempo para abrir una nueva ubicación minorista, latencia de provisioning de interconexión como entrada al rendimiento del entrenamiento) requieren colaboración con otras unidades de negocio y una comprensión de lo que realmente miden. El equipo que hace este cambio, de medir la excelencia técnica a medir la contribución de negocio, responde una pregunta diferente en las conversaciones de presupuesto: no “qué tan eficientemente hemos gestionado la red este trimestre” sino “qué resultados de negocio dependieron de la plataforma de red este trimestre, y qué habría fallado sin ella”. Es una pregunta más difícil de responder, pero es la que determina si la plataforma obtiene financiación para la siguiente fase.

El principio de Medida de Impacto sobre Medida de Eficiencia (Impact Measurement over Efficiency Measurement) sigue: priorizar la medición de los resultados que importan al negocio por encima de las métricas operativas que solo importan al equipo de red. Las métricas de eficiencia son entradas. Los resultados son lo que le importa al negocio.

Este reencuadre también cambia lo que el equipo pide en los ciclos de planificación. Un equipo que presenta “hemos reducido el MTTR un 40%” informa sobre su propio rendimiento. Un equipo que presenta “el plazo de expansión minorista es alcanzable porque nuestra automatización de onboarding puede gestionar cuarenta activaciones concurrentes sin intervención manual” informa sobre la capacidad de negocio. Ambos hechos pueden ser ciertos. Solo uno de ellos es relevante para la decisión sobre si dotar de personal el proyecto de expansión minorista.

14.4 El SLA Interno#

Una plataforma de automatización de la que dependen otros equipos sin compromisos de fiabilidad es una trampa de confianza. Funciona hasta que no funciona, y el equipo consumidor no tiene datos para planificar. El responsable de infraestructura de la cadena de tiendas que programa veinte solicitudes simultáneas de activación de sucursales un lunes por la mañana necesita saber, antes del lunes por la mañana, cuál será el comportamiento de la plataforma: cuánto tiempo tardará cada activación, ¿pueden ejecutarse veinte en paralelo o se encolarán?, qué pasa si una falla a mitad del despliegue, y cómo comunicará la plataforma ese fallo.

Estas son preguntas de SLA. En el modelo de producto, cada servicio de automatización lleva un SLA explícito, no como protección legal sino como el contrato operativo que hace el servicio planificable.

Un SLA de automatización tiene cuatro componentes:

• Disponibilidad: el porcentaje de tiempo que la interfaz de servicio es accesible y acepta solicitudes. Un servicio de activación de sucursales con una disponibilidad mensual del 99,5% tiene aproximadamente tres horas y media de tiempo de fallo permitido por mes. Esa cifra es un compromiso: cuando el servicio está caído, el equipo debe una explicación y un plazo de recuperación.

• Latencia de ejecución: cuánto tiempo tarda el servicio en cumplir una solicitud desde el envío hasta la finalización. Para la activación de sucursales, esto podría ser: confirmación en treinta segundos, provisioning iniciado en cinco minutos, finalización en cuarenta minutos para una sede estándar. Esos números definen cómo se ve “funcionando”, no solo si el servicio es accesible.

• Presupuesto de errores: con qué frecuencia puede fallar el servicio sin violar el SLA. Un servicio con un 99% de finalizaciones exitosas por semana tiene un presupuesto de errores del uno por ciento. Cuando más del uno por ciento de las activaciones fallan en una semana, algo va mal y el equipo debe una revisión. El rol de NRE descrito en la sección 13.2 del Capítulo 13 es la persona que es propietaria de definir y defender estos presupuestos, y el modelo de presupuesto de errores de la literatura de SRE se aplica directamente: cuando el presupuesto de errores se consume, los nuevos despliegues de automatización se pausan hasta que se restaure la fiabilidad.

SRE (Ingeniería de Fiabilidad del Sitio) es una disciplina originada en las operaciones de software a gran escala que aplica principios de ingeniería a la fiabilidad: definir objetivos de nivel de servicio, medir presupuestos de errores y usar datos de fiabilidad para gobernar la velocidad de funcionalidades. El rol de NRE (Ingeniero de Fiabilidad de Red) adapta estos principios a las plataformas de automatización de red. Ambos roles y su aplicación a los equipos de red se cubren en detalle en la sección 13.2 del Capítulo 13.

• Camino de escalada: cuando el servicio falla o no cumple su SLA, a quién llama el consumidor, y cuál es el tiempo de respuesta esperado. Un camino de escalada que va al buzón general del equipo de red no es un camino de escalada: es una cola de tickets. Un SLA de producto requiere un contacto de escalada nombrado o basado en roles con un compromiso de respuesta definido.

La pregunta del modelo de soporte sigue naturalmente: cuando la automatización falla, ¿quién es su propietario? Tres modos de fallo aparecen en casi todos los incidentes, y confundir cuál está activo lleva a que los incidentes caigan entre equipos.

La superposición entre estas categorías es donde los incidentes se pierden. Un flujo de trabajo de automatización que falla porque el push de gRPC Network Management Interface (gNMI) fue rechazado podría ser un error de automatización (modelo de datos incorrecto), un fallo de plataforma (el colector gNMI perdió su sesión), o un fallo de red (el dispositivo se reinició durante el push). El proceso de respuesta a incidentes debe ser diseñado para clasificar entre estas categorías sin requerir que el equipo consumidor entienda cuál está activa. Desde la perspectiva de la cadena de tiendas, la tienda no obtuvo conectividad. Quién lo arregla y cuándo es el problema del proveedor, no el suyo.

Una secuencia práctica de triage para cualquier fallo de automatización sigue tres pasos. Primero, revisar los registros de automatización: ¿el flujo de trabajo informó de un error, y es ese error consistente en múltiples ejecuciones de la misma entrada o específico a una? El fallo consistente en una entrada específica apunta a un error de automatización; el fallo aleatorio o intermitente apunta a otro lugar. Segundo, revisar la salud de la plataforma: ¿están fallando simultáneamente otros servicios no relacionados, y el motor de ejecución, el SoT y la pila de observabilidad informan de estar sanos? El fallo amplio simultáneo a través de servicios no relacionados es una firma de fallo de plataforma, independientemente de lo que digan los registros del flujo de trabajo. Tercero, revisar el estado del dispositivo: ¿el elemento de red recibió y aplicó la configuración pretendida, y su estado actual coincide con lo que la automatización intentó aplicar? Si el flujo de trabajo se completó sin error pero la red no convergió, el fallo está en la capa de red. Esta secuencia puede codificarse como los tres primeros pasos de un runbook automatizado, de modo que el ingeniero de guardia llegue a un incidente con el triage ya hecho en lugar de empezar desde cero.

La referencia al equipo de plataforma en el segundo modo de fallo conecta con el Capítulo 10: la fiabilidad de la plataforma es una condición previa para los SLAs de servicio. Un servicio no puede comprometerse a una disponibilidad del 99,5% si el motor de ejecución sobre el que se ejecuta no tiene ningún objetivo de fiabilidad. Los patrones de ingeniería de plataforma del Capítulo 10, redundancia, monitoreo de salud, recuperación automatizada, son los que hacen creíbles los SLAs de automatización.

Diseñar el camino de escalada antes de que ocurra el incidente. La conversación post-incidente sobre quién era el propietario de qué siempre es más difícil que la conversación pre-incidente que estableció límites claros.

El radio de explosión es una preocupación de diseño relacionada que pertenece a la misma conversación pre-incidente. Un error de provisioning manual afecta a una sede porque un ingeniero configura una sede a la vez. Un error de automatización puede afectar a todas las sedes que coinciden con el patrón de entrada antes de que ningún humano note que algo va mal. La respuesta a esto no es ralentizar la automatización: es diseñar límites de concurrencia y despliegue por etapas en el contrato de servicio como opciones de seguridad deliberadas, no como detalles de implementación. Un servicio de activación de sucursales que limita los despliegues concurrentes a cinco trabajos activos, valida el primer despliegue hasta la finalización antes de liberar el siguiente lote, y se detiene en cualquier trabajo fallido hasta que un humano lo apruebe no es un servicio lento: es un servicio cuyo radio de explosión está delimitado por diseño. Esa delimitación debería aparecer en el contrato de servicio, junto con la disponibilidad y la latencia de ejecución, de modo que los equipos consumidores entiendan tanto lo que la plataforma puede hacer como lo que se negará a hacer para protegerlos. El responsable de infraestructura de la cadena de tiendas que entiende que la plataforma pausará un despliegue de cuarenta tiendas después del primer fallo, en lugar de completar treinta y nueve despliegues más sobre una plantilla defectuosa, confiará más en la plataforma, no menos.

La existencia de compromisos de SLA, controles de radio de explosión y un marco de triage crea las condiciones para una relación diferente con la gobernanza de cambios. En organizaciones que operan bajo la gestión de cambios tradicional, cada cambio de red, incluidos los automatizados, puede ser enrutado a través de un Consejo Asesor de Cambios para la aprobación previa. Ese proceso fue diseñado para un mundo donde cada cambio es único, hecho a mano e impredecible: la persona adecuada revisando un cambio manual de un ingeniero humano añade genuina reducción de riesgos porque el juicio humano varía. La misma lógica aplicada a un flujo de trabajo automatizado que ha sido diseñado, probado en un entorno de pre-producción, validado contra el SoT, restringido por límites de radio de explosión y ejecutado exitosamente docenas de veces no añade reducción de riesgos: añade latencia a una operación cuyo perfil de riesgo se estableció antes de que se ejecutara nunca en producción.

El Patrón de Automatización Pre-aprobada (Pre-Approved Automation Pattern) resuelve esto: la aprobación de cambios se aplica una vez al diseño del flujo de trabajo, no repetidamente a cada ejecución de ese flujo de trabajo. Cuando un flujo de trabajo de activación de sucursales ha pasado sus etapas de validación, ha sido revisado y aprobado por las partes interesadas de ingeniería y operaciones relevantes, y se ha desplegado a producción con sus restricciones de seguridad activas, cada ejecución posterior de ese flujo de trabajo no es un nuevo cambio que requiera nueva aprobación. Es una instancia de una operación ya aprobada y delimitada. La pregunta de gobernanza apropiada es “¿está esta ejecución dentro del envolvente aprobado?” no “¿debería ocurrir esta ejecución?” Un proveedor de nube no requiere que un humano apruebe cada solicitud de creación de red virtual: el servicio fue diseñado con las restricciones apropiadas, probado a fondo y aprobado como servicio. Las solicitudes individuales de clientes dentro de ese límite de servicio no son eventos de cambio que requieran revisión. Son invocaciones de servicio. Los servicios de automatización de red, una vez diseñados y aprobados adecuadamente, deberían operar de la misma manera. El trabajo que justifica esta confianza es exactamente lo que describen las secciones 14.2 a 14.4: contratos de servicio explícitos, salidas observables, radio de explosión delimitado y un camino de triage definido cuando algo va mal. Ese trabajo es la aprobación de cambios, hecha una vez, en el momento adecuado.

14.5 Rendimiento, Coste y ROI#

La automatización tiene costes. Infraestructura de cómputo para el motor de ejecución, el orquestador y la pila de observabilidad. Almacenamiento para registros del SoT, historial de trabajos y telemetría. Tiempo de ingeniería para construir, probar y mantener el código de automatización (y los tokens de IA de codificación correspondientes para soportarlo). Licencias de herramientas para los componentes comerciales de la plataforma. Carga de soporte cuando los consumidores presentan problemas o solicitan nuevas capacidades. Estos costes son reales y recurrentes.

La cuestión del ROI también es real, y los equipos de red que la evitan ceden las decisiones de presupuesto a los equipos de finanzas y adquisiciones que la responderán con menos precisión. El marco tiene tres componentes:

• Coste de la automatización: el coste completo de construir y ejecutar la plataforma. Salarios de ingeniería asignados al desarrollo y mantenimiento de la plataforma, costes de infraestructura (cómputo, almacenamiento, redes para la propia infraestructura de automatización), licencias de herramientas y sobrecarga operativa. Esa cifra es cognoscible y el equipo debería conocerla.

• Coste del equivalente manual: lo que costaría entregar los mismos servicios sin automatización. Para la activación de sucursales, se trata de horas de ingeniería por sede multiplicadas por el coste por hora de los ingenieros que lo harían, más el coste de los errores (incidentes causados por errores de provisioning manual, medidos en Mean Time To Resolution (MTTR) y servicios afectados). Para la expansión de la cadena de tiendas, el coste manual es suficientemente grande para hacer la inversión en automatización obviamente justificada. Para un servicio de bajo volumen provisionado dos veces al año, el cálculo es diferente.

• Valor de las capacidades desbloqueadas: los resultados de negocio que no serían posibles sin automatización. Este es el componente más difícil de cuantificar y el argumento de mayor valor que presentar. Ciento veinte tiendas en seis meses no es cuestión de eficiencia: es una capacidad binaria. Sin automatización, no ocurre en ese plazo independientemente del presupuesto de ingeniería. El equipo de red que puede declarar claramente “el plazo de expansión minorista depende de nuestra plataforma de automatización” participa en una conversación estratégica, no en una negociación de presupuesto.

Tres ejes definen el espacio de diseño de cualquier servicio de automatización, y cada uno representa un compromiso que el modelo de producto pone en evidencia:

• Velocidad: ¿qué tan rápido es el servicio desde el envío de la solicitud hasta la finalización?
• Seguridad: ¿qué tan fiablemente el servicio evita empeorar las cosas, a través de validación, etapas de prueba en seco y caminos de retroceso?
• Utilización: ¿cuántas solicitudes concurrentes puede gestionar la plataforma sin degradación?

Estos ejes están en tensión. Maximizar la seguridad mediante validación exhaustiva y etapas de ejecución supervisadas añade latencia: un flujo de trabajo más seguro es típicamente uno más lento. Maximizar la velocidad reduciendo etapas de validación aumenta el riesgo. Maximizar la utilización concurrente requiere una inversión en infraestructura que puede no estar justificada por el volumen real de solicitudes.

El enfoque de producto fuerza que estos compromisos sean explícitos en el contrato de servicio. Cuando el responsable de infraestructura de la cadena de tiendas pregunta si veinte despliegues simultáneos son seguros, la respuesta no es “funciona en pruebas”. La respuesta es una declaración concreta sobre el diseño de la plataforma: la capacidad de despliegue concurrente está limitada a veinticuatro trabajos activos, cada despliegue tiene un camino de retroceso independiente, y el sistema de observabilidad confirma la convergencia exitosa del estado antes de marcar un trabajo como completo. Esas declaraciones provienen de un equipo que ha pensado en los compromisos como decisiones de diseño de producto, no como detalles de implementación de ingeniería.

La medición del ROI alimenta directamente la priorización. Qué automatización construir a continuación debería estar informado por qué resultados de negocio están más restringidos por las limitaciones de red. El equipo que hace seguimiento de qué solicitudes manuales consumen más tiempo de ingeniería, qué servicios tienen la tasa de fallo más alta durante el provisioning manual, y qué capacidades de negocio están bloqueadas por el rendimiento de la red tiene los datos para hacer argumentos de priorización que el negocio puede evaluar. El equipo que no tiene esos datos hace argumentos de priorización basados en lo que es técnicamente interesante, y esos argumentos pierden ciclos de presupuesto ante equipos que han cuantificado su impacto.

14.6 Priorización y Roadmap#

Dos preguntas se enfrentan a cada equipo de automatización de red constantemente y raramente se responden formalmente: qué tareas automatizar a continuación, y cuándo decir no a una solicitud. El modelo de producto requiere respuestas formales a ambas. Estas son las categorías de priorización:

• Impacto de negocio: ¿qué servicio, cuando se automatiza, habilita la capacidad de negocio de mayor valor? El Mapa de Servicios Orientado al Negocio de la sección 14.3 es la entrada a esta pregunta. El servicio que, cuando se automatiza, desbloquea una iniciativa de negocio estratégica se clasifica por encima del servicio que, cuando se automatiza, ahorra doce horas de ingeniería al año.

• Frecuencia por esfuerzo: ¿con qué frecuencia se hace esta tarea manualmente, y cuánto tiempo de ingeniería toma cada ocurrencia? Una tarea hecha diariamente que toma cuatro horas cada vez tiene doscientas veces el ROI de una tarea hecha semanalmente que toma treinta minutos. Las tareas manuales de alta frecuencia con esfuerzo significativo por ocurrencia son los casos más claros para la automatización.

• Reducción de riesgos: algunas tareas vale la pena automatizarlas incluso si son poco frecuentes, porque el coste del error humano es catastrófico. Los cambios manuales de peering BGP que, cuando se configuran mal, causan fugas de rutas que afectan a cientos de clientes, vale la pena automatizarlos incluso si ocurren solo seis veces al año. La automatización se justifica no por el rendimiento sino por eliminar un modo de error con consecuencias inaceptables.

• Demanda del consumidor: ¿qué están solicitando activamente otros equipos? La demanda del consumidor es una señal imperfecta, porque los equipos a menudo solicitan lo que saben que es posible en lugar de lo que sería más valioso. Pero las solicitudes consistentes de los mismos equipos para la misma capacidad son datos significativos sobre dónde la interfaz de servicio no se adecua a los casos de uso reales.

El patrón Backlog de Automatización (Automation Backlog) trata las tareas no automatizadas de la misma manera que un equipo de producto trata un backlog de funcionalidades: priorizado, estimado, y con criterios de aceptación claros sobre lo que significa “hecho”. Hecho no es “la automatización se ejecutó exitosamente en el laboratorio”. Hecho es “la automatización ha superado las etapas de la Escalera de Confianza (Confidence Ladder) descritas en la sección 13.5.2 del Capítulo 13, está documentada y está disponible para el consumo en autoservicio por los equipos consumidores relevantes”. El backlog es visible para las partes interesadas, de modo que puedan ver lo que viene y planificar en consecuencia.

La comunicación del roadmap importa más que el propio roadmap. Un roadmap de automatización de red compartido con los equipos dependientes en una cadencia trimestral es una señal de confianza. Hace legible el trabajo del equipo de automatización para el negocio. Permite a los equipos consumidores planificar su propio trabajo alrededor de lo que la plataforma podrá y no podrá hacer el próximo trimestre. Crea la oportunidad de retroalimentación para que los equipos consumidores pongan en evidencia requisitos que el equipo de red no sabía que existían.

Los bucles de retroalimentación de los consumidores y las partes interesadas son la entrada más valiosa para las decisiones del roadmap. ¿Qué equipos presentan las excepciones más frecuentes? ¿Qué salidas de automatización requieren interpretación manual antes de que el consumidor pueda actuar sobre ellas? ¿Dónde fuerza la interfaz de servicio actual a los consumidores a enviar solicitudes en términos de red en lugar de términos de negocio? Estas son señales de retroalimentación de producto, y capturarlas sistemáticamente es lo que separa un roadmap que refleja las necesidades reales del consumidor de uno que refleja lo que el equipo de automatización cree que los consumidores deberían querer.

La cadencia de las reuniones con las partes interesadas vale la pena nombrarla explícitamente. Una reunión recurrente, trimestral para la mayoría de plataformas y mensual para plataformas en desarrollo activo, donde se revisa el roadmap, se recoge la retroalimentación del consumidor y se comunican los próximos cambios, no es una reunión de estado. Es el mecanismo por el cual una plataforma de automatización se comporta como un producto que escucha a sus usuarios. Los equipos que se saltan este paso construyen automatización que resuelve el problema del año pasado mientras consume el presupuesto de este año.

14.6.1 La Función de Gestión de Producto#

No todos los equipos necesitan un Product Manager dedicado. Cada programa de automatización maduro necesita a alguien que ejerza la función de gestión de producto.

En equipos pequeños, el arquitecto de red o el NRE senior puede absorber la función de gestión de producto junto con su trabajo técnico. Mantienen el backlog, dirigen las reuniones con las partes interesadas y son propietarios de las conversaciones de alineación de negocio. A esta escala, unas pocas horas a la semana es suficiente para mantener la función viva.

A medida que la plataforma crece, el trabajo de traducción entre las partes interesadas externas y la ingeniería interna se vuelve sustancial. Una plataforma que da servicio a diez equipos consumidores, con treinta servicios en producción y un roadmap trimestral que requiere negociación a través de prioridades en competencia, no puede gestionarse como producto en unas pocas horas a la semana. La función se convierte en un rol a tiempo completo.

El rol de Product Manager de Automatización de Red (Network Automation Product Manager) está emergiendo en organizaciones con programas de automatización maduros. Sus responsabilidades son:

• Ser propietario de la relación con las partes interesadas en nombre de la plataforma: el punto de contacto principal para los equipos consumidores, responsable de traducir sus necesidades en requisitos de servicio
• Mantener el Mapa de Servicios Orientado al Negocio y el Backlog de Automatización, con una priorización que refleje tanto el impacto de negocio como la realidad de ingeniería
• Comunicar el roadmap externamente y gestionar las expectativas cuando cambian las prioridades
• Definir y hacer seguimiento de las métricas de impacto de negocio, haciendo visible la contribución de la plataforma a los resultados de negocio para el liderazgo
• Representar la retroalimentación del consumidor en las discusiones de priorización del equipo, asegurando que las prioridades de ingeniería reflejen las necesidades reales de los usuarios en lugar de las preferencias técnicas internas

Este rol no requiere una expertise profunda en redes. Requiere la capacidad de entender lo que el equipo de red puede entregar, lo que el negocio necesita, y dónde se alinean y no se alinean esas dos cosas. El modelo de colaboración entre el Product Manager de Automatización de Red y los roles técnicos del Capítulo 13, sección 13.2 sigue un patrón familiar de las organizaciones de productos de software: el Product Manager es propietario de qué se construye y por qué, el Ingeniero de Plataforma de Red y el Desarrollador de Automatización son propietarios de cómo se construye, y el NRE es propietario de cómo se mantiene saludable en producción. Los conflictos entre estos grupos son características del modelo, no defectos: el PM impulsa las necesidades del consumidor, los ingenieros impulsan la sostenibilidad de la plataforma, y la tensión entre ellos produce mejores decisiones de las que cualquiera de los dos habría tomado por separado.

El rol de Product Manager de Automatización de Red es controvertido en algunas organizaciones de red porque introduce un rol no técnico en una estructura de equipo centrada técnicamente. La preocupación es válida: un PM sin suficiente base técnica hará compromisos que el equipo de ingeniería no puede cumplir, y tendrá dificultades para distinguir entre solicitudes que son sencillas de implementar y solicitudes que requieren cambios fundamentales de plataforma. La solución no es evitar el rol sino hacer los límites de colaboración concretos. Dos salvaguardas son innegociables: el PM no puede comprometer una fecha de entrega a una parte interesada externa sin el visto bueno explícito del responsable de ingeniería sobre el alcance y el plazo, y el responsable de ingeniería tiene autoridad de veto sobre cualquier compromiso que requiera cambios de plataforma aún no diseñados o estimados. Sin estas salvaguardas, el rol de PM crea un nuevo modo de fallo: las partes interesadas externas reciben promesas que el equipo de ingeniería descubre después del hecho, y el daño a la credibilidad recae sobre la plataforma, no sobre el PM.

Dos años después de su transición de plataforma, a Jordi, un arquitecto de red que había liderado el cambio de su equipo de las operaciones manuales a una plataforma de automatización (presentado en el Capítulo 13), se le pidió que se uniera a una reunión con el proyecto de integración de la cadena de tiendas. El responsable del equipo de negocio expuso el calendario de onboarding, señaló un período de seis semanas donde cuarenta tiendas necesitaban ponerse en marcha simultáneamente, y preguntó: “¿Está la plataforma preparada para eso?” Jordi tenía la respuesta: la plataforma podía gestionarlo técnicamente, pero la cobertura de monitoreo para las sedes recién activadas tenía un retraso de doce horas antes de que se ingiriera la telemetría completa. Cuarenta activaciones simultáneas significaría cuarenta sedes funcionando durante medio día con cobertura de observabilidad reducida. Lo dijo directamente, nombró el riesgo y propuso una modificación a la secuencia de onboarding que distribuiría las activaciones en un período de tres días sin extender el plazo global. El equipo de negocio lo aceptó. La conversación ocurrió en quince minutos porque Jordi entendía tanto la restricción técnica como su consecuencia de negocio. Esa traducción, entre lo que hace la plataforma y lo que experimenta el negocio, es la función de gestión de producto independientemente de quién tenga el título.

14.6.2 Gestión del Ciclo de Vida del Servicio#

La descripción del rol de PM en la sección 14.6.1 nombra las responsabilidades. Esta sección muestra cómo operan esas responsabilidades a través de las cuatro etapas por las que pasa cada servicio de red: definición, entrega, operaciones y evolución.

flowchart LR
    classDef def fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef del fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef ops fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef evo fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b

    DEF["Definición<br/>Contrato de servicio<br/>Justificación de negocio"]
    DEL["Entrega<br/>Gestión del backlog<br/>Criterios de aceptación"]
    OPS["Operaciones<br/>Monitoreo del SLA<br/>Comunicación con el consumidor"]
    EVO["Evolución<br/>Versionado<br/>Deprecación"]

    DEF --> DEL --> OPS --> EVO
    EVO -->|"próxima versión"| DEF

    class DEF def
    class DEL del
    class OPS ops
    class EVO evo

Definición

El primer contacto del PM con un nuevo servicio es antes de que el equipo de ingeniería escriba una línea de código de automatización. Un equipo consumidor llega con una solicitud: “necesitamos hacer el onboarding de tiendas más rápido,” o “nuestro equipo de aplicación no puede provisionar segmentos de red sin presentar un ticket.” El trabajo del PM en esta etapa es traducir esa solicitud en un contrato de servicio delimitado usando la estructura de tres componentes de la sección 14.2: ¿qué proporciona el consumidor (superficie de entrada), qué observa (superficie de salida), y qué dependencias internas lleva el servicio que los consumidores no necesitan entender? Esa traducción no es un documento de requisitos entregado a ingeniería. Es una negociación entre lo que el consumidor necesita y lo que la plataforma puede entregar, con el PM y el responsable de ingeniería ambos en la sala.

El PM es propietario de la pregunta “¿cómo es hecho desde la perspectiva del consumidor?”. El responsable de ingeniería es propietario de “¿cómo es hecho desde la perspectiva de la plataforma?”. Ambas preguntas deben responderse antes de que la definición esté completa, porque un contrato de servicio que satisface al consumidor pero ignora las restricciones de plataforma generará retrabajo durante la entrega, y uno que satisface a la plataforma pero no al consumidor no se usará después del lanzamiento.

Antes de que cierre la definición, el PM coloca el nuevo servicio en el Mapa de Servicios Orientado al Negocio de la sección 14.3. Este paso asegura que el servicio tiene una justificación de negocio explícita y que su prioridad relativa a otros elementos del Backlog de Automatización puede evaluarse con criterios consistentes. Un servicio que no puede colocarse en el mapa, porque nadie puede articular qué capacidad de negocio habilita o cuál es el impacto de su ausencia, no está listo para ser definido. Eso es una señal para volver a la conversación con el consumidor, no para empezar la ingeniería.

Entrega

Una vez acordado el contrato de servicio, el PM gestiona la entrada del Backlog de Automatización correspondiente a través del desarrollo. Los criterios de aceptación se escriben en términos del consumidor: “una activación estándar de sucursal se completa en cuarenta minutos del envío, con un evento de ciclo de vida emitido en cada etapa,” no “el push de gNMI al router PE se completa sin error.” La distinción importa porque los criterios de aceptación escritos en términos de implementación pueden pasar mientras la experiencia del consumidor falla: el push se completó, pero el consumidor no recibió ninguna notificación y no puede saber si su tienda está activa.

Durante la entrega, el PM es propietario de toda la comunicación externa sobre el plazo y el alcance. El responsable de ingeniería es propietario de las decisiones técnicas internas. Esta división protege al equipo de ingeniería del patrón que descarrila la mayoría de los proyectos de automatización: las adiciones de alcance que llegan después de acordar el contrato de servicio. Cada nuevo requisito después de la firma del contrato es un nuevo elemento del Backlog de Automatización con su propia priorización, no una modificación a la entrega actual. El trabajo del PM es mantener ese límite con los equipos consumidores, porque el equipo de ingeniería no puede hacerlo sin dañar la relación con el consumidor. Un alcance de entrega que puede ser ampliado por cualquier parte interesada en cualquier momento es una entrega que nunca se completa.

Operaciones

Cuando el servicio entra en funcionamiento, el rol del PM cambia de la entrega al mantenimiento de la confianza. El SLA interno de la sección 14.4 define lo que el servicio se compromete: disponibilidad, latencia de ejecución, presupuesto de errores y camino de escalada. El PM hace seguimiento de estas métricas no para diagnosticar fallos, que es la responsabilidad del NRE, sino para ser propietario de la comunicación orientada al consumidor cuando se aproximan o superan los umbrales. Un equipo consumidor que descubre que su servicio ha estado funcionando fuera de su SLA leyendo un panel al que no se les dijo que vigilaran no ha recibido un SLA: ha recibido una métrica sin una relación. El PM es la relación.

El PM también dirige el proceso de recogida de retroalimentación operativa. ¿Qué equipos consumidores presentan las solicitudes de excepción más frecuentes? ¿Qué salidas de servicio requieren interpretación manual antes de que el consumidor pueda actuar sobre ellas? ¿Dónde fuerza la superficie de entrada actual a los consumidores a enviar solicitudes en términos de red en lugar de términos de negocio? Estas señales no son quejas: son datos de producto, y el trabajo del PM es agregarlas sistemáticamente y llevarlas a la conversación del roadmap con suficiente especificidad para que el equipo de ingeniería pueda actuar sobre ellas. La retroalimentación que llega como “los consumidores no están satisfechos con la activación de sucursales” no es accionable. La retroalimentación que llega como “siete de las últimas doce solicitudes de excepción eran para sedes temporales que no coincidían con ningún nivel definido, y las siete requirieron la implicación directa del equipo de red” es accionable: nombra una brecha en la superficie de entrada y cuantifica su coste operativo.

Evolución

Los servicios que dejan de evolucionar acumulan discrepancias entre lo que fueron diseñados para gestionar y lo que los consumidores necesitan realmente. El PM es propietario de la decisión de cuándo y cómo evoluciona un servicio, informado por la retroalimentación operativa recogida en la etapa anterior y las entradas cambiantes en el Mapa de Servicios Orientado al Negocio.

No toda la evolución conlleva la misma consecuencia operativa. Un cambio que añade un nuevo campo de entrada opcional o emite un evento de salida más rico es aditivo: los consumidores existentes no se ven afectados, y la adopción de la nueva capacidad es opcional. Un cambio que renombra un campo obligatorio, elimina un evento de salida o altera un compromiso de SLA rompe el contrato existente para todos los consumidores que dependen de él. El PM debe distinguir entre estas dos categorías antes de que comience cualquier evolución, porque requieren procesos diferentes: los cambios aditivos pueden entregarse como actualizaciones menores, mientras que los cambios que rompen el contrato requieren un incremento de versión, un camino de migración y un plazo de deprecación comunicado a los equipos consumidores antes de que el cambio llegue.

El plazo de deprecación es donde muchos equipos fallan. Los equipos de ingeniería naturalmente quieren eliminar la versión antigua tan pronto como la nueva es estable. Los equipos consumidores naturalmente quieren quedarse en la versión de la que dependen hasta que tengan capacidad para migrar. El PM negocia la ventana entre esas dos posiciones y se compromete con ambas partes: una fecha específica después de la cual la versión antigua no tiene soporte, comunicada con suficiente antelación para que los equipos consumidores puedan planificar su migración. Los servicios evolucionados sin este proceso erosionan la confianza que el contrato de servicio fue diseñado para construir. El equipo consumidor que descubre un cambio que rompe el contrato en producción no ha experimentado un fallo técnico: ha experimentado un fallo de relación, y eso es más difícil de recuperar.

14.7 Resumen#

Cuatro temas anclan este capítulo:

Servicios, no scripts: el cambio de producto es de construir automatización que se ejecute a proporcionar servicios de los que otros dependen. El patrón Servicio de Red como Producto nombra este reencuadre: el servicio es el artefacto primario, la red subyacente es el detalle de implementación. El Patrón de Contrato de Servicio es el artefacto que hace esto concreto: una definición explícita y versionada de superficie de entrada, superficie de salida y dependencias internas que delimita la interfaz a lo que los consumidores necesitan proporcionar y lo que pueden observar, sin exponer detalles de implementación de red que no deberían necesitar entender.

La alineación de negocio es estructural: medir el impacto de negocio requiere diseñar la automatización desde los resultados de negocio hacia abajo, no desde el comportamiento del dispositivo hacia arriba. El Mapa de Servicios Orientado al Negocio es el instrumento: un mapeo explícito de servicios de red a las capacidades de negocio que habilitan y el impacto de negocio de la degradación o no disponibilidad. Los equipos que pueden hacer este mapeo fluidamente son los que otras unidades de negocio llaman cuando están planificando algo nuevo, porque esos equipos ya han respondido la pregunta “qué posibilidades abre la red”. Los que no pueden hacerlo se enteran de nuevas iniciativas cuando el plazo ya se ha fijado, y se encuentran explicando por qué la red no puede estar lista a tiempo. El Backlog de Automatización aplica la misma lógica a la priorización: qué automatización construir a continuación debería estar determinado por qué resultados de negocio están más restringidos por las limitaciones de red, no por qué automatización es más interesante técnicamente.

SLAs y modelos de soporte antes de que sean necesarios: definir compromisos de fiabilidad, caminos de escalada y propiedad de fallos antes del primer incidente importante es lo que separa una plataforma de una colección de scripts. El SLA interno, con sus cuatro componentes de disponibilidad, latencia de ejecución, presupuesto de errores y camino de escalada, es el instrumento que hace la confianza explícita. La taxonomía de tres modos de fallo (error de automatización, fallo de plataforma, fallo de red) es el marco de triage que evita que los incidentes caigan entre equipos. El Patrón de Automatización Pre-aprobada extiende esto: una vez que un flujo de trabajo ha sido diseñado, probado y aprobado con sus restricciones de seguridad activas, las ejecuciones individuales son instancias de una operación aprobada, no nuevos cambios que requieran reaprobación. Tanto el modelo de SLA como el modelo de gobernanza deben establecerse antes del primer incidente, no después.

La función de gestión de producto a lo largo del ciclo de vida del servicio: cada servicio de red pasa por cuatro etapas: definición, entrega, operaciones y evolución, y la función de gestión de producto es propietaria de la continuidad a través de las cuatro. En la definición, el PM traduce las solicitudes del consumidor en un contrato de servicio delimitado antes de que empiece la ingeniería. En la entrega, el PM mantiene el límite de alcance y es propietario de la comunicación externa. En las operaciones, el PM es propietario de la comunicación de SLA orientada al consumidor y agrega la retroalimentación en datos de producto accionables. En la evolución, el PM distingue los cambios aditivos de los que rompen el contrato, es propietario de la decisión de versionado y negocia el plazo de deprecación con ingeniería y los equipos consumidores. Sin esta función, los servicios se definen de manera ad hoc, se entregan sin criterios de aceptación, se operan sin una relación con el consumidor y se evolucionan sin aviso. Con ella, la plataforma se comporta como un producto que escucha a sus usuarios y gana su confianza a lo largo del tiempo.

La disciplina de producto descrita en este capítulo es una condición previa para lo que describe la Parte 5. La automatización en bucle cerrado toma decisiones de remediación en tiempo real. Las redes auto-recuperables responden a los fallos sin intervención humana. Las redes autónomas toman decisiones de enrutamiento y provisioning en nombre de sus consumidores. Cada una de estas representa la plataforma tomando acciones de las que un consumidor depende sin autorización humana directa para esa acción específica. Sin límites de servicio definidos, estado observable, compromisos de fiabilidad y escalada clara cuando se superan los umbrales, la operación autónoma no es un producto. Es un sistema impredecible que actúa sin contrato. El trabajo de este capítulo es lo que hace que la operación autónoma sea algo en lo que se puede confiar, que es la base sobre la que se construye la Parte 5.

Referencias y Lectura Adicional#

• Continuous Delivery, Jez Humble, Dave Farley (Addison-Wesley, 2010). El texto fundacional sobre el ciclo de vida de entrega de software: cómo construir pipelines de despliegue que hacen del lanzamiento una operación fiable y de bajo riesgo. Los patrones de ciclo de vida del servicio en este capítulo, desde el desarrollo hasta la operación en producción, se basan en estos principios aplicados a la automatización de red.

• The Art of SLOs, Google SRE Workbook (disponible en sre.google). La guía práctica para definir objetivos de nivel de servicio, presupuestos de errores y la relación entre compromisos de fiabilidad y velocidad de funcionalidades. El modelo de SLA interno de la sección 14.4 aplica estos principios a las plataformas de automatización que dan servicio a consumidores internos.

• Empowered, Marty Cagan (Wiley, 2020). Un marco de gestión de producto para organizaciones técnicas: cómo organizar equipos alrededor de resultados en lugar de funcionalidades, cómo definir lo que significa “hecho” para un equipo de producto, y cómo mantener la alineación estratégica entre el trabajo de ingeniería y las prioridades de negocio. El rol de Product Manager de Automatización de Red descrito en la sección 14.6.1 se basa en este marco.

• Team Topologies, Matthew Skelton, Manuel Pais (IT Revolution Press, 2019). Referenciado en el Capítulo 13, sigue siendo relevante aquí: el modelo de equipo de plataforma, donde una plataforma de automatización da servicio a equipos alineados con flujos como consumidores internos, es la estructura organizativa que el modelo de producto en este capítulo está diseñado para soportar.

• Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, Gene Kim (IT Revolution Press, 2018). Investigación empírica sobre lo que separa las organizaciones tecnológicas de alto rendimiento de las de bajo rendimiento. Relevante para la sección 14.4: los datos muestran que los consejos de aprobación de cambios no están correlacionados con mejores resultados de estabilidad pero sí fuertemente correlacionados con una entrega más lenta, la base de evidencia detrás del Patrón de Automatización Pre-aprobada y el argumento de que la gobernanza de cambios pertenece al momento del diseño del flujo de trabajo, no a cada ejecución.

💬 Found something to improve? Send feedback for this chapter