2. Principis de Disseny#

Un equip d’automatització de xarxes va passar sis mesos construint un sistema del qual estaven genuïnament orgullosos. Extreia la intenció d’un model de dades estructurat, generava configuracions de dispositius a través d’un motor de plantilles, validava els canvis contra una biblioteca de polítiques i els aplicava mitjançant NETCONF amb suport complet de reversió. Arquitectònicament, era sòlid. La demo per a la direcció va anar bé. Llavors el van lliurar a l’equip d’operacions de xarxa.

L’adopció no va arribar mai. Els operadors continuaven usant la CLI. Quan se’ls preguntava per què, les respostes eren consistents: “No sé què farà abans que ho faci.” “Si alguna cosa va malament, no puc saber què ha passat.” “No entenc com llegir la sortida.” L’equip d’automatització havia construït alguna cosa tècnicament impressionant però operativament opaca. No hi havia mode de simulació prèvia, ni vista prèvia de canvis llegible per humans, ni registre d’auditoria escrit en termes que els operadors reconeguessin. El sistema era una caixa negra que demanava confiança que no havia guanyat. Sis mesos d’esforç d’enginyeria sense usar.

Aquest resultat és més comú del que la majoria d’equips admet. L’automatització no falla només per errors o mala arquitectura. Falla perquè les persones que necessiten confiar en ella no ho fan. Explorarem els principis de disseny fonamentals que fan que l’automatització de xarxes sigui fiable, escalable i segura. No són teories abstractes: són la diferència entre l’automatització que s’adopta i lliura valor real, o l’automatització que s’ignora i eventualment s’abandona.

Molts d’aquests principis s’apliquen també a altres projectes de programari. Però l’automatització de xarxes té característiques úniques perquè suporta infraestructura crítica. Els enginyers de xarxa han construït i mantingut aquests sistemes durant dècades usant un model basat en la cautela, la precisió i la verificació manual. Ara els demanem que adoptin un model fonamentalment diferent. I això requereix confiança.

2.1 Construint Confiança#

Abans d’entrar en principis específics, parlem de confiança. És la pedra angular de l’automatització de xarxes exitosa. Sense ella, l’adopció es torna gairebé impossible.

Per què importa tant la confiança? Perquè sense ella, els enginyers de xarxa no adoptaran la teva automatització. Necessiten creure que l’automatització proporciona almenys el mateix nivell de confiança que els processos manuals que reemplaça (més altres beneficis).

Fins i tot més complicat: els sistemes d’automatització sovint són construïts per enginyers que poden no tenir experiència profunda en xarxes. Per això l’automatització ha de compensar incorporant característiques fortes i explícites que la facin segura, fiable i fàcil de personalitzar i gestionar per als equips d’enginyeria de xarxes.

La rellevància de l’automatització de confiança està inspirada en la presentació de Damien Garros Building Trustworthy Network Automation a Autocon3.

Per simplificar, aquestes són les quatre característiques bàsiques que necessitem:

• Predictable: Resultats consistents i deterministes. Els enginyers necessiten saber què passarà abans de prémer “executar”, i obtenir el mateix comportament cada vegada.
• Reliable: Gestiona els errors amb elegància. Es recupera dels fallades. Garanteix que les operacions es completin de forma segura (o es reverteixin) fins i tot sota condicions inesperades i a escala.
• Usable: Interfícies que permeten als enginyers validar, raonar i controlar el comportament sense complexitat excessiva. Amb barreres de protecció.
• Understandable: No pot ser una caixa negra. Ha d’exposar la intenció, els passos, els resultats i les decisions d’una manera que generi confiança humana.

graph BT
  %% ===== Middle Layer =====
  subgraph L2[**Qualitats**]
    direction LR
    B1[Predictible]:::layer2
    B2[Fiable]:::layer2
    B3[Usable]:::layer2
    B4[Comprensible]:::layer2
  end

  %% ===== Top Layer =====
  subgraph L1[" "]
    direction TB
    A[Confiança]:::layer1
  end

  %% ===== Connections: Behavior → Outcome =====
  B1 --> A
  B2 --> A
  B3 --> A
  B4 --> A

  %% ===== Styling =====
  classDef layer1 fill:#ffcccc,stroke:#b8860b,stroke-width:2px,color:#000;
  classDef layer2 fill:#ffe6cc,stroke:#4682b4,stroke-width:1.5px,color:#000;

La predictibilitat o el comportament determinista s’està tornant cada vegada més rellevant a mesura que les tecnologies d’IA/ML entren en el domini de l’automatització de xarxes, perquè aquestes introdueixen certa aleatorietat.

Aquestes característiques no són opcionals, no són consideracions posteriors. I els enginyers de xarxa que usaran i dependran de l’automatització les han de reconèixer.

He construït moltes solucions d’automatització de xarxes. Res és més frustrant que veure com una solució ben dissenyada s’ignora o s’abandona perquè els operadors de xarxa no hi confiaven. Aquests principis t’ajuden a evitar aquest resultat.

Així que, donades aquestes característiques, explorem els principis que les sustenten.

2.2 Principis de Disseny#

Amb la confiança com a fonament, podem explorar els principis de disseny que sustenten les qualitats necessàries per a una automatització de confiança. Aquests fan que l’automatització sigui fiable, predictible i escalable.

La llista completa podria ser molt més llarga (l’ampliarem més endavant en introduir altres principis d’enginyeria de programari). Però hi ha sis principis fonamentals que tota solució d’automatització de xarxes hauria d’incorporar:

• Idempotency: La mateixa operació múltiples vegades = el mateix estat final. Redueix els efectes secundaris, elimina l’ambigüitat, fa que l’automatització sigui més comprensible i segura de repetir.
• Transactional: Els canvis es completen totalment o fallen de forma segura. Sense estats parcials, inconsistents o a mig aplicar. Essencial per a la predictibilitat i habilita les reversions a nivell de xarxa.
• Intent-Driven: Defineix l’estat desitjat del sistema sota diferents condicions. Millora la predictibilitat, redueix la càrrega cognitiva, fa el sistema més usable.
• Dry Run Friendly: Mostra què faria abans de fer-ho. Fa que l’automatització sigui més usable i de confiança en permetre que els humans validin accions, visualitzin resultats i detectin problemes abans que arribin a la xarxa.
• Versioning: Suporta el versionat tant de dades com de lògica. Mou-te cap enrere o cap endavant en el temps, recupera estats anteriors, manté múltiples estats en paral·lel. Reforça la predictibilitat i enforteix la fiabilitat.
• Comprovable: Un entorn de proves adequat és essencial abans d’executar canvis en producció. Millora la fiabilitat i ajuda els enginyers a entendre el comportament del sistema.

Aquests principis no són exclusius de les xarxes, s’apliquen a l’automatització en qualsevol domini de TI. Però es tornen especialment crítics en les xarxes, on els canvis comporten un risc operacional significatiu.

Aquests sis principis formen la base per a una automatització de xarxes segura, predictible i de confiança. Estableixen les bases per a conceptes més avançats introduïts més endavant. Es tornen encara més importants en escalar l’automatització a través d’infraestructures grans i complexes.

graph BT
  %% ===== Bottom Layer =====
  subgraph L3[**Principis**]
    direction LR
    C1[Idempotent]:::layer3
    C2[Versionat]:::layer3
    C3[Transaccional]:::layer3
    C4[Comprovable]:::layer3
    C5[Simulació Prèvia]:::layer3
    C6[Basat en Intenció]:::layer3
  end

  %% ===== Middle Layer =====
  subgraph L2[**Qualitats**]
    direction LR
    B1[Predictible]:::layer2
    B2[Fiable]:::layer2
    B3[Usable]:::layer2
    B4[Comprensible]:::layer2
  end

  %% ===== Top Layer =====
  subgraph L1[" "]
    direction TB
    A[Confiança]:::layer1
  end

  %% ===== Connections: Foundation → Behavior =====
  C1 --> B1
  C1 --> B4

  C2 --> B3
  C2 --> B2

  C3 --> B1
  C3 --> B2

  C4 --> B2
  C4 --> B4

  C5 --> B3
  C5 --> B4

  C6 --> B1
  C6 --> B3

  %% ===== Connections: Behavior → Outcome =====
  B1 --> A
  B2 --> A
  B3 --> A
  B4 --> A

  %% ===== Styling =====
  classDef layer1 fill:#ffcccc,stroke:#b8860b,stroke-width:2px,color:#000;
  classDef layer2 fill:#ffe6cc,stroke:#4682b4,stroke-width:1.5px,color:#000;
  classDef layer3 fill:#ccffcc,stroke:#228b22,stroke-width:1.5px,color:#000;

Cadascun d’aquests principis de disseny mereix més context. Els explorarem en un ordre que reflecteix les seves dependències lògiques: començar per definir què volem aconseguir, després assegurar-nos que ocorri de forma segura i correcta, i finalment validar que funcioni.

2.2.1. Basat en Intenció#

Per què començar amb la intenció? Abans de parlar sobre com executar l’automatització, necessitem entendre què estem intentant aconseguir. El disseny basat en intenció és la base sobre la qual es construeix tot.

Cas d’ús comú per començar amb l’automatització: scripts o playbooks que executen accions simples. Pujar o baixar una interfície proporcionant el FQDN i el nom de la interfície. Però això crea un problema. La següent persona que treballi amb aquella interfície no sabrà quin és el seu Desired State. Hauria d’estar activa o inactiva?

Aquest problema afecta tant les operacions manuals com les automatitzades. Però amb l’automatització, el problema empitjora. No pots inferir amb confiança la intenció de la xarxa a partir del seu estat actual, especialment quan s’han aplicat molts canvis ad hoc. La configuració real de la xarxa és el resultat de la teva lògica Intent-Driven, no un registre fiable d’ella.

La intenció es manifesta en diferents nivells depenent de les teves necessitats de variabilitat i personalització. Els entorns simples poden requerir menys dades variables i poden basar-se en plantilles. Altres dades poden requerir revisió entre equips, mentre que alguns poden actualitzar-se seguint convencions i barreres de protecció.

Algú podria argumentar que la seva intenció és simplement l’Actual State de la xarxa: “revisa la configuració, aquesta és la meva intenció.” Si bé això és tècnicament una intenció, no pots provar que coincideix amb la teva intenció original o real i que no ha estat alterada per les circumstàncies, tret que tinguis una font separada amb la qual comparar. La configuració de la xarxa és la sortida de la teva intenció, no la intenció en si mateixa.

Per això la qualitat de les teves dades Intent-Driven determina directament la qualitat de la teva automatització. Aquest concepte està estretament relacionat amb el Source of Truth (SoT) (SoT), que cobrirem en detall al Capítol 4.

Infraestructura com a Codi (IaC): L’automatització basada en intenció és la base de Infrastructure as Code (IaC): tractar les definicions d’infraestructura de xarxa com a codi de programari. Amb IaC, obtens control de versions, processos de revisió de codi, proves i la capacitat de tractar els canvis d’infraestructura de la mateixa manera que els canvis de programari. Això connecta l’automatització de xarxes amb les millors pràctiques d’enginyeria de programari. IaC manté les plantilles, els inventaris i la intenció com a fitxers sota control de versions. Els canvis es revisen, proven i rastregen, no s’apliquen com a edicions de CLI puntuals.

Basant-nos en la intenció, el següent principi garanteix que un cop sabem què volem, puguem executar-ho de forma segura i consistent.

2.2.2. Idempotència#

Per què importa la idempotència: La idempotència garanteix que les execucions repetides produeixin el mateix resultat. És essencial perquè l’automatització sovint s’executa múltiples vegades per accident, per mecanismes de reintent o per disseny. Sense idempotència, cada execució podria realitzar canvis impredictibles.

Idempotency significa que executar la mateixa operació múltiples vegades resulta en el mateix estat final, sense efectes secundaris no desitjats.

Per exemple, en l’aprovisionament automatitzat d’ACL, si definim una regla, esperem:

• Si la regla no existeix, s’afegeix en una posició específica.
• Si la regla ja existeix, no afegir duplicats.
• Si s’afegeix una altra regla més tard, l’anterior roman intacta i no es reordena.

Sona com a sentit comú, però la realitat és més complexa. El sistema ha d’implementar lògica per garantir la idempotència. Per exemple, necessita comprovar:

• Quin és l’estat actual de l’ACL?
• La regla ja en forma part?
• Si no, quina diferència cal aplicar?

Sense idempotència, la configuració pot aplicar-se en un ordre impredictible, afectant la reproducibilitat.

La idempotència s’aplica a les diferents dimensions de l’automatització de xarxes. Per exemple, en sol·licitar una adreça IP a través de DHCP o des d’un sistema IPAM que entén el mapeig entre la sol·licitud de l’identificador i el resultat:

Figura 1: Exemple d’Idempotència (de la xerrada de Damien Garros a Autocon3)

Com llegiràs més endavant, per aconseguir la idempotència, prefereix usar models Declarative en lloc de Imperative. Defineix l’estat final en lloc dels passos. Això no significa que usar el mode imperatiu sigui impossible, però és més complicat.

La idempotència se centra en la consistència dins d’una única execució. El principi transaccional garanteix que els canvis s’apliquin atòmicament en múltiples sistemes, prevenint estats parcials o inconsistents.

2.2.3. Transaccional#

Per què importa la transaccionalitat: Els canvis de xarxa sovint afecten múltiples dispositius simultàniament. Sense transaccionalitat, una fallada a mig procés deixa la xarxa en un estat inconsistent: alguns dispositius actualitzats, altres no. Especialment problemàtic en sistemes distribuïts on coordinar a través de múltiples actors és intrínsecament complex.

Transactional és un concepte comú en les bases de dades, on múltiples canvis s’apliquen atòmicament per mantenir la consistència. En xarxes (un sistema distribuït), la transaccionalitat és fins i tot més complicada, però no és un problema nou. El 2006, NETCONF (RFC 6241) va introduir el commit a nivell de xarxa que aplica canvis globalment a través de múltiples dispositius o reverteix completament si la validació falla. Aquesta Atomic Operation prevé estats parcials on alguns dispositius s’han actualitzat però altres no: un escenari de malson per a la resolució de problemes. Tanmateix, no totes les plataformes suporten NETCONF, i la complexitat d’integració varia significativament. Així que, tot i que el problema està resolt en teoria, la implementació pràctica depèn de la teva infraestructura.

Proporcionar comportament transaccional prevé operacions parcials o trencades (que són difícils de resoldre i deixen els sistemes en estats impredictibles) i és essencial per evitar erosionar la confiança en la teva automatització. Una xarxa on alguns dispositius van aplicar un canvi i altres no és pitjor que una xarxa que va revertir completament.

Llavors, en general, com podríem aplicar la transaccionalitat a les xarxes? És una combinació de tècniques:

• NETCONF: Capacitats de gestió de xarxa que suporten la coordinació de gestió distribuïda. Però el suport és molt limitat.
• Transaccions recolzades per base de dades: Emmagatzema els canvis de configuració en una base de dades amb propietats ACID, després aplica’ls en lots coordinats amb capacitat de Rollback.
• Cues de notificació de canvis: Captura tots els canvis previstos, valida’ls com a grup, després executa amb un mecanisme de Rollback coordinat si algun dispositiu falla.
• Patrons de commit en dues fases: Prepara els canvis en tots els dispositius primer (fase 1), després confirma’ls simultàniament (fase 2), amb Rollback si la fase 2 falla en qualsevol dispositiu.
• Registres transaccionals: Registra cada intent de canvi amb suficient detall per desfer operacions parcials manual o automàticament.

Tingues en compte que tots els mecanismes en un entorn distribuït requereixen una capacitat de reversió per proporcionar un rollback sense problemes. Necessites un commit o snapshot que pugui activar-se (interna o externament a la plataforma) per passar a un estat anterior. Això no sempre està disponible. On no estan disponibles els commits atòmics vertaders, implementa una etapa de “preparació” validada i usa un commit coordinat orquestrat o un desplegament per etapes per reduir el risc (usa-ho només quan no hi hagi atomicitat nativa disponible).

Aquest principi es connecta naturalment amb Versioning: quan alguna cosa va malament, necessites saber exactament en quin estat estàs per poder revertir a una versió coneguda com a bona.

2.2.4. Versionat#

Per què importa el versionat: Cada canvi comporta risc. El versionat et permet saber exactament què va canviar, quan va canviar, qui ho va canviar i proporciona la capacitat de revertir si és necessari. És la base de les operacions segures a escala.

Històricament, l’enginyeria de xarxes va gestionar els canvis a través de còpies de seguretat de configuració: instantànies utilitzades per a finalitats de reversió. Tanmateix, reconciliar l’estat posterior al canvi després d’una reversió és extremadament complex perquè les còpies de seguretat manquen de context.

En enginyeria de programari, Version Control System (VCS) com Git és una pràctica estàndard (no he treballat en cap entorn sense alguna forma de VCS). Aquests sistemes permeten:

• Col·laboració fàcil: Múltiples desenvolupadors contribueixen codi i poden avançar en diferents branques.
• Viatge en el temps: Tornar a punts anteriors en la història per entendre què va canviar i quan.
• Agrupació atòmica: Múltiples canvis de fitxer poden agrupar-se com una sola unitat.

Aplicar Versioning a l’automatització de xarxes proporciona beneficis significatius:

• Auditabilitat i Traçabilitat: Rastreja fàcilment qui va canviar què i quan, fent el sistema transparent.
• Col·laboració entre equips: Facilita la revisió de canvis i permet el desenvolupament d’automatització basat en equip.
• Atomic Operations: Els canvis relacionats en múltiples fitxers poden aplicar-se junts, prevenint estats parcials o incomplets.
• Integració amb CI/CD: Els pipelines automatitzats poden activar proves i validació quan es detecten canvis de codi.

Les plantilles de configuració són un exemple destacat de dades que es beneficien del versionat. Un únic canvi de plantilla impacta en totes les configuracions derivades de la xarxa, per la qual cosa el control de versions es torna essencial. En general, totes les dades s’han d’emmagatzemar de forma versionada. És comú tenir fitxers YAML o JavaScript Object Notation (JSON) versionats que modelen dades de qualsevol tipus, o dades amb relacions més complexes.

GitOps: Un patró emergent que porta el versionat més lluny: el repositori Git es converteix en l’única font de veritat, i un controlador compara contínuament el Desired State a Git amb l’Actual State a la xarxa, corregint automàticament la deriva. Està guanyant adopció en l’automatització de xarxes, especialment en entorns cloud-native i amb integració de Kubernetes.

El versionat proporciona l’historial i la traça d’auditoria. El següent principi garanteix que validem que els canvis funcionen correctament abans del desplegament.

2.2.5. Comprovable#

Per què importa la comprovabilitat: L’automatització a escala amplifica els errors. Un bug en un playbook que afecta un dispositiu és manejable. El mateix bug aplicat a 10.000 dispositius és un desastre. Les proves són la teva xarxa de seguretat abans de desplegar en producció.

Les proves són particularment desafiants en xarxes. Sovint no tens tota la xarxa (pensa en els peeerings BGP d’Internet, on no tens l’altre costat), o l’escala és prohibitiva (imagina provar un fabric de centre de dades amb milers de switches). Reproduir escenaris de prova reals pot ser gairebé impossible o prohibitivament car.

Això no significa que et quedis sense opcions. Pots implementar proves en múltiples nivells que validen el comportament de l’automatització i l’estat de la xarxa sota diverses circumstàncies.

La piràmide de proves proporciona un marc útil:

graph BT
  %% Unit tests (base)
  U1["Proves Unitàries<br/>(Qualitat de Dades, Lògica)"]:::unit

  %% Integration tests
  I1["Proves d'Integració<br/>(Entorn Simulat)"]:::integration

  %% End-to-end tests (top)
  E1["Proves End-to-End<br/>(Laboratori, Validació)"]:::enduser

  %% Links
  U1 --> I1
  I1 --> E1

  %% Styling
  classDef unit fill:#a6e3a1,stroke:#3b7a57,stroke-width:2px,color:#000;
  classDef integration fill:#89b4fa,stroke:#1e3a8a,stroke-width:2px,color:#000;
  classDef enduser fill:#f9e2af,stroke:#b8860b,stroke-width:2px,color:#000;

• Les Unit Test validen la qualitat de les dades, la lògica bàsica i els comportaments específics de forma aïllada usant mocks o sistemes falsos. S’executen ràpidament i detecten errors fonamentals de forma primerenca.
• Les Integration Test introdueixen sistemes de tercers en un entorn simulat (i simplificat). Diferents components d’automatització interactuen entre ells i amb versions de xarxa simulades, permetent-te validar els punts d’integració (per exemple, simulant la interfície Application Programming Interface (API) o Secure Shell (SSH) Command Line Interface (CLI) d’un dispositiu de xarxa).
• Les End-to-End Test validen el comportament en escenaris gairebé reals usant entorns de xarxa virtualitzats o laboratoris que simulen part de la teva xarxa de producció (aprofundirem en aquest tema al Capítol 9).

Els assistents de codi d’IA són cada vegada més útils per a la generació de proves. Si pots articular què provar, aquestes eines poden ajudar a crear suites de proves completes ràpidament (i detectar fallades lògiques que potser no notes a primera vista).

La visió crítica: l’automatització requereix proves contínues per garantir que res es trenqui a mesura que els sistemes creixen. Una regressió introduïda tard en el desenvolupament és molt més cara que una detectada durant les proves unitàries. A mesura que la teva automatització escala, això es torna innegociable.

Estratègies de Proves Avançades:

• Enginyeria del Caos: Injecta fallades intencionalment (interrupcions de dispositius, latència de xarxa) per validar que la teva automatització i monitoratge les gestionen correctament (Netflix va popularitzar aquest enfocament amb el seu Chaos Monkey).
• Proves Basades en Propietats: Defineix propietats que sempre han de ser certes (per exemple, “BGP sempre ha de convergir en 30 segons”) i deixa que els frameworks de proves generin escenaris per verificar-les.

Finalment, abans de desplegar qualsevol canvi, els operadors necessiten visibilitat sobre el que passarà.

2.2.6. Simulació Prèvia (Dry-Run)#

Per què importa la capacitat de simulació prèvia: Fins i tot amb totes les salvaguardes anteriors, els humans necessiten entendre què farà l’automatització abans que s’executi. La capacitat de dry-run tendeix un pont entre la confiança i l’acció: mostra als operadors exactament què canviarà abans que es realitzi qualsevol canvi.

En qualsevol decisió important, entendre el pla d’acció abans de l’execució és crític. En construir una casa, vols veure com quedarà abans d’aprovar la construcció. De manera similar, en l’enginyeria de xarxes, estem acostumats als processos de gestió de canvis que revisen els plans d’execució abans del desplegament.

Amb l’automatització de xarxes, la freqüència i l’abast dels canvis poden augmentar dramàticament. Proporcionar als operadors una visibilitat clara del que s’executarà abans que ocorri és essencial per generar confiança i permetre una revisió adequada.

Hi ha eines que proporcionen aquesta capacitat de Dry Run, però sempre pots crear la teva pròpia si és necessari:

• Ansible: Els flags --check i --diff mostren què canviaria.
• Terraform: L’ordre terraform plan mostra la diferència entre l’estat actual i el Desired State.
• APIs de Xarxa Personalitzades: Algunes poden exposar un mode “dry-run” o vista prèvia.

Aquí hi ha un exemple de com es veu aquesta visibilitat:

Sortida de Diff d’Ansible

- description: Uplink to CoreSwitch1
+ description: Uplink to CoreSwitch2
  mtu: 9216

Sortida del Pla de Terraform

~ description = "Uplink to CoreSwitch1" -> "Uplink to CoreSwitch2"
  mtu          = 9216

Resposta de Vista Prèvia d’API de Xarxa Personalitzada

{
  "operation": "PATCH",
  "path": "/interfaces/Gi0-1",
  "changes": [
    {
      "field": "description",
      "current_value": "Uplink to CoreSwitch1",
      "proposed_value": "Uplink to CoreSwitch2",
    }
  ],
  "mtu": 9216
}

Les simulacions prèvies transformen l’automatització d’un enfocament d’“esperar el millor” en un procés deliberat i revisable.

Conceptes Avançats de Dry-Run:

• Anàlisi d’Impacte: Més enllà de mostrar què canvia, analitzar i comunicar l’impacte en el negoci (per exemple, “Això afectarà temporalment el 10% del trànsit”).
• Desplegaments per Etapes: Implementar dry-run a escala desplegant canvis gradualment a un subconjunt de dispositius primer, validant l’impacte abans del desplegament complet.
• Simulació de Xarxa: Combinar amb eines de proves de xarxa per executar dry-runs contra una rèplica de la teva xarxa de producció.

2.3. Patrons de Decisió Arquitectònica#

Més enllà dels principis fonamentals, hi ha conceptes clau i consideracions que connecten la teoria amb la implementació pràctica. Aquests patrons t’ajuden a prendre decisions estratègiques sobre la teva arquitectura d’automatització.

2.3.1. Declaratiu vs. Imperatiu#

L’elecció entre enfocaments declaratius i imperatius és fonamental. Cadascun té fortaleses i compensacions, depenent del cas d’ús. Gestionar la configuració d’infraestructura pot prendre dos enfocaments:

• L’automatització Declarative defineix l’estat final desitjat; el sistema determina com aconseguir-ho. Exemple: “Vull que la interfície Gi0/1 tingui un MTU de 9000.” El motor d’automatització determina l’estat actual i aplica només els canvis necessaris. Se centra en QUÈ, els resultats desitjats.
• L’automatització Imperative especifica els passos exactes a executar. Exemple: “Mostra la configuració de la interfície, analitza-la, calcula la diferència, envia aquestes ordres CLI exactes en aquest ordre.” Se centra en COM, les accions específiques.

Els enfocaments declaratius suporten naturalment Idempotency, capacitats de Dry Run i comportament Transactional, però requereixen infraestructura i sistemes que ho suportin.

Els enfocaments imperatius ofereixen un control precís però són més difícils de fer idempotents i més propensos a efectes secundaris no desitjats. Tanmateix, poden ser l’única opció quan el sistema objectiu manca de capacitats declaratives.

La compensació clau: els enfocaments declaratius escalen millor. Quan estan disponibles, la complexitat d’implementar fluxos de treball complexos roman constant, mentre que els enfocaments imperatius veuen com la complexitat creix exponencialment a mesura que els fluxos de treball es tornen més intricats.

La majoria dels frameworks d’automatització moderns (Terraform, Ansible, Kubernetes, o eines basades en Yet Another Next Generation (YANG)) tendeixen cap a models Declarative mentre permeten alternatives Imperative quan és necessari (per exemple, mòduls raw d’Ansible, Command Line Interface (CLI) directe, Netmiko).

Algunes eines com Ansible poden funcionar de les dues maneres depenent del tipus de mòdul. Els mòduls específics de xarxa (com cisco.ios.ios_interfaces) són declaratius, mentre que ansible.netcommon.cli_command executa ordres imperatives. En l’exemple a continuació, veuràs els dos enfocaments:

- name: Enfocaments Imperatiu vs. Declaratiu a Ansible
  hosts: switches
  gather_facts: no
  vars:
    interface_name: GigabitEthernet0/1
    new_description: Uplink to CoreSwitch2
  tasks:
    - name: Imperatiu - Executar ordres exactes
      ansible.netcommon.cli_command:
        command: |
          configure terminal
          interface {{ interface_name }}
          description {{ new_description }}
          no shutdown
          end
      # Repetir aquesta tasca pot afegir duplicats i falla la idempotència

    - name: Declaratiu - Definir l'estat desitjat
      cisco.ios.ios_interfaces:
        config:
          - name: "{{ interface_name }}"
            description: "{{ new_description }}"
            enabled: true
        state: merged
      # Repetir aquesta tasca és segur, convergeix a l'estat desitjat

Tingues en compte que amb un enfocament declaratiu, estàs descarregant la lògica a un sistema extern, i en alguns escenaris, això pot no ser una opció disponible. Observa en l’exemple anterior com aprofites un mòdul d’Ansible cisco.ios.ios_interfaces que implementa la lògica necessària per proporcionar el sabor declaratiu.

L’enfocament declaratiu és més segur i predictible, però requereix suport de mòduls per al teu dispositiu específic.

2.3.2. Infraestructura Mutable vs. Immutable#

El concepte: Permets modificacions in situ a la infraestructura (la xarxa), o reemplaces la infraestructura per complet quan es necessiten canvis?

• Infraestructura Mutable: L’enfocament tradicional on accedeixes per Secure Shell (SSH) als dispositius i modifiques les configuracions directament (o les modifiques a través de NETCONF, gNMI, o qualsevol Application Programming Interface (API)). Canvis aplicats in situ.
  • Pro: Menys disruptiu, menor sobrecàrrega.
  • Contra: Més difícil de rastrejar l’estat, augmenta el risc de Configuration Drift.
• Infraestructura Immutable: Mai modifiques la infraestructura en execució. En canvi, crees nova infraestructura amb els canvis desitjats i canvies el trànsit/connexions. S’usa molt al núvol (contenidors, VMs) però és menys comú en xarxes.
  • Pro: Estat predictible, més fàcil de verificar, elimina la deriva.
  • Contra: Requereix orquestració, recuperació més complexa, major sobrecàrrega de recursos.

En l’automatització de xarxes, generalment estem en un estat híbrid: les configuracions són mutables (les canviem in situ), però el principi d’immutabilitat hauria de guiar el teu disseny: versiona tot, rastreja els canvis i sigues capaç de reconstruir des de zero si és necessari.

2.3.3. Greenfield vs. Brownfield#

No és un terme tècnic, però és útil per entendre dos escenaris diferents en desenvolupar solucions d’automatització de xarxes:

• Els entorns Brownfield existeixen amb sistemes heretats, processos manuals, configuracions inconsistents i coneixement tribal. Són més difícils perquè estàs automatitzant una complexitat que mai va ser dissenyada per ser automatitzada: dissenys inconsistents, dades que falten, tecnologia heretada, hàbits humans i restriccions de trànsit en viu. Però és l’entorn més comú.
• Els entorns Greenfield es construeixen des de zero amb disseny automation-first. Pots implementar tots els principis de forma neta: control de versions des del primer dia, intenció declarativa, models de dades nets, proves exhaustives. Ideal però poc freqüent.

Aprofundim una mica més en per què els entorns brownfield són tan complicats…

• Dissenys de xarxa inconsistents (o si era consistent, ja no està completament implementat) i és només un munt d’excepcions juntes.
• Manca de dades netes i fiables. La xarxa en si mateixa o potser algun full de càlcul desactualitzat són les referències.
• Alguns dispositius de xarxa de diferents proveïdors i generacions no suporten interfícies modernes de gestió de xarxa (més enllà de CLIs) que limiten la implementació d’enfocaments declaratius.
• Cultura operacional i por al canvi. No oblidis que les persones són el primer, i necessites guanyar confiança abans de l’adopció.
• L’automatització ha de coexistir amb el trànsit en viu sense una transició neta. El marge d’error és mínim.

Tanmateix, encara hi ha esperança en aquests casos. Els tres enfocaments següents faciliten el començament amb aquests escenaris:

1. Enfocament de greenfield parcial: Automatitza la nova infraestructura mentre refactoritzis gradualment els sistemes heretats. Això mostra progrés sense començar amb la màxima complexitat.
2. Selecció incremental d’objectius: Centra’t en parts de la xarxa que són més fàcils d’automatitzar i proporcionen victòries ràpides:
   • Afegir detecció de deriva de configuració i remediació per a algunes característiques de gestió (AAA, NTP, SNMP).
   • Automatitzar l’aprovisionament d’interfícies per a un sol tipus de dispositiu.
   • Estandarditzar un únic subsistema abans d’expandir-se.
3. Construir impuls: Cada petita victòria demostra el valor de l’automatització i genera confiança per al finançament i l’expansió.

2.3.4. Diversitat de Dispositius i Abstracció de Serveis#

No tots els dispositius o serveis de xarxa funcionen de la mateixa manera. Diferents proveïdors, models i fins i tot versions de programari tenen interfícies, capacitats i limitacions úniques. La teva automatització ha d’abordar aquesta heterogeneïtat de forma estratègica.

Dos enfocaments principals:

• Abraçar l’Automatització Específica del Proveïdor: Escriu automatització adaptada a les capacitats úniques de cada proveïdor sense comprometre la reproducibilitat. Pros: més simple inicialment, aprofita les fortaleses del dispositiu. Contres: crea sitges, més difícil de migrar si els requisits canvien.
• Abstraure-ho: Crea una capa d’abstracció agnòstica al proveïdor que estandarditza les operacions comunes. Pros: portabilitat, interfície unificada. Contres: complexitat afegida, possible pèrdua de capacitats específiques del dispositiu.

Millor Pràctica: Enfocament per Capes La majoria de les operacions madures usen les dues: drivers específics del proveïdor a la part inferior (una capa per tipus de dispositiu), després una capa d’abstracció comuna per sobre. Això et dóna els beneficis de les dues estratègies.

El principi clau: separa els detalls d’implementació (com funcionen els dispositius específics) de l’objectiu final que vols aconseguir. Això permet la independència del proveïdor i simplifica el raonament sobre el teu sistema.

2.3.5. La Fal·làcia de les Eines sobre el Disseny#

Si bé les eines són essencials, no són un substitut del bon disseny. Un error comú: comprar una eina i esperar que resolgui els problemes d’automatització. Les eines importen, però amplien l’arquitectura i el disseny existents. Una estratègia d’automatització ben dissenyada amb una eina mediocre supera una estratègia mal dissenyada amb la millor eina disponible.

El disseny i l’arquitectura són estratègia i han d’anar primer. Les eines són detalls d’implementació. Inverteix temps en entendre els teus requisits, dissenyar la teva arquitectura i definir els teus principis abans de seleccionar eines. De vegades una arquitectura distribuïda és apropiada. Altres vegades una solució més simple i capaç s’adapta millor a les teves necessitats en termes de resultat versus complexitat. No hi ha una fórmula única, però has de reconèixer i ser intencional sobre les teves eleccions.

Recorda també que les eines no són caixes màgiques. Sempre has d’aportar la teva pròpia lògica. La personalització i la configuració específica del domini són inevitables.

Al Capítol 3, explorarem una arquitectura de referència que destaca els principals blocs de construcció que has de considerar en avaluar eines.

2.3.6. Comprar vs. Construir#

Una pregunta estratègica comuna: hauries de comprar una solució ja preparada, construir automatització personalitzada o usar un enfocament híbrid?

La regla simple: compra quan puguis, construeix quan hagis de fer-ho. Contraintuïtivament, construir és sovint més car que comprar. Però comprar el que necessites no sempre és possible.

En avaluar la decisió:

• Compra: Usa-ho quan un producte s’adapta estretament a les teves necessitats, suporta la teva arquitectura i l’anàlisi cost/benefici ho afavoreix.
• Construeix: Usa-ho quan els teus requisits són únics, tens l’experiència, o les solucions ja preparades no s’ajusten als teus principis.

Aquesta és fonamentalment una decisió de disseny, no d’adquisició. Es tracta de quanta personalització i control necessites realment.

En la pràctica, la majoria de les organitzacions usen un enfocament híbrid: compren components estratègics (plataformes d’orquestració, sistemes CI/CD, emmagatzematge de dades) però construeixen automatització específica del domini (plantilles, fluxos de treball, lògica de validació). Has de posseir la capa específica del domini: les receptes genèriques rarament lliuren els resultats que necessites.

En avaluar solucions de codi obert, considera l’extensibilitat. Sovint pots reutilitzar el framework i construir les teves pròpies capes personalitzades a sobre: per exemple, una font de dades per emmagatzemar la intenció de xarxa que estén l’eina principal amb models de dades personalitzats. A més, no oblidis que amb el codi obert, encara pots obtenir suport i edicions empresarials per afegir xarxes de seguretat quan sigui necessari.

2.3.7. Governança de l’Automatització#

Qui decideix què s’automatitza? Qui aprova un canvi en la lògica d’automatització? Qui pot autoritzar que una plantilla de treball s’executi contra mil dispositius en producció? Aquestes preguntes rarament tenen respostes tècniques clares, però s’han de respondre organitzacionalment abans que l’automatització arribi a qualsevol escala significativa.

L’automatització sense govern introdueix una classe diferent de risc que les operacions manuals. Un enginyer que comet un error manual afecta un dispositiu o una sessió. Un enginyer d’automatització que comet un error en una plantilla de playbook pot afectar tots els dispositius en abast simultàniament. El radi d’explosió escala amb la capacitat de l’automatització.

La governança en aquest context significa definir quatre coses:

• Límits d’abast: quines operacions són elegibles per a l’automatització i quines requereixen execució humana independentment de la maduresa de l’automatització. Els canvis de política BGP, les modificacions de protocols d’encaminament o les actualitzacions de polítiques de seguretat poden romandre amb supervisió humana fins i tot quan la resta de la pila està automatitzada, no perquè l’automatització no pugui fer-los, sinó perquè les conseqüències de l’error són prou grans com per justificar un humà en el procés.

• Procés d’aprovació de lògica: els canvis en la lògica d’automatització (nous playbooks, plantilles modificades, models de dades actualitzats al SoT) han de passar per un procés de revisió equivalent a una revisió de codi de programari. La disciplina aquí reflecteix l’enginyeria de programari: els canvis en el codi que s’executa en producció requereixen revisió abans d’arribar a producció. El codi d’automatització no és diferent.

• Autorització d’execució: qui pot executar quin treball, contra quin abast, sota quines condicions. Això es mapeja directament al control d’accés basat en rols a la capa d’Execució (Capítol 5) i la capa de Presentació (Capítol 8). El model de governança ha d’expressar-se en els controls d’accés de les eines, no només en un document de política.

• Auditoria i responsabilitat: l’automatització ha de produir el mateix registre d’auditoria que produeix la gestió manual de canvis. Un esdeveniment d’execució ha de ser traçable a un tiquet de canvi, un aprovador i una versió específica de la lògica d’automatització que es va executar. Això no és opcional en entorns regulats.

La governança no és burocràcia per si mateixa. És el mecanisme pel qual les organitzacions estenen la confiança a l’automatització de forma incremental. Començar amb operacions de baix risc, reversibles i ben enteses i expandir l’abast a mesura que l’automatització guanya un historial és més efectiu que bloquejar l’automatització per complet o desplegar-la sense barreres de protecció.

2.3.8. Per Què Importen Aquests Principis: Aprenent de les Fallades#

L’automatització amplifica el que li alimentes. Els processos nets i ben dissenyats es tornen més eficients i fiables. Però el disseny deficient, les dades dolentes o la lògica defectuosa també escalen, creant problemes més grans més ràpid.

Mapeant als Principis: Cadascun dels nostres sis principis de disseny principals aborda directament una d’aquestes fallades. Això demostra que no són opcionals: són salvaguardes essencials.

La Lliçó: No automatitzis el caos esperant arreglar-lo més tard. En canvi:

1. Comença amb processos que entens i pots validar.
2. Automatitza incrementalment, aprenent de cada pas.
3. Tracta cada fallada d’automatització com una oportunitat d’aprenentatge.
4. Incorpora salvaguardes: límits de velocitat, mecanismes de reversió, observabilitat, contenció del radi d’explosió.
5. Separa les responsabilitats perquè les fallades en una àrea no es propaguin globalment.

Observa com això es connecta amb l’enfocament de Persones, Procés i Tecnologia introduït al Capítol 1.

Els principis que hem explorat (Intent-Driven, Idempotency, Transactional, Versioning, comprovabilitat i capacitat de Dry Run) aborden directament aquests modes de fallada. No són característiques opcionals; són salvaguardes essencials que han d’incorporar-se des del principi.

2.4. Principis d’Enginyeria de Programari#

A més dels principis de disseny específics de xarxes, els principis més amplis d’enginyeria de programari juguen un paper crucial en la construcció de sistemes d’automatització mantenibles i escalables. Si véns d’un entorn d’enginyeria de programari, reconeixeràs la majoria d’aquests; el valor aquí és veure com s’apliquen específicament a l’automatització de xarxes.

No tots els dotze tenen el mateix pes en aquest domini. Quatre aborden modes de fallada específics de l’automatització d’infraestructura crítica: Principi de Mínima Sorpresa (l’automatització que es comporta de forma inesperada destrueix la confiança operacional establerta a la secció 2.1 abans que pugui arrelar), Programació Defensiva i Robusta (les xarxes fallen de formes parcials i no deterministes que l’automatització ha d’anticipar per disseny, no gestionar com a excepcions), Fallar Ràpid, Fallar Visible (la detecció primerenca de fallades conté el radi d’explosió abans que escali a través dels dispositius), i Separació de Responsabilitats (el principi estructural que el marc NAF al Capítol 3 instancia directament, separar la intenció, la lògica d’execució i la presentació no és una bona pràctica genèrica aquí, és l’estructura específica que manté els blocs independentment evolucionables). Els vuit principis restants són higiene estàndard de programari: correctes, importants i dignes de conèixer, però no la raó per la qual l’automatització de xarxes específicament falla o té èxit.

Els organitzem en dues categories seguint la inspiració de Robert C. Martin “Clean Code” i “Clean Architecture”:

• Principis de Codi Net: Com escriure lògica d’automatització que sigui llegible, mantenible i correcta.
• Principis d’Arquitectura Neta: Com estructurar els sistemes perquè els components romanguin independents, comprovables i evolucionables.

Centrant-se en aplicar-los a l’automatització de xarxes, pots trobar bons exemples d’aquests principis en aquesta sèrie de blog de Network to Code de Ken Celenza.

2.4.1. Principis de Codi Net#

En aquesta secció, el focus és en com es construeixen els components de programari.

Escriu Codi per als Lectors

El codi que escrius serà llegit moltes vegades en el futur: per tu mateix (en depurar) o per altres. I probablement no tindran el teu context original. Expressa la teva intenció clarament en el codi a través de noms significatius, comentaris i estructura (si us plau, no abussis dels comentaris; usa’ls amb cura). El codi d’automatització no són només instruccions per a les màquines; és una forma de documentació per als humans.

DRY – Don’t Repeat Yourself (No et Repeteixis)

Evita duplicar la lògica en el teu codi d’automatització. En canvi, extreu els patrons comuns en plantilles, funcions o fluxos de treball reutilitzables.

En lloc d’escriure lògica de configuració específica del dispositiu en deu playbooks diferents, crea una plantilla compartida amb variables per a les diferències. Això redueix els errors i facilita les actualitzacions. Aquest principi també s’aplica a les dades: usa estructures de dades adequades aprofitant l’herència i el polimorfisme per crear models de dades més escalables i reutilitzables.

Quan violes DRY, una correcció en un lloc requereix correccions en altres cinc, i inevitablement en perdràs un.

Principi de Responsabilitat Única (SRP)

Cada mòdul, funció o flux de treball ha de tenir una raó per canviar. En l’automatització de xarxes, això significa:

• Un renderitzador de plantilles de configuració no hauria de gestionar també el descobriment de dispositius.
• Un flux de treball de validació no hauria d’executar també canvis.

Quan cada component té una única responsabilitat, les fallades estan aïllades, les proves són més simples i els canvis són menys arriscats. Òbviament, hi haurà una funció de composició (o orquestració) per connectar totes aquestes funcions.

Fallar Ràpid, Fallar Visible

Detecta els problemes el més aviat possible i exposa’ls clarament. En automatització:

• Valida les dades immediatament en rebre-les (no esperes fins al desplegament).
• Fes que la sortida de Dry Run sigui explícita i òbvia.
• Registra les fallades amb context complet, no amb codis d’error vagos.
• Alerta als operadors immediatament quan alguna cosa va malament.

Detectar els problemes aviat redueix el radi d’explosió i el temps de resposta.

Seguretat

El xifratge, l’autenticació, el mínim privilegi i els registres d’auditoria han d’estar incorporats en els sistemes d’automatització des del principi, no afegits posteriorment.

En l’automatització de xarxes: cada canvi ha de ser auditable, les credencials mai han d’estar codificades en dur, i el control d’accés ha de seguir el principi de mínim privilegi. Un únic sistema d’automatització amb accés complet a la xarxa és un desastre de seguretat esperant ocórrer.

Aprofundirem en les consideracions de seguretat i compliment al Capítol 12.

Principi de Mínima Sorpresa

L’automatització ha de comportar-se de la manera que els usuaris esperen. El comportament sorprenent o contraintuïtiu erosiona la confiança.

Per exemple, si una tasca d’automatització es diu “deploy_interface”, els operadors esperen que creï una interfície, no que l’elimini. El comportament inesperat frustra els usuaris i causa errors.

Programació Defensiva i Robusta

Incorpora reintents, patrons de Circuit Breaker, Compensation Logic i mecanismes de resposta alternativa. Els sistemes distribuïts fallen. Dissenya per a això en lloc de contra això. Si un dispositiu és temporalment inaccessible, reintenta amb retrocés exponencial en lloc de fallar immediatament. Si un canvi falla a mig camí, tingues un pla de reversió.

En l’automatització de xarxes:

• Enviament conservador: Assegura’t que les dades que envies a les APIs o dispositius s’adhereixen a esquemes i contractes estrictes.
• Acceptació liberal: Estigues preparat per gestionar variacions (per exemple, atributs com a enters o cadenes amb conversió) per maximitzar la interoperabilitat amb diferents versions del sistema.

Aquest principi connecta el codi net amb l’arquitectura. Afecta tant com escrius la lògica d’integració com com estructures les interfícies del sistema.

2.4.2. Principis d’Arquitectura Neta#

A continuació, explorem els principis que governen com els components d’una solució d’automatització de xarxes s’uneixen.

KISS – Keep It Simple, Stupid (Mantén-ho Simple)

El més simple és més fàcil d’entendre, provar i mantenir. Evita la sobre-enginyeria de solucions en disseny, implementació i arquitectura. La simplicitat redueix els errors, augmenta la mantenibilitat, millora la llegibilitat i fa els sistemes més fàcils d’estendre o depurar.

Simple no significa simplista. Significa triar l’enfocament més directe que satisfà els requisits sense sobre-enginyeria o afegir abstraccions prematures.

En l’automatització de xarxes, això significa preferir enfocaments Declarative directes sobre scripts imperatius complexos (quan sigui possible), prioritzant la claredat, els components petits i composables, el comportament predictible i les solucions que poden ser fàcilment enteses per altres (inclòs el teu jo futur).

Separació de Responsabilitats

Separa clarament les dades (configuració), la lògica (fluxos de treball) i la presentació (APIs/UIs). Això prevé l’acoblament estret i permet l’evolució independent de cada capa.

En l’automatització de xarxes:

• Capa de dades: Intenció de xarxa emmagatzemada de forma estructurada.
• Capa de lògica: Motors d’automatització i regles de validació.
• Capa de presentació: APIs, CLIs, dashboards per a operadors.

Aquesta separació et permet canviar com els operadors interactuen amb l’automatització sense afectar la lògica subjacent. Aquesta separació es mapeja directament als blocs de construcció NAF: la capa de dades és la Font de Veritat (Capítol 4), la capa de lògica abasta Execució (Capítol 5), Observabilitat (Capítol 6) i Orquestració (Capítol 7), i la capa de Presentació és el Capítol 8. El Capítol 3 introdueix el marc NAF complet.

Observabilitat

L’automatització ha d’estar instrumentada per mesurar el seu propi comportament, detectar fallades i activar accions correctives. No pots optimitzar el que no pots mesurar. Rastreja tant les mètriques tècniques com les orientades al negoci (per exemple, el ROI de les iniciatives d’automatització).

Al Capítol 6, cobrirem els diferents tipus de dades d’observabilitat que ens importen en xarxes: mètriques, registres, traces, fluxos de xarxa, alertes (i molts més!), i com aprofitar-los per proporcionar informació útil a tots els nivells.

Sense observabilitat, estàs volant a cegues. No sabràs si l’automatització està funcionant correctament o només aparentant funcionar. Recorda: els sistemes d’automatització també fallen i necessiten monitoratge. Instrumenta les teves eines d’automatització tan a fons com instrumentes la xarxa.

Extensibilitat

Dissenya amb el futur en ment. Arribaran nous proveïdors, noves tecnologies i nous requisits. L’arquitectura ha de permetre aquests sense requerir reescriptures completes.

En la pràctica: usa arquitectures de plugins per als drivers específics del proveïdor, evita les suposicions codificades en dur sobre la topologia de xarxa, i manté les interfícies estables mentre les implementacions evolucionen.

Acoblament Mínim, Cohesió Màxima

Defineix contractes clars per com es comuniquen els sistemes: esquemes, regles de validació i polítiques de compatibilitat cap enrere. Aquests contractes permeten l’evolució independent dels components.

En l’automatització de xarxes, si el teu sistema d’orquestració parla amb els teus drivers de dispositius a través d’una API REST ben definida, qualsevol de les capes pot evolucionar de forma independent sempre que es mantingui el contracte de l’API.

Aborda sempre cada sistema amb un Disseny API-First: dissenya les APIs primer (no les implementacions). Això garanteix que els sistemes puguin desenvolupar-se de forma independent i intercanviar-se sense trencar altres components.

Aquests principis avançats s’exploraran amb major profunditat en capítols posteriors a mesura que discutim l’escalat de l’automatització en organitzacions grans (i més petites). Per ara, entén que aquests principis complementen els principis de disseny que vam explorar anteriorment: junts, formen la base per a una automatització de xarxes de confiança, mantenible i a escala.

2.5. Resum#

Aquest capítol va establir que la confiança és la base de l’automatització de xarxes exitosa. La confiança emergeix de quatre qualitats principals: Predictable, Reliable, Usable i Understandable.

Aquestes qualitats estan recolzades per sis principis de disseny fonamentals:

1. Basat en Intenció: Defineix què vols aconseguir abans de com aconseguir-ho.
2. Idempotent: Les execucions repetides produeixen resultats consistents.
3. Transaccional: Els canvis es completen totalment o fallen de forma segura, mai parcialment.
4. Versionat: Rastreja tots els canvis amb historial complet i registres d’auditoria.
5. Comprovable: Valida el comportament abans de desplegar en producció.
6. Dry-Run Friendly: Vista prèvia dels canvis abans de l’execució.

Més enllà d’aquests principis fonamentals, vam explorar patrons de decisió arquitectònica (declaratiu vs. imperatiu, greenfield vs. brownfield, abstracció de dispositius) i principis d’enginyeria de programari (codi net i arquitectura neta) que operacionalitzen aquests patrons en sistemes reals.

Aquests principis no són teoria abstracta: tenen implementacions concretes en eines i frameworks que usaràs. Al llarg de la resta d’aquest llibre, veurem com el pensament arquitectònic (Capítol 3) aplica aquests principis a sistemes més grans, i com els blocs de construcció (Capítols 4-9) els operacionalitzen.

Les conclusions clau:

• Comença amb principis, no amb eines.
• Dissenya per a resultats Predictable, no per a la complexitat.
• Mesura i millora contínuament.

Quan fas això de forma consistent, la confiança segueix naturalment, i amb la confiança arriba la capacitat d’escalar l’automatització en tota la teva organització.

Ara entens els principis que fan que l’automatització sigui de confiança. Al Capítol 3 (Pensament Arquitectònic), veurem com estructurar aquests principis en sistemes escalables. Aprendràs com dissenyar automatització que creix amb la teva organització sense tornar-se inmanejable: una vista pràctica i arquitectònica de com aplicar sistemàticament els principis que has après aquí.

💬 Found something to improve? Send feedback for this chapter