7. Orquestració#

L’equip de xarxa havia fet tot bé. Tenien una Font de Veritat sòlida, playbooks ben provats per a cada operació i un runbook clar per executar-los. Sobre el paper, desplegar un nou servei de VLAN estava completament automatitzat. A la pràctica, trigava mig dia i requeria un enginyer específic.

Aquell enginyer coneixia la seqüència. Primer, validar que les dades del SoT eren completes. Llavors executar el playbook de pre-comprovació. Llavors revisar la sortida, buscar els dispositius fallits i decidir si continuar. Llavors activar el playbook de desplegament. Llavors esperar. Llavors executar el playbook de validació. Llavors actualitzar el tiquet de ServiceNow manualment. Si algun dispositiu fallava a mig camí, fer-ne el rollback abans que els altres ho notessin. Ho tenia tot en un runbook, pas a pas, en un document compartit que ningú més havia interioritzat completament.

Quan se n’anà de vacances, els desplegaments s’aturaren. Quan un enginyer júnior intentà la seqüència i s’equivocà d’ordre, la xarxa quedà en un estat parcial durant sis hores. L’automatització existia. La coordinació seguia sent manual.

Aquest és el problema que resol aquest capítol. L’orquestració és el bloc constructiu que transforma una col·lecció d’eines d’automatització en un sistema que es comporta com un de sol. Coordina els altres blocs, decideix quan s’executen, gestiona les fallades de manera elegant, registra cada decisió i ho fa tot sense que un enginyer estigui al mig gestionant el flux manualment.

7.1. Fonaments#

7.1.1. Context#

Cada bloc constructiu que hem cobert fins ara fa una cosa bé. La Font de Veritat conté la intenció. L’Executor l’aplica. El Collector recupera l’estat. L’Observabilitat dona sentit a aquest estat. Cadascun és un especialista, i els especialistes necessiten un connector: alguna cosa que decideixi quan cadascun ha d’actuar, qué fer amb el resultat i com recuperar-se quan alguna cosa va malament.

Aquest connector és l’Orchestrator.

Al Capítol 3 el vam situar al centre del marc NAF com el bloc que coordina tots els altres. El Capítol 5 va mostrar com l’Executor aplica els canvis de configuració; el Capítol 6 va mostrar com l’Observabilitat valida els resultats. Aquest capítol mostra com l’Orquestrador seqüencia tots dos, i gestiona tot el que pot anar malament entremig.

Sense orquestració, no esteu executant automatització. Esteu executant scripts que algú ha d’invocar en l’ordre correcte, en el moment correcte i interpretar de la manera correcta. Això és automatització de nom tan sols.

7.1.2. Objectius#

L’Orquestrador ha de complir cinc objectius:

1. Coordinar fluxos de treball multibloc d’extrem a extrem. Un desplegament no és una acció única; és una seqüència: validar la intenció al SoT, executar pre-comprovacions, executar la configuració, validar el resultat, notificar als interessats. L’Orquestrador manté la seqüència completa unida.

2. Reaccionar als events automàticament, amb o sense iniciació humana. Una aprovació de ServiceNow, una alerta d’Observabilitat, una anàlisi de compliment programada: tots aquests han de poder iniciar un flux de treball sense que un humà l’iniciï manualment.

3. Execució resilient i escalable. Un flux de treball que toca 800 switches en paral·lel ha de completar-se de manera fiable. Ha de sobreviure un reinici. Ha de gestionar fallades parcials sense perdre el treball fet pels dispositius que han tingut èxit.

4. Proporcionar visibilitat a prova de manipulació. Els operadors necessiten veure qué s’està executant ara mateix. Els auditors necessiten veure qué s’executà el mes passat, qui ho desencadenà, quina versió del flux de treball s’executà i qué produí cada pas. Ambdues necessitats s’han de satisfer des del mateix sistema.

5. Gestionar les definicions de fluxos de treball com a programari de producció. Un flux de treball que es desplega a 800 switches en producció no es pot canviar descuradament. La pròpia lògica s’ha de persistir, versionar, provar i promocionar a producció amb la mateixa disciplina aplicada a qualsevol codi que s’executa en producció.

7.1.3. Pilars#

Cinc pilars suporten aquests objectius:

1. Motor de fluxos de treball: definir, executar i fer el seguiment de processos de múltiples passos
2. Capa d’activació: manual, programada, impulsada per events, webhook
3. Execució resilient: el flux de treball sobreviu reinicis; suporta reintents, rollback i operacions concurrents entre centenars de dispositius sense colls d’ampolla per dispositiu
4. Auditoria i observabilitat: cada pas registrat, cada decisió traçable
5. Gestió de la pipeline: persistir, versionar i promocionar les definicions de fluxos de treball de manera segura en producció

7.1.4. Abast#

L’Orquestrador coordina. No actua.

Dins de l’abast:

• Coordinar altres blocs constructius
• Definir la lògica del flux de treball i les dependències entre passos
• Gestionar l’activació des de múltiples fonts
• Fer el seguiment de l’estat d’execució i produir rastres d’auditoria
• Gestionar les decisions de rollback quan els passos fallen

Fora de l’abast:

• Executar canvis al dispositiu (això és l’Executor)
• Emmagatzemar l’estat operatiu de la xarxa (això és l’Observability)
• Contenir la intenció de xarxa (això és la Font de Veritat)

Un error comú és construir un Orquestrador que duplica les responsabilitats d’execució o emmagatzematge dels seus veïns. La interfície entre blocs ha de mantenir-se neta.

7.2. Funcionalitats#

Els cinc objectius i pilars es realitzen a través de cinc funcionalitats bàsiques. Cada una s’associa directament a un objectiu i al seu pilar de suport:

1. Motor de Fluxos de Treball: com s’estructuren els fluxos de treball i com es coordinen els passos
2. Activació: com i quan s’inicien els fluxos de treball, i qué experimenta el que fa la crida
3. Resiliència i Escala: com els fluxos de treball es completen de manera fiable davant de fallades i a gran volum
4. Estat i Traçabilitat: seguiment de l’estat d’execució i producció de registres d’auditoria a prova de manipulació
5. Gestió de la Pipeline: persistir i gestionar les definicions de fluxos de treball de manera segura en producció

graph LR

    subgraph Goals["Objectius"]
        direction TB
        A1[Coordinar fluxos de treball multibloc d'extrem a extrem]
        A2[Reaccionar als events automàticament]
        A3[Execució resilient i escalable]
        A4[Visibilitat a prova de manipulació i auditoria]
        A5[Canvis segurs a les pipelines de producció]
    end

    subgraph Pillars["Pilars"]
        direction TB
        B1[Motor de fluxos de treball: definir, executar, fer el seguiment]
        B2[Capa d'activació: manual, programada, impulsada per events]
        B3[Execució resilient: durable, reintents, rollback a escala]
        B4[Auditoria i observabilitat: cada pas registrat]
        B5[Gestió de la pipeline: persistir, versionar, promocionar de manera segura]
    end

    subgraph Functionalities["Funcionalitats"]
        direction TB
        C1[Motor de Fluxos de Treball]
        C2[Activació]
        C3[Resiliència i Escala]
        C4[Estat i Traçabilitat]
        C5[Gestió de la Pipeline]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;

7.2.1. Motor de Fluxos de Treball#

El motor de fluxos de treball és el nucli de l’Orquestrador. Defineix processos de múltiples passos, els executa, fa el seguiment del seu estat i gestiona les relacions entre passos.

Abans d’entrar en els patrons, val la pena nombrar els quatre enfocaments fonamentals de coordinació, perquè aquesta elecció conforma tot el que ve a continuació.

7.2.1.1. Enfocaments de coordinació#

• Monòlit (programa imperatiu): Un únic script Python crida a cada pas en seqüència, espera cada resultat i decideix qué fer a continuació. Simple d’escriure, i molts equips comencen aquí. El problema és la durabilitat: si l’script falla al pas 5 de 10, reinicieu des del principi. No hi ha estat persistent entre execucions. Tampoc podeu paral·lelitzar passos sense escriure lògica de threading vosaltres mateixos. Funciona per a operacions petites i ràpides; es trenca sota càrrega i infraestructura poc fiable. A la pràctica, això és el que el bloc Executor ja proporciona: un script invocat per un operador. Anomenar-ho orquestració és generós.

• Flux de treball (basat en DAG): Aquí és on comença genuïnament l’orquestració. Els passos es defineixen com un graf acíclic dirigit, on cada node és una tasca i les arestes expressen dependències. El motor fa el seguiment de l’estat per node: si reinicieu després d’una fallada, només es tornen a executar els passos fallits o incomplets. El paral·lelisme és integrat: les branques independents s’executen concurrentment. Aquest és l’enfocament dominant per a l’orquestració en producció, i el més provat per a l’automatització de xarxes. Les eines d’aquesta categoria inclouen Prefect, Temporal i les plantilles de flux de treball d’AWX.

• Coreografia (impulsada per events, sense coordinador central): No hi ha Orquestrador. Cada component reacciona als events publicats pels altres: l’Executor publica “desplegament completat”, el sistema d’Observabilitat el consumeix i executa la validació, el sistema de notificació consumeix el resultat de la validació. L’acoblament entre components és lax, cosa que facilita afegir nous consumidors. L’inconvenient: no hi ha un lloc únic per entendre l’estat complet del flux de treball. Depurar fallades entre serveis requereix correlacionar events de múltiples sistemes. Aquest enfocament funciona per a patrons reactius simples però escala malament en complexitat.

• Agèntic (bucle sentir-lògica-actuar): Un Large Language Model (LLM) o sistema d’IA actua com a capa de lògica. L’agent observa l’estat actual (de l’Observabilitat o el SoT), raona sobre quina acció tanca el buit i invoca l’Executor. En lloc de seguir un graf de flux de treball predefinit, pren decisions dinàmicament en temps d’execució. Aquest és l’enfocament que intercanvia determinisme per flexibilitat i forma la base arquitectònica per a xarxes autònomes. La secció 7.2.7 el cobreix en profunditat; el Capítol 17 l’estén fins a l’autonomia total.

7.2.1.2. Patrons de flux de treball#

Dins de l’enfocament basat en DAG, quatre patrons cobreixen la majoria de fluxos de treball d’automatització de xarxes del món real:

• Seqüencial: Els passos s’executen un darrere l’altre; cada un depèn que el previ es completi correctament. Adequat quan es requereix un ordre estricte: validar la intenció, llavors pre-comprovar, llavors executar, llavors verificar.

• Paral·lel (fan-out/fan-in): Múltiples passos independents s’executen concurrentment. Un pas fan-out llança moltes tasques paral·leles (una per dispositiu, o una per edifici); un pas fan-in espera que totes es completin abans de continuar. Essencial per a operacions entre centenars de dispositius: sense fan-out, una operació de 10 segons per dispositiu en 800 dispositius triga més de dues hores de manera seqüencial.

• Branques condicionals: El camí pres depèn de l’estat en temps d’execució. Ha passat la pre-comprovació? Branca cap a l’execució. Ha fallat? Branca cap a l’avortament i la notificació. La definició del flux de treball inclou nodes de decisió que avaluen els resultats i trien el pas següent.

• Patró Saga: Per a fluxos de treball de llarga durada, el patró Saga afegeix transaccions compensatòries a cada pas. Si el flux de treball té èxit fins al pas N i llavors falla, el flux executa accions compensatòries per als passos N-1 fins a 1 en ordre invers, retornant el sistema a un estat conegut i correcte. Així és com funciona el rollback a nivell d’orquestració: no tornant a executar tot el flux de treball, sinó executant l’invers de cada pas que ha tingut èxit.

flowchart TD
    subgraph Sequential["Seqüencial"]
        S1[Pas A] --> S2[Pas B] --> S3[Pas C]
    end

    subgraph FanOut["Fan-out i Fan-in"]
        F0[Inici] --> F1[Dispositiu 1]
        F0 --> F2[Dispositiu 2]
        F0 --> F3[Dispositiu N]
        F1 --> FJ[Fan-in]
        F2 --> FJ
        F3 --> FJ
    end

    subgraph Saga["Saga - rollback en cas de fallada"]
        P1[Pas 1] --> P2[Pas 2] --> P3[Pas 3]
        P3 -- fallada --> R3[Rollback 3]
        R3 --> R2[Rollback 2]
        R2 --> R1[Rollback 1]
    end

7.2.1.3. Gestió de dependències#

Els passos del flux de treball rarament existeixen de manera aïllada. El motor ha d’expressar i aplicar tres tipus de dependències:

• Dependències de dades: La tasca B no pot començar fins que la tasca A es completi i produeixi un resultat que B consumeixi. El motor passa les sortides entre passos com a dades estructurades. A la pràctica, això significa que el pas de pre-comprovació passa la llista de dispositius assolibles al pas d’execució, en lloc de tornar a consultar des de zero.

• Dependències de múltiples entrades (fan-in): Un pas espera múltiples branques paral·leles abans de continuar. El motor manté l’estat de cada branca i activa el pas d’unió només quan es compleix la política de finalització configurada: tots completats, o N de M, o primer èxit.

• Dependències externes: De vegades un pas no pot continuar fins que alguna cosa fora del sistema succeeixi. S’obre una finestra de canvi. Un humà aprova. Un dispositiu torna a ser assolible després d’un reinici. El motor ha de suportar estats d’espera amb timeouts configurables i camins d’escalada definits per quan l’espera mai es resol.

7.2.2. Activació#

Un flux de treball ha de començar d’alguna manera. L’activació respon dues preguntes: qué fa que un flux de treball comenci, i qué experimenta el que fa la crida després.

7.2.2.1. Modes d’activació#

Quatre modes cobreixen tot l’espectre des de l’humà fins a la total automatització:

• Crida API: L’orquestrador exposa un endpoint HTTP. Un operador el crida manualment, un botó d’interfície el crida, o un sistema extern (ServiceNow, Nautobot, una pipeline de CI/CD) el crida quan es produeix un event. Tots aquests són el mateix mecanisme: el que difereix és qui inicia la crida i si porta dades d’event estructurades. Adequat per a qualsevol canvi que hagi de començar ara, sigui l’iniciador un humà o un sistema.

• Programat: Un horari tipus cron inicia un flux de treball a una hora configurada. Anàlisis de compliment nocturnes, auditories de firmware setmanals, informes de capacitat mensuals. La majoria d’orquestradors ho suporten de manera nativa; alguns equips usen un planificador extern i criden l’API de l’orquestrador.

• Cua de missatges: L’Orquestrador consumeix missatges d’una cua (Kafka, NATS, RabbitMQ) i inicia un flux de treball per missatge. Això desacobla el productor d’events de l’orquestrador: el productor publica i continua; l’orquestrador processa al seu propi ritme. Adequat per a fluxos d’events d’alt volum on les garanties de lliurament-com-a-màxim-una-vegada de les crides API directes són insuficients.

L’elecció entre push (crida API) i pull (cua de missatges, programat) depèn del volum i la tolerància d’acoblament. Les crides API són més simples però requereixen que el remitent conegui l’endpoint de l’orquestrador. Les cues de missatges escalen millor per a fluxos d’alt volum però afegeixen infraestructura a operar.

7.2.2.2. Contracte de resposta#

Un cop s’inicia un flux de treball, el que ha fet la crida necessita saber qué esperar de tornada:

• Síncron: El que fa la crida espera fins que el flux de treball es completa i rep el resultat directament. Adequat per a operacions curtes (menys de 30 segons) on el que fa la crida necessita el resultat per continuar. La majoria de casos d’ús interactius comencen aquí i descobreixen que l’han superat quan intenten executar un desplegament de 10 minuts i el client API fa timeout.

• Asíncron: El que fa la crida rep immediatament un ID d’execució del flux de treball i consulta per obtenir l’estat, o registra una URL de callback per rebre el resultat quan es completi. Necessari per a qualsevol flux de treball que toqui més d’un grapat de dispositius. Això té una implicació directa sobre com el sistema presenta l’estat: la capa de Presentació (Capítol 8) ha d’exposar endpoints d’estat i notificacions push, perquè els usuaris van iniciar els fluxos de treball des d’algun lloc i necessiten una manera de fer-ne el seguiment sense mantenir una connexió HTTP oberta.

• Híbrid: El flux de treball s’inicia de manera asíncrona, però el que fa la crida pot opcionalment bloquejar-se en un endpoint de sync-wait si cal. Un patró de conveniència que evita forçar els que fan crides a triar d’entrada.

7.2.3. Resiliència i Escala#

Això és el que separa un orquestrador amb el qual prototipeu d’un en el qual confieu a les 3 de la matinada en producció. Un flux de treball que s’executa de manera fiable en condicions ideals no us diu res sobre si sobreviurà un reinici del coordinador a mig camí, si gestionarà que 40 dels 800 dispositius fallin les pre-comprovacions, o si es degradarà de manera elegant quan una dependència mai no es resolgui. La propera vegada que es provi el vostre orquestrador, no serà en una demostració.

La resiliència a la capa d’execució, coberta al Capítol 5, aborda la idempotència i els reintents a nivell de dispositiu individual: si un playbook falla contra un dispositiu, torneu-lo a intentar. El que el Capítol 5 no aborda és la durabilitat a nivell de flux de treball: qué passa quan el propi Orquestrador es reinicia a mig camí, quan 40 dels 800 dispositius fallen les pre-comprovacions, o quan una dependència mai no es resol i el flux de treball es queda penjat. L’escalat del propi orquestrador, incloent l’alta disponibilitat, els treballadors horitzontals i la càrrega de la base de dades sota execucions concurrents, és una preocupació d’infraestructura abordada al Capítol 11.

7.2.3.1. Estat durable#

Un motor de flux de treball que emmagatzema l’estat d’execució a la memòria ho perd tot en un reinici. Això és acceptable per a scripts i inacceptable per a l’orquestració en producció. L’estat durable vol dir que el progrés del flux de treball sobreviu a la fallada de l’orquestrador: quins passos s’han completat, qué han produït, quins estan pendents. Quan l’orquestrador torna a estar en línia, repren des d’on va deixar-ho.

Temporal està construït completament al voltant d’aquesta garantia: reprodueix la funció del flux de treball des del seu historial d’events en un reinici, fent que l’estat en vol sigui resistent a les fallades. AWX emmagatzema l’estat del job a la seva base de dades. Els scripts no emmagatzemen res.

7.2.3.2. Estratègies de reintent#

No totes les fallades són iguals. Un dispositiu que era breument inassolible durant un reinici de firmware hauria de tornar-se a intentar. Un dispositiu que ha retornat un error permanent d’autorització no hauria de fer-ho: tornar-ho a intentar no ajudarà i pot activar polítiques de bloqueig.

La configuració de reintent hauria de distingir:

• Fallades transitòries: talls de xarxa, timeouts d’API, contesa temporal de recursos. Reintenteu amb backoff exponencial.
• Fallades permanents: credencials incorrectes, dispositiu en mode de manteniment, configuració que no s’aplica a aquest tipus de dispositiu. Avorteu i escaleu.

La definició del flux de treball hauria d’especificar la política de reintent per pas. Un pas de pre-comprovació i un pas d’enviament de configuració tenen una semàntica de fallada diferent i no haurien de compartir la mateixa configuració de reintent.

7.2.3.3. Rollback i compensació#

Quan un flux de treball de desplegament falla a mig camí, teniu tres opcions: deixar l’estat parcial, corregir-lo manualment o fer-ne el rollback automàticament. En la majoria d’operacions de xarxa, l’estat parcial és perillós: els dispositius que van rebre la nova configuració es comportaran de manera diferent dels que no van rebre-la.

El Patró Saga aborda això definint una transacció compensatòria per a cada pas. Si el flux de treball té èxit fins al pas N i llavors falla, executa accions compensatòries per als passos N-1 fins a 1 en ordre invers. En un desplegament de VLAN: si l’enviament de configuració té èxit en 30 dispositius i falla en el 31è, la saga fa rollback dels 30 enviaments reeixits abans d’informar de la fallada.

7.2.3.4. Control de concurrència#

El fan-out entre 800 dispositius simultàniament aclapararia la majoria de les capes d’execució. El control de concurrència a nivell d’orquestració significa:

• Agrupament per lots: executeu N dispositius en paral·lel, espereu que el lot es completi, llavors executeu el lot següent. Això controla el radi de l’explosió: si una configuració dolenta revela un problema, encara no heu tocat tots els 800 dispositius.
• Limitació de taxa: la capa d’execució té límits; l’orquestrador ha de respectar-los. No deixeu que la cua d’AWX s’ompli amb 800 jobs simultanis.
• Llindars d’èxit parcial: definiu qué significa l’èxit a escala. 798 dels 800 dispositius configurats correctament pot ser suficient per continuar; 600 dels 800 hauria d’aturar el flux de treball i escalar.

7.2.3.5. Timeout i tallacircuits#

Els fluxos de treball que esperen indefinidament són un problema de fiabilitat. Cada pas que pot bloquejar-se necessita un timeout configurat. Quan el timeout expira, el flux de treball necessita una acció definida: escalar, saltar o avortar.

El patró Circuit Breaker estén això a les fallades repetides: si un pas falla més de N vegades en una finestra, deixeu d’intentar-ho i genereu una alerta. Això evita que un únic dispositiu inassolible mantingui un flux de treball obert durant hores.

7.2.3.6. Resiliència a través dels límits de blocs#

Els cinc patrons anteriors aborden les fallades dins de la pròpia execució de l’Orquestrador: estat durable, reintents, rollback, concurrència, timeouts. Però els fluxos de treball també fallen als límits entre blocs, i aquestes fallades requereixen un tractament diferent.

Quan l’Orquestrador crida l’API del SoT i rep un timeout, la resposta adequada és diferent de quan l’Executor retorna una fallada de dispositiu. Un timeout del SoT significa que l’Orquestrador no pot verificar que la intenció que està a punt de desplegar és actual. Continuar amb dades en memòria cau arriscaria aplicar una configuració obsoleta. La resposta correcta normalment és avortar i tornar a intentar en lloc de continuar amb incertesa. Un event de la capa de Presentació que mai arriba (el webhook d’aprovació de ServiceNow) pot significar que la sol·licitud ha estat rebutjada, que la integració és trencada o que el missatge s’ha perdut. Aquests requereixen camins de recuperació diferents: una aprovació absent no és una fallada transitòria que hauria de tornar-se a intentar indefinidament.

Les fallades als límits de blocs s’han de classificar explícitament a la definició del flux de treball:

• Dependència no disponible (SoT, Observabilitat): el flux de treball no pot continuar de manera segura. Falleu de manera neta, emeteu un event de diagnòstic i no torneu a intentar amb dades obsoletes.
• Dependència degradada (lectura parcial del SoT, Observabilitat amb retard): el flux de treball pot continuar amb el reconeixement explícit que opera amb confiança reduïda. Registreu l’estat degradat; no continueu en silenci.
• Bloc aigües avall fallit (l’Executor ha retornat error, el Collector no ha retornat dades): apliqueu els patrons de reintent i rollback anteriors, però classifiqueu la font de fallada amb precisió perquè l’alerta i el registre d’auditoria nomenin el bloc correcte.

Un flux de treball que tracta totes les fallades com a errors de dispositiu reintentables tornarà a intentar una integració del SoT trencada fins que esgoti el seu pressupost de reintents i avisi un enginyer de guàrdia amb el diagnòstic equivocat. Classificar les fallades als límits de blocs és la diferència entre un flux de treball que falla ràpid i un que falla de manera confusa.

7.2.4. Estat i Traçabilitat#

Quan alguna cosa va malament a les 3 de la matinada, dues preguntes necessiten resposta immediata: quin és l’estat actual del flux de treball, i qui l’ha activat?

Quan l’equip d’auditoria faci preguntes tres mesos més tard, el mateix registre ha de respondre: qué s’ha executat, quina versió de la definició del flux de treball s’ha executat, qué ha rebut cada pas com a entrada, qué ha produït com a sortida i quin ha estat el resultat final.

Aquestes són preguntes diferents amb urgències diferents, però provenen de la mateixa font: l’estat d’execució del flux de treball i el seu registre d’auditoria.

La traçabilitat és una preocupació transversal a tota la plataforma d’automatització: la Font de Veritat registra cada canvi en la intenció; l’Observabilitat registra cada canvi en l’estat de la xarxa. Però cap d’aquests registres us diu qui ha iniciat un flux de treball, quins passos s’han executat en seqüència i qué ha causat el resultat. Només el registre d’auditoria de l’Orquestrador tanca aquesta bretxa. Com que l’Orquestrador coordina tots els altres blocs, el seu rastre és la visió autoritzada de tot el que ha passat a través del sistema d’automatització complet per a un event donat.

7.2.4.1. L’estat no és l’estat de la xarxa#

Aquesta distinció és fàcil de passar per alt. Al Capítol 6, “estat” significava l’estat operatiu de la xarxa: comptadors d’interfície, sessions BGP, CPU del dispositiu. Al Capítol 5, “estat” significava la intenció de configuració desitjada continguda al SoT. Aquí, l’estat significa l’estat d’execució del propi flux de treball: quins passos s’han executat, quins s’estan executant, quins han fallat i qué han produït.

Els dos estan relacionats (un pas del flux de treball produeix canvis d’estat de la xarxa que l’Observabilitat llavors valida) però s’emmagatzemen de manera diferent, es consulten de manera diferent i serveixen propòsits diferents. No els confongueu.

7.2.4.2. La màquina d’estats del flux de treball#

Cada execució de flux de treball passa per una màquina d’estats definida:

• Pendent: rebuda però encara no iniciada
• En execució: executant passos activament
• Completada: tots els passos requerits s’han completat correctament
• Fallida: un pas ha fallat i el flux de treball no ha pogut continuar
• Cancel·lada: aturada per un humà o un senyal extern

Cada pas dins del flux de treball porta el seu propi estat. Una execució de fan-out parcialment reeixida ha de mostrar exactament quins dispositius han tingut èxit, quins han fallat i quins han estat saltats. “El flux de treball ha fallat” no és útil sense el desglossament per dispositiu.

7.2.4.3. Requisits del registre d’auditoria#

Cada registre d’execució de flux de treball ha de contenir, com a mínim:

• Qui o qué ha activat l’execució: identitat humana, nom del sistema, ID de l’event activador
• Quan ha començat i quan s’ha completat
• Quina versió de la definició del flux de treball s’ha executat
• L’entrada completa que ha rebut el flux de treball
• La sortida de cada pas
• El resultat final

Aquest registre ha de ser a prova de manipulació: no es pot editar a posteriori. En entorns regulats, el registre d’auditoria de l’Orquestrador és el registre de gestió de canvis. Si aquest registre es pot alterar, el sistema de gestió de canvis no és de confiança.

7.2.5. Gestió de la Pipeline#

Un flux de treball que configura 800 switches en producció és, arquitectònicament, programari de producció. El repte central no és simplement el versionat: és com s’emmagatzemen, es validen i es promouen les definicions de fluxos de treball perquè la pròpia lògica sigui tan fiable com la infraestructura que gestiona.

La definició del flux de treball codifica decisions: quines pre-comprovacions executar, qué fer quan un dispositiu és inassolible, qué constitueix l’èxit. Canviar-la descuradament canvia el que passarà a cada dispositiu que toqui aquell flux de treball la propera vegada que s’executi.

He vist equips trencar silenciosament els fluxos de treball en producció editant la definició del flux de treball directament a la interfície d’usuari de l’eina d’orquestració. Ningú ho va notar fins que la propera execució va tocar un tipus de dispositiu que el pas modificat no gestionava correctament. L’edició de la interfície no tenia revisió, ni proves, ni camí de rollback.

7.2.5.1. Estratègies#

• Definicions respaldades per Git: Emmagatzemeu les definicions de fluxos de treball al control de versions. L’eina d’orquestració extreu de Git en el desplegament, no d’edicions locals de la interfície. Això us dona un historial, un procés de revisió i la capacitat de fer rollback a qualsevol versió anterior.

• Versions de pipeline blau/verd: Manteniu dues versions d’un flux de treball en producció: la versió estable actual que gestiona tots els fluxos de treball actius, i una nova versió que rep noves execucions després d’un període de validació. El trànsit canvia només quan la nova versió ha provat ser estable.

• Desplegament canari: Una nova versió del flux de treball gestiona primer un petit nombre d’execucions. Un flux de treball d’actualització de firmware podria aplicar la nova versió a 10 dispositius abans de promocionar-la a tota la flota. Els problemes surten a 10 dispositius, no a 800.

7.2.5.2. Provar els canvis d’orquestració#

Les definicions de fluxos de treball es poden provar abans de la producció:

• Mode dry-run: executeu el flux de treball contra entrades reals però salteu els passos que modifiquen la xarxa. Verifiqueu que la lògica produeix la seqüència d’accions esperada.
• Entorn de prova: un subconjunt de dispositius dedicat a provar els canvis del flux de treball abans que s’executin contra la producció.
• Execució en ombra: executeu la nova versió en paral·lel amb la versió actual, però ignoreu els seus resultats. Compareu les sortides per detectar divergències abans de canviar.

7.2.6. Panorama de Solucions#

El mercat d’eines d’orquestració cobreix una àmplia gamma de models, des de plataformes específiques de xarxa fins a motors de fluxos de treball de propòsit general. La pregunta rarament és “quina és la millor” i gairebé sempre és “quina s’adapta a com operem.”

Una pregunta arquitectònica talla a través de totes: la vostra eina d’orquestració també serveix com a motor d’execució, o són separats? AWX/AAP col·lapsa els dos en un. Prefect, Temporal i Windmill són orquestradors que criden a eines d’execució separades (Ansible, scripts personalitzats, APIs). El model col·lapsat és més simple d’operar; el model separat us dona més flexibilitat per intercanviar motors d’execució de manera independent. El Capítol 3 va introduir aquest compromís sota l’acoblament mínim.

7.2.7. L’Orquestrador Agèntic#

L’enfocament de coordinació agèntica llistat a la secció 7.2.1 introdueix un model d’execució diferent: en lloc de seguir un DAG predefinit, un Large Language Model (LLM) rep un objectiu i determina la seqüència d’accions en temps d’execució. L’agent observa l’estat actual dels blocs d’Observabilitat i SoT, raona sobre quina acció tanca el buit, invoca l’Executor i torna a observar per verificar el resultat. Si el resultat no és el que s’esperava, raona de nou. La lògica de decisió no està codificada en una definició de flux de treball; viu en el raonament del model.

El que habilita això a tota la plataforma d’automatització és el Model Context Protocol (MCP) (Model Context Protocol). Cada bloc constructiu exposa un servidor MCP: un conjunt definit d’eines que l’agent pot cridar com a part del seu bucle de raonament. El servidor del SoT exposa consultes de dispositius i cerques d’intenció; el servidor d’Observabilitat exposa consultes d’estat i comprovacions de compliment; el servidor de l’Executor exposa l’activació de jobs i el polling d’estat. L’agent crida aquestes eines en qualsevol seqüència que requereixi la situació, sense que l’autor del flux de treball hagi precodificat cada combinació possible.

La implicació arquitectònica és que els blocs no necessiten saber res els uns dels altres ni sobre l’agent. La interfície MCP és el contracte. El mateix SoT que avui respon crides REST d’un flux de treball basat en DAG respondrà crides d’eines MCP d’un agent d’IA sense modificació. Els límits nets de blocs paguen aquí d’una manera que l’acoblament estret mai no ho faria.

Aquesta secció introdueix el patró. El tractament arquitectònic complet, incloent com l’orquestració agèntica escala fins a l’operació autònoma contínua a tota la xarxa, és al Capítol 17.

7.3. Exemple d’Implementació#

7.3.1. Orquestrant el Cicle de Vida del Servei de VLAN al Campus#

Hem estat seguint la mateixa xarxa de campus a través de la Part 2. Al Capítol 4, vam emmagatzemar la sol·licitud de servei de VLAN a Nautobot: l’ID de VLAN, la subxarxa, els switches objectiu i les plantilles de configuració per proveïdor. Al Capítol 5, vam usar Ansible via AWX per enviar aquella configuració als switches del campus. Al Capítol 6, vam validar el desplegament i vam començar a monitorar el servei.

El que mai no vam abordar és qui coordina tot això. Cada capítol tenia una suposició implícita: un enginyer executava cada pas manualment. Aquí ho fem explícit i substituïm l’enginyer per un flux de treball.

L’escenari

L’equip d’aplicacions ha enviat una sol·licitud per a un nou segment d’aplicació: VLAN app-payments, subxarxa 10.22.14.0/24, desplegada a tots els switches d’accés de building-b a través de les piles de Cisco i Arista. La sol·licitud va ser enviada a través de ServiceNow i acaba de rebre l’aprovació final.

Aquella aprovació activa un webhook. L’Orquestrador el rep i inicia el flux de treball de desplegament del servei de VLAN.

El flux de treball

Implementem això com una plantilla de flux de treball d’AWX, consistent amb la capa d’execució ja existent. AWX suporta plantilles de flux de treball que encadenen plantilles de job amb branques condicionals i portes d’aprovació, cosa que és suficient per a aquest escenari.

flowchart TD
    A[Webhook ServiceNow\nSol·licitud VLAN aprovada] --> B[Pas 1: Validar SoT\nConsultar Nautobot per registres de dispositiu\ni completesa de la definició de VLAN]
    B --> C{Dades del SoT completes?}
    C -- No --> Z1[Abortar: notificar l'enginyer\ni actualitzar el tiquet ServiceNow]
    C -- Sí --> D[Pas 2: Fan-out pre-checks\nAccessibilitat i estat VLAN\na tots els switches objectiu]
    D --> E{Pre-checks superats?}
    E -- Fallades --> Z2[Abortar: informar fallades\nper dispositiu a ServiceNow]
    E -- Superats --> F[Pas 3: Porta d'aprovació\nValidació humana opcional\nabans de l'execució en producció]
    F --> G[Pas 4: Executar desplegament\nPlaybook Ansible via AWX]
    G --> H[Pas 5: Validació fan-out\nComprovació d'Observabilitat per switch]
    H --> I{Tots els dispositius validats?}
    I -- Èxit complet --> J[Pas 6: Notificar\nActualitzar tiquet ServiceNow\npublicar a Slack]
    I -- Fallada parcial --> K[Pas 6a: Compensació Saga\nRollback només de l'abast fallit]
    K --> J

Pas 1: Validació del SoT

L’Orquestrador consulta Nautobot per confirmar que els registres de dispositius i la definició de VLAN són complets abans que res toqui la xarxa. Aquest pas de guàrdia és responsabilitat de l’Orquestrador, no de l’Executor: l’Executor hauria de rebre una entrada vàlida, no descobrir dades dolentes a mig enviament. Si alguna comprovació falla, el flux de treball s’avorta i actualitza el tiquet de ServiceNow amb el buit específic. (Com s’estructura la validació del SoT es cobreix al Capítol 4.)

Pas 2: Pre-comprovacions als switches objectiu (fan-out)

El flux de treball fa fan-out a tots els switches objectiu en paral·lel. Cada branca executa una pre-comprovació lleugera: accessibilitat, estat de la taula de VLAN, capacitat disponible. El pas fan-in classifica els resultats i realitza branques; el llindar de fallada és configurable. El que importa des del punt de vista de l’orquestració és que aquest és un patró fan-out/fan-in amb branques condicionals, no un polling seqüencial. (Els patrons d’execució de pre-comprovació estan al Capítol 5.)

Pas 3: Porta d’aprovació

Un signe d’aprovació humana opcional abans de l’enviament a producció. Un enginyer té 30 minuts per aprovar o rebutjar; un timeout continua automàticament i es registra. L’Orquestrador manté el flux de treball en un estat d’espera amb una dependència externa fins que l’aprovació arriba o la finestra expira.

Pas 4: Execució del desplegament

L’Orquestrador activa la plantilla de job d’AWX del Capítol 5, passa els paràmetres del pas de validació del SoT i espera el resultat. L’Executor gestiona la resta. Aquesta és la separació de preocupacions a la pràctica: l’Orquestrador decideix actuar, l’Executor actua.

Pas 5: Validació d’Observabilitat (fan-out)

Després del desplegament, un segon fan-out executa un job de validació per switch objectiu: apareix la VLAN a la taula de VLAN, estan les interfícies en l’estat esperat? El fan-in classifica els resultats: èxit total, èxit parcial o fallada. (El que valida la capa d’Observabilitat i com ho fa es cobreix al Capítol 6.)

Pas 6: Enrutament del resultat

L’èxit total tanca el flux de treball: el tiquet de ServiceNow s’actualitza i es publica un resum a Slack. La fallada parcial activa la compensació Saga: el playbook de rollback s’executa només per als dispositius que han fallat la validació; els dispositius que han tingut èxit conserven la seva configuració. El tiquet de ServiceNow registra el resultat per dispositiu.

Tornem a l’enginyer de l’obertura

Aquest flux de treball mostra els set blocs constructius del marc NAF del Capítol 3 treballant junts: Nautobot (Font de Veritat) ha proporcionat la intenció, AWX (Executor) l’ha aplicat, Prometheus (Observabilitat) ha validat el resultat, la plantilla de flux de treball d’AWX (Orquestrador) ha coordinat la seqüència completa i un webhook de ServiceNow (Presentació, cobert al Capítol 8) ha activat tot el flux a partir de la sol·licitud de l’equip d’aplicacions.

L’enginyer de la història d’obertura segueix aquí. És qui revisa la porta d’aprovació quan s’activa. És qui investiga la fallada parcial que el patró Saga ha marcat però no ha pogut resoldre completament. Segueix sent l’expert. El que l’orquestrador li ha tret no és l’expertesa, sinó la càrrega de mantenir la seqüència al cap, tornar-la a executar pas a pas i ser l’única persona capaç de fer-ho. Això és el que realment costa la coordinació sense automatització.

7.4. Resum#

Aquest capítol ha establert que l’Orchestrator és el bloc constructiu que transforma un conjunt d’eines d’automatització que funcionen en un sistema que es comporta com un de sol. Sense ell, la coordinació segueix sent manual, les fallades requereixen intervenció humana i l’escala de la xarxa es converteix en un límit sobre quanta automatització és realment possible.

En el seu nucli, l’orquestració descansa en un motor de fluxos de treball que defineix com s’estructuren i s’executen els processos de múltiples passos. L’elecció entre monòlit, DAG, coreografia i coordinació agèntica és una decisió arquitectònica, no una preferència d’eines. El model DAG amb els seus patrons nombrats (seqüencial, fan-out, condicional, Saga) és l’estàndard de producció per a l’automatització de xarxes. El patró agèntic, introduït a la Secció 7.2.7 amb Model Context Protocol (MCP) com a capa d’interfície, representa un compromís diferent i rep el seu tractament complet al Capítol 17.

L’activació defineix com el món exterior arriba a l’orquestrador. La distinció entre l’activació a la capa d’execució (Capítol 5) i l’activació a la capa d’orquestració importa arquitectònicament: una condueix un únic canvi de dispositiu, l’altra condueix un flux de treball multisistema coordinat. L’automatització impulsada per events i el Patró de Bucle Tancat hereten les propietats no negociables de la idempotència i la deduplicació precisament perquè els activadors automatitzats s’activen sense revisió humana.

La resiliència i l’escala separen l’automatització que funciona en les demostracions de l’automatització que funciona a les 3 de la matinada. L’estat durable, les estratègies de reintent que distingeixen les fallades transitòries de les permanents, el Patró Saga per a la compensació de fallades parcials i els controls de concurrència per a poblacions de dispositius grans no són funcionalitats opcionals per afegir més endavant. Defineixen si l’orquestrador és de confiança quan les condicions no són ideals.

L’estat i la traçabilitat proporcionen el registre del que s’ha executat, qui l’ha activat i el que ha produït cada pas. Aquest registre és diferent de l’estat operatiu de la xarxa (Capítol 6) i la intenció de xarxa (Capítol 4). Els registres d’auditoria a prova de manipulació són un requisit de compliment, no una reflexió posterior. La gestió de la pipeline tanca el bucle: les definicions de fluxos de treball són programari de producció i s’han de versionar, provar i promocionar amb la mateixa disciplina que qualsevol altre codi que s’executa a la plataforma d’automatització.

L’escenari del servei de VLAN del campus ha reunit aquestes cinc funcionalitats: un flux de treball de deu passos activat per un webhook de ServiceNow, coordinant la validació del SoT, les pre-comprovacions, l’execució, la validació d’Observabilitat i la compensació Saga, sense cap enginyer en el bucle de coordinació. La propera pregunta natural és qui veu aquest flux de treball en execució i com l’equip d’aplicacions que l’ha activat en fa el seguiment del progrés. Això és la capa de Presentació, coberta al Capítol 8.

💬 Found something to improve? Send feedback for this chapter