1. L’Imperatiu de l’Automatització#

Des que van arribar el Software-Defined Networking (SDN) i el DevOps, els enginyers han debatut si l’automatització de xarxes és necessària, un luxe o simplement una sobreenginyeria. La resposta? Depèn. Els hiperscaladors la necessiten: van començar a principis dels anys 2010 perquè no tenien cap altra opció. Les petites empreses potser no necessiten automatització completa en absolut. La majoria de les xarxes se situen en algun punt intermedi. La cultura, les habilitats, la maduresa de les eines i les prioritats del negoci determinen la velocitat d’adopció. Avui, tots aquests factors s’estan alineant. L’automatització s’està tornant inevitable.

Un equip de xarxa en una empresa logística regional va passar tres anys construint el que van anomenar la seva plataforma d’automatització. Playbooks d’Ansible per a l’aprovisionament de VLANs, configuració de veïns BGP i hardening de dispositius. El seu codi vivia a Git. Els canvis passaven per revisió entre parells. El desplegament trigava minuts en lloc de dies. Per tots els indicadors que tenien, estaven fent l’automatització bé.

Aleshores l’empresa va adquirir un competidor i va doblar la seva mida d’un dia per l’altre. Noves seus, dos nous proveïdors, convencions de nomenclatura que entraven en conflicte amb les pròpies. La primera vegada que van executar el seu playbook d’aprovisionament contra el nou entorn, va fallar en un cas límit. El van apedaçar. Va fallar en un altre. Sis setmanes després de l’adquisició, un enginyer dedicava més temps a mantenir l’automatització del que hauria portat gestionar la xarxa manualment.

La revisió post-mortem va ser incòmoda. Les eines no havien fallat. Ansible funcionava bé. El que havia fallat era invisible: no existia una descripció única de com havia de semblar la xarxa. Cada playbook portava les seves pròpies suposicions sobre convencions de nomenclatura, estratègies d’assignació d’IPs i comportament dels proveïdors. Quan l’entorn va canviar, tots els supòsits es van trencar simultàniament. L’equip havia automatitzat la seva xarxa existent, no construït una plataforma capaç d’adaptar-se al canvi.

Aquest és el patró en el cor de tot estancament d’automatització. Les organitzacions arriben a un punt en què l’automatització construïda per al problema d’avui es converteix en l’obstacle de demà.

1.1. La Tempesta Perfecta#

L’automatització ja no és opcional. Els hiperscaladors afronten un creixement explosiu impulsat per la Artificial Intelligence (AI): centenars de milers de Central Processing Unit (CPU)s i Graphics Processing Unit (GPU)s comunicant-se a través d’Ethernet d’alta velocitat. Les empreses i els proveïdors de serveis equilibren infraestructura llegada, nous serveis, proliferació de cloud/on-prem/edge i costos creixents.

Tot la resta del món tecnològic va passar a API-first i autoservei. Els desenvolupadors esperen el mateix de les xarxes. Les càrregues de treball de ML necessiten dades estructurades. La seguretat i el compliment normatiu requereixen processos automatitzats i auditables.

La pregunta ja no és “Hem d’automatitzar?” És “Per què no ho hem fet ja?”

Malgrat els beneficis evidents, diverses barreres han frenat l’adopció, i moltes persisteixen:

• Sense models d’intenció: Les xarxes es descrivien mitjançant configuracions de dispositius, no mitjançant “com hauria de comportar-se realment la xarxa?”. Sense dades clares d’intenció, l’automatització roman fràgil i centrada en els dispositius.
• Dissenys desordenats i inconsistents: L’automatització necessita predictibilitat. Les xarxes plenes d’excepcions, solucions provisionals i casos únics són impossibles d’automatitzar. Els dissenys nets i estandarditzats són els que funcionen.
• Proliferació de proveïdors: La barreja de proveïdors, plataformes i serveis genera constants maldecaps d’integració.
• Habilitats inadequades: Pocs enginyers coneixien tant les xarxes com el desenvolupament de programari. Aquesta bretxa dificultava dissenyar bé l’automatització.
• Por al canvi: Les xarxes són crítiques. La gestió conservadora del canvi feia difícil justificar l’automatització.
• Sense entorns de prova segurs: La majoria dels equips mancaven de laboratoris adequats que repliquessin producció. Provar l’automatització de forma segura era gairebé impossible.

Aquestes barreres no operen de forma independent. Es reforcen mútuament: sense models d’intenció, l’automatització roman fràgil; l’automatització fràgil amplifica la por al canvi; la por al canvi bloqueja la inversió necessària per desenvolupar les habilitats i els entorns de prova que reduirien la fragilitat.

flowchart LR
    subgraph Tècnic
        A[Sense models d'intenció]
        B[Dissenys desordenats]
        C[Proliferació de proveïdors]
        D[Sense entorns de prova]
    end
    subgraph Organitzatiu
        E[Habilitats inadequades]
    end
    A --> F[Por al canvi]
    B --> F
    C --> F
    D --> F
    E --> F
    F -->|limita la inversió| E
    F -->|frena l'avenç en| A

    style F fill:#ffcccc,stroke:#cc0000,stroke-width:2px

Bones notícies: per al 2025, la majoria d’aquestes barreres s’estan dissolent. Les empreses i els proveïdors avancen. La State of Network Automation Survey de Chris Grundemann (Network Automation Forum) mostra el canvi que s’està produint ara. Tot i així, no existeix cap fórmula màgica única. Primer cal entendre la mentalitat.

1.2. Com abordar l’automatització de xarxes#

Aquest llibre cobreix els conceptes arquitectònics fonamentals que es necessiten per a una automatització de xarxes exitosa. No perseguiu una única eina: no existeix cap solució màgica. L’èxit prové de combinar tres pilars: Persones, Procés i Tecnologia (en aquest ordre).

1.2.1. Els tres pilars de l’èxit#

Com la piràmide de Maslow (cal una base sòlida abans de construir més amunt), cada pilar sosté l’anterior.

flowchart BT
    A[Persones] --> B[Procés]
    B --> C[Tecnologia]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc

• Persones: L’automatització viu o mor en funció de les persones que la dissenyen, construeixen i operen. Comprengui les seves necessitats. Capaciti-les mitjançant formació i col·laboració.
• Procés: L’alineació organitzativa importa. Vinculi els resultats de l’automatització a valor mesurable: reducció de costos, lliurament més ràpid, major fiabilitat.
• Tecnologia: Les eines existeixen. El repte és triar les adequades i integrar-les dins d’una arquitectura sòlida.

Equilibri aquests tres pilars i l’automatització es converteix en una capacitat organitzativa, no tan sols en un projecte tècnic. El canvi és iteratiu. El progrés arriba pas a pas. S’enfrontarà repetidament al clàssic dilema comprar-o-construir: l’abordem al llarg de tot el llibre.

1.3. Com és la realitat#

Cada organització segueix el seu propi camí. La majoria comença amb scripts petits i després amplia cap a gestió de configuracions, comprovacions de compliment i resolució de problemes.

1.3.1. Entenent l’espectre de l’automatització#

La maduresa de l’automatització evoluciona des de les operacions manuals fins a les xarxes autònomes:

graph LR
    A[Operacions Manuals] --> B[Tasques amb Scripts]
    B --> C[Automatització de Fluxos]
    C --> D[Sistemes Basats en Intenció]
    D --> E[Xarxes Autònomes]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc
    style D fill:#ccffcc
    style E fill:#ccccff

Operacions Manuals: Cada canvi és una decisió humana executada manualment a través de Command Line Interface (CLI). Ràpid per a un únic enginyer en un dispositiu conegut, poc fiable a qualsevol escala. La xarxa és tan consistent com l’última persona que la va tocar. No existeix auditoria més enllà dels registres d’inici de sessió.

Tasques amb Scripts: El treball repetitiu s’embolcalla en scripts. Un script genera configuracions des d’un full de càlcul; un bucle aplica el mateix canvi a cinquanta dispositius. Fràgil als extrems: cada variació en l’estat del dispositiu, el comportament del proveïdor o la convenció de nomenclatura requereix un nou script o una nova excepció. Aquí és on comencen la majoria dels equips, i on molts es queden.

Automatització de Fluxos: Els scripts són reemplaçats per playbooks i pipelines estructurats. Els canvis són reproduïbles, auditables i es poden activar mitjançant interfícies d’autoservei. L’automatització encara descriu com configurar els dispositius en lloc de com ha de semblar la xarxa. La reconciliació d’estat continua sent una activitat manual. Els equips en aquesta etapa solen descriure la seva automatització com a funcional, fins que l’entorn canvia.

Sistemes Basats en Intenció: La xarxa es descriu com a intenció (el que es vol) en lloc de configuració (com aconseguir-ho). Una font de veritat conté aquesta intenció com a dades estructurades. Els motors d’automatització tradueixen la intenció en l’estat del dispositiu i validen el resultat. Quan l’entorn canvia, la intenció roman estable i la capa d’execució s’adapta. La major part d’aquest llibre tracta de construir bé aquesta capa: els blocs de font de veritat, execució, observabilitat, orquestració i presentació de la Part 2 són els components d’un sistema basat en intenció.

Xarxes Autònomes: El sistema observa el seu propi estat, detecta desviacions respecte a la intenció i tanca el bucle sense intervenció humana. Això requereix que la capa basada en intenció sigui fiable, ben entesa i operada amb disciplina. Les Parts 4 i 5 exploren els patrons que ho fan possible: automatització de bucle tancat, xarxes autorecuperables i les condicions organitzatives que fan que l’operació autònoma sigui de confiança.

Les Parts 1 a 3 d’aquest llibre construeixen els fonaments arquitectònics per als sistemes basats en intenció. Les Parts 4 i 5 aborden el que es necessita per fer el pas cap a l’operació autònoma. La majoria de les organitzacions avui se situen entre les Tasques amb Scripts i l’Automatització de Fluxos. L’objectiu no és saltar-se etapes: és construir cada capa sobre fonaments sòlids perquè la següent no requereixi reconstruir l’anterior.

El que realment canvia a escala no és l’objectiu sinó l’arquitectura. L’automatització dissenyada per a 50 dispositius exposa les seves dreceres a 500. Els playbooks que incorporen suposicions implícites de nomenclatura fallen quan la xarxa creix més enllà del coneixement operatiu d’un sol equip. La Part 3 examina què es trenca quan una plataforma d’automatització passa de desenes a milers de dispositius, i com dissenyar-ho des del principi.

Un benefici ocult de l’automatització de xarxes és que motiva a simplificar l’arquitectura de xarxa tant com sigui possible per facilitar l’automatització. La complexitat que era tolerable quan es gestionava manualment es converteix en un obstacle actiu quan l’automatització ha de raonar sobre cada excepció.

L’automatització total és un objectiu a llarg termini. L’automatització no reemplaça les persones: amplifica l’experiència, permetent que els enginyers es centrin en el disseny i la resolució de problemes. Els guanys reals són consistència, fiabilitat i velocitat. L’automatització també permet coses impossibles de fer manualment a escala: validació en temps real, comprovacions de compliment instantànies, canvis coordinats en centenars de seus simultàniament.

A continuació es presenten alguns exemples de com es veu l’automatització en diferents entorns:

Hiperscaladors

• Prendre un disseny i expandir-lo a totes les dades necessàries per a la intenció de xarxa: racks, dispositius, cables, Internet Protocol (IP)s, overlay, xarxes. Usar-lo per generar la Bill of Materials (BOM) i les configuracions de bootstrap servides mitjançant Zero Touch Provisioning (ZTP) quan els dispositius es connecten.
• Correlacionar dades d’observabilitat (mètriques, logs, fluxos) en esdeveniments en temps real enriquits amb context. Activar fluxos de treball que mitiguin els problemes dels usuaris: drenant connexions mentre es manté la capacitat dins del SLA.

Proveïdors de Serveis

• Proves de malla completa d’enllaços d’Internet entre proveïdors de trànsit. Mantenir la pèrdua de paquets i la latència dins de tolerància. Detectar problemes, drenar tràfic d’enllaços sospitosos. Recuperar-los quan es resolguin.
• Monitorar les notificacions de manteniment de circuits dels proveïdors (email, webhooks). Convertir-les a dades estructurades. Silenciar alertes o reaccionar proactivament per minimitzar l’impacte.

Empreses

• Portal d’autoservei on els usuaris defineixen polítiques de seguretat. Convertir-les en regles de tallafoc seguint la política d’aplicació. Habilitar un cicle de vida de regles que netegi les regles no utilitzades.
• Gestió del cicle de vida i renovació de dispositius. Detectar dispositius End of Life (EOL), marcar vulnerabilitats de programari, automatitzar actualitzacions, facilitar migracions de plataforma.

La clau: identificar quins processos consumeixen més temps, són més propensos a errors o són més crítics. Entendre com donen suport al negoci. Després evolucionar-los cap a versions més eficients i automatitzades.

Aquestes solucions poden ser simples o complexes, però comparteixen patrons comuns. Aquest llibre analitza aquests patrons i conclou amb casos d’ús sofisticats del món real a la Part 5 — Patrons i Casos d’Ús.

Fins i tot amb bones intencions, les coses surten malament. A continuació es presenten alguns errors comuns a tenir en compte.

1.3.2. Errors comuns que evitar#

Descobrirà molts errors al llarg d’aquest llibre. Aquí n’hi ha alguns que convé tenir presents:

• Intentar automatitzar-ho tot alhora: Comenci petit. Triï casos d’ús d’alt impacte i baix risc per guanyar confiança i experiència.
• Incrustar la intenció dins de les eines: Quan les convencions de nomenclatura, les estratègies d’assignació d’IPs i els supòsits sobre el comportament dels proveïdors viuen dins de playbooks i scripts en lloc d’en una referència compartida, no existeix una descripció única de com hauria de semblar la xarxa. Quan l’entorn canvia, tots els supòsits incorporats es trenquen alhora. La intenció pertany a un únic lloc, compartit per tots els components d’automatització.
• Subestimar la qualitat de les dades: L’automatització és tan bona com les seves dades. Inverteixi en precisió i consistència des del principi.
• Construir sense provar: Provi i validi abans de desplegar a producció.
• Automatitzar la xarxa actual en lloc de dissenyar per al canvi: L’automatització construïda al voltant de la topologia, els proveïdors i les convencions de nomenclatura actuals funciona fins que alguna cosa canvia. Abans de construir qualsevol component d’automatització, pregunti’s no “funciona això ara?” sinó “seguirà funcionant quan l’entorn canviï?”. Codificar la xarxa actual en l’automatització crea deute tècnic que s’acumula cada vegada que el negoci evoluciona.
• Construir per als enginyers que ho van construir, no per a les persones que ho usen: Una plataforma d’automatització dissenyada només per a l’equip que la va construir és un punt únic de fallada. L’equip d’aplicacions que envia una sol·licitud de servei, l’operador que aprova un canvi, l’auditor que revisa un informe de compliment: cadascun té necessitats, vocabulari i expectatives diferents. Tenir presents aquests usuaris des del principi modela cada decisió arquitectònica: com s’estructura l’API, com es mostren els errors, com es comunica l’estat. L’automatització que els enginyers entenen però els consumidors no poden usar serà silenciosament ignorada.

Per últim: deixi que el treball parli per si mateix. Defineixi i faci un seguiment de mètriques que demostrin objectivament els beneficis de l’automatització de xarxes i el seu impacte en el negoci.

1.3.3. Mesurar l’èxit de l’automatització#

Centri’s en dos grups: mètriques tècniques i mètriques de negoci. Totes dues importen al lideratge.

Mètriques Tècniques:

• Temps Mitjà de Recuperació (MTTR): Amb quina rapidesa pot detectar, diagnosticar i resoldre problemes de xarxa?
• Taxa d’Èxit de Canvis: Quin percentatge dels canvis de xarxa es despleguen sense causar incidents?
• Configuration Drift: Quant de consistents són les configuracions dels dispositius a tota la xarxa?
• Velocitat de Desplegament: Amb quina rapidesa pot implementar nous serveis o canvis de configuració?

Mètriques de Negoci:

• Disponibilitat del Servei: Són els serveis gestionats per automatització més fiables que els gestionats manualment?
• Productivitat d’Enginyeria: Dediquen els equips més temps al treball estratègic enfront de les tasques operatives?
• Postura de Compliment: Amb quina rapidesa pot validar i remediar les infraccions de compliment?
• Utilització de Recursos: Està aprofitant millor la capacitat i el rendiment de la xarxa?

Faci un seguiment regular d’aquestes mètriques. Justifiquen la inversió continuada i mostren on millorar. El Capítol 6 explica com el bloc d’Observabilitat recull i exposa aquestes mètriques; el Capítol 14 les connecta amb el valor de negoci i el pensament de producte de plataforma.

1.4. Resum#

La plataforma d’automatització de l’empresa logística era tècnicament competent. El falliment va ser arquitectònic: cap descripció única de la intenció, cap separació entre com hauria de semblar la xarxa i com arribar-hi, cap manera de raonar sobre el sistema quan l’entorn va canviar. Aquesta forma de falliment no és inusual. És el resultat per defecte quan l’automatització es tracta com una col·lecció de scripts en lloc d’una plataforma amb un disseny basat en principis.

Les forces que impulsen l’automatització són estructurals, no opcionals: l’escala de la infraestructura moderna, l’expectativa d’autoservei a velocitat de desenvolupador i el cost creixent d’operar xarxes manualment. Les organitzacions que tracten l’automatització com un problema d’eines descobreixen que cada nou entorn requereix reconstruir des de zero. Les que la tracten com un problema arquitectònic construeixen alguna cosa que es potencia amb el temps.

Els tres pilars (Persones, Procés, Tecnologia) són una cadena de dependències, no una llista de verificació. Les eleccions tecnològiques que escalen són les que es realitzen al servei d’un procés clar, per persones que entenen el problema. Aconseguir aquest ordre correcte és el que separa l’automatització que creix de l’automatització que s’ha de reconstruir cada pocs anys.

L’espectre d’automatització va des de les operacions manuals passant per tasques amb scripts, automatització de fluxos, sistemes basats en intenció i xarxes autònomes. La majoria de les organitzacions avui se situen en algun punt intermedi. Aquest llibre construeix els fonaments arquitectònics per a la capa basada en intenció: les Parts 1 i 2 estableixen el per què i el com, la Part 3 examina què canvia a escala, i les Parts 4 i 5 exploren els patrons que permeten el pas cap a l’operació autònoma.

El falliment arquitectònic específic de la història de l’empresa logística no és accidental. És el resultat per defecte quan l’automatització es dissenya sense principis explícits: sense intenció compartida, sense separació entre com hauria de semblar la xarxa i com arribar-hi, sense manera de raonar sobre el sistema quan l’entorn va canviar. El Capítol 2 anomena aquests principis i mapeja cadascun amb la classe de falliment que prevé.

💬 Found something to improve? Send feedback for this chapter