14. L’Automatització com a Producte#

Sis mesos abans de la conversa que va canviar la manera de treballar de l’equip, l’equip de plataforma de xarxa havia lliurat quelcom genuïnament impressionant. Dos anys d’esforç constant havien produït una plataforma de provisioning que gestionava l’onboarding de sucursals de punta a punta: una interfície d’autoservei per a sol·licituds de llocs, un flux de treball de validació en bucle tancat que detectava errors de configuració abans del desplegament, i un tauler operatiu que feia seguiment de la salut del servei a tres-centes ubicacions. L’equip havia passat de finestres de canvi de vint-i-quatre hores a desplegaments automatitzats de quaranta minuts. N’estaven orgullosos, i tenien raons per estar-ho.

Aleshores, l’equip de desenvolupament de negoci va tancar l’adquisició d’una cadena de botigues. Cent vint noves tendes necessitaven connectivitat de xarxa en sis mesos. El responsable d’infraestructura va enviar un únic correu electrònic: “Comptem amb la plataforma d’automatització per a això. Com ho engeguem?”

La primera resposta interna de l’equip de plataforma de xarxa va ser confiant: podien automatitzar-ho. Els fluxos de treball existien. Les plantilles existien. Les eines eren provades.

La seva segona resposta, quan van intentar respondre el correu, va ser menys confident. El responsable d’infraestructura no estava preguntant si l’automatització era tècnicament possible. Estava fent un conjunt de preguntes diferent: Quin és el SLA per a l’onboarding de botigues, concretament el compromís de quan una botiga obté connectivitat després que s’enviï la informació del lloc? Qui és el camí d’escalada quan un desplegament falla a mitges? Hi ha una pàgina d’estat o un tauler que l’equip del responsable d’infraestructura pugui monitoritzar sense preguntar directament a l’equip de xarxa? Quina és la capacitat de la plataforma: pot gestionar vint desplegaments simultanis, o caldrà processar les sol·licituds per lots? I la pregunta més incòmoda: què passa amb les botigues que van fer l’onboarding durant un incident de plataforma, es remedien automàticament o algú ha d’auditar-les una per una?

L’equip de xarxa tenia automatització. No tenia respostes (en termes de negoci i de producte).

Aquesta bretxa, entre “hem construït automatització que funciona” i “proporcionem un servei del qual altres equips poden dependre i planificar”, és el tema d’aquest capítol.

Aquest és un tema que m’apassiona. Una sessió que vaig impartir a Autocon3 cobreix això des d’una perspectiva d’automatització orientada al disseny i és una referència complementària a aquest capítol.

14.1 De Capacitat a Producte#

El Capítol 13 va descriure com els equips transformen les seves persones, els seus rols i les seves maneres de treballar per construir l’automatització com a capacitat organitzativa. Aquesta transformació és necessària. No és suficient.

Una capacitat és quelcom que l’equip pot fer. Un producte és quelcom del qual altres equips (o eventualment, entitats externes) poden dependre. La distinció no és sobre qualitat tècnica: la plataforma d’onboarding de la cadena de botigues era tècnicament excel·lent. La distinció és sobre la relació entre el proveïdor i el consumidor. Una capacitat existeix per als seus autors. Un producte existeix per als seus usuaris.

La producció de l’equip de xarxa ha canviat. Abans de l’automatització, la producció era la configuració de dispositius: un router proveït, una VLAN estesa, una ACL aplicada. El consumidor d’aquesta producció era el propi dispositiu, i l’evidència de l’èxit era un ping que responia o una aplicació que funcionava. Amb l’automatització, la producció canvia: el producte de l’equip de xarxa és un servei de xarxa consumit per altres equips. Cada interacció amb la xarxa, aprovisionar un lloc de sucursal, expandir un segment per a una nova aplicació, aplicar una política de seguretat, concedir temporalment accés de conferència a una VLAN, afegir una connexió de peering en un intercanvi d’internet, es converteix en una sol·licitud de servei en lloc d’un tiquet de canvi. La configuració del dispositiu és el detall d’implementació. El servei és l’artefacte.

Aquest és el patró Servei de Xarxa com a Producte (Network Service as Product): el servei és l’artefacte primari, i la xarxa subjacent és la implementació. Això no és nou en l’enginyeria de programari: les APIs abstrauen la infraestructura, i el cridador no sap ni li importa quins servidors gestionen la sol·licitud. No obstant, és un canvi significatiu per als equips de xarxa que històricament han organitzat el seu treball al voltant de dispositius, proveïdors i protocols. L’enginyer que definia la seva identitat al voltant de l’habilitat de configuració de routers ara se li demana que defineixi la seva identitat al voltant de la capacitat de lliurament de serveis. Aquesta reformulació connecta directament amb el Dilema de l’Artesà del Capítol 13, secció 13.1: l’expert en l’ofici antic és la persona que necessita fer la reformulació de manera més urgent, i l’enginyer que la fa completament es torna més valuós, no menys.

La llar tècnica d’aquest producte és el bloc de Presentació descrit al Capítol 8. La interfície d’autoservei, la superfície d’API, la integració de webhooks, el model d’accés basat en rols: aquí és on el contracte de servei és visible per als consumidors. El Capítol 14 fa zoom enrere des de la interfície tècnica cap al model organitzatiu i de negoci que l’envolta. Quins compromisos vénen amb la interfície? Qui és el propietari quan falla? Com evoluciona el servei? Qui decideix què fa a continuació?

14.2 Definint el Producte#

Dos modes de fallada apareixen de manera constant quan els equips intenten convertir l’automatització de xarxa en serveis.

El primer és la sobreexposició: la interfície revela detalls d’implementació, i els consumidors han d’entendre les interioritats de la xarxa per usar-la. Un servei de provisioning de sucursals que demana un ID de VLAN, una màscara de subxarxa i un número d’àrea OSPF no és un servei: és un CLI amb un formulari web. El consumidor, que és un coordinador d’instal·lacions de la cadena de botigues, no sap què és un àrea OSPF i no hauria de necessitar saber-ho.

El segon és la sobrerestricció: la interfície és tan limitada que només gestiona els casos d’ús exactes que l’equip de xarxa va anticipar. Qualsevol sol·licitud que es desviï de la plantilla requereix un procés d’excepció. El coordinador d’instal·lacions que necessita aprovisionar una botiga temporal amb un requisit de connectivitat diferent al d’una ubicació minorista permanent no pot fer-ho en autoservei. Obre un tiquet. El tiquet va a l’equip de xarxa. El benefici de l’automatització no ha arribat a aquest consumidor.

El Patró de Contracte de Servei (Service Contract Pattern) resol ambdós modes de fallada en fer la definició de la interfície explícita, versionada i deliberadament delimitada. Un contracte de servei té tres components:

• Superfície d’entrada: allò que proporciona el consumidor, expressat en termes de negoci, no en termes de xarxa (disculpeu la insistència, però això és clau). Una sol·licitud de lloc de sucursal pren un nom d’ubicació, una adreça física, un nivell de lloc (estàndard, petit, temporal) i una data d’activació. No pren un ID de VLAN. El contracte tradueix la intenció de negoci en implementació de xarxa internament, i aquesta traducció és responsabilitat de la plataforma d’automatització. Les definicions de nivell no són permanents: un nivell temporal definit per a un quiosc minorista temporal no cobrirà un espai d’esdeveniments temporal amb requisits de connectivitat diferents. La superfície d’entrada ha de revisar-se amb els equips consumidors amb la mateixa cadència que el full de ruta, de manera que els nivells reflecteixin casos d’ús reals en lloc dels casos d’ús que l’equip de xarxa va anticipar quan es va escriure per primera vegada el contracte.

• Superfície de sortida: allò que observa el consumidor, incloent tant la compleció exitosa com el fracàs. Una superfície de sortida ben dissenyada no exposa “el desplegament ha fallat al pas 7 de 14: el push de gNMI ha estat rebutjat amb el codi d’error 400”. Exposa “l’activació ha fallat: el circuit físic en aquesta adreça encara no ha estat proveït pel portador. Data estimada de compleció: [data del SoT]. No cal cap acció per part vostra; el sistema tornarà a intentar-ho automàticament quan el circuit estigui operatiu”. L’automatització no simplement té èxit o falla: emet esdeveniments de cicle de vida observables en termes que el consumidor entén.

• Dependències internes: allò que el servei fa seguiment internament i que els consumidors no haurien de veure però que l’equip ha de gestionar. L’estat del circuit del portador. Els serveis veïns que comparteixen infraestructura amb aquest. La relació de consistència entre el registre del SoT del nou lloc i els registres d’inventari que impulsen el monitoratge automatitzat. Quan un circuit entra en manteniment del portador, l’equip de xarxa necessita saber quins serveis es veuen afectats i quina exposició d’SLO crea. El consumidor pot necessitar saber l’impacte en el seu servei; no necessita conèixer el detall d’implementació que el va causar.

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["Interfície del Consumidor"]
        IN["Superfície d'Entrada<br/>Ubicació, nivell, data<br/>Intenció de negoci"]
        OUT["Superfície de Sortida<br/>Estat, esdeveniments de cicle de vida<br/>Llenguatge de negoci"]
    end

    subgraph Contract["Contracte de Servei"]
        TRANS["Capa de Traducció<br/>Intenció a implementació<br/>VLAN, subxarxa, àrea OSPF"]
    end

    subgraph Internal["Dependències Internes"]
        CIRC["Estat del circuit"]
        SOT["Consistència del SoT"]
        NEIGHBOR["Serveis veïns"]
    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

Amb el contracte de servei definit, la propera pregunta és què passa amb ell amb el temps.

La qüestió del cicle de vida és on molts equips inverteixen poc. Un contracte de servei no tracta només el moment del provisioning. Què passa amb aquest servei quan canvia la infraestructura subjacent? Un lloc de sucursal que funciona sobre un circuit que entra en manteniment programat del portador té un impacte d’SLO previst. Qui sap sobre aquest impacte, qui decideix si notificar a l’equip d’operacions de la cadena de botigues, i qui és propietari de la comunicació si la finestra de manteniment s’allarga? Aquestes preguntes requereixen que els serveis siguin entitats de primera classe al Source of Truth.

El SoT del Capítol 4 descriu la intenció com el registre autoritatiu del que hauria de ser la xarxa. Els serveis, en el model de producte, estenen aquesta intenció cap amunt: no només com haurien de ser els elements de la xarxa, sinó quines funcions de negoci lliuren aquests elements i a qui. Un SoT que modela dispositius i circuits però no serveis no pot respondre la pregunta “quines botigues minoristes es veuen afectades per aquest manteniment de circuit?” No pot alimentar els mapes de dependències que fan possible la gestió de canvis conscient dels serveis. El bloc d’Orquestració del Capítol 7 depèn d’aquest graf de dependències en coordinar la remediació: un flux de treball en bucle tancat que respon a una fallada de circuit necessita saber quins serveis es veuen afectats abans de poder enrutar notificacions i disparar la seqüència de recuperació correcta.

Aquesta és precisament l’abstracció que la secció 4.2.2 del Capítol 4 formalitza com el bloc orientat al disseny: un operador proporciona una intenció d’alt nivell (“afegir una sucursal”) i el SoT l’expandeix en els cinquanta o més objectes tècnics que l’Executor necessita abans de tocar un dispositiu. El model de servei del Cap. 14 estén aquest mateix principi un nivell per sobre, de “quins objectes tècnics han d’existir” a “quina funció de negoci lliuren aquests objectes, i a qui”. El SoT que va ser dissenyat per abstraure la sintaxi de dispositius dels operadors pot igualment abstraure les interioritats de la xarxa dels consumidors de serveis, si els serveis estan modelats com a objectes de primera classe dins d’ell.

La conseqüència pràctica: els serveis han d’estar modelats al SoT amb les seves cadenes de dependències. El servei de lloc de sucursal depèn d’un circuit físic, que depèn d’un proveïdor, que té un historial de finestres de manteniment. El servei de segment de xarxa depèn d’un conjunt de commutadors d’accés. El servei de peering en l’intercanvi d’internet depèn d’una sessió BGP, que depèn d’un port físic, que viu en una instal·lació específica. Quan qualsevol dependència canvia d’estat, el model de servei s’actualitza, i el consumidor afectat pot ser notificat en termes que entén.

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["Servei de Lloc de Sucursal<br/>Botiga 847"]
    S2["Servei de Connectivitat d'Aplicació<br/>Sistema d'Inventari"]

    C1["Circuit<br/>Proveïdor X, CID-44821"]
    SW1["Commutador d'Accés<br/>bldg-b-sw-01"]
    BGP1["Sessió BGP<br/>AS64501"]
    PORT1["Port Físic<br/>rack-14-u32"]

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

    MAINT["Finestra de Manteniment del Portador<br/>2026-06-15 02:00 UTC"]
    C1 -.->|"afectat per"| MAINT

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

Els serveis de xarxa que l’equip hauria de poder modelar d’aquesta manera inclouen: activació de nous llocs de sucursal, accés temporal de xarxa per a una conferència o esdeveniment efímer, connectivitat d’aplicació amb ACLs que apliquen regles de dependència, expansió de peering d’internet en un punt d’intercanvi, i extensió de VLAN per a un nou segment de projecte. Cadascun d’aquests té un consumidor de negoci, un cicle de vida, dependències i una definició significativa de salut i fallada.

La majoria dels equips que construeixen aquest model no comencen amb una pissarra en blanc. La xarxa existent ja té tres-centes sucursals, anys de canvis de configuració acumulats, i un SoT que modela dispositius i circuits però no serveis. Abans que aquests llocs existents puguin participar en el model de servei, el seu estat real ha de ser descobert i reconciliat amb el que el SoT creu que és cert. Un lloc la configuració en execució del qual ha derivat del seu registre al SoT no es pot gestionar de manera segura sota el cicle de vida automatitzat fins que no es resolgui aquesta deriva: l’automatització aplicarà configuracions basades en la visió del SoT de la intenció, i si aquesta visió és errònia, l’aplicació empitjorarà les coses. El descobriment i la reconciliació, llegint l’estat del dispositiu i comparant-lo amb els registres del SoT per identificar i resoldre bretxes, és el pas previ per als entorns brownfield. Aquest treball no és glamurós i porta temps, però ometre’l significa que el model de servei només és vàlid per als llocs aprovisionats després que es va construir la plataforma, que normalment és una fracció petita de la xarxa.

Modelar serveis al SoT és necessari però no suficient: l’equip també necessita observar-los al nivell correcte. El bloc d’Observabilitat del Capítol 6 tanca el bucle: l’observabilitat a nivell de servei, fent seguiment de si un servei és saludable des de la perspectiva del consumidor, és diferent de l’observabilitat a nivell de dispositiu, fent seguiment de si la infraestructura subjacent és saludable. Ambdues són necessàries. Un servei pot semblar degradat al seu consumidor mentre tots els dispositius subjacents informen d’estar sans, si el model de servei no està instrumentat al nivell correcte.

14.3 Alineació amb el Negoci#

L’argument tradicional per a l’automatització de xarxa se centra en l’eficiència operativa: menys tiquets, provisioning més ràpid, taxes d’error més baixes. Aquest argument és cert i útil per justificar la inversió inicial. No és suficient per mantenir la inversió estratègica al llarg del temps.

L’eficiència operativa es mesura contra la línia de base actual. Un equip que redueix el temps de provisioning manual de quatre hores a quaranta minuts ha demostrat una millora significativa en el rendiment. El líder de la unitat de negoci que va aprovar el pressupost fa tres anys està satisfet però no és estratègicament compromès: l’equip de xarxa funciona millor, i això és bo, però no és una raó per invertir més.

L’argument més fort és la capacitat: l’automatització permet resultats de negoci que d’altra manera serien impossibles o prohibitivament costosos. L’expansió de la cadena de botigues és un exemple concret. Sense una plataforma d’automatització madura, l’onboarding de cent vint botigues en sis mesos requereix un equip d’enginyers de xarxa dedicats a aquest projecte durant sis mesos. Assumint una taxa agressiva de provisioning manual d’aproximadament una botiga per enginyer per dia (un número que varia significativament depenent del tipus de connectivitat, el recompte de dispositius, el temps de coordinació amb el portador i si els reconeixements de lloc estan completats), es tracta d’un equip d’aproximadament vuit persones sense altres responsabilitats. Amb una plataforma d’automatització madura, el mateix treball és gestionat per l’equip existent executant fluxos de treball automatitzats en paral·lel. El resultat de negoci, expansió completada en sis mesos a un cost acceptable, només és assolible perquè existeix l’automatització. Aquest no és un argument d’eficiència. És un argument de capacitat. Un argument de negoci.

Un segon exemple: una organització que executa entrenament de models d’IA a gran escala depèn de la latència i la fiabilitat del provisioning d’interconnexió. Si posar en marxa un nou clúster d’entrenament requereix dues setmanes de provisioning manual de xarxa, la capacitat del negoci d’executar experiments d’entrenament a velocitat competitiva està limitada pel rendiment de l’equip de xarxa. L’automatització que redueix el provisioning de dues setmanes a quaranta-vuit hores és una entrada directa a una capacitat de negoci que la unitat de negoci considera estratègica. L’equip de xarxa que no pot articular aquesta connexió està deixant influència sobre la taula.

Un tercer exemple: un proveïdor de serveis els enginyers del qual configuren manualment routers PE, instàncies VRF, sessions BGP amb dispositius CE de clients i polítiques de QoS per a cada nou contracte MPLS VPN empresarial tarda quatre setmanes des de l’acceptació de la comanda fins al servei actiu. Aquest termini no és un problema d’operacions: és un problema de vendes. Els competidors que han automatitzat la mateixa seqüència de provisioning, generant configuracions consistents a partir d’una sol·licitud de servei, validant-les contra la topologia existent i aplicant-les a través d’un flux de treball provat, prometen posades en marxa en dues setmanes en les respostes a peticions de proposta. El proveïdor de quatre setmanes no pot igualar aquest compromís independentment de com de qualificats siguin els seus enginyers, perquè la restricció no és l’habilitat: és la naturalesa sèrie i manual del procés de provisioning. L’automatització que comprimeix la posada en marxa de quatre setmanes a tres dies canvia el que l’equip de vendes pot prometre, la qual cosa canvia quins contractes l’empresa pot guanyar. Aquest no és un argument d’eficiència. És un argument d’ingressos, i pertany a la conversa sobre si invertir en la plataforma d’automatització.

La seqüència del raonament importa. L’automatització dissenyada des del comportament del dispositiu cap amunt, commençant per “què podem automatitzar de la configuració del router” i treballant cap a “què obté el negoci d’això”, sovint no pot articular el valor de negoci perquè mai va ser dissenyada per lliurar un resultat de negoci. L’automatització dissenyada des de la capacitat de negoci cap avall, commençant per “quins resultats de negoci requereixen serveis de xarxa fiables” i treballant cap enrere a través del disseny de serveis cap a l’automatització que implementa aquests serveis, pot connectar el seu treball amb les prioritats de negoci des de la primera conversa.

El patró Mapa de Serveis Orientat al Negoci (Business-Driven Service Map) fa explícita aquesta connexió: un mapatge de serveis de xarxa cap a les capacitats de negoci que habiliten. Per a cada servei de xarxa, el mapa respon tres preguntes: quins processos de negoci depenen d’aquest servei, quin és l’impacte de negoci si aquest servei es degrada o no està disponible, i quina capacitat de negoci seria possible si aquest servei fos més ràpid, més fiable o en autoservei. Aquest és el document que un Product Manager d’Automatització de Xarxa posseïria, i és l’instrument primari per alinear el full de ruta d’automatització amb les prioritats de negoci.

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["Capacitats de Negoci"]
        B1["Expansió Minorista"]
        B2["Velocitat d'Entrenament d'IA"]
        B3["Operacions d'Esdeveniments"]
    end

    subgraph SVC["Serveis de Xarxa"]
        S1["Activació de Sucursal"]
        S2["Provisioning d'Interconnexió"]
        S3["Accés Temporal"]
    end

    subgraph AUTO["Automatització"]
        A1["Flux de Treball d'Onboarding de Lloc"]
        A2["Provisioning de Circuit i BGP"]
        A3["Cicle de Vida de VLAN de Conferència"]
    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

Aquesta reformulació és incòmoda per a molts equips de xarxa, perquè requereix mesurar coses diferents. Les mètriques operatives (tiquets tancats, taxa d’èxit de canvis, Mean Time To Resolution (MTTR)) estan dins del control de l’equip i són fàcils d’instrumentar. Les mètriques de resultat de negoci (temps per obrir una nova ubicació minorista, latència de provisioning d’interconnexió com a entrada al rendiment de l’entrenament) requereixen col·laboració amb altres unitats de negoci i una comprensió del que realment mesuren. L’equip que fa aquest canvi, de mesurar l’excel·lència tècnica a mesurar la contribució de negoci, respon una pregunta diferent en les converses de pressupost: no “com hem gestionat la xarxa d’una manera eficient aquest trimestre” sinó “quins resultats de negoci van dependre de la plataforma de xarxa aquest trimestre, i què hauria fallat sense ella”. És una pregunta més difícil de respondre, però és la que determina si la plataforma s’obté finançament per a la propera fase.

El principi de Mesura d’Impacte sobre Mesura d’Eficiència (Impact Measurement over Efficiency Measurement) segueix: prioritzar la mesura dels resultats que importen al negoci per sobre de les mètriques operatives que importen només a l’equip de xarxa. Les mètriques d’eficiència són entrades. Els resultats són el que li importa al negoci.

Aquesta reformulació també canvia el que l’equip demana en els cicles de planificació. Un equip que presenta “hem reduït el MTTR un 40%” informa sobre el seu propi rendiment. Un equip que presenta “el termini d’expansió minorista és assolible perquè la nostra automatització d’onboarding pot gestionar quaranta activacions concurrents sense intervenció manual” informa sobre la capacitat de negoci. Ambdós fets poden ser certs. Només un d’ells és rellevant per a la decisió sobre si dotar de personal el projecte d’expansió minorista.

14.4 L’SLA Intern#

Una plataforma d’automatització de la qual depenen altres equips sense compromisos de fiabilitat és una trampa de confiança. Funciona fins que no funciona, i l’equip consumidor no té dades per planificar. El responsable d’infraestructura de la cadena de botigues que programa vint sol·licituds simultànies d’activació de sucursals un dilluns al matí necessita saber, abans del dilluns al matí, quin serà el comportament de la plataforma: quant de temps trigarà cada activació, poden executar-se vint en paral·lel o s’encuaran, què passa si una falla a mitja implementació, i com comunicarà la plataforma aquesta fallada?

Aquestes són preguntes d’SLA. En el model de producte, cada servei d’automatització porta un SLA explícit, no com a protecció legal sinó com el contracte operatiu que fa el servei planificable.

Un SLA d’automatització té quatre components:

• Disponibilitat: el percentatge de temps que la interfície de servei és accessible i accepta sol·licituds. Un servei d’activació de sucursals amb una disponibilitat mensual del 99,5% té aproximadament tres hores i mitja de temps de falla permès per mes. Aquesta xifra és un compromís: quan el servei és inactiu, l’equip deu una explicació i un termini de recuperació.

• Latència d’execució: quant de temps triga el servei a complir una sol·licitud des de l’enviament fins a la compleció. Per a l’activació de sucursals, això podria ser: confirmació en trenta segons, provisioning iniciat en cinc minuts, compleció en quaranta minuts per a un lloc estàndard. Aquests números defineixen com es veu “funcionant”, no només si el servei és accessible.

• Pressupost d’errors: amb quina freqüència pot fallar el servei sense violar l’SLA. Un servei amb un 99% de completions exitoses per setmana té un pressupost d’errors d’un per cent. Quan més de l’u per cent de les activacions fallen en una setmana, alguna cosa va malament i l’equip deu una revisió. El rol d’NRE descrit a la secció 13.2 del Capítol 13 és la persona que és propietària de definir i defensar aquests pressupostos, i el model de pressupost d’errors de la literatura d’SRE s’aplica directament: quan el pressupost d’errors es consumeix, els nous desplegaments d’automatització es pausen fins que es restauri la fiabilitat.

SRE (Enginyeria de Fiabilitat de Llocs) és una disciplina originada en les operacions de programari a gran escala que aplica principis d’enginyeria a la fiabilitat: definir objectius de nivell de servei, mesurar pressupostos d’errors i usar dades de fiabilitat per governar la velocitat de funcionalitats. El rol d’NRE (Enginyer de Fiabilitat de Xarxa) adapta aquests principis a les plataformes d’automatització de xarxa. Ambdós rols i la seva aplicació als equips de xarxa es cobreixen en detall a la secció 13.2 del Capítol 13.

• Camí d’escalada: quan el servei falla o no compleix el seu SLA, a qui truca el consumidor, i quin és el temps de resposta esperat. Un camí d’escalada que va a la bústia general de l’equip de xarxa no és un camí d’escalada: és una cua de tiquets. Un SLA de producte requereix un contacte d’escalada nomenat o basat en rols amb un compromís de resposta definit.

La pregunta del model de suport segueix naturalment: quan l’automatització falla, qui és el seu propietari? Tres modes de fallada apareixen en gairebé tots els incidents, i confondre quin és l’actiu porta que els incidents caiguin entre equips.

La superposició entre aquestes categories és on els incidents es perden. Un flux de treball d’automatització que falla perquè el push de gRPC Network Management Interface (gNMI) va ser rebutjat podria ser un error d’automatització (model de dades incorrecte), una fallada de plataforma (el col·lector gNMI ha perdut la seva sessió), o una fallada de xarxa (el dispositiu s’ha reiniciat durant el push). El procés de resposta a incidents ha de ser dissenyat per classificar entre aquestes categories sense requerir que l’equip consumidor entengui quina és l’activa. Des de la perspectiva de la cadena de botigues, la botiga no ha obtingut connectivitat. Qui ho soluciona i quan és el problema del proveïdor, no el seu.

Una seqüència pràctica de triatge per a qualsevol fallada d’automatització segueix tres passos. Primer, comprovar els registres d’automatització: el flux de treball ha informat d’un error, i és aquest error consistent a través de múltiples execucions de la mateixa entrada o específic a una? La fallada consistent en una entrada específica apunta a un error d’automatització; la fallada aleatòria o intermitent apunta a un altre lloc. Segon, comprovar la salut de la plataforma: estan fallant simultàniament altres serveis no relacionats, i el motor d’execució, el SoT i la pila d’observabilitat informen d’estar sans? La fallada àmplia simultània a través de serveis no relacionats és una signatura de fallada de plataforma, independentment del que diguin els registres del flux de treball. Tercer, comprovar l’estat del dispositiu: l’element de xarxa ha rebut i aplicat la configuració pretesa, i el seu estat actual coincideix amb el que l’automatització va intentar aplicar? Si el flux de treball s’ha completat sense error però la xarxa no ha convergit, la fallada és a la capa de xarxa. Aquesta seqüència pot codificar-se com els tres primers passos d’un runbook automatitzat, de manera que l’enginyer de guàrdia arribi a un incident amb el triatge ja fet en lloc de començar des de zero.

La referència a l’equip de plataforma en el segon mode de fallada connecta amb el Capítol 10: la fiabilitat de la plataforma és una condició prèvia per als SLAs de servei. Un servei no pot comprometre’s a una disponibilitat del 99,5% si el motor d’execució sobre el qual s’executa no té cap objectiu de fiabilitat. Els patrons d’enginyeria de plataforma del Capítol 10, redundància, monitoratge de salut, recuperació automatitzada, són els que fan creïbles els SLAs d’automatització.

Dissenyar el camí d’escalada abans que passi l’incident. La conversa post-incident sobre qui era el propietari de cada cosa és sempre més difícil que la conversa pre-incident que va establir fronteres clares.

El radi d’explosió és una preocupació de disseny relacionada que pertany a la mateixa conversa pre-incident. Un error de provisioning manual afecta un lloc perquè un enginyer configura un lloc alhora. Un error d’automatització pot afectar tots els llocs que coincideixen amb el patró d’entrada abans que cap humà noti que alguna cosa va malament. La resposta a això no és alentir l’automatització: és dissenyar límits de concurrència i desplegament per etapes en el contracte de servei com a opcions de seguretat deliberades, no com a detalls d’implementació. Un servei d’activació de sucursals que limita els desplegaments concurrents a cinc treballs actius, valida el primer desplegament fins a la compleció abans d’alliberar el proper lot, i es deté en qualsevol treball fallat fins que un humà l’aprovi no és un servei lent: és un servei el radi d’explosió del qual està delimitat per disseny. Aquesta delimitació hauria d’aparèixer en el contracte de servei, juntament amb la disponibilitat i la latència d’execució, de manera que els equips consumidors entenguin tant el que la plataforma pot fer com el que es negarà a fer per protegir-los. El responsable d’infraestructura de la cadena de botigues que entén que la plataforma pausarà un desplegament de quaranta botigues després de la primera fallada, en lloc de completar trenta-nou desplegaments més sobre una plantilla defectuosa, confiaran més en la plataforma, no menys.

L’existència de compromisos d’SLA, controls de radi d’explosió i un marc de triatge crea les condicions per a una relació diferent amb la governança de canvis. En organitzacions que operen sota la gestió de canvis tradicional, cada canvi de xarxa, inclosos els automatitzats, pot ser enrutat a través d’un Consell Assessor de Canvis per a l’aprovació prèvia. Aquest procés va ser dissenyat per a un món on cada canvi és únic, fet a mà i imprevisible: la persona adequada revisant un canvi manual d’un enginyer humà afegeix genuïna reducció de riscos perquè el judici humà varia. La mateixa lògica aplicada a un flux de treball automatitzat que ha estat dissenyat, provat en un entorn de pre-producció, validat contra el SoT, restringit per límits de radi d’explosió i executat exitosament desenes de vegades no afegeix reducció de riscos: afegeix latència a una operació el perfil de risc de la qual es va establir abans que s’executés mai en producció.

El Patró d’Automatització Pre-aprovada (Pre-Approved Automation Pattern) resol això: l’aprovació de canvis s’aplica una vegada al disseny del flux de treball, no repetidament a cada execució d’aquest flux de treball. Quan un flux de treball d’activació de sucursals ha passat les seves etapes de validació, ha estat revisat i aprovat per les parts interessades d’enginyeria i operacions rellevants, i s’ha desplegat a producció amb les seves restriccions de seguretat actives, cada execució posterior d’aquest flux de treball no és un nou canvi que requereixi nova aprovació. És una instància d’una operació ja aprovada i delimitada. La pregunta de governança apropiada és “és aquesta execució dins de l’envolupant aprovat?” no “hauria de passar aquesta execució?” Un proveïdor de núvol no requereix que un humà aprovi cada sol·licitud de creació de xarxa virtual: el servei va ser dissenyat amb les restriccions apropiades, provat a fons i aprovat com a servei. Les sol·licituds individuals de clients dins d’aquest límit de servei no són esdeveniments de canvi que requereixin revisió. Són invocacions de servei. Els serveis d’automatització de xarxa, un cop dissenyats i aprovats adequadament, haurien de funcionar de la mateixa manera. El treball que justifica aquesta confiança és exactament el que descriuen les seccions 14.2 a 14.4: contractes de servei explícits, sortides observables, radi d’explosió delimitat i un camí de triatge definit quan alguna cosa va malament. Aquest treball és l’aprovació de canvis, feta una vegada, en el moment adequat.

14.5 Rendiment, Cost i ROI#

L’automatització té costos. Infraestructura de còmput per al motor d’execució, l’orquestrador i la pila d’observabilitat. Emmagatzematge per a registres del SoT, historial de treballs i telemetria. Temps d’enginyeria per construir, provar i mantenir el codi d’automatització (i els tokens d’IA de codificació corresponents per donar-li suport). Llicències d’eines per als components comercials de la plataforma. Càrrega de suport quan els consumidors presenten problemes o sol·liciten noves capacitats. Aquests costos són reals i recurrents.

La qüestió del ROI també és real, i els equips de xarxa que l’eviten cedeixen les decisions de pressupost als equips de finances i adquisicions que la respondran amb menys precisió. El marc té tres components:

• Cost de l’automatització: el cost complet de construir i executar la plataforma. Salaris d’enginyeria assignats al desenvolupament i manteniment de la plataforma, costos d’infraestructura (còmput, emmagatzematge, xarxes per a la pròpia infraestructura d’automatització), llicències d’eines i sobrecàrrega operativa. Aquesta xifra és cognoscible i l’equip hauria de conèixer-la.

• Cost de l’equivalent manual: el que costaria lliurar els mateixos serveis sense automatització. Per a l’activació de sucursals, es tracta d’hores d’enginyeria per lloc multiplicades pel cost per hora dels enginyers que ho farien, més el cost dels errors (incidents causats per errors de provisioning manual, mesurats en Mean Time To Resolution (MTTR) i serveis afectats). Per a l’expansió de la cadena de botigues, el cost manual és prou gran per fer la inversió en automatització òbviament justificada. Per a un servei de baix volum proveït dues vegades a l’any, el càlcul és diferent.

• Valor de les capacitats desblocades: els resultats de negoci que no serien possibles sense automatització. Aquest és el component més difícil de quantificar i l’argument de major valor a presentar. Cent vint botigues en sis mesos no és qüestió d’eficiència: és una capacitat binària. Sense automatització, no succeeix en aquest termini independentment del pressupost d’enginyeria. L’equip de xarxa que pot declarar clarament “el termini d’expansió minorista depèn de la nostra plataforma d’automatització” participa en una conversa estratègica, no en una negociació de pressupost.

Tres eixos defineixen l’espai de disseny de qualsevol servei d’automatització, i cadascun representa un compromís que el model de producte posa en evidència:

• Velocitat: com de ràpid és el servei des de l’enviament de la sol·licitud fins a la compleció?
• Seguretat: com de fiablement el servei evita empitjorar les coses, a través de validació, etapes de prova en sec i camins de retrocés?
• Utilització: quantes sol·licituds concurrents pot gestionar la plataforma sense degradació?

Aquests eixos estan en tensió. Maximitzar la seguretat mitjançant validació exhaustiva i etapes d’execució supervisades afegeix latència: un flux de treball més segur és típicament un de més lent. Maximitzar la velocitat reduint etapes de validació augmenta el risc. Maximitzar la utilització concurrent requereix una inversió en infraestructura que pot no estar justificada pel volum real de sol·licituds.

L’enfocament de producte força que aquests compromisos siguin explícits en el contracte de servei. Quan el responsable d’infraestructura de la cadena de botigues pregunta si vint desplegaments simultanis són segurs, la resposta no és “funciona en proves”. La resposta és una declaració concreta sobre el disseny de la plataforma: la capacitat de desplegament concurrent està limitada a vint-i-quatre treballs actius, cada desplegament té un camí de retrocés independent, i el sistema d’observabilitat confirma la convergència exitosa de l’estat abans de marcar un treball com complet. Aquestes declaracions provenen d’un equip que ha pensat en els compromisos com a decisions de disseny de producte, no com a detalls d’implementació d’enginyeria.

La mesura del ROI alimenta directament la priorització. Quina automatització construir a continuació hauria d’estar informada per quins resultats de negoci estan més restringits per les limitacions de xarxa. L’equip que fa seguiment de quines sol·licituds manuals consumeixen més temps d’enginyeria, quins serveis tenen la taxa de fallada més alta durant el provisioning manual, i quines capacitats de negoci estan bloquejades pel rendiment de la xarxa té les dades per fer arguments de priorització que el negoci pot avaluar. L’equip que no té aquestes dades fa arguments de priorització basats en el que és tècnicament interessant, i aquests arguments perden cicles de pressupost davant equips que han quantificat el seu impacte.

14.6 Priorització i Full de Ruta#

Dos preguntes s’enfronten a cada equip d’automatització de xarxa constantment i rarament es responen formalment: quines tasques automatitzar a continuació, i quan dir no a una sol·licitud. El model de producte requereix respostes formals a ambdues. Aquestes són les categories de priorització:

• Impacte de negoci: quin servei, quan s’automatitza, habilita la capacitat de negoci de major valor? El Mapa de Serveis Orientat al Negoci de la secció 14.3 és l’entrada a aquesta pregunta. El servei que, quan s’automatitza, desbloqueja una iniciativa de negoci estratègica es classifica per sobre del servei que, quan s’automatitza, estalvia dotze hores d’enginyeria a l’any.

• Freqüència per esforç: amb quina freqüència es fa aquesta tasca manualment, i quant de temps d’enginyeria pren cada ocurrència? Una tasca feta diàriament que pren quatre hores cada vegada té dues-centes vegades el ROI d’una tasca feta setmanalment que pren trenta minuts. Les tasques manuals d’alta freqüència amb esforç significatiu per ocurrència són els casos més clars per a l’automatització.

• Reducció de riscos: algunes tasques val la pena automatitzar-les fins i tot si són poc freqüents, perquè el cost de l’error humà és catastròfic. Els canvis manuals de peering BGP que, quan es configuren malament, causen fuites de rutes que afecten centenars de clients, val la pena automatitzar-los fins i tot si succeeixen només sis vegades a l’any. L’automatització es justifica no pel rendiment sinó per eliminar un mode d’error amb conseqüències inacceptables.

• Demanda del consumidor: què estan sol·licitant activament altres equips? La demanda del consumidor és un senyal imperfecte, perquè els equips sovint sol·liciten el que saben que és possible en lloc del que seria més valuós. Però les sol·licituds constants dels mateixos equips per a la mateixa capacitat són dades significatives sobre on la interfície de servei no s’adequa als casos d’ús reals.

El patró Backlog d’Automatització (Automation Backlog) tracta les tasques no automatitzades de la mateixa manera que un equip de producte tracta un backlog de funcionalitats: prioritzat, estimat, i amb criteris d’acceptació clars sobre el que significa “fet”. Fet no és “l’automatització s’ha executat amb èxit al laboratori”. Fet és “l’automatització ha superat les etapes de l’Escala de Confiança (Confidence Ladder) descrites a la secció 13.5.2 del Capítol 13, està documentada i està disponible per al consum en autoservei pels equips consumidors rellevants”. El backlog és visible per a les parts interessades, de manera que puguin veure el que ve i planificar en conseqüència.

La comunicació del full de ruta importa més que el propi full de ruta. Un full de ruta d’automatització de xarxa compartit amb els equips dependents en una cadència trimestral és un senyal de confiança. Fa llegible el treball de l’equip d’automatització per al negoci. Permet als equips consumidors planificar el seu propi treball al voltant del que la plataforma podrà i no podrà fer el proper trimestre. Crea l’oportunitat de retroalimentació perquè els equips consumidors posin en evidència requisits que l’equip de xarxa no sabia que existien.

Els bucles de retroalimentació dels consumidors i les parts interessades són l’entrada més valuosa per a les decisions del full de ruta. Quins equips presenten les excepcions més freqüents? Quines sortides d’automatització requereixen interpretació manual abans que el consumidor pugui actuar sobre elles? On força la interfície de servei actual als consumidors a enviar sol·licituds en termes de xarxa en lloc de termes de negoci? Aquests són senyals de retroalimentació de producte, i capturar-los sistemàticament és el que separa un full de ruta que reflecteix les necessitats reals del consumidor d’un que reflecteix el que l’equip d’automatització creu que els consumidors haurien de voler.

La cadència de les reunions amb les parts interessades val la pena nombrar-la explícitament. Una reunió recurrent, trimestral per a la majoria de plataformes i mensual per a plataformes en desenvolupament actiu, on es revisa el full de ruta, es recull la retroalimentació del consumidor i es comuniquen els propers canvis, no és una reunió d’estat. És el mecanisme pel qual una plataforma d’automatització es comporta com un producte que escolta els seus usuaris. Els equips que salten aquest pas construeixen automatització que soluciona el problema de l’any passat mentre consumeix el pressupost d’enguany.

14.6.1 La Funció de Gestió de Producte#

No tots els equips necessiten un Product Manager dedicat. Cada programa d’automatització madur necessita algú que exerceixi la funció de gestió de producte.

En equips petits, l’arquitecte de xarxa o l’NRE sènior pot absorbir la funció de gestió de producte juntament amb el seu treball tècnic. Mantenen el backlog, dirigeixen les reunions amb les parts interessades i són propietaris de les converses d’alineació de negoci. A aquesta escala, unes poques hores a la setmana és suficient per mantenir la funció viva.

A mesura que la plataforma creix, el treball de traducció entre les parts interessades externes i l’enginyeria interna es torna substancial. Una plataforma que dóna servei a deu equips consumidors, amb trenta serveis en producció i un full de ruta trimestral que requereix negociació a través de prioritats en competència, no es pot gestionar com a producte en unes poques hores a la setmana. La funció es converteix en un rol a temps complet.

El rol de Product Manager d’Automatització de Xarxa (Network Automation Product Manager) està emergint en organitzacions amb programes d’automatització madurs. Les seves responsabilitats són:

• Ser propietari de la relació amb les parts interessades en nom de la plataforma: el punt de contacte principal per als equips consumidors, responsable de traduir les seves necessitats en requisits de servei
• Mantenir el Mapa de Serveis Orientat al Negoci i el Backlog d’Automatització, amb una priorització que reflecteixi tant l’impacte de negoci com la realitat d’enginyeria
• Comunicar el full de ruta externament i gestionar les expectatives quan canvien les prioritats
• Definir i fer seguiment de les mètriques d’impacte de negoci, fent visible la contribució de la plataforma als resultats de negoci per al lideratge
• Representar la retroalimentació del consumidor en les discussions de priorització de l’equip, assegurant que les prioritats d’enginyeria reflecteixin les necessitats reals dels usuaris en lloc de les preferències tècniques internes

Aquest rol no requereix una expertesa profunda en xarxes. Requereix la capacitat d’entendre el que l’equip de xarxa pot lliurar, el que el negoci necessita, i on s’alineen i no s’alineen aquestes dues coses. El model de col·laboració entre el Product Manager d’Automatització de Xarxa i els rols tècnics del Capítol 13, secció 13.2 segueix un patró familiar de les organitzacions de productes de programari: el Product Manager és propietari del que es construeix i per què, l’Enginyer de Plataforma de Xarxa i el Desenvolupador d’Automatització són propietaris de com es construeix, i l’NRE és propietari de com es manté saludable en producció. Els conflictes entre aquests grups són característiques del model, no defectes: el PM impulsa les necessitats del consumidor, els enginyers impulsen la sostenibilitat de la plataforma, i la tensió entre ells produeix millors decisions de les que qualsevol dels dos hauria pres per separat.

El rol de Product Manager d’Automatització de Xarxa és controvertit en algunes organitzacions de xarxa perquè introdueix un rol no tècnic en una estructura d’equip centrada tècnicament. La preocupació és vàlida: un PM sense prou base tècnica farà compromisos que l’equip d’enginyeria no pot complir, i tindrà dificultats per distingir entre sol·licituds que són fàcils d’implementar i sol·licituds que requereixen canvis fonamentals de plataforma. La solució no és evitar el rol sinó fer les fronteres de col·laboració concretes. Dues salvaguardes no són negociables: el PM no pot comprometre una data de lliurament a una part interessada externa sense el vistiplau explícit del responsable d’enginyeria sobre l’abast i el termini, i el responsable d’enginyeria té autoritat de veto sobre qualsevol compromís que requereixi canvis de plataforma no dissenyats o estimats encara. Sense aquestes salvaguardes, el rol de PM crea un nou mode de fallada: les parts interessades externes reben promeses que l’equip d’enginyeria descobreix després del fet, i el dany a la credibilitat recau sobre la plataforma, no sobre el PM.

Dos anys després de la seva transició de plataforma, al Jordi, un arquitecte de xarxa que havia liderat el canvi del seu equip de les operacions manuals a una plataforma d’automatització (presentat al Capítol 13), se li va demanar que s’unís a una reunió amb el projecte d’integració de la cadena de botigues. El responsable de l’equip de negoci va exposar el calendari d’onboarding, va assenyalar un període de sis setmanes on quaranta botigues havien de posar-se en marxa simultàniament, i va preguntar: “Està la plataforma preparada per a això?” El Jordi tenia la resposta: la plataforma podia gestionar-ho tècnicament, però la cobertura de monitoratge per als llocs recentment activats tenia un retard de dotze hores abans que s’ingerís la telemetria completa. Quaranta activacions simultànies significaria quaranta llocs funcionant durant mig dia amb una cobertura d’observabilitat reduïda. Ho va dir directament, va nomenar el risc i va proposar una modificació a la seqüència d’onboarding que escamparia les activacions en un període de tres dies sense estendre el termini global. L’equip de negoci ho va acceptar. La conversa va passar en quinze minuts perquè el Jordi entenia tant la restricció tècnica com la seva conseqüència de negoci. Aquesta traducció, entre el que fa la plataforma i el que experimenta el negoci, és la funció de gestió de producte independentment de qui tingui el títol.

14.6.2 Gestió del Cicle de Vida del Servei#

La descripció del rol de PM a la secció 14.6.1 nombra les responsabilitats. Aquesta secció mostra com operen aquestes responsabilitats a través de les quatre etapes per les quals passa cada servei de xarxa: definició, lliurament, operacions i evolució.

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ó<br/>Contracte de servei<br/>Justificació de negoci"]
    DEL["Lliurament<br/>Gestió del backlog<br/>Criteris d'acceptació"]
    OPS["Operacions<br/>Monitoratge de l'SLA<br/>Comunicació amb el consumidor"]
    EVO["Evolució<br/>Versionatge<br/>Deprecació"]

    DEF --> DEL --> OPS --> EVO
    EVO -->|"propera versió"| DEF

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

Definició

El primer contacte del PM amb un nou servei és abans que l’equip d’enginyeria escrigui una línia de codi d’automatització. Un equip consumidor arriba amb una sol·licitud: “necessitem fer l’onboarding de botigues més ràpid,” o “el nostre equip d’aplicació no pot aprovisionar segments de xarxa sense presentar un tiquet.” La feina del PM en aquesta etapa és traduir aquesta sol·licitud en un contracte de servei delimitat usant l’estructura de tres components de la secció 14.2: què proporciona el consumidor (superfície d’entrada), què observa (superfície de sortida), i quines dependències internes porta el servei que els consumidors no necessiten entendre? Aquesta traducció no és un document de requisits lliurat a enginyeria. És una negociació entre el que el consumidor necessita i el que la plataforma pot lliurar, amb el PM i el responsable d’enginyeria tots dos a la sala.

El PM és propietari de la pregunta “com és fet des de la perspectiva del consumidor”. El responsable d’enginyeria és propietari de “com és fet des de la perspectiva de la plataforma”. Ambdues preguntes han de respondre’s abans que la definició estigui completa, perquè un contracte de servei que satisfà el consumidor però ignora les restriccions de plataforma generarà retreball durant el lliurament, i un que satisfà la plataforma però no el consumidor no s’usarà després del llançament.

Abans que tanqui la definició, el PM col·loca el nou servei en el Mapa de Serveis Orientat al Negoci de la secció 14.3. Aquest pas assegura que el servei té una justificació de negoci explícita i que la seva prioritat relativa a altres elements del Backlog d’Automatització es pot avaluar amb criteris consistents. Un servei que no es pot col·locar en el mapa, perquè ningú pot articular quina capacitat de negoci habilita o quin és l’impacte de la seva absència, no està preparat per ser definit. Això és un senyal per tornar a la conversa amb el consumidor, no per començar l’enginyeria.

Lliurament

Un cop acordat el contracte de servei, el PM gestiona l’entrada del Backlog d’Automatització corresponent a través del desenvolupament. Els criteris d’acceptació s’escriuen en termes del consumidor: “una activació estàndard de sucursal es completa en quaranta minuts de l’enviament, amb un esdeveniment de cicle de vida emès en cada etapa,” no “el push de gNMI al router PE es completa sense error.” La distinció importa perquè els criteris d’acceptació escrits en termes d’implementació poden passar mentre l’experiència del consumidor falla: el push s’ha completat, però el consumidor no ha rebut cap notificació i no pot saber si la seva botiga està activa.

Durant el lliurament, el PM és propietari de tota la comunicació externa sobre el termini i l’abast. El responsable d’enginyeria és propietari de les decisions tècniques internes. Aquesta divisió protegeix l’equip d’enginyeria del patró que descarrila la majoria dels projectes d’automatització: les addicions d’abast que arriben després d’acordar el contracte de servei. Cada nou requisit després de la signatura del contracte és un nou element del Backlog d’Automatització amb la seva pròpia priorització, no una modificació al lliurament actual. La feina del PM és mantenir aquest límit amb els equips consumidors, perquè l’equip d’enginyeria no pot fer-ho sense danyar la relació amb el consumidor. Un abast de lliurament que pot ser ampliat per qualsevol part interessada en qualsevol moment és un lliurament que mai s’acaba.

Operacions

Quan el servei entra en funcionament, el rol del PM canvia del lliurament al manteniment de la confiança. L’SLA intern de la secció 14.4 defineix el que el servei es compromet: disponibilitat, latència d’execució, pressupost d’errors i camí d’escalada. El PM fa seguiment d’aquestes mètriques no per diagnosticar fallades, que és la responsabilitat de l’NRE, sinó per ser propietari de la comunicació orientada al consumidor quan s’aproximen o superen els llindars. Un equip consumidor que descobreix que el seu servei ha estat funcionant fora del seu SLA llegint un tauler al qual no se’ls va dir que vigilessin no ha rebut un SLA: ha rebut una mètrica sense una relació. El PM és la relació.

El PM també dirigeix el procés de recollida de retroalimentació operativa. Quins equips consumidors presenten les sol·licituds d’excepció més freqüents? Quines sortides de servei requereixen interpretació manual abans que el consumidor pugui actuar sobre elles? On força la superfície d’entrada actual als consumidors a enviar sol·licituds en termes de xarxa en lloc de termes de negoci? Aquests senyals no són queixes: són dades de producte, i la feina del PM és agregar-les sistemàticament i portar-les a la conversa del full de ruta amb prou especificitat que l’equip d’enginyeria pugui actuar sobre elles. La retroalimentació que arriba com “els consumidors no estan satisfets amb l’activació de sucursals” no és accionable. La retroalimentació que arriba com “set de les darreres dotze sol·licituds d’excepció eren per a llocs temporals que no coincidien amb cap nivell definit, i les set van requerir la implicació directa de l’equip de xarxa” és accionable: nomena una bretxa en la superfície d’entrada i quantifica el seu cost operatiu.

Evolució

Els serveis que deixen d’evolucionar acumulen discrepàncies entre el que van ser dissenyats per gestionar i el que els consumidors necessiten realment. El PM és propietari de la decisió de quan i com evoluciona un servei, informat per la retroalimentació operativa recollida en l’etapa anterior i les entrades canviants en el Mapa de Serveis Orientat al Negoci.

No tota l’evolució comporta la mateixa conseqüència operativa. Un canvi que afegeix un nou camp d’entrada opcional o emet un esdeveniment de sortida més ric és additiu: els consumidors existents no es veuen afectats, i l’adopció de la nova capacitat és opcional. Un canvi que reanomena un camp obligatori, elimina un esdeveniment de sortida o altera un compromís d’SLA trenca el contracte existent per a tots els consumidors que en depenen. El PM ha de distingir entre aquestes dues categories abans que comenci qualsevol evolució, perquè requereixen processos diferents: els canvis additius es poden lliurar com a actualitzacions menors, mentre que els canvis que trenquen el contracte requereixen un increment de versió, un camí de migració i un termini de deprecació comunicat als equips consumidors abans que el canvi arribi.

El termini de deprecació és on molts equips fallen. Els equips d’enginyeria naturalment volen eliminar la versió antiga tan aviat com la nova és estable. Els equips consumidors naturalment volen quedar-se en la versió de la qual depenen fins que tinguin capacitat per migrar. El PM negocia la finestra entre aquestes dues posicions i es compromet amb ambdues parts: una data específica després de la qual la versió antiga no té suport, comunicada amb prou antelació perquè els equips consumidors puguin planificar la seva migració. Els serveis evolucions sense aquest procés erosionen la confiança que el contracte de servei va ser dissenyat per construir. L’equip consumidor que descobreix un canvi que trenca el contracte en producció no ha experimentat una fallada tècnica: ha experimentat una fallada de relació, i és més difícil recuperar-se d’aquesta.

14.7 Resum#

Quatre temes ancoren aquest capítol:

Serveis, no scripts: el canvi de producte és de construir automatització que s’executi a proporcionar serveis dels quals altres depenen. El patró Servei de Xarxa com a Producte nomena aquesta reformulació: el servei és l’artefacte primari, la xarxa subjacent és el detall d’implementació. El Patró de Contracte de Servei és l’artefacte que fa això concret: una definició explícita i versionada de superfície d’entrada, superfície de sortida i dependències internes que delimita la interfície al que els consumidors necessiten proporcionar i el que poden observar, sense exposar detalls d’implementació de xarxa que no haurien de necessitar entendre.

L’alineació de negoci és estructural: mesurar l’impacte de negoci requereix dissenyar l’automatització des dels resultats de negoci cap avall, no des del comportament del dispositiu cap amunt. El Mapa de Serveis Orientat al Negoci és l’instrument: un mapatge explícit de serveis de xarxa a les capacitats de negoci que habiliten i l’impacte de negoci de la degradació o no disponibilitat. Els equips que poden fer aquest mapatge fluidament són els que altres unitats de negoci truquen quan estan planificant quelcom nou, perquè aquests equips ja han respost la pregunta “quines possibilitats obre la xarxa”. Els que no ho poden fer s’assabenten de noves iniciatives quan el termini ja s’ha fixat, i es troben explicant per què la xarxa no pot estar a punt a temps. El Backlog d’Automatització aplica la mateixa lògica a la priorització: quina automatització construir a continuació hauria d’estar determinada per quins resultats de negoci estan més restringits per les limitacions de xarxa, no per quina automatització és més interessant tècnicament.

SLAs i models de suport abans que siguin necessaris: definir compromisos de fiabilitat, camins d’escalada i propietat de fallades abans del primer incident important és el que separa una plataforma d’una col·lecció de scripts. L’SLA intern, amb els seus quatre components de disponibilitat, latència d’execució, pressupost d’errors i camí d’escalada, és l’instrument que fa la confiança explícita. La taxonomia de tres modes de fallada (error d’automatització, fallada de plataforma, fallada de xarxa) és el marc de triatge que evita que els incidents caiguin entre equips. El Patró d’Automatització Pre-aprovada estén això: un cop un flux de treball ha estat dissenyat, provat i aprovat amb les seves restriccions de seguretat actives, les execucions individuals són instàncies d’una operació aprovada, no nous canvis que requereixin reaprovació. Tant el model d’SLA com el model de governança han d’establir-se abans del primer incident, no després.

La funció de gestió de producte al llarg del cicle de vida del servei: cada servei de xarxa passa per quatre etapes: definició, lliurament, operacions i evolució, i la funció de gestió de producte és propietària de la continuïtat a través de totes quatre. En la definició, el PM tradueix les sol·licituds del consumidor en un contracte de servei delimitat abans que comenci l’enginyeria. En el lliurament, el PM manté el límit d’abast i és propietari de la comunicació externa. En les operacions, el PM és propietari de la comunicació d’SLA orientada al consumidor i agrega la retroalimentació en dades de producte accionables. En l’evolució, el PM distingeix els canvis additius dels que trenquen el contracte, és propietari de la decisió de versionatge i negocia el termini de deprecació amb enginyeria i els equips consumidors. Sense aquesta funció, els serveis es defineixen de manera ad hoc, es lliuren sense criteris d’acceptació, s’operen sense una relació amb el consumidor i s’evolucionen sense avís. Amb ella, la plataforma es comporta com un producte que escolta els seus usuaris i guanya la seva confiança al llarg del temps.

La disciplina de producte descrita en aquest capítol és una condició prèvia per al que descriu la Part 5. L’automatització en bucle tancat pren decisions de remediació en temps real. Les xarxes autorecuperables responen a les fallades sense intervenció humana. Les xarxes autònomes prenen decisions d’enrutament i provisioning en nom dels seus consumidors. Cadascuna d’aquestes representa la plataforma prenent accions de les quals un consumidor depèn sense autorització humana directa per a aquesta acció específica. Sense fronteres de servei definides, estat observable, compromisos de fiabilitat i escalada clara quan se superen els llindars, l’operació autònoma no és un producte. És un sistema imprevisible que actua sense contracte. El treball d’aquest capítol és el que fa que l’operació autònoma sigui quelcom en el qual es pot confiar, que és la base sobre la qual es construeix la Part 5.

Referències i Lectura Addicional#

• Continuous Delivery, Jez Humble, Dave Farley (Addison-Wesley, 2010). El text fundacional sobre el cicle de vida de lliurament de programari: com construir pipelines de desplegament que fan del llançament una operació fiable i de baix risc. Els patrons de cicle de vida del servei en aquest capítol, des del desenvolupament fins a l’operació en producció, es basen en aquests principis aplicats a l’automatització de xarxa.

• The Art of SLOs, Google SRE Workbook (disponible a sre.google). La guia pràctica per definir objectius de nivell de servei, pressupostos d’errors i la relació entre compromisos de fiabilitat i velocitat de funcionalitats. El model d’SLA intern de la secció 14.4 aplica aquests principis a les plataformes d’automatització que donen servei a consumidors interns.

• Empowered, Marty Cagan (Wiley, 2020). Un marc de gestió de producte per a organitzacions tècniques: com organitzar equips al voltant de resultats en lloc de funcionalitats, com definir el que significa “fet” per a un equip de producte, i com mantenir l’alineació estratègica entre el treball d’enginyeria i les prioritats de negoci. El rol de Product Manager d’Automatització de Xarxa descrit a la secció 14.6.1 es basa en aquest marc.

• Team Topologies, Matthew Skelton, Manuel Pais (IT Revolution Press, 2019). Referenciat al Capítol 13, continua sent rellevant aquí: el model d’equip de plataforma, on una plataforma d’automatització dóna servei a equips alineats amb fluxos com a consumidors interns, és l’estructura organitzativa que el model de producte en aquest capítol està dissenyat per donar suport.

• Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, Gene Kim (IT Revolution Press, 2018). Recerca empírica sobre el que separa les organitzacions tecnològiques d’alt rendiment de les de baix rendiment. Rellevant per a la secció 14.4: les dades mostren que els consells d’aprovació de canvis no estan correlacionats amb millors resultats d’estabilitat però sí fortament correlacionats amb un lliurament més lent, la base d’evidència darrere del Patró d’Automatització Pre-aprovada i l’argument que la governança de canvis pertany al moment del disseny del flux de treball, no a cada execució.

💬 Found something to improve? Send feedback for this chapter