4. La Font de Veritat#

Un nou servei havia d’entrar en funcionament abans d’acabar la setmana. El canvi era senzill: una nova VLAN, una nova subxarxa, regles de tallafoc actualitzades i una nova comunitat BGP als encaminadors de vora. L’enginyer de xarxa sabia exactament què havia de fer. El que va seguir van ser quatre dies de coordinació entre cinc sistemes: l’eina IPAM per reservar la subxarxa, el CMDB per registrar el servei, la plataforma de gestió de tallafocs per aplicar la nova política, el sistema de configuració d’encaminadors per a la comunitat BGP i la plataforma de monitorització per afegir els nous llindars. Cada sistema tenia la seva pròpia interfície, el seu propi model de dades i el seu propi flux d’aprovació. I com que no hi havia cap referència compartida, l’enginyer havia de transportar el context manualment: copiant valors d’un sistema a l’altre i esperant que res no hagués canviat entre passos.

Sis mesos més tard, el servei es va donar de baixa. Es va eliminar la VLAN. Es va alliberar la subxarxa. Però la regla del tallafoc va quedar. Ningú recordava que estava vinculada a aquell servei. La comunitat BGP va continuar existint en dos encaminadors de vora. El llindar de monitorització no parava d’activar alertes de baixa prioritat que el NOC va aprendre a ignorar. Amb el temps, la xarxa va acumular capes de configuració òrfena: restes de canvis que mai no es van registrar del tot, mai no es van revertir del tot, mai no es van connectar a un registre compartit d’intenció.

Així és com es veu gestionar una xarxa sense una font de veritat. No un error dramàtic puntual, sinó una acumulació lenta d’inconsistències on cada canvi requereix actualitzar múltiples sistemes desconnectats i on res no controla quines coses formen part del mateix conjunt.

Tot sistema d’automatització comença amb una pregunta: Què vaig a fer exactament? Quan desplegueu una regla de tallafoc, afegiu una adreça IP o configureu una VLAN, ho feu basant-vos en alguna representació d’intenció. Aquesta representació és la vostra font de veritat: la versió única i fiable del que hauria d’estar desplegat.

Faig servir “Font de Veritat” i “Intenció” de manera intercanviable. Són exactament el mateix concepte.

Sense una font de veritat fiable, les operacions de xarxa es converteixen en un caos de coneixement tribal. Els enginyers no es posen d’acord en el que hi ha desplegat. Els fulls de càlcul contradiuen el que realment s’executa. Dos sistemes d’automatització diferents fan canvis contradictoris al mateix dispositiu. Quan quelcom falla, us trobeu fent arqueologia: “Per què estava configurat així? Qui ho va aprovar? Quan va canviar?”

Aquest capítol explica com construir una font de veritat que funcioni tant si teniu desenes de dispositius com centenars de milers, que serveixi tothom qui necessita dades (persones, automatització i altres sistemes), que mantingui les dades precises i fiables, i que gestioni la complexitat d’obtenir dades de múltiples fonts. Cobrirem sis blocs funcionals: Modelatge, Consum, Aplicació, Versionat, Agregació i Orientat al Disseny, que junts creen una base sòlida per a l’automatització de xarxes. També tractaré qüestions pràctiques a l’hora d’incorporar xarxes existents a aquest sistema i us mostraré quines solucions hi ha disponibles.

4.1. Fonaments#

La font de veritat fa tres coses: defineix com expresseu el que voleu, on viu aquesta intenció i com la manteniu fiable al llarg del temps. Sense ella, els altres blocs funcionals es converteixen en eines aïllades sense referència compartida. Amb ella, treballen junts.

4.1.1. Objectius#

La vostra font de veritat ha de complir sis requisits:

1. Capturar tot el que necessiteu. Emmagatzemeu la imatge completa de la vostra xarxa: configuracions, actius, topologia, serveis, adreces IP, circuits, especificacions de dispositius, credencials, finestres de manteniment, aspectes de compliment normatiu i propietaris. Incloeu no només el que s’executa avui, sinó el que heu planificat i el que esteu retirant. Quan totes aquestes dades viuen en un sol lloc en lloc d’estar disperses en fulls de càlcul i en la memòria de les persones, els vostres sistemes d’automatització disposen del context que necessiten per prendre decisions encertades.

2. Deixar que els operadors pensin en termes de negoci, no en sintaxi de dispositiu. El personal hauria de treballar a nivell de negoci (“afegir una nova sucursal” o “configurar un servei MPLS”) i no a nivell de Command Line Interface (CLI). En segon pla, el vostre sistema s’encarrega de les configuracions específiques de cada dispositiu. Això permet que les persones es concentrin en el que volen aconseguir, no en els detalls de baix nivell.

3. Permetre que persones i màquines accedeixin a les dades fàcilment. El vostre sistema necessita Application Programming Interface (API)s (Representational State Transfer (REST), GraphQL) perquè l’automatització pugui obtenir i modificar dades. Necessita una interfície web i un Command Line Interface (CLI) perquè les persones puguin navegar-hi i editar-les. Tothom necessita controls d’accés sòlids per veure només el que hauria de veure. Podeu tenir centenars de fluxos d’automatització executant-se simultàniament, dotzenes de membres del personal editant dades i sistemes externs sincronitzant-se, i tot queda consistent i ràpid.

4. Mantenir les dades netes i fiables. Valideu-ho tot: comproveu que els tipus de dades siguin correctes, que les relacions tinguin sentit, que les VLANs estiguin en rangs vàlids i que les adreces IP no es dupliquin. Registreu qui ha canviat què i quan. Deixeu que les persones aprovin els canvis importants abans que s’apliquin. Si quelcom va malament, podeu fer un rollback. La vostra automatització ha de poder confiar que les dades són precises, perquè les dades incorrectes condueixen a un estat de xarxa incorrecte i a interrupcions.

5. Permetre que les persones treballin en paral·lel sense interferir-se. Múltiples equips han de poder proposar canvis simultàniament. Els canvis s’agrupen en blocs atòmics: o tots entren o tots fallen, sense estats intermedis. Podeu provar els canvis en un entorn de proves abans que entrin en producció. Per a grans migracions, podeu crear una branca, fer la vostra feina i fusionar-la de nou. Sempre sabreu quina intenció s’utilitza ara en comparació amb la que s’està proposant.

6. Importar dades d’altres sistemes. Probablement ja teniu gestió d’actius per al maquinari, sistemes IP per a les adreces, proveïdors de circuits per a la connectivitat i CMDBs per als serveis. No els dupliqueu. En lloc d’això, sincronitzeu-los. Establiu regles clares sobre quin sistema posseeix quines dades. Manteniu-ho tot sincronitzat en ambdues direccions. Això us ofereix una visió unificada de tot sense reinventar la roda.

4.1.2. Pilars#

Aquests sis pilars no són funcionalitats independents; formen una arquitectura per capes. El Modelatge defineix el que es pot expressar. L’Orientat al Disseny tradueix aquesta expressió en artefactes tècnics. El Consum posa aquests artefactes a disposició de tots els sistemes que els necessiten. L’Aplicació manté la fiabilitat de les dades a l’entrada. El Versionat preserva el registre d’intenció al llarg del temps, habilitant el rollback i l’auditoria. L’Agregació evita que la Font de Veritat es converteixi en un altre silo aïllat incorporant dades autoritzades dels sistemes que ja les posseeixen.

Elimineu-ne qualsevol, i els altres es degraden. Sense Aplicació, el Consum serveix dades incorrectes. Sense Versionat, no hi ha manera de rastrejar el que va canviar quan quelcom falla. Sense Agregació, els operadors mantenen dades duplicades entre sistemes i la Font de Veritat perd credibilitat. La secció 4.2 aborda cadascun en profunditat.

Abans de detallar les sis Funcionalitats, aclarim l’abast de la Font de Veritat.

4.1.3. Abast#

Abans d’entrar en els detalls d’implementació, és important entendre de quines coses és responsable la font de veritat i de quines no.

Dins de l’abast:

La font de veritat gestiona totes les dades d’intenció: la definició completa del que hauria de semblar la vostra xarxa. Això inclou les configuracions de producció, els entorns de proves, les branques de desenvolupament i els escenaris de test. Tot el que descriu “el que voleu” viu aquí.

Fora de l’abast:

La font de veritat no fa diverses coses que podrien semblar relacionades:

1. Dades d’observabilitat: La font de veritat no emmagatzema mètriques, registres ni estat en temps d’execució. No obstant, sí que defineix les expectatives amb les quals comparareu, com els valors de llindar per a les alertes o les xifres de rendiment base. Les dades reals d’observabilitat viuen en un altre lloc (cobert al Capítol 6).

2. Interacció amb la xarxa: La font de veritat no parla amb els dispositius ni n’empeny configuracions. Proporciona els artefactes necessaris (configuracions de dispositiu, regles de validació, manifests de desplegament) però no els executa. Aquesta és la feina de l’Executor (Capítol 5).

3. Lògica d’orquestració: La font de veritat no defineix la seqüència de passos ni els fluxos de treball per desplegar els canvis. Defineix l’estat final desitjat. Com arribar-hi (quins dispositius primer, quins passos de validació, procediments de rollback) correspon a l’Orquestrador (Capítol 7).

Penseu en la font de veritat com l’estrella polar de la vostra estratègia d’automatització de xarxes. És la resposta única i autoritzada a la pregunta “Com hauria de ser la xarxa?” Tot el que hi ha en el vostre sistema d’automatització (execució, monitorització, orquestració) fa referència a aquesta veritat per fer la seva feina. Quan la realitat divergeix de la intenció, la font de veritat us indica en quina realitat us heu de convertir.

4.2. Funcionalitats#

Parlem ara dels sis blocs funcionals que implementen tot això.

Cada un es correspon a un objectiu i un pilar:

1. Modelatge: Defineix quines dades emmagatzemeu i com es relacionen. Models de dispositiu, interfícies, VLANs, circuits i serveis. Deixeu que evolucioni a mesura que canviïn les vostres necessitats.

2. Orientat al Disseny: Tradueix la intenció d’alt nivell en configuracions reals de dispositiu mitjançant plantilles i lògica.

3. Consum: Com les persones i els sistemes obtenen i utilitzen les dades. Application Programming Interface (API)s, interfície web, Command Line Interface (CLI). Tothom té controls d’accés adaptats al seu rol.

4. Aplicació: Assegura que les dades incorrectes no s’escapin. Validació, comprovacions d’unicitat i integritat referencial. Missatges d’error clars.

5. Versionat: Manté l’historial complet. Qui ha canviat què, quan i per què. Rollback quan calgui.

6. Agregació: Importa dades d’altres sistemes (CMDB, IPAM, etc.) i les manté sincronitzades.

graph LR

    %% --- Subgraphs ---
    subgraph Objectius
        direction TB
        A1[Capturar tot el que necessiteu]
        A2[Permetre als operadors pensar en termes de negoci, no en sintaxi de dispositiu]
        A3[Permetre que persones i màquines accedeixin a les dades fàcilment]
        A4[Mantenir les dades netes i fiables]
        A5[Permetre que les persones treballin en paral·lel sense interferir-se]
        A6[Importar dades d'altres sistemes]
    end

    subgraph Pilars
        direction TB
        B1[Marc de Modelatge de Dades Flexible]
        B2[Disseny i plantilles]
        B3[APIs i interfícies]
        B4[Validació de dades]
        B5[Historial de canvis]
        B6[Agregació de dades]
    end

    subgraph Funcionalitats
        direction TB
        C1[Modelatge]
        C2[Orientat al Disseny]
        C3[Consum]
        C4[Aplicació]
        C5[Versionat]
        C6[Agregació]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6

    %% --- Row gradient classes ---
    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;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    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;
    class A6,B6,C6 row6;

La següent és una perspectiva arquitectònica del bloc d’Intenció:

graph TB

    %% Tier 1
    subgraph T1[Extern]
        A[Consum]
    end

    %% Tier 2
    subgraph T2[Dades]
        B[Orientat al Disseny]
        D[Modelatge]
    end

    %% Tier 3
    subgraph T3[Motor]
        C[Agregació]
        E[Aplicació]
        F[Versionat]
    end

    %% Tier connections
    A <--> B
    A <--> D

    B <--> D

    D <--> C
    D <--> E
    D <--> F

4.2.1. Modelatge#

El vostre model de dades és crític: determina el que podeu representar i amb quina facilitat podeu treballar-hi. Com va assenyalar George Box: “Tots els models són incorrectes, però alguns són útils.” No hi ha cap model perfecte que funcioni per a tothom. En la meva experiència, el modelatge de dades és més art que ciència. Però certs patrons apareixen de manera consistent en els projectes exitosos.

4.2.1.1. Principis Fonamentals#

La manera com organitzeu les dades importa. Determina el que podeu expressar i amb quina eficiència els sistemes poden validar-les i utilitzar-les. Els diferents formats tenen compromisos diferents. El YAML és llegible però no valida gaire. El JavaScript Object Notation (JSON) funciona a tot arreu però és verbós. El Yet Another Next Generation (YANG) afegeix validació però té una corba d’aprenentatge pronunciada. Trieu en funció del que realment necessiteu.

Les vostres dades existeixen a diferents nivells. El mateix element de xarxa es pot descriure de múltiples maneres per a propòsits diferents:

• Nivell de servei: Amigable per al negoci (“configurar un L3VPN MPLS per a la sucursal X”)
• Nivell tècnic: Especificacions tècniques (“BGP AS 65001, route targets 65001:100, polítiques…”)
• Nivell de dispositiu: Configuracions reals (“interface xe-0/0/0; unit 100;…”)

Els bons models connecten aquestes capes. Podeu començar a nivell de negoci i després generar configuracions de dispositiu automàticament. Però no sempre necessiteu les tres capes: depèn del que esteu construint.

4.2.1.2. Persistència de Dades i Escala#

Triar com emmagatzemar les dades del model té implicacions profundes per a la consistència, el rendiment i l’evolució. Implicacions que esdevenen crítiques a mesura que la vostra xarxa creix de centenars a centenars de milers d’objectes gestionats.

• Bases de dades relacionals (p. ex., MySQL, PostgreSQL): Aquesta és l’aposta segura per a la majoria d’equips, i ho dic com un compliment. Imposen consistència d’esquema, proporcionen transaccions ACID i tots els enginyers del vostre equip ja coneixen SQL. Excel·leixen en la representació de jerarquies normalitzades (VLANs que contenen interfícies) i en la prevenció d’anomalies de dades. L’inconvenient: els canvis d’esquema fan mal a escala i el rendiment cau amb unions profundes entre milions de files. Però és un bon problema de tenir: significa que heu desplegat quelcom real.

• Bases de dades de documents (p. ex., MongoDB, CouchDB): Ideals si necessiteu flexibilitat d’esquema i escalabilitat horitzontal. Els documents modelen de manera natural les estructures niades (un dispositiu amb totes les seves configuracions i metadades com un sol blob). Però aquí hi ha la trampa: ara sou responsables de la consistència entre documents i les consultes complexes es tornen cares ràpidament. Tret que tingueu una raó específica per anar per documents, quedeu-vos amb les relacionals.

• Bases de dades de grafs (p. ex., Neo4j): Aquestes són genuïnament millors quan les relacions importen més que els objectes: “A quines VLANs es connecta aquesta interfície? Quins dispositius encaminen entre aquests dos llocs?” Travessen relacions de profunditat arbitrària de manera eficient. Però tret que feu consultes complexes de topologia constantment, esteu triant l’opció exòtica. El vostre equip d’operacions no la coneix, les eines són menys madures i el rendiment d’escriptura queda enrere per a actualitzacions simples. Les bases de dades de grafs resolen problemes reals, però assegureu-vos que teniu realment aquests problemes primer.

flowchart TD
    Q1{Requisit principal?}
    Q1 -->|Travessar relacions complexes en profunditat| Q2{Consultes de topologia constants?}
    Q1 -->|L'esquema evoluciona freqüentment| DB_D[Base de dades de documents]
    Q1 -->|Consultes estructurades, integritat referencial| DB_R[Base de dades relacional]
    Q2 -->|Sí| DB_G[Base de dades de grafs]
    Q2 -->|Ocasionalment| DB_R

    style DB_R fill:#ccffcc,stroke:#28a745
    style DB_G fill:#cce5ff,stroke:#4a90e2
    style DB_D fill:#ffffcc,stroke:#ffc107

Més sobre la persistència de dades, des d’una perspectiva diferent, al capítol d’Observabilitat.

La selecció de la base de dades és un dels principals diferenciadors entre els productes d’aquest espai. Per exemple, NetBox i Nautobot utilitzen bases de dades relacionals, mentre que Infrahub utilitza una base de dades de grafs, com podeu veure a la secció 4.2.8.

La persistència també es pot implementar utilitzant emmagatzematge basat en fitxers amb models de dades com YAML o JavaScript Object Notation (JSON) (o CSV), sovint rastrejats en sistemes Git per al control de versions.

La majoria dels sistemes de Font de Veritat en producció utilitzen persistència políglota: una base de dades relacional per a la intenció autoritzada i les relacions, emmagatzematge de documents o Git per a la flexibilitat i la memòria cau, i capacitats de grafs per a l’anàlisi de topologia.

Quina granularitat ha de tenir el vostre model? Això importa per al rendiment. Si modeleu cada interfície de cada dispositiu com un objecte separat, acabareu amb 50.000 objectes o més per a una xarxa mitjana. Les consultes es tornen lentes. Les actualitzacions es fan pesades.

L’enfocament pràctic: utilitzeu plantilles per als patrons comuns. Digueu “les interfícies 1-40 utilitzen aquesta plantilla estàndard” i rastrejeu només les excepcions. Això són 2 objectes en lloc de 40, les consultes es mantenen ràpides i el renderitzat continua funcionant.

Al Capítol 11 cobrirem com decisions com aquesta impacten el rendiment.

4.2.1.3. Dominis de Dades de Xarxa#

Les implementacions completes de Font de Veritat solen modelar aquests dominis interconnectats:

• Inventari i Actius: Dispositius físics i lògics, especificacions de maquinari, números de sèrie, data de compra, termes del contracte, etapa del cicle de vida
• Infraestructura del Centre de Dades: Ubicacions (geogràfiques i jeràrquiques), edificis, plantes, sales, bastidors, distribució d’alimentació, rutes de cables
• Gestió d’Adreces IP (IPAM): Pools d’adreces, subxarxes, assignacions, resolució DNS, àmbits DHCP, seguiment d’utilització
• Virtualització i Cloud: VPCs, subxarxes, grups de seguretat, instàncies de còmput, emmagatzematge, relacions d’orquestració de contenidors
• Connectivitat: Circuits físics (MPLS, Ethernet), túnels virtuals, relacions de peering, assignacions d’amplada de banda, polítiques QoS
• Encaminament: Comunitats BGP, sistemes autònoms, polítiques d’encaminament, llistes de prefixos, route targets per a serveis L3VPN
• Serveis: Definicions de servei lògic (L3VPN, L2VPN, travessia de tallafocs), mapejos servei-dispositiu, SLAs
• Seguretat i Compliment: Llistes de control d’accés, regles de tallafocs, zones de seguretat, etiquetes de compliment, requisits d’auditoria
• Gestió: Detalls SNMP, subscripcions gNMI, fonts NTP, destinacions syslog, integració TACACS+/RADIUS

Aquests dominis són interdependents: l’Encaminament fa referència a la Connectivitat, els Serveis abasten l’Inventari i l’IPAM, les polítiques de Seguretat s’apliquen tant als Dispositius com als Serveis. Una Font de Veritat ben dissenyada modela aquestes relacions explícitament en lloc de tractar cada domini com una taula aïllada.

graph TD
    INV[Inventari i Actius]
    DC[Infraestructura del Centre de Dades]
    IPAM[Gestió d'Adreces IP]
    VIRT[Virtualització i Cloud]
    CONN[Connectivitat]
    ROUTE[Encaminament]
    SVC[Serveis]
    SEC[Seguretat i Compliment]
    MGMT[Gestió]

    DC --> INV
    INV --> IPAM
    INV --> MGMT
    CONN --> INV
    VIRT --> IPAM
    ROUTE --> CONN
    SVC --> INV
    SVC --> ROUTE
    SVC --> IPAM
    SEC --> INV
    SEC --> SVC

    classDef foundation fill:#ddeeff,stroke:#4a90e2,stroke-width:2px
    classDef overlay fill:#e8f5e9,stroke:#28a745
    classDef policy fill:#fff3cd,stroke:#ffc107
    class INV,IPAM,CONN foundation
    class ROUTE,VIRT,DC,MGMT overlay
    class SVC,SEC policy

Més enllà dels dominis específics de xarxa, també calen molts altres tipus de dades. Per exemple, un backend de secrets per emmagatzemar credencials. De manera més general, la gestió completa de dades encaixa dins d’un sistema global de gestió d’infraestructura de TI.

Vull compartir una pregunta habitual per a molts equips que debaten entre fer servir una font de dades específica per a xarxes, com NetBox, o una de propòsit general com ServiceNow. En la meva experiència, tot i que és possible assolir resultats similars, el fet que ServiceNow sigui un sistema de tota l’empresa fa que sigui més difícil (i lent) d’evolucionar, alentint als equips de xarxa per aprofitar-lo per a una representació completa de la xarxa.

Classificació de Dades i Atributs Comuns

En tots els dominis de xarxa, certs patrons de classificació apareixen de manera consistent. Els models ben dissenyats inclouen aquests atributs fonamentals per mantenir una manipulació de dades coherent:

• Rol: Quin propòsit té aquest objecte? (core, distribució, accés; primari, secundari)
• Estat: Està actiu, planificat, en fase de retirada o retirat?
• Tipus: Quin tipus d’objecte és? (VLAN, dispositiu, circuit, servei)
• Propietat: Quin equip o unitat de negoci el gestiona?
• Ubicació: On es troba aquest recurs geogràficament o organitzativament?

4.2.1.4. Patrons de Disseny de Models: Extensibilitat, Polimorfisme i Migracions#

Algunes solucions inclouen un model integrat basat en el que els creadors pensen que haurien de ser les xarxes. Això és fantàstic si la vostra xarxa s’adapta a aquesta suposició, i no tan bo si no ho fa. Altres solucions us deixen construir-lo des de zero: gran flexibilitat, però necessiteu disciplina. Normalment, el millor enfocament és un híbrid: feu servir els models integrats per als casos comuns (el 80% que fa tothom), però assegureu-vos que podeu estendre’ls per a les vostres necessitats específiques.

L’espectre: des d’opinat fins a personalitzat

Hi ha un espectre aquí, i val la pena entendre on us situeu:

• Models Molt Opinats (p. ex., NetBox de sèrie):

  • Pros: Ràpid de desplegar, menys presa de decisions, bones pràctiques integrades
  • Contres: Dolorós si la vostra xarxa no s’adapta al motlle, canviar el model és difícil

• Models Totalment Personalitzats (construïu el vostre des de zero, com Infrahub):

  • Pros: Adaptació perfecta a les vostres necessitats específiques, sense camps innecessaris
  • Contres: Temps extra per dissenyar, molt d’assaig i error, ningú a qui copiar (però hi ha referències)

Tot i que Infrahub us permet construir models totalment personalitzats, també inclou models opinats per començar.

On hauríeu de començar realment? El que dic a tothom: comenceu amb eines amb models opinats com NetBox, Nautobot o Infrahub. Punt. No m’importa el especial que creieu que és la vostra xarxa. Els equips de “construirem el nostre model perfecte” continuen modelant dos anys més tard mentre els equips d’aquestes eines van llençar models vàlids molts mesos enrere.

No sou Google (o potser sí?). En molts casos, no esteu construint un cloud hiperscala. Feu servir el que existeix, amplieu-ho quan tingueu límits reals (no imaginaris) i llenceu quelcom que funcioni.

Òbviament, si ja anticipeu que teniu un cas d’ús de xarxa molt especial, podeu considerar quina eina el suportarà millor, però no reinventeu completament la roda des del primer dia.

L’única decisió que importa: podeu estendre sense reescriure? Si afegir un camp personalitzat per rastrejar el “centre de costos” requereix reconstruir tot el vostre esquema, fugiu. Si podeu afegir-lo com un atribut personalitzat en 20 minuts, heu trobat l’eina correcta.

Voleu un 80% d’estandardització amb un 20% de flexibilitat (per gestionar la vostra realitat específica). Qualsevol cosa que pretengui ser “infinitament flexible” trigarà un temps infinit a configurar-se.

Polimorfisme: Un Model, Moltes Variants

No totes les interfícies es creen iguals. Un port òptic físic i una interfície de túnel comparteixen algunes propietats, però són bèsties diferents. Podríeu crear models completament separats per a cadascun, però això es complica ràpidament i limita la usabilitat.

Millor enfocament: definiu un model base compartit que cobreixi el que tenen en comú, i després creeu variants especialitzades per als detalls que difereixen.

# Totes les interfícies comparteixen aquests conceptes bàsics
interfaces:
  - name: "eth0"
    type: "physical"
    status: "up"
    mtu: 1500
    ipv4_address: "192.0.2.1/24"

# Però un port òptic físic té coses addicionals
  - name: "eth0"
    type: "physical_optical"
    status: "up"
    mtu: 1500
    ipv4_address: "192.0.2.1/24"
    optics_module: "100GBASE-LR4"
    tx_power_dbm: -2.5
    rx_power_dbm: -8.3
    laser_temperature: 48.2

# I un túnel sembla totalment diferent per sota
  - name: "tun-vpn-dallas"
    type: "tunnel_gre"
    status: "up"
    mtu: 1476
    ipv4_address: "10.0.0.1/30"
    tunnel_source: "203.0.113.1"
    tunnel_destination: "198.51.100.5"
    tunnel_encap: "GRE"
    tunnel_key: 100

D’aquesta manera, els vostres scripts poden consultar “totes les interfícies d’aquest dispositiu” sense saber si estan parlant amb òptiques o túnels. Però quan necessiteu detalls específics d’òptiques (obtenir lectures de potència TX), podeu accedir a aquests camps especialitzats. Afegiu un nou tipus d’interfície en el futur? Cap problema: simplement afegiu una altra variant.

Els Models Canvien: Planifiqueu-ho

Les xarxes viuen durant dècades. El vostre model no es mantindrà estàtic. Afegireu nous camps, canviareu com les coses es relacionen entre si i deprecareu coses que ja no funcionen. Però no podeu simplement canviar un interruptor i trencar tot el que s’executa sobre el vostre esquema antic.

El repte és que quan el vostre model canvia, moltes coses aigüest avall es poden trencar: els validadors necessiten noves regles, les APIs canvien el que retornen, les consultes a la base de dades assumeixen que certes columnes existeixen, les vostres plantilles necessiten camins de camp diferents, els informes estan escrits contra l’estructura antiga. Tot això ha d’adaptar-se, o almenys no trencar-se catastròficament. Aquí teniu com gestionar els canvis sense fer-ho explotar tot:

• Marqueu les coses com a obsoletes abans d’eliminar-les. Si un camp desapareixerà, aviseu a tothom 2-3 versions per endavant. Doneu-los un període de gràcia per migrar.

• Doneu suport a àlies de camps durant la transició. El codi antic que demana device_name? Redirigiu-lo a hostname per sota. La vostra API continua funcionant, la gent té temps d’actualitzar la seva automatització.

• Creeu ajudants de migració. Quan reestructureu dades (com moure interfícies d’una llista plana a niades sota els dispositius), proporcioneu scripts que facin la feina.

• Proveu amb tot el que depèn de les vostres dades. Abans de llençar canvis d’esquema:

  • L’API continua retornant dades de la manera antiga? (via àlies)
  • Les vostres plantilles continuen renderitzant?
  • Les consultes SQL continuen funcionant?
  • Les integracions amb sistemes externs continuen analitzant el que reben?

• Espereu versions mixtes en producció durant un temps. Les grans organitzacions sovint tenen dispositius en tres versions d’esquema diferents simultàniament:

  150 dispositius en l'esquema 1.9 (antic)
  300 dispositius en l'esquema 2.0 (actual)
  50 dispositius en l'esquema 2.1 (proves beta)

El vostre sistema ha de gestionar els tres sense trencar-se. Aquesta complexitat val la pena: les xarxes importen massa per trencar-se amb canvis d’esquema descuidats.

4.2.1.5. Plantilles de Configuració#

Les plantilles converteixen la intenció abstracta (“vull una VLAN”) en ordres reals de Command Line Interface (CLI). Aquí hi ha la regla clau: les plantilles contenen lògica, no dades. La plantilla diu “utilitza l’ID de VLAN del model de dades, posa’l aquí.” L’ID de VLAN real prové de les dades, no de la plantilla. Això fa que les dades siguin portables i provables. Jinja2 és popular perquè és llegible per humans, s’integra amb Python i Ansible, i és pràctic per a xarxes reals. No obstant, no és l’única opció: hi ha moltes alternatives vàlides.

Per exemple, donat una estructura de dades per a interfícies:

interfaces:
  - name: Ethernet1
    description: Uplink to core
    enabled: true
  - name: Ethernet2
    description: Server port
    enabled: false

I aquesta plantilla Jinja2 de configuració CLI:

# Interfaces
{% for iface in interfaces %}
interface {{ iface.name }}
  description {{ iface.description }}
  {% if iface.enabled %}
  no shutdown
  {% else %}
  shutdown
  {% endif %}
{% endfor %}

Genera la següent sortida CLI:

# Interfaces
interface Ethernet1
  description Uplink to core
  no shutdown
interface Ethernet2
  description Server port
  shutdown

Observeu la clara separació de responsabilitats entre les dades i l’artefacte de configuració.

Una alternativa interessant a Jinja és el llenguatge de configuració declaratiu CUE, que unifica múltiples funcionalitats de dades:

• Dades brutes, com YAML
• Validació de dades/esquema, com JSON Schema (més a la secció d’aplicació)
• Generació dinàmica de dades, com Jinja

CUE tracta la configuració com a dades tipades i composables amb invariants aplicats, en lloc de text poc estructurat (com Jinja).

4.2.2. Orientat al Disseny#

Quan teniu 50 dispositius i 30 VLANs, podeu gestionar-los individualment: creeu cada VLAN, configureu cada interfície, assigneu cada IP a mà. És tediós però manejable.

Quan teniu 5.000 dispositius i centenars de serveis, la gestió manual és impossible. Afegir una nova oficina de sucursal significaria especificar manualment més de 100 elements de configuració per ubicació. El bloc funcional Orientat al Disseny resol això: els operadors descriuen el que volen a alt nivell (“afegir una sucursal”) i el sistema ho expandeix en especificacions tècniques completes.

4.2.2.1. De la Intenció de Negoci a les Dades Tècniques#

Exemple - “Afegir oficina de sucursal a Dallas”:

Intenció de Negoci (Alt Nivell):

{
  "type": "branch_office",
  "location": "dallas-tx",
  "site_code": "DAL-01",
  "circuit_count": 2,
  "employee_count": 50,
  "applications": ["erp", "voip", "video"]
}

Processament del Disseny

flowchart LR
    A[Intenció de Negoci]
    B[Aplicar Plantilla]
    C[Assignar Recursos]
    D[Resoldre Lògica]
    E[Renderitzar Detalls]
    F[Objectes per a l'Executor]

    A --> B --> C --> D --> E --> F

    style A fill:#fff3cd,stroke:#ffc107
    style B fill:#ffe6cc,stroke:#fd7e14
    style C fill:#d4edda,stroke:#28a745
    style D fill:#cce5ff,stroke:#4a90e2
    style E fill:#e2d9f3,stroke:#6f42c1
    style F fill:#d1ecf1,stroke:#17a2b8

Això transforma la intenció d’alt nivell en detalls tècnics exhaustius.

4.2.2.2. Patrons de Disseny i Blocs de Construcció Reutilitzables#

Els sistemes de disseny efectius depenen de biblioteques de patrons.

Biblioteca de Patrons de Disseny de Xarxa

Cada patró codifica decisions arquitectòniques provades. Desviar-se’n requereix aprovació explícita, però desplegar-los s’hauria de veure com una operació normal.

4.2.2.3. Fer els Dissenys Reproduïbles#

Aquí hi ha un problema: dissenyeu un lloc el dilluns i assigneu la VLAN 100. Dissenyeu un lloc diferent el dimarts i assigneu la VLAN 101. Però si torneu a executar el disseny del dilluns sis mesos més tard per a la validació, el sistema podria assignar la VLAN 102 perquè la VLAN 100 ja està ocupada.

Això no és reproduïble. La solució: cada vegada que feu una sol·licitud de disseny, registreu quins recursos va obtenir aquell disseny. Si arriba la mateixa sol·licitud de nou, obteniu la mateixa VLAN. Això requereix rastrejar permanentment els mapejos de sol·licitud-recurs i sempre assignar en el mateix ordre.

• Ordre d’assignació determinista: Sempre itereu pels candidats en el mateix ordre
• Assignació atòmica: La reserva de recursos és atòmica; l’assignació parcial no és possible

Per això molts sistemes de disseny utilitzen emmagatzematge adreçable per contingut (hash del disseny) per garantir la consistència.

4.2.2.4. Distinció Renderitzar vs. Construir#

Els sistemes de disseny separen dues fases:

Donar suport al renderitzat sense construcció permet:

• Validació segura abans del compromís
• Anàlisi hipotètica sense risc
• Revisió i aprovació en equip
• Proves en entorn de prova primer

4.2.2.5. Versionat i Evolució del Disseny#

Els dissenys de xarxa evolucionen amb el temps. Sorgeixen nous patrons. Les eines milloren. Els dissenys del 2020 potser necessiten actualitzar-se per al 2025.

Reptes del versionat de dissenys:

• Versió de disseny 1 (2020): Plantilla d’oficina de sucursal: encaminador únic, 2 VLANs
• Versió de disseny 2 (2023): Plantilla d’oficina de sucursal: encaminador dual (redundància), 4 VLANs, seguretat millorada

Què passa amb les sucursals desplegades amb la Versió 1?

• Continuar executant la versió antiga? (deute de seguretat)
• Forçar l’actualització de totes les sucursals? (risc de canvi)
• Migració gradual? (complexitat operativa)

Solucions:

Disseny com a codi amb versionat

designs/
  ├─ branch_office_v1.yaml (deprecated 2023-01-01)
  ├─ branch_office_v2.yaml (current)
  └─ branch_office_v2_beta.yaml (testing)

Sites:
  - site: DAL-01
    design: branch_office_v2 (references specific version)
    design_parameters: {...}

Això permet:

• Saber exactament quina versió de disseny va generar cada lloc
• Migració gradual (actualitzar lloc per lloc)
• Revertir a v1 si v2 té problemes
• Provar v3 en proves abans de llençar-la

Accommodació de casos especials

La majoria dels llocs utilitzen la plantilla design_v2, però el lloc DAL-01 té requisits especials:

• Espai de bastidor addicional (peculiaritat de l’edifici antic)
• Adreçament IP inusual (assignació heretada)
• Regla de tallafoc personalitzada (requisit de negoci històric)

Solució:

• Desplegar design_v2 com a base
• Aplicar substitucions específiques del lloc
• Rastrejar les substitucions per separat (documentar el cas especial)

Això evita:

• Dissenyar excepcions a la plantilla (contamina el disseny)
• Configuració manual de les excepcions (deriva amb el temps)
• Pèrdua del context sobre per què existeixen les excepcions

4.2.3. Consum#

Les dades tancades en una base de dades no serveixen de res. La capa de consum és com les persones i els sistemes obtenen realment accés a les dades. Feu-ho fàcil, i obtindreu acceptació. Feu-ho difícil, i la gent treballarà al marge del sistema.

4.2.3.1. Disseny i Seguretat de l’API#

Els diferents estils d’API serveixen a diferents patrons de consum. Aquí hi ha alguns dels més populars avui dia:

Comparació d’Estils d’API

Les estratègies de consum efectives sovint combinen múltiples interfícies:

• REST per a operacions simples i amigables per als humans
• GraphQL per a consultes complexes de múltiples dominis amb filtratge d’autorització
• gRPC/streaming per a automatització d’alt volum
• Webhooks per a sistemes aigüest avall reactius

Nota sobre MCP (Model Context Protocol) A més dels estils d’API tradicionals, models d’interacció emergents com el Model Context Protocol (MCP) permeten als agents d’IA interactuar amb sistemes d’una manera estructurada i orientada a eines. A diferència de REST o gRPC, que defineixen semàntiques de transport i sol·licitud, MCP se centra en la descoberta segura de capacitats, la recuperació de dades contextuals i l’execució controlada d’accions per a fluxos de treball controlats per agents. Aquest patró és particularment rellevant en operacions assistides per IA i casos d’ús d’observabilitat, on els sistemes de raonament automatitzat necessiten accés estructurat a telemetria, configuració i eines de remediació. Tot i que continua evolucionant, MCP representa un canvi des de les APIs centrades en recursos cap a models d’interacció orientats a agents.

Una regla crítica: feu l’autenticació i l’autorització a la capa de l’API, no aigüest avall. Això evita forats de seguretat i fa que l’auditoria funcioni correctament.

Més sobre les implicacions de seguretat al Capítol 12.

4.2.3.2. Operacions de l’API: Versionat, Rendiment i Memòria Cau#

Un cop les APIs estan dissenyades i protegides, les preocupacions operatives sobre l’evolució i el rendiment esdevenen crítiques.

Versionat i Evolució de l’API

Les xarxes són infraestructura de llarga durada; els sistemes d’automatització han d’evolucionar sense trencar els fluxos de treball operatius.

• Versionat per URL: /api/v1/devices i /api/v2/devices mantenen implementacions separades

  • Pro: Explícit, depurable, els clients trien quan actualitzar
  • Contra: Manteniu múltiples implementacions (això és realment bo: us obliga a planificar les migracions)

• Versionat per capçalera: Mateix endpoint, versió a Accept: application/vnd.company+json; version=2

  • Pro: Endpoint únic, URLs més netes
  • Contra: Invisible als registres, més difícil de depurar, els clients s’equivoquen constantment

En qualsevol cas, anuncieu els canvis disruptius amb 6-12 mesos d’antelació mitjançant capçaleres de deprecació:

Deprecation: true
Sunset: Mon, 01 Jan 2026 00:00:00 GMT
Link: <https://docs/migration>; rel="deprecation"

Recomano utilitzar el versionat per URL: /api/v1/devices i /api/v2/devices. Sí, el versionat per capçalera sembla més net a la documentació. Però quan quelcom falla a les 3 de la matinada i esteu cercant als registres, voleu veure /v1/ vs /v2/ immediatament, no buscar a les capçaleres de sol·licitud per esbrinar quina versió de l’API va causar el problema. El vostre jo futur de guàrdia us ho agrairà.

Rendiment i Memòria Cau

Consumir dades d’una en una pot funcionar bé per a alguns casos d’ús, però quan l’escala creix, finalment s’assoleixen els límits de rendiment.

Les operacions massives permeten actualitzar milers d’objectes en una sola crida a l’API. Això és essencial per a l’escala però introdueix compromisos:

• API d’objecte únic: POST /api/devices/device Beneficis: Valida cada canvi, missatges d’error clars per objecte Cost: 10.000 actualitzacions de dispositiu = 10.000 sol·licituds API + viatges d’anada i tornada = minuts

• API massiva: POST /api/devices/bulk-update Beneficis: Un sol viatge d’anada i tornada per a 10.000 actualitzacions, es pot paral·lelitzar el processament al backend Cost: Dreceres de validació (ometre comprovacions costoses), més difícil d’informar errors per objecte

Altres alternatives per millorar el consum de dades inclouen limitar l’abast mitjançant:

• Paginació i filtratge per evitar que els clients carreguin accidentalment milions d’objectes a la memòria o esgotin el temps: GET /api/devices?location=datacenter-1&status=active&limit=100&offset=0

  La paginació basada en cursor ofereix avantatges sobre la paginació basada en offset quan es tracta de grans conjunts de dades, ja que és més eficient per a sistemes distribuïts i es manté consistent fins i tot quan les dades es modifiquen entre sol·licituds.

• Estratègies de memòria cau milloren dramàticament el rendiment:

  • Memòria cau del servidor: Memòria cau Redis de “tots els dispositius a la ubicació X” invalidada quan qualsevol dispositiu d’aquella ubicació canvia
  • Memòria cau del client: Les ETags HTTP permeten als clients validar les dades en memòria cau sense tornar a descarregar-les
  • Omissió de la capa de validació: Per a consultes de només lectura, ometeu les comprovacions de validació

• Limitació de velocitat protegeix els backends de la sobrecàrrega. Per exemple:

  • 10 sol·licituds/segon per usuari
  • 1.000 sol·licituds/minut per clau API
  • Senyals de contrapressió (HTTP 429) indiquen als clients que redueixin el ritme

4.2.3.3. Modelatge de Dades Sensible al Context#

Les persones diferents necessiten coses diferents. Els enginyers de xarxa volen cercar i trobar dades, editar camps específics amb retroalimentació de validació i veure relacions. Els fluxos d’automatització necessiten APIs, transaccions i webhooks. Els equips d’operacions volen vistes centrades en tasques i rastres d’auditoria. El negoci vol informes sense detalls tècnics. Els sistemes externs necessiten sincronitzar dades en ambdues direccions.

Noteu que la interfície d’usuari del bloc de consum pertany a la capa de Presentació. En cobrirem més al Capítol 8.

Les dades han d’adaptar-se a cada context de consumidor. Per exemple, no tots els detalls del dispositiu han d’estar exposats a cada persona. La personalització sensible al context fa que el consum de dades sigui més eficient i efectiu.

Un enginyer de xarxa necessita interfícies i detalls d’encaminament. Les finances volen informació de cost i garantia. La seguretat vol la zona de compliment. En lloc de retornar tots els 500 camps a tothom, doneu a cada consumidor només el que necessita. Podeu fer-ho amb paràmetres de consulta a l’API (?view=network_engineer) o GraphQL deixant-los sol·licitar camps específics.

El Repte: Un Model de Dades No Pot Servir a Tots els Consumidors

Considereu un objecte de dispositiu únic a la Font de Veritat que conté centenars d’atributs:

• Detalls de maquinari (model, número de sèrie, versió de firmware)
• Configuració de xarxa (adreces IP, VLANs, protocols d’encaminament)
• Metadades operatives (ubicació, centre de costos, venciment de la garantia)
• Relacions de servei (quins clients utilitzen aquest dispositiu)
• Context de seguretat (zona de compliment, polítiques d’accés)

Els consumidors diferents necessiten vistes radicalment diferents d’aquestes dades:

Exemple: Dispositiu “router-core-01” en Contexts Diferents

Patrons d’Implementació

1. Transformacions basades en vistes: Les consultes a l’API especifiquen el context desitjat, el servidor transforma el model de dades en conseqüència

   GET /api/devices/router-core-01?view=network-engineer
   → Returns: {interfaces: [...], bgp_peers: [...], vlans: [...]}
   
   GET /api/devices/router-core-01?view=finance
   → Returns: {cost_center: "...", warranty_expiry: "...", purchase_cost: ...}

2. Selecció de camps GraphQL: Els consumidors sol·liciten explícitament només els camps necessaris

   query NetworkEngineerView {
     device(name: "router-core-01") {
       interfaces { name, ip_address, status }
       bgp_neighbors { peer_ip, state }
     }
   }
   
   query FinanceView {
     device(name: "router-core-01") {
       cost_center
       purchase_date
       warranty_expiration
     }
   }

3. Capes de projecció: El backend calcula vistes derivades optimitzades per a patrons d’accés específics

   • Gràfic de topologia de xarxa: Dispositius com a nodes, connexions com a arestes (per a la visualització de topologia)
   • Arbre de dependència de serveis: Vista jeràrquica de serveis -> dispositius -> components (per a l’anàlisi d’impacte)
   • Matriu de compliment: Dispositius agrupats per zona amb estat d’adhesió a polítiques (per a auditoria)

4. Llenguatges específics de domini (DSLs): Llenguatges de consulta especialitzats adaptats als models mentals dels usuaris

   • Enginyer de xarxa: “Mostra’m tots els dispositius amb la sessió BGP caiguda al datacenter-1”
   • Finances: “Calcula l’amortització mensual dels dispositius comprats al tercer trimestre del 2025”
   • Seguretat: “Llista els dispositius a la zona PCI amb CVEs crítics”

Beneficis del Modelatge Sensible al Context

No obstant, cal considerar els reptes i altres consideracions:

• Sobrecàrrega de manteniment de vistes: Cada nova vista requereix definició, proves i documentació
• Consistència entre vistes: Les mateixes dades exposades a través de múltiples vistes han de mantenir-se consistents
• Complexitat de rendiment: El càlcul de vistes dinàmiques afegeix latència; requereix estratègies de memòria cau
• Descoberta: Els consumidors han de saber quines vistes existeixen i quan utilitzar-les

El modelatge sensible al context és el pont entre l’optimització de l’estructura de dades (com emmagatzemar les dades de manera eficient) i l’optimització del consum (com els consumidors accedeixen a les dades de manera natural). Reconeix que la Font de Veritat serveix a molts amos, cadascun amb la seva pròpia perspectiva sobre el que significa “veritat” per a la seva feina.

4.2.3.4. Interfícies Assistides per IA#

Aplicar la IA a la capa de Consum redueix la càrrega cognitiva de treballar amb models de dades grans i complexos. Tres patrons són cada vegada més comuns en les implementacions modernes de Font de Veritat:

• Suggeriments contextuals: A mesura que escriviu un nom de dispositiu, el sistema suggereix dispositius coincidents que heu editat anteriorment en aquesta ubicació. Quan creeu un servei, suggereix paràmetres tècnics raonables basats en el tipus de servei i els patrons històrics. Això redueix els errors d’entrada sense afegir fricció de validació.

• Advertències d’anomalies en l’escriptura: Abans d’una actualització massiva, la interfície avisa si l’operació és inusual en comparació amb els patrons històrics. Una reassignació massiva de VLANs que normalment afecta 10 dispositius però que està a punt d’afectar 400 activa un pas de confirmació. El sistema no bloqueja l’operació; planteja una pregunta.

• Consultes en llenguatge natural: Les interfícies recolzades per LLM permeten als operadors consultar la Font de Veritat en llenguatge planer: “Quins dispositius de l’edifici-b no tenen etiqueta de monitorització?” La interfície tradueix això en una consulta estructurada a l’API i retorna els resultats en forma llegible per humans. Això és valuós per a la investigació ad hoc però no és un substitut de les interfícies d’automatització estructurades.

Els tres patrons depenen del mateix fonament: accés a dades d’operació històriques i un esquema ben modelat sobre el qual la IA pot raaonar. La secció 4.2.4.4 cobreix com s’apliquen tècniques similars a la validació de la qualitat de dades en la ruta d’escriptura.

4.2.4. Aplicació#

Les dades incorrectes destrueixen l’automatització. La intenció errònia condueix a xarxes trenques, bretxes de seguretat i equips d’operacions confosos. L’Aplicació és el vostre guardià: atura les dades clarament incorrectes perquè no entrin i explica clarament per què.

4.2.4.1. Validació d’Esquema i Restriccions#

Hi ha moltes maneres d’implementar la validació d’esquema, des de llenguatges de programació genèrics fins a solucions més específiques:

• JSON Schema: Document JSON que descriu les restriccions de dades per comparar amb les dades reals.
• CUE: Proporciona generació de dades tipades i validades amb restriccions i validació.
• YANG: Llenguatge de modelatge específic per a xarxes amb aplicació de restriccions integrada.

Per exemple, amb JSON Schema podeu validar les vostres dades JSON (o YAML):

• Dades JSON

{
  "hostname": "sw-core-01",
  "mgmt_ip": "192.0.2.10",
  "role": "core",
  "interfaces": [
    {
      "name": "Ethernet1",
      "enabled": true,
      "vlan": 100
    },
    {
      "name": "Ethernet2",
      "enabled": false,
      "vlan": 200
    }
  ]
}

• JSON Schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["hostname", "mgmt_ip", "role", "interfaces"],
  "additionalProperties": false,
  "properties": {
    "hostname": {
      "type": "string",
      "pattern": "^[a-z0-9-]+$"
    },
    "mgmt_ip": {
      "type": "string",
      "format": "ipv4"
    },
    "role": {
      "type": "string",
      "enum": ["core", "distribution", "access"]
    },
    "interfaces": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["name", "enabled", "vlan"],
        "additionalProperties": false,
        "properties": {
          "name": {
            "type": "string",
            "pattern": "^Ethernet[0-9]+$"
          },
          "enabled": {
            "type": "boolean"
          },
          "vlan": {
            "type": "integer",
            "minimum": 1,
            "maximum": 4094
          }
        }
      }
    }
  }
}

4.2.4.2. Aplicació Estricta vs. Suau#

Rebutgeu les dades incorrectes. Parada total. He vist massa sistemes de “validació suau” convertir-se en abocadors perquè “només aquesta vegada” es converteix en el procediment operatiu estàndard. Si és prou important per validar, és prou important per aplicar.

Però, com sempre, hi ha excepcions:

1. Directrius de política (no regles): “Esteu fent servir una subxarxa /22 quan normalment fem servir /24” és un advertiment, no un error. Aviseu l’usuari, registreu-ho, però deixeu-los continuar si ho superen.

2. Comprovacions costoses entre objectes: Si la validació triga més d’uns quants segons, accepteu el canvi i valideu de manera asíncrona. Però encara apliqueu el resultat: marqueu la infracció, notifiqueu l’usuari i exigiu correccions.

3. Descoberta de xarxa brownfield: Quan importeu configuracions existents, trobareu infraccions a tot arreu. Marqueu-les, però no bloquegeu la importació. El punt és descobrir el que hi ha realment, fins i tot si viola el vostre model ideal.

Tot the rest? Rebutgeu-ho. La vostra automatització depèn de dades fiables. Les dades incorrectes signifiquen interrupcions.

4.2.4.3. Compromisos de Cost i Rendiment de la Validació#

La validació no és gratuïta. Una jerarquia de costos de validació afecta les decisions de disseny:

graph LR
    SPEED["⚡ VELOCITAT"]
    V1["< 1ms<br/>Validació de tipus"]
    V2["~10ms<br/>Unicitat"]
    V3["5-50ms<br/>Regex"]
    V4["50-200ms<br/>Integritat<br/>referencial"]
    V5["100-500ms<br/>Motor de regles"]
    V6["1-5 seg<br/>API externa"]
    V7["Hores+<br/>Consistència"]
    THOROUGH["EXHAUSTIVITAT 🎯"]
    
    SPEED --> V1
    V1 --> V2
    V2 --> V3
    V3 --> V4
    V4 --> V5
    V5 --> V6
    V6 --> V7
    V7 --> THOROUGH
    
    style SPEED fill:none,stroke:none,font-size:14px,font-weight:bold
    style THOROUGH fill:none,stroke:none,font-size:14px,font-weight:bold
    style V1 fill:#d4edda,stroke:#28a745,stroke-width:2px
    style V2 fill:#d7ecf1,stroke:#17a2b8,stroke-width:2px
    style V3 fill:#dfe8f1,stroke:#17a2b8,stroke-width:2px
    style V4 fill:#fff3cd,stroke:#ffc107,stroke-width:2px
    style V5 fill:#ffe8cd,stroke:#ffc107,stroke-width:2px
    style V6 fill:#f8d7da,stroke:#dc3545,stroke-width:2px
    style V7 fill:#f5c2c7,stroke:#dc3545,stroke-width:2px

Els sistemes pràctics trien un objectiu de rendiment i validen només fins a aquest nivell per als camins d’escriptura síncrons:

• Camí ràpid (< 10ms): Tipus, regex, comprovacions d’índex local
• Camí estàndard (< 100ms): Unicitat, integritat referencial
• Camí lent (< 5seg): Motor de regles, lògica de negoci complexa
• Camí asíncron (hores més tard): Validació en segon pla, comprovacions de consistència

4.2.4.4. Qualitat de Dades Millorada per IA#

L’aprenentatge automàtic millora la qualitat de les dades sense reduir el rendiment. Aquestes tècniques de validació basades en IA complementen les funcionalitats d’IA orientades a l’usuari de la secció 4.2.3.4 per crear una capa de dades intel·ligent integral.

Detecció d’Anomalies

Confronteu els patrons històrics amb les noves sol·licituds per inferir inconsistències:

• Patró històric: En aprovisionar una nova sucursal, els operadors creen una VLAN en el rang 1000-1999, l’assignen a site_a i configuren l’encaminament estàtic
• Nova sol·licitud: Crear la VLAN 2500, assignar a site_c, habilitar OSPF
• Alerta: “Aquest patró de creació de VLAN és inusual. N’esteu segurs? (98% de confiança que hauria d’estar en el rang 1000-1999)”
• Tècnica d’ML: Clustering i detecció de valors atípics sobre vectors de canvi històrics

Suggeriments de Correcció Automàtica

Suggeriu correccions automàticament cap a la solució vàlida més probable:

• Entrada: Adreça IP “192.0.2.1/33” (longitud de prefix no vàlida > 32)
• Sistema: “Volíeu dir /24? (inferit de subxarxes similars en aquest lloc)”
• Tècnica d’ML: Coincidència de patrons en les assignacions de subxarxes dins de la mateixa ubicació

Embeddings Vectorials per a la Consistència

Feu servir embeddings per detectar desviacions significatives de les configuracions peers:

• Emmagatzemar embeddings de cada configuració de dispositiu
• Nova configuració de dispositiu presentada
• Comparar l’embedding amb dispositius similars del mateix rol
• Si és significativament diferent: “Aquest dispositiu difereix dels seus peers en rol: Els dispositius similars tenen servidors NTP X,Y,Z i syslog al servidor Z”
• Tècnica d’ML: Similitud de cosinus sobre embeddings de configuració de dispositiu

Consideracions d’Implementació d’ML

Fixeu-vos en l’ús de puntuacions de “confiança”. Aquest és un concepte important quan s’utilitza la IA perquè dóna més context sobre fins a quin punt podeu confiar en la recomanació. Sempre emparelleu els suggeriments de la IA amb explicacions del patró subjacent que els va desencadenar.

4.2.4.5. Cost de l’Aplicació: Implicacions per al Disseny del Sistema#

La validació d’alta fidelitat afecta l’arquitectura:

4.2.5. Versionat#

La intenció de la vostra xarxa canvia constantment. S’afegeixen dispositius, s’actualitzen configuracions, es mouen serveis i s’ajusten polítiques. El Versionat us permet entendre el que era veritat en cada moment, com va arribar a ser així i com tornar a quelcom segur si cal.

4.2.5.1. Control de Versions i Rastres d’Auditoria Immutables#

Tots els canvis s’han de registrar de manera immutable, creant un historial complet. Això pot prendre formes diferents, per exemple:

• Registres de canvis

  Change Event:
    timestamp: 2025-02-07T14:32:15Z
    user: engineer@company.com
    action: UPDATE
    resource_type: vlan
    resource_id: vlan-100
    changes:
      description: "Customer VLAN" → "Production Customer VLAN"
      assigned_sites: [site-a, site-b] → [site-a, site-b, site-c]
    reason: "Adding new office location"
    request_id: req-12345

• Commits de Git

  commit 0c0ad51152f9b3be307802badb15eca8d121c576 (HEAD -> new-site, origin/new-site)
  Author: Engineer <engineer@company.com>
  Date:   Sat Feb 7 09:43:59 2026 +0100
  
      Adding a new site: BCN01
  
  diff --git a/sites.yaml b/site.yaml
  index ae18c87..dabf6c5 100644
  --- a/sites.yaml
  +++ b/sites.yaml
  @@ -219,51 +219,1279 @@ sites:
  
  + BCN01:

Aquest registre immutable respon preguntes crítiques:

• Quina era la intenció de la xarxa en la data X? (viatge en el temps)
• Qui va fer aquest canvi i per què? (responsabilitat)
• Quina configuració de desplegament correspon a aquesta intenció? (traçabilitat)
• Què va canviar entre les versions Y i Z? (diff/comparació)

La immutabilitat és la clau: ningú, ni tan sols els administradors, pot editar els registres històrics. Això evita les encobertes i assegura que els rastres d’auditoria es mantinguin fiables.

El versionat també està relacionat amb les polítiques de retenció, i cal equilibrar el compliment normatiu amb la pràctica, per exemple:

• Conservar tots els canvis durant 7 anys (requisit reglamentari)
• Eliminar les versions intermèdies al cap de 2 anys (p. ex., si la VLAN 100 va canviar 10 vegades, conservar només l’inici i el final)
• Arxivar a l’emmagatzematge fred al cap d'1 any (per al cost)

Relacionat amb els esdeveniments de canvi de dades, els patrons d’event sourcing (emmagatzemar tots els canvis com a esdeveniments per a la recreació completa de dades) són potents però menys comuns en la gestió d’infraestructura de xarxa. Això es deu al fet que la intenció de xarxa és altament amb estat. Les dades actuals són més importants que la seqüència de canvis que hi ha conduït. A més, els canvis de xarxa sovint impliquen estat extern (configuracions de dispositius, assignacions d’IP en sistemes externs) que no es pot recrear completament a partir dels esdeveniments. No obstant, l’event sourcing pot ser valuós per a casos d’ús específics com l’auditoria de compliment o l’anàlisi forense.

4.2.5.2. Patrons de Control de Versions: Branques, Fusions i Rollback#

Els sistemes moderns de Font de Veritat prenen molt prestats dels patrons de control de versions de programari. Aquestes capacitats permeten el treball en paral·lel segur, els canvis experimentals i la recuperació ràpida dels errors.

Branques per a Fluxos de Treball en Paral·lel

Qualsevol organització amb més d’un enginyer o agent d’IA treballant en paral·lel necessita una manera de treballar sense bloquejar els altres. Quan un actor (humà o IA) està treballant en l’aprovisionament de noves dades, no pot bloquejar tota la Font de Veritat.

Aprenent del desenvolupament de programari, els mecanismes de branques permeten fluxos de treball de dades en paral·lel. Cada equip pot treballar en pistes de dades paral·leles i finalment fusionar-les amb la pista “principal” quan estiguin a punt. Aquesta fusió és una oportunitat per resoldre qualsevol inconsistència que s’hagi introduït.

Flux de treball d’exemple:

main branch (production intent)
  │
  ├─── feature/add-dallas-office (Engineer A)
  │     • Creates site DAL-01
  │     • Allocates VLANs 2100-2110
  │     • Defines 5 new devices
  │
  └─── feature/upgrade-ntp-servers (Engineer B)
        • Changes NTP config for all devices
        • Updates 3,000 device records

Quan ambdues branques es fusionen de nou a main:

• Sense conflicte: Objectes diferents modificats -> fusió automàtica
• Conflicte detectat: Tots dos van modificar el NTP de device-core-01 -> resolució manual necessària
• Validació: El resultat fusionat ha de superar totes les regles d’aplicació abans del commit

Implementar aquest mecanisme de branques en bases de dades tradicionals és un problema important en si mateix. Per exemple, NetBox i Nautobot, que es basen en bases de dades relacionals, han adoptat enfocaments diferents: NetBox utilitza còpies de bases de dades per a les branques, mentre que Nautobot aprofita Dolt (una base de dades SQL amb Versioning similar a Git integrat). Infrahub, dissenyat des de zero tenint en compte les branques semblants a Git, ho va implementar utilitzant una base de dades de grafs amb capacitats de branques natives integrades.

Rollback i Recuperació

Els errors passen. El Rollback de dades ha de ser ràpid i fiable. Tingueu en compte que aquest és el Rollback de les dades d’intenció en si, no directament de la configuració de la xarxa.

Fer un rollback de dades requereix que el component d’Execució apliqui els canvis de configuració (podeu fer un Rollback de les configuracions de la infraestructura de xarxa si és possible, però finalment tant la xarxa com la intenció han d’estar sincronitzades per mantenir un estat estable).

Per donar suport al Rollback de dades, hi ha dos enfocaments principals:

El Rollback pot activar-se de dues maneres:

• Manual: L’operador reconeix el problema, inicia el Rollback
• Automatitzat:
  • L’observabilitat detecta taxes d’error augmentades després del desplegament
  • La validació posterior al desplegament falla (“500 dispositius no accessibles després del canvi”)
  • El llindar d’impacte al negoci superat (“infraccions de l’SLA del client > 10”)

La combinació de branques (treball en paral·lel sense conflictes) i Rollback (recuperació ràpida d’errors) proporciona la flexibilitat temporal que demana l’automatització de xarxes a gran escala.

4.2.5.3. Transaccions Atòmiques i Garanties de Consistència#

Les garanties transaccionals asseguren la consistència de les dades quan múltiples canvis relacionats han de tenir èxit o fallar junts:

• Atomicitat: O tot té èxit o tot reverteix
• Consistència: Les restriccions de dades es mantenen abans i després
• Aïllament: Les transaccions concurrents no interfereixen
• Durabilitat: Un cop confirmat, persisteix fins i tot si el sistema falla

Implementar-ho requereix un disseny acurat:

• Transaccions de base de dades (si totes les dades estan en una sola BD)
• Transaccions distribuïdes (si les dades s’estenen per diversos sistemes)
• Patró Saga (si no hi ha suport de transaccions distribuïdes natiu)

Al Capítol 11 cobrirem com aquests requisits impacten els sistemes fiables.

4.2.5.4. Fluxos de Treball d’Aprovació de Canvis#

Un cop es proposen els canvis de dades, potser requeriran fluxos de treball d’aprovació humana abans que es facin actius. Les dades solen passar per diverses etapes abans de considerar-se definitives, de manera similar als pipelines d’integració contínua.

graph LR
    A["📝 L'operador proposa un canvi<br/>Afegir 50 nous dispositius de sucursal"] --> C["📦 STAGING<br/>Sense efecte a la xarxa encara<br/>Previsualitzar, provar, dry-run"]
    C --> D["✓ Comprovacions automatitzades<br/>Esquema i restriccions?"]
    C --> E["✓ Simulació<br/>Impacte en encaminament/MPLS?"]
    C --> F["✓ Compliment<br/>Polítiques de seguretat?"]
    D --> G{Totes les comprovacions<br/>passen?}
    E --> G
    F --> G
    G -->|Passa| H["👥 Revisió humana<br/>Control de canvis"]
    G -->|Falla| I["❌ Rebutjat<br/>Notificar el proposant"]
    H --> J{Aprovat?}
    J -->|Sí| K["✅ APROVAT<br/>Preparat per al desplegament"]
    J -->|No| I

Un flux de treball de canvi de dades d’exemple podria semblar així:

1. L’operador proposa el canvi: “Afegir 50 nous dispositius de sucursal”

2. El canvi entra a STAGING: (sense efecte a la xarxa encara, es pot previsualitzar, provar, dry-run)

3. Les comprovacions automatitzades s’executen (Integració Contínua):

   • Validació: Supera l’esquema i les restriccions?
   • Simulació: Trenca l’encaminament, MPLS, etc.?
   • Compliment: Viola les polítiques de seguretat?
   • Informe: Totes passen

4. Revisió humana:

   • El comitè de control de canvis rep la notificació
   • Revisa el diff, la justificació i el radi d’explosió
   • Aprova o sol·licita canvis

5. Decisió d’aprovació, canvi a l’estat APROVAT.

6. Activació del desplegament: Un cop aprovat, activa el component de flux de treball per desplegar finalment els canvis relacionats a la xarxa (un activador habitual per als fluxos de treball d’execució automatitzats)

No obstant, no tots els canvis requereixen aprovació humana, i aquí és on la majoria d’organitzacions s’equivoquen. Els comitès de control de canvis són on l’automatització va a morir. No dic que s’ometi les aprovacions, sinó que s’automatitzin (és a dir, l’aprovació de canvis a escala).

Si el vostre CAB es reuneix setmanalment per aprovar l’afegiment de VLANs, ja heu perdut. Construïu barreres de seguretat que aprovin automàticament el 95% dels canvis i reserveu la revisió humana per a les coses realment arriscades. Per exemple, quan es proveeix un VPC d’AWS, els operadors no esperen que els humans aprovin el canvi de xarxa: estan seguint plantilles provades dins dels límits definits.

La regla és: els canvis que s’ajusten a les barreres de seguretat clarament definides continuen automàticament; només la lògica de les barreres de seguretat requereix revisió i aprovació humana. Definiu una cobertura mínima de barreres de seguretat i una tolerància màxima d’impacte. Després aparteu-vos i deixeu que el sistema funcioni.

En cas contrari, la vostra “automatització” és simplement una manera més elegant d’esperar reunions.

4.2.6. Agregació#

Les dades de la vostra xarxa no viuen en el buit. Els sistemes de RR.HH. rastreen qui treballa on. La gestió d’actius coneix els detalls dels dispositius i les dates de garantia. Els sistemes IPAM posseeixen les assignacions d’adreces IP. Els proveïdors de circuits tenen informació de connectivitat. Els equips de serveis tenen detalls de l’SLA.

No construïu un altre silo de dades. La vostra organització ja en té massa. Si la vostra font de veritat no pot extreure dades de ServiceNow, Infoblox i el vostre CMDB, simplement esteu construint el full de càlcul 2.0 amb una API. Ningú el mantindrà. Passareu la vostra vida suplicant a la gent que “si us plau, actualitzi la Font de Veritat” mentre us ignoren i continuen utilitzant les seves eines existents.

L’Agregació no és opcional: incorporeu dades dels sistemes existents, manteniu-les sincronitzades en ambdues direccions i presenteu una visió unificada. La font de veritat ha de ser una capa de federació, no una base de dades de substitució.

4.2.6.1. No Comenceu des de Zero#

Gairebé amb tota seguretat teniu dades disperses per múltiples sistemes. Cada sistema és autoritzat per al seu domini: els RR.HH. posseeixen l’organització, els sistemes d’actius posseeixen els detalls del maquinari, l’IPAM posseeix les assignacions d’IP. La font de veritat no substitueix aquests sistemes; reuneix les seves dades en una interfície consistent per tal que els clients no hagin de consultar cinc sistemes diferents.

• Context organitzatiu:

  • Sistema de RR.HH.: Departaments, equips, rols, matriu de responsabilitats

• Infraestructura:

  • Gestió d’actius: Detalls de maquinari, números de sèrie, adquisició, garantia
  • Plataforma cloud: VPCs, subxarxes, grups de seguretat, detalls d’instàncies
  • Proveïdor de circuits (extern): Estat de connectivitat, utilització, fallades
  • Sistema IPAM: Assignacions d’IP, àmbits DHCP, entrades DNS
  • Gestió de configuració: Plantilles, línies de base

• Serveis:

  • Catàleg de serveis: Definicions de servei, SLAs, clients
  • Sistema de facturació: Càrrecs, planificació de capacitat

Cada sistema és autoritzat dins del seu domini (entenent domini com un tipus de dades, o un subconjunt del tipus de dades clarament delimitat). La Font de Veritat no els substitueix; orquestra les seves dades en un tot coherent accessible a través d’una interfície consistent, eliminant la necessitat que les aplicacions client correlacionin dades de múltiples fonts.

4.2.6.2. Resolució de Conflictes en Sistemes Federats#

Quan les dades provenen de múltiples fonts, sorgeixen conflictes:

• El sistema IPAM centralitzat diu: 192.0.2.0/24 està assignat al client X
• El CMDB diu: 192.0.2.0/24 està assignat al client Y

Qui té raó? Depèn de la designació d’autoritat a través de la governança.

Per exemple, una estratègia de propietat de domini de recursos podria especificar:

• IPAM centralitzat, font de veritat per a:

  • Assignacions d’adreces IP
  • Mides de subxarxa
  • Àmbits DHCP

• CMDB, font de veritat per a:

  • Mapejos VLAN-a-subxarxa
  • Assignacions d’IP d’interfície
  • Estat operatiu de la interfície de xarxa

Les estratègies de resolució de conflictes inclouen:

• Autoritat de la font (la més habitual): Una decisió de governança designa un sistema com a autoritat (p. ex., el Sistema d’Actius és autoritzat per a les credencials del dispositiu)

• Basat en la marca de temps: Feu servir la marca de temps de la darrera modificació; el canvi més recent guanya. Risc: No té en compte els canvis correctius vs. els errors

• Resolució lògica: Avalueu el context:

  • El valor de la Font de Veritat s’utilitza actualment als dispositius (actual, funcionant provadament)
  • El valor del Sistema d’Actius és el Desired State (hauria de ser)
  • Opció 1: Confiar en l’actual (el que funciona)
  • Opció 2: Confiar en el que hauria de ser (model de governança)
  • Opció 3: Detectar: la configuració del dispositiu no coincideix amb cap dels dos valors, investigar més

• Escalada manual: Quan la confiança és mitjana (els valors difereixen però no es contradiuen), escalar a la revisió humana

4.2.6.3. Arquitectura d’Agregació#

Hi ha dos enfocaments fonamentals per a l’agregació de dades:

4.2.6.4. Mecanismes de Sincronització#

Mantenir les dades consistents entre sistemes és el repte central de l’agregació. L’elecció de l’arquitectura determina quin enfocament de sincronització cal fer servir:

No hi ha cap sistema de sincronització en temps real. Les dades acabaran sent eventualment consistents, però això pot tardar un temps que cal avaluar per a cada cas d’ús.

4.2.6.5. Governança de Dades i Marcs d’Autoritat#

La federació efectiva requereix una governança clara amb definicions explícites per domini de dades. Per exemple:

Per a cada element de dades, les metadades d’autoritat haurien de registrar:

• Sistema font: D’on ve?
• Darrera hora de sincronització: Quan es va verificar?
• Mètode d’actualització: Polling, push o webhook?
• Nivell d’autoritat: Fins a quin punt es pot confiar en aquestes dades?

Amb aquestes metadades, el sistema pot prendre decisions de governança informades sobre el tractament de les dades.

I, quan es treballa amb múltiples entitats, prepareu-vos per als errors. Els sistemes externs inevitablement fallaran. Quan una font federada no estigui disponible (p. ex., l’IPAM cau durant 30 minuts), existeixen diverses estratègies (escolliu el vostre verí):

1. Bloquejar operacions: “No es poden assignar adreces IP sense l’IPAM”
2. Fer servir dades en memòria cau + marcar com a obsoletes: “Fent servir dades IPAM de fa 2 hores; potser siguin inconsistents”
3. Degradació gradual: “Encara es poden aprovisionar dispositius, ometre l’assignació d’IP i posar-la a la cua per quan l’IPAM es recuperi”

4.2.7. Incorporació de Xarxes Existents#

Les sis funcionalitats anteriors descriuen com funciona una Font de Veritat un cop poblada i de confiança. Dues realitats operatives determinen si hi arriba i s’hi manté: com la poblar des d’una xarxa existent, i com mantenir-la precisa al llarg del temps. Cap de les dues s’adiu nítidament a una sola funcionalitat, però ambdues són prerequisits perquè qualsevol de les sis funcioni a la pràctica.

Quan desplegueu una font de veritat en una xarxa existent, us enfronteu a un problema delicat: com poblar-la amb l’estat actual sense simplement incorporar tota la vostra herència com a veritat permanent?

L’enfocament incorrecte: Fer polling dels vostres dispositius i assumir que “el que s’executa = el que hauria de ser”. Carregareu totes les solucions provisionals, hacks i deute tècnic directament a la font de veritat.

L’enfocament correcte: Feu servir l’estat actual de la xarxa com a punt de partida, no com a veritat. Feu-ne un snapshot, carregueu-lo i després redissenyeu-lo deliberadament perquè sigui net. Un cop tingueu el disseny que realment voleu, deixeu de sincronitzar des de la xarxa. La font de veritat es converteix en el cap; la xarxa segueix el seu lideratge.

Aquí teniu com és això a la pràctica:

1. Arrencada: Feu un snapshot de la vostra xarxa actual (dispositius, IPs, VLANs, circuits) i carregueu-lo a la font de veritat com a dades inicials.

2. Redisseny: Durant setmanes i mesos, demaneu a les persones que revisin aquestes dades i decideixin quin hauria de ser l’estat desitjat realment. Probablement voldreu consolidar les VLANs redundants, netejar les coses heretades, estandarditzar la nomenclatura i escriure les plantilles de disseny per als futurs desplegaments.

3. Canviar la direcció: Un cop tingueu el disseny que voleu, deixeu de sincronitzar des de la xarxa de tornada a la font de veritat. Ara la font de veritat és el cap. L’Execució (Capítol 5) empeny els canvis cap a la xarxa.

4. Detectar la deriva: L’Observabilitat (Capítol 6) vigila els dispositius que divergeixen del que diu la font de veritat que haurien de ser. Quan es produeix la deriva, els operadors decideixen: arreglar el dispositiu o arreglar la font de veritat?

Hi ha eines com Slurpit.io o extensions per a NetBox o Nautobot centrades en aquest problema.

Aquest enfocament requereix un esforç inicial però evita la trampa de tractar l’estat desplegat com a veritat permanent. La vostra Font de Veritat evoluciona cap a la intenció de disseny neta, fins i tot si la xarxa triga temps a alinear-se completament. Òbviament, podeu continuar fent-la servir en mode dry-run per verificar que la xarxa no ha derivat.

4.2.8. Cicle de Vida de les Dades i Reconciliació#

Les dades s’envelleixen. Un commutador es dona de baixa sense eliminar-lo de la Font de Veritat. Una adreça IP es reassigna manualment durant un incident. Una VLAN s’afegeix a un port troncal per un contractista que fa feina d’emergència. Tres mesos més tard, ningú recorda, i la Font de Veritat registra quelcom que la xarxa va deixar de ser fa setmanes.

L’Aplicació (secció 4.2.4) valida les dades a l’entrada. Això no és suficient. Un registre que era precís quan es va crear pot tornar-se incorrecte simplement perquè el món ha canviat al seu voltant. Sense un procés de reconciliació continu, la Font de Veritat perd credibilitat gradualment: els equips deixen de confiar-hi, comencen a mantenir els seus propis fulls de càlcul i l’automatització construïda sobre ella comença a produir resultats incorrectes silenciosament.

El patró de reconciliació

La reconciliació significa comparar periòdicament l’estat real de la xarxa amb la Font de Veritat i classificar cada discrepància:

• Deriva de configuració: un dispositiu difereix de la intenció de la Font de Veritat. La Font de Veritat és correcta; la xarxa ha derivat. Activeu el bloc d’Execució per remediar.
• Canvi no registrat: s’ha fet un canvi deliberat a la xarxa però no s’ha registrat a la Font de Veritat. La xarxa és correcta; la Font de Veritat és obsoleta. Alerteu l’operador perquè actualitzi la intenció.
• Registre òrfe: la Font de Veritat té un objecte (dispositiu, prefix, VLAN) per a quelcom que ja no existeix a la xarxa. Poseu-lo a la cua per a la revisió de neteja.

Cada classe requereix una resposta diferent. L’automatització pot gestionar la remediació de la deriva (dins de les barreres de seguretat definides). Els canvis no registrats requereixen judici humà: era una solució d’emergència que s’hauria de formalitzar, o un canvi no autoritzat que s’hauria de revertir? Els registres orfes necessiten un flux de treball de neteja que no elimini automàticament, sinó que presenti el candidat per a la revisió.

Patrons de degradació de dades a observar

A la pràctica, les fonts més comunes d’obsolescència de la Font de Veritat són:

• Dispositius donats de baixa no eliminats: la Font de Veritat té un registre de dispositiu amb una IP de gestió, però el dispositiu s’ha eliminat físicament. L’automatització dirigida a aquesta IP fallarà o, pitjor, arribarà a un dispositiu que es va redeployar amb un rol diferent.
• IPs reassignades manualment: una IP indicada a la Font de Veritat com a pertanyent al dispositiu A ara és usada pel dispositiu B, assignada durant un incident. Tant la Font de Veritat com l’IPAM poden ser internament consistents però incorrectes respecte a la xarxa real.
• Ampliació de l’abast de les VLAN: una VLAN es va desplegar en un conjunt definit de commutadors, però durant la resolució de problemes es va afegir als troncs addicionals. La intenció de la Font de Veritat ja no coincideix amb la pertinença real.

Freqüència de reconciliació

No totes les dades envelleixen al mateix ritme. L’inventari de dispositius canvia lentament; l’estat operatiu canvia constantment. Un enfocament pràctic és nivell la cadència de reconciliació per tipus de dades: inventari de dispositius reconciliat diàriament, assignacions d’IP reconciliades cada hora, pertinença a VLAN reconciliada després de cada esdeveniment de canvi i en un escombrat per lots diari.

La incorporació de xarxes existents (secció 4.2.7) és una migració única. La reconciliació és el procés operatiu que manté la credibilitat de la Font de Veritat després de la posada en marxa. Els equips que ometen la reconciliació descobriran que la confiança en la Font de Veritat s’erosiona en mesos, i l’automatització construïda sobre ella comença silenciosament a produir resultats incorrectes.

La Font de Veritat com a dependència en viu

Hi ha una diferència estructural entre una Font de Veritat usada com a referència (l’automatització la llegeix al principi d’un flux de treball) i una Font de Veritat usada com a dependència en viu (l’automatització la llegeix a cada pas d’un flux de treball, confiant que les dades siguin actuals). Tots dos patrons són vàlids, però el segon crea requisits operatius que el primer no té.

Quan l’Executor o l’Orquestrador llegeix l’inventari de dispositius de la Font de Veritat al principi del flux de treball i després procedeix a desplegar-se en 200 dispositius, treballa a partir d’un snapshot. Si un dispositiu es dona de baixa a mig funcionament, o una adreça IP es reassigna entre la lectura del snapshot i el pas d’execució, l’automatització actua sobre dades obsoletes. Per als fluxos de treball curts, això sol ser acceptable. Per als fluxos de treball de llarga durada (actualitzacions de firmware que s’executen durant hores, execucions d’aprovisionament que s’estenen per finestres de manteniment), la finestra d’obsolescència és significativa.

La mitigació és tractar la disponibilitat de la Font de Veritat com una dependència, no com una suposició:

• L’Orquestrador hauria de validar que la lectura de la Font de Veritat va tenir èxit i va retornar un registre actual (comprovant les marques de temps de darrera sincronització o fent servir el propi endpoint de salut de la Font de Veritat) abans de començar un pas de desplegament.
• Per als fluxos de treball de llarga durada, considereu tornar a llegir la Font de Veritat en cada etapa principal del flux de treball en lloc d’una sola vegada al principi.
• Si la Font de Veritat no està disponible, el flux de treball hauria de fallar de manera neta amb un error clar, no continuar amb un snapshot en memòria cau d’edat desconeguda.

Això també significa que la pròpia Font de Veritat ha de ser dissenyada per a la disponibilitat. Una Font de Veritat que és la font autoritzada d’escriptura per a tota l’automatització però que no té cap configuració d’alta disponibilitat és un punt únic de fallada per a tota la plataforma d’automatització. La secció 4.2.9 cobreix solucions específiques; el Capítol 11 aborda el disseny de disponibilitat per a la plataforma en el seu conjunt.

4.2.9. Panorama de Solucions#

Hi ha molts productes de font de veritat disponibles. Alguns són de codi obert, alguns comercials. Alguns són de propòsit general, alguns especialitzats per a dominis específics com la gestió d’IP. Aquesta és una instantània de principis del 2026: el panorama canvia constantment, de manera que sempre comproveu les capacitats i l’impuls actuals abans de triar.

4.2.9.1. Solucions de Codi Obert#

4.2.9.2. Solucions Comercials#

Totes les solucions de codi obert enumerades anteriorment també tenen una oferta comercial.

4.2.9.3. Plataformes Especialitzades#

4.2.9.4. Consideracions de Selecció#

Quan avalueu solucions de Font de Veritat, considereu aquests factors d’alineació:

• Requisits d’escala: Nombre de dispositius (centenars vs. centenars de milers), taxa de canvis, volum de consultes
• Necessitats del model de dades: Estructura relacional (NetBox, Nautobot) vs. relacions de grafs (Infrahub) vs. magatzem de documents flexible
• Ecosistema d’integració: Eines existents (monitorització, ITSM, plataformes cloud) que han de federar dades
• Experiència de l’equip: Familiaritat amb Python/Django, preferència per plataformes low-code, comoditat amb els fluxos de treball de Git
• Model operatiu: Auto-allotjat vs. SaaS, processos d’aprovació de canvis, requisits RBAC
• Trajectòria d’evolució: Camí de migració brownfield, extensibilitat de l’esquema, estabilitat de l’API

4.3. Exemple d’Implementació#

4.3.1. Cas d’Ús: Construint la Font de Veritat per a la Xarxa del Campus#

Tornem a la xarxa del campus presentada al Capítol 3. Amb aproximadament 800 commutadors d’accés i distribució de Cisco, Arista i HPE distribuïts per múltiples edificis, l’equip d’operacions gestiona un flux constant de sol·licituds de servei: noves VLANs, assignacions de subxarxes IP, actualitzacions de polítiques d’encaminament i canvis de control d’accés. Abans que res d’això es pugui automatitzar de manera fiable, les dades han d’estar en un lloc consistent i autoritzat.

Avui el campus opera amb tres sistemes separats que posseeixen cadascun una part del quadre:

• Infoblox: IPAM autoritzat que gestiona l’assignació d’adreces IP, les assignacions de prefixos i el DNS a través de totes les subxarxes del campus
• ServiceNow: Inventari d’actius i CMDB que rastreja les ubicacions dels commutadors, els models de maquinari, les assignacions d’edificis i l’historial de manteniment
• Commutadors del campus: La configuració en execució real, distribuïda entre 800 dispositius sense cap visió consolidada única del que hi ha desplegat on

Repte: Quan l’equip d’aplicacions presenta una sol·licitud de nou segment de servei VLAN, l’enginyer de xarxa ha de fer una referència creuada manual d’Infoblox per trobar una subxarxa disponible, ServiceNow per saber quins commutadors hi ha a l’edifici objectiu, i sessions Secure Shell (SSH) al dispositiu per comprovar les assignacions actuals de VLAN. La Configuration Drift s’acumula perquè no hi ha cap acord únic sobre quin hauria de ser l’estat desitjat de cada commutador. Afegir una nova plantilla de disseny de proveïdor requereix actualitzar la documentació en múltiples llocs sense cap garantia de consistència.

Solució: Desplegar Nautobot com a Font de Veritat de Xarxa federada que s’integra tant amb Infoblox com amb ServiceNow, extreu l’estat actual dels commutadors del campus i afegeix el model de dades específic de xarxa que ni Infoblox ni ServiceNow poden proporcionar: definicions de VLAN, plantilles de configuració per proveïdor, patrons de disseny per a les capes d’accés i distribució, i el model de dades de sol·licitud de servei que connecta una sol·licitud de negoci amb els objectes tècnics que han d’existir abans que l’Executor pugui executar un sol playbook.

Aquest exemple és il·lustratiu, no prescriptiu. Hi ha molts productes i arquitectures de Font de Veritat vàlids que podrien resoldre aquest escenari. El punt és demostrar com els sis blocs funcionals: Modelatge, Consum, Aplicació, Versionat, Agregació i Orientat al Disseny, treballen junts en un escenari real. La Font de Veritat de la vostra organització probablement tindrà un aspecte diferent basat en les eines existents, l’experiència de l’equip i les restriccions.

4.3.2. Arquitectura de la Solució#

graph TB
    IPAM["Infoblox<br/>Authoritative IPAM<br/>IP ranges, DNS"]
    CMDB["ServiceNow<br/>Authoritative CMDB<br/>Assets, locations, metadata"]
    DEVICES["🖧 Campus Switches<br/>Cisco, Arista, HPE<br/>~800 devices"]
    
    SLURPIT["Slurpit<br/>Brownfield Discovery<br/>Config extraction"]
    
    subgraph NAUTO ["🔗 Nautobot (Aggregation Hub)"]
        direction TB
        AGG["Aggregation Layer<br/>Authority rules<br/>Conflict resolution"]
        SOT["Consolidated SoT and data expansion<br/>Devices, IPs, sites<br/>relationships"]
        API["Consumption APIs<br/>REST, GraphQL<br/>Webhooks"]
    end
    
    EXEC["🚀 Execution System<br/>Config generation<br/>Device deployment"]
    OBS["👁️ Observability<br/>State validation<br/>Drift detection"]
    UI["🖥️ Presentation<br/>Web UI, CLI<br/>Dashboards"]
    
    IPAM -->|Webhooks/Polling<br/>IP data| AGG
    CMDB -->|Webhooks/Polling<br/>Asset data| AGG
    DEVICES -->|SSH/NETCONF<br/>Device state| SLURPIT
    SLURPIT -->|Transformed data<br/>Initial bootstrap| AGG
    
    AGG --> SOT
    SOT --> API
    
    API -->|Intent queries| EXEC
    API -->|Config templates| EXEC
    API -->|Data access| UI
    
    OBS -->|State Drift| API
    API -->|Inventory| OBS
    
    EXEC -.->|Deploy configs| DEVICES
    OBS -.->|Monitor state| DEVICES

La idea clau: Nautobot no substitueix Infoblox ni ServiceNow. Agrega les seves dades, resol conflictes i actua com l’API única que els sistemes aigüest avall (Execució, Observabilitat, Presentació) consumeixen. Aquesta separació de responsabilitats permet que cada sistema sigui el millor de la seva categoria.

Com Treballen Junts els 6 Components#

Modelatge: Cada font de dades ve amb el seu propi model de dades amb alguns solapaments que permeten la connexió de dades mitjançant identificadors. La responsabilitat és distribuïda, cada font de dades s’especialitza en dades diferents. L’estructura ha de permetre dades parcials fins que tota la informació estigui consolidada (p. ex., un dispositiu pot existir a Nautobot abans de l’assignació d’IP).

Consum: Nautobot ofereix una API REST i una interfície GraphQL perquè altres dispositius puguin consultar les dades de manera consistent com a punt central en lloc d’haver d’integrar-se amb totes les fonts de dades.

Aplicació: Nautobot aplica la validació global per a la consistència. Si l’IPAM diu que la 10.1.1.5 està assignada a device-dal-01, però aquest prefix està assignat per a una altra regió on el dispositiu no pertany, cal marcar-ho. A més, evita les dades orfes: no es pot assignar una IP d’Infoblox si el dispositiu no existeix a ServiceNow (integritat referencial). A més, la validació suau avisa: “El dispositiu s’ha actualitzat per darrera vegada a ServiceNow fa 30 dies; potser sigui obsolet” (sense bloquejar), amb capacitat per netejar les dades.

Versionat: Tots els canvis es rastreen com a registres de changelog. Quan un objecte canvia i l’IPAM reassigna automàticament una IP, Nautobot registra “IPAM webhook: IP 10.1.1.5 assignada a device-dal-02, interfície eth1.1 el 2024-02-08T14:32:00Z”, cosa que permet rastrejar per què un dispositiu té la seva IP actual a través de la història. No obstant, la capacitat de rollback és limitada perquè no hi ha cap mecanisme per tornar a un moment anterior en el temps (nota: l’aplicació VCS de Nautobot permet capacitats més sofisticades però no es cobreix aquí per simplicitat).

Agregació: Aquest és un aspecte clau en aquesta solució ja que hi ha múltiples fonts de dades a interconnectar. Nautobot prioritza Infoblox per a les dades d’IP (és l’IPAM autoritzat). Per als metadades d’actius (garantia, centre de costos), ServiceNow és autoritzat, i Nautobot l’utilitza per resoldre discrepàncies. L’estratègia de sincronització podria ser:

• ServiceNow -> Nautobot: Sincronització periòdica cada 4 hores (es pot tolerar un lleuger retard en els metadades d’actius)
• Infoblox -> Nautobot: Webhooks en temps real per als canvis d’IP (els canvis d’IPAM són urgents, no es pot esperar el polling)
• Dispositius de xarxa -> Nautobot: Utilitzant l’App d’Incorporació de Nautobot, les dades de la xarxa s’incorporen als models de dades de Nautobot (la consistència eventual és acceptable) A més, si hi ha algunes fallades, Nautobot podria oferir alguns mecanismes de resiliència com ara:
• Si Infoblox cau durant 2 hores, Nautobot continua operant amb les dades d’IP en memòria cau, marcades com a “obsoletes”
• Els operadors veuen l’advertiment: “Dades IP de fa 2 hores; IPAM no disponible actualment; nova assignació diferida”
• Un cop Infoblox es recupera, les assignacions pendents es processen atòmicament

Orientat al Disseny: Fent servir l’Aplicació Nautobot Design Builder, Nautobot ofereix una interfície d’alt nivell per satisfer una nova sol·licitud de servei VLAN. L’operador proporciona la intenció d’alt nivell: { "vlan_name": "app-payments", "subnet_size": "/24", "location": "building-b", "vendors": ["arista", "cisco"] }. Aleshores, una plantilla de disseny expandeix això: crea l’objecte VLAN a Nautobot, sol·licita un prefix /24 disponible d’Infoblox per al rang d’IP de building-b, genera automàticament plantilles de configuració per proveïdor (sintaxi Arista EOS per als commutadors de distribució, sintaxi Cisco IOS-XE per als commutadors d’accés), consulta ServiceNow per identificar quins dels 800 commutadors del campus es troben físicament a building-b, resultant en tots els objectes tècnics que l’Executor necessita abans d’executar un sol playbook.

4.3.3. Flux d’Implementació#

Càrrega inicial de dades

1. Importació d’Infoblox: Nautobot es connecta a l’API d’Infoblox -> extreu tots els rangs d’IP, reserves i registres DNS
2. Importació de ServiceNow: Nautobot es connecta al CMDB de ServiceNow -> extreu tots els actius de TI, ubicacions i relacions
3. Descoberta de xarxa brownfield amb Slurpit: Slurpit.io es connecta als dispositius de xarxa existents per extreure l’estat de configuració actual:
   • Inventari de dispositius (models, números de sèrie, versions de programari)
   • Configuracions d’interfície i estat operatiu
   • Adreçament IP i assignacions de VLAN
   • Configuracions de protocol d’encaminament
   • Transforma les configuracions de dispositiu en models de dades compatibles amb Nautobot
4. Detecció i resolució de divergències: El procés d’auditoria de Nautobot correlaciona dades de les tres fonts (Infoblox, ServiceNow, Slurpit):
   • Exemple de conflicte: L’IP de la interfície del dispositiu mostra 10.1.1.5/24, però Infoblox mostra aquesta IP assignada a un dispositiu diferent
   • Flux de resolució: Nautobot marca 47 conflictes per a la revisió humana
     • L’enginyer de xarxa avalua cadascun: “Confiar en l’estat del dispositiu” o “Confiar en l’IPAM; el dispositiu necessita correcció”
     • S’apliquen les regles de governança: “Confiar en el dispositiu per als ports d’accés, confiar en l’IPAM per a les IPs d’infraestructura”
   • Resolució per lots: Conflictes similars resolts amb política consistent
5. Població de l’esquema unificat: Nautobot fusiona les tres fonts: devices[*].{ name, location_id, ipv4_address, serial_number, cost_center } amb dades validades i lliures de conflictes

Operacions en viu

1. Nova sol·licitud de servei VLAN: L’equip d’aplicacions presenta una sol·licitud a ServiceNow. Nautobot detecta el webhook, crea els objectes VLAN i prefix, consulta Infoblox per al pròxim /24 disponible en el rang d’adreces de building-b, l’assigna automàticament i marca el registre amb el sol·licitant, l’aprovador i la marca de temps. El bloc d’Execució ara pot consultar Nautobot per a cada punt de dades que necessiti per desplegar el servei a través de tots els commutadors objectiu.
2. Nou commutador del campus incorporat: L’operador crea l’entrada d’actiu a ServiceNow. Nautobot detecta el webhook, crea l’objecte de dispositiu amb metadades d’ubicació, proveïdor i rol, consulta Infoblox per a una IP de gestió en el rang de gestió del lloc i assigna la plantilla de disseny apropiada basada en el rol i el proveïdor del dispositiu. El commutador s’inscriu a la Font de Veritat i és elegible per als futurs desplegaments abans que ningú toqui el CLI.
3. Finestra de manteniment d’Infoblox: L’IPAM cau durant 2 hores. Nautobot mostra les dades en memòria cau “Dades IP vàlides a les 14:30 UTC; actualització pendent”. Els operadors encara poden consultar l’inventari de dispositius i les definicions de VLAN, però les noves assignacions d’IP es difereixen. Quan Infoblox torna, les assignacions pendents s’encuen i es processen atòmicament.

Gestió d’inconsistències i detecció periòdica de deriva

Després de la incorporació inicial, Nautobot monitoritza contínuament les divergències entre les tres fonts de dades:

1. Sincronització contínua: A més de les actualitzacions orientades a esdeveniments activades quan es produeixen canvis, la sincronització periòdica s’executa cada 4-6 hores:

   • Sincronització d’Infoblox: Basada en webhooks per als canvis d’IP + reconciliació periòdica
   • Sincronització de ServiceNow: Polling periòdic per a les actualitzacions de metadades d’actius
   • Descoberta de Slurpit: Polling periòdic de dispositius per capturar l’estat real de la xarxa

2. Auditoria i correlació de Nautobot: El procés d’auditoria de Nautobot compara dades de totes les fonts per detectar inconsistències:

   • Conflictes de fonts de dades: L’IP de la interfície del dispositiu difereix de l’assignació d’Infoblox
   • Configuration Drift: L’estat del dispositiu difereix de la intenció de Nautobot (servidor NTP canviat, VLAN afegida al tronc)
   • Metadades obsoletes: L’actiu de ServiceNow s’ha actualitzat per darrera vegada fa 90 dies (possible obsolescència)

3. Classificació de divergències i remediació:

   • Tipus 1 - Configuration Drift: El dispositiu difereix de la intenció de Nautobot -> Activar l’Execució per corregir el dispositiu
     • Exemple: Servidor NTP canviat al dispositiu -> L’Execució regenera la configuració i empeny la correcció
   • Tipus 2 - Obsolescència d’intenció: Canvi intencional no reflectit encara a Nautobot -> Alertar l’operador per actualitzar la Font de Veritat
     • Exemple: L’operador va afegir la VLAN manualment durant un incident -> Actualitzar Nautobot per reflectir la intenció actual
   • Tipus 3 - Desajust d’autoritat externa: Conflicte entre fonts autoritzades (Infoblox vs. realitat del dispositiu)
     • Exemple: Desajust d’assignació d’IP -> Decisió humana requerida basada en les regles de governança

4. Remediació automàtica vs. manual:

   • Auto-remediació: Els canvis pre-aprovats (NTP, DNS, servidors syslog) es corregeixen automàticament via Execució
   • Aprovació manual: Els canvis crítics (configuració BGP, protocols d’encaminament, polítiques de seguretat) requereixen revisió humana abans de la correcció
   • Escalada: Els conflictes no resolibles o els patrons de deriva repetits s’escalen a l’equip de xarxa

5. Rastre d’auditoria: Totes les divergències detectades, resolucions i accions de remediació registrades per al compliment normatiu i la resolució de problemes

4.3.4. Compromisos de l’Enfocament#

Avantatges d’aquest Enfocament#

Limitacions i Restriccions#

Hi ha altres maneres i solucions que podrien adaptar-se millor al vostre cas d’ús. Preneu les vostres pròpies decisions basant-vos en les vostres necessitats i requisits. Sempre hi ha compromisos a tenir en compte.

4.4. Resum#

La regla del tallafoc òrfena de la història inicial no era un error de configuració. Ningú va fallar en la seva feina. La regla va quedar perquè no hi havia cap sistema que connectés la VLAN amb el servei i amb la política del tallafoc. Quan es va eliminar la VLAN, aquesta connexió no existia, de manera que la regla no tenia res que activés la seva neteja. La font de veritat és el sistema que fa explícites aquestes connexions.

Sis funcionalitats construeixen aquest sistema. El Modelatge defineix com hauria de ser la xarxa i a quin nivell d’abstracció. L’Orientat al Disseny tradueix una sol·licitud de negoci (“afegir la sucursal de Dallas”) en els 50+ objectes tècnics que l’Executor necessita abans de tocar un dispositiu. El Consum posa aquesta intenció a disposició de manera consistent per als humans, els fluxos d’automatització i altres sistemes. L’Aplicació assegura que les dades que entren a la Font de Veritat siguin vàlides abans que puguin produir un estat de xarxa incorrecte aigüest avall. El Versionat registra cada canvi amb l’autor, la raó i la marca de temps, fent que la Font de Veritat sigui auditable i recuperable. L’Agregació connecta la Font de Veritat amb els sistemes autoritzats que ja posseeixen parts de les dades: l’IPAM per a les adreces, el CMDB per als actius, els proveïdors de circuits per a la connectivitat.

L’exemple d’implementació del campus va mostrar els sis funcionant junts: Nautobot com a hub de federació, Infoblox i ServiceNow com a fonts autoritzades per als seus respectius dominis, plantilles de disseny que tradueixen una sol·licitud de servei VLAN en tot el necessari per al desplegament automatitzat. El resultat no és simplement una base de dades d’estat de la xarxa. És la referència única que cada altre bloc de construcció consulta per saber com hauria de ser la xarxa.

El Capítol 5 pren aquesta intenció i la converteix en acció: el bloc d’Execució llegeix de la Font de Veritat i empeny canvis a la xarxa, amb les garanties de consistència i el comportament de rollback que la funcionalitat de Versionat de la Font de Veritat fa possible.

Referències i Lectures Addicionals#

Modelatge de Dades i Estàndards d’Esquema

• IETF RFC 6020 i RFC 7950: Estàndard del llenguatge de modelatge de dades YANG
• Models YANG de l’IETF: Repositori de models YANG estàndard incloent IETF, IEEE i OpenConfig
• OpenConfig: Models de configuració orientats a la comunitat i sense proveïdors
• NETCONF (RFC 6241): Protocol de configuració de xarxa complementari a YANG

APIs i Consum de Dades

• Especificació GraphQL
• gRPC: Marc RPC modern per a APIs d’alt rendiment
• Guia de Disseny d’API REST: Millors pràctiques de Microsoft per al versionat i la paginació
• OAuth 2.0 (RFC 6749) i OpenID Connect (RFC 6750): Estàndards d’autenticació/autorització

Qualitat de Dades i Validació

• Data Quality Fundamentals (DAMA DMBOK): Marcs de qualitat de dades empresarials
• JSON Schema: Estàndard de validació d’esquemes declarativa
• Restriccions YANG (RFC 6020, secció 8.2.4): Patrons de validació específics de xarxa

Versionat, Auditoria i Gestió de Canvis

• Pro Git (Scott Chacon i Ben Straub): Conceptes de control de versions i patrons de disseny
• The Phoenix Project (Gene Kim, Kevin Behr, George Spafford): Gestió de canvis i disciplina operativa
• Semantic Versioning: Estratègia de versionat per a APIs i models de dades

Integració i Agregació de Dades

• Enterprise Integration Patterns (Gregor Hohpe i Bobby Woolf): Patrons d’arquitectura d’integració de dades
• Master Data Management (David Loshin): Marcs de governança federada

Programabilitat i Automatització de Xarxes

• Network Programmability and Automation, 2nd Edition (Jason Edelman, Matt Oswalt, Scott S. Lowe, Christian Adell): Conceptes fonamentals per a l’automatització de xarxes
• Infrastructure as Code, 2nd Edition (Kief Morris): Tractar les configuracions d’infraestructura com a codi versionat

Sistemes Distribuïts i Escalabilitat

• Designing Data-Intensive Applications (Martin Kleppmann): Escalabilitat, consistència i patrons de disseny d’API
• Distributed Systems (Andrew S. Tanenbaum i Maarten van Steen): Conceptes fonamentals per a sistemes federats

💬 Found something to improve? Send feedback for this chapter