La Marta Ríos va fer l'exercici d'anotar en què se li n'anava la setmana. El resultat incomoda: apagar i encendre els entorns de desenvolupament, esborrar instantànies de discos que ja ningú no recorda, revisar quins certificats són a punt de caducar, rotar credencials, exportar un informe de recursos sense etiquetar i aplicar pedaços a les màquines. Res d'això és difícil, res requereix criteri, i tot s'ha de fer. Són hores d'un perfil sènior dedicades a tasques que una màquina executaria millor, sempre igual i sense oblidar-se'n.

Amb la plataforma ja observable després de les tres lliçons anteriors, toca automatitzar l'operació. Azure Automation és el servei que executa scripts programats o disparats per esdeveniments, amb identitat pròpia, sense servidor per mantenir i amb registre de tot el que fa. En aquesta lliçó construiràs el compte d'automatització de Contoso, escriuràs el runbook que apaga els entorns de desenvolupament a la nit, el connectaràs amb les alertes de 07-01 i veuràs on acaba Automation i on comencen Azure Update Manager i Machine Configuration.

1. Què és Azure Automation i els seus components
2. Tipus de runbook i quin triar
3. Crear aa-contoso-operaciones amb identitat administrada
4. El runbook estrella: apagar i encendre per etiqueta
5. Programacions, proves, control de codi font i publicació
6. Disparar un runbook des d'una alerta: runbook, Logic App o funció
7. Gestió d'actualitzacions amb Azure Update Manager
8. Configuració d'estat desitjat i Machine Configuration
9. Azure Resource Graph: inventari a escala
10. Costos i bones pràctiques de runbooks
11. Errors Comuns i Consells
12. Exercicis
13. Conclusió

Azure Automation és un servei administrat que executa scripts —anomenats runbooks— en infraestructura de Microsoft, sota una identitat pròpia i amb un registre complet de cada execució. No cal aprovisionar ni apedaçar res. Les seves peces:

L'Hybrid Runbook Worker mereix una nota. Un runbook normal s'executa al núvol d'Azure i només arriba al que sigui accessible des d'internet o per xarxa privada. Els servidors de facturació de taulells que Contoso conserva a Barcelona no ho són. Instal·lant l'agent en una d'aquestes màquines, el mateix runbook s'executa dins de la xarxa local, amb accés a recursos interns, però programat i auditat des d'Azure. És la via per automatitzar el que és local sense obrir res cap enfora, i encaixa amb la connectivitat híbrida del mòdul 2.

La recomanació és directa: PowerShell llevat de motiu de pes. Els mòduls Az cobreixen tot Azure, la sintaxi és la mateixa que a Cloud Shell (mòdul 1) i el resultat és un fitxer de text que es revisa en un pull request. Els runbooks gràfics semblen còmodes i no ho són: no es poden comparar a Git, no es revisen bé i no es reutilitzen.

El compte necessita permisos per actuar sobre els recursos. La manera correcta —i l'única acceptable en producció— és una identitat administrada assignada pel sistema, amb els permisos mínims i en l'àmbit mínim, aplicant l'RBAC del mòdul 4.

Tres decisions que convé raonar. L'àmbit és rg-contoso-reservas-dev, no la subscripció: una fallada o un abús del runbook no pot tocar producció, per construcció. El rol és el més específic que serveix, mai Colaborador a nivell de subscripció, i menys encara Propietario —que a més permetria a la identitat concedir-se més permisos—. I la identitat és administrada, sense secrets per rotar ni que es puguin filtrar; els comptes d'execució clàssics basats en certificat estan retirats.

Després cal importar els mòduls necessaris (Az.Accounts, Az.Compute, Az.Resources) i fixar la versió de l'entorn d'execució. Una actualització automàtica de mòduls pot canviar el comportament d'un runbook que feia un any que funcionava; en producció, la versió es fixa i s'actualitza deliberadament.

Aquest és el runbook que més diners estalvia i el que millor il·lustra les bones pràctiques. Els recursos de desenvolupament etiquetats amb horario=laborable no han d'estar encesos de nit ni el cap de setmana: són unes 128 hores setmanals de les 168 possibles, i això és directament factura.

Els cinc punts numerats són les bones pràctiques que fan la diferència entre un script i un runbook de producció. Connect-AzAccount -Identity autentica sense ni un sol secret. La selecció per etiqueta en lloc de per llista de noms significa que una màquina nova s'incorpora sola només etiquetant-la —i reforça la política d'etiquetatge del mòdul 1—. La idempotència permet executar-lo dues vegades sense efectes estranys, cosa que importa molt quan el dispara un reintent. El try per màquina evita que una fallada aïllada deixi les quinze restants enceses. I el throw final fa que el treball aparegui com a fallit, condició sobre la qual es pot alertar. El paràmetre $Simulacio és la xarxa de seguretat en estrenar: s'executa primer en sec i es revisa la sortida.

Una advertència de cost important: aturar una màquina des del sistema operatiu no deixa de facturar. Només l'estat deallocated, que és el que produeix Stop-AzVM, allibera el còmput. És un error clàssic que fa que l'automatització no estalviï res.

El cicle de vida d'un runbook té un detall que sorprèn: existeix en esborrany i en publicat, i les programacions executen sempre la versió publicada. Editar sense publicar no canvia res en producció, cosa que és una protecció, no una nosa.

L'ordre correcte de treball és: escriure, provar al tauler de prova —que executa l'esborrany de manera interactiva i mostra la sortida en directe, ideal amb $Simulacio = $true—, publicar, i només llavors programar.

Les dues programacions de Contoso són diàries, de dilluns a divendres, en zona horària W. Europe Standard Time: sch-apagado-dev a les 20:00 amb el paràmetre Accio=Detener, i sch-encendido-dev a les 07:30 amb Accio=Iniciar. Els paràmetres s'associen al vincle entre programació i runbook, de manera que el mateix runbook serveix per a totes dues amb una sola base de codi. La zona horària no és un detall: una programació en UTC es desplaça una hora a l'estiu i l'equip arriba a les 8:00 amb les màquines apagades.

El control de codi font tanca el cercle amb el mòdul 5. El compte es connecta al repositori contoso-infra d'Azure Repos, carpeta /runbooks, i cada push a la branca principal sincronitza els runbooks. Les conseqüències són les que ja coneixes: revisió per pull request, historial de qui va canviar què, i possibilitat de revertir. Amb la sincronització activa, el portal deixa de ser el lloc on s'edita; editar-hi crea divergències que la sincronització següent trepitja.

A 07-01 vas crear ag-guardia-contoso i vas deixar anunciat que un grup d'accions pot executar un runbook. Aquí es tanca el cercle: l'alerta detecta, el runbook remeia.

El disparador és un webhook: una URL amb un testimoni d'un sol ús que es genera en crear-lo i no es pot tornar a consultar, per la qual cosa cal desar-la immediatament a kv-contoso-pro. El grup d'accions envia a aquesta URL l'esquema comú d'alertes, i el runbook el rep al paràmetre $WebhookData, del qual extreu quin recurs va disparar l'alerta:

Runbook, Logic App o funció? Totes tres poden reaccionar a una alerta, i l'elecció importa:

La regla que Contoso aplica: si la tasca manipula infraestructura d'Azure i l'escriuria un administrador, és un runbook. Si consisteix a encadenar sistemes i notificar persones, és una Logic App. Si és lògica de negoci amb requisits de latència, és una funció. I res no impedeix combinar-les: l'alerta de la cua dispara alhora un runbook que escala i una Logic App que avisa a Teams.

L'antiga solució de gestió d'actualitzacions integrada a Automation ha estat substituïda per Azure Update Manager, un servei independent que ja no requereix compte d'Automation ni àrea de treball, i que funciona igual per a màquines d'Azure i per a servidors habilitats per a Arc.

Les seves peces són tres: avaluació de l'estat de pedaços de cada màquina, implementació puntual sota demanda, i configuracions de manteniment, que són finestres recurrents amb el seu àmbit i la seva política de reinici.

Contoso manté dues configuracions: mc-contoso-dev-mensual, que apedaça vm-motor-disponibilidad-dev el segon dissabte de matinada, i mc-contoso-pro-mensual, més conservadora, per al sistema operatiu base de vmss-api-disponibilidad-pro. En un conjunt d'escalat l'estratègia preferible continua sent diferent: reemplaçar instàncies amb una imatge nova ja apedaçada en lloc d'apedaçar en calent, que és el que és coherent amb el bestiar davant de les mascotes del mòdul 2. I recorda coordinar la finestra amb una regla de processament d'alertes de 07-01 per no despertar ningú amb reinicis previstos.

Automation incloïa State Configuration (DSC), que defineix en codi l'estat que una màquina ha de tenir —quins serveis corren, quins paquets estan instal·lats, quines claus de registre— i el corregeix quan es desvia. Aquesta capacitat s'ha traslladat a Azure Machine Configuration, una extensió d'Azure Policy: en lloc de viure al compte d'Automation, s'assigna com una directiva més dins de la iniciativa «Base de governança de Contoso» del mòdul 4, i el seu compliment apareix al costat de la resta al tauler de governança.

La diferència conceptual amb Automation és la que convé retenir: un runbook executa una acció en un moment donat; Machine Configuration vigila i manté un estat de manera contínua. Contoso ho fa servir per exigir que a tots els servidors hi hagi l'agent d'Azure Monitor instal·lat i determinats serveis aturats, sense escriure ni un runbook.

Abans d'automatitzar cal saber sobre què. Azure Resource Graph consulta amb KQL les metadades de tots els recursos de totes les subscripcions en segons, cosa que amb az resource list recorrent grups trigaria minuts i esgotaria els límits de l'API. És el complement natural d'Automation: el runbook actua, Resource Graph decideix sobre què.

La consulta es llegeix igual que el KQL de 07-02, amb dues diferències: la taula Resources conté la configuració dels recursos, no els seus registres, i no hi ha TimeGenerated perquè descriu l'estat actual, no una sèrie temporal. El seu valor aquí és concret: la columna Etiquetada llista exactament les màquines de desenvolupament que no porten horario i que, per tant, el runbook està ignorant i continuen enceses de nit. S'executa amb az graph query -q "<consulta>" o des d'un runbook amb Search-AzGraph.

El model de preus és dels més benignes d'Azure: es paguen els minuts d'execució dels treballs, amb una franja mensual gratuïta generosa —de l'ordre de 500 minuts— que cobreix de sobres un ús com el de Contoso, i els nodes gestionats per configuració d'estat, si se'n fan servir. El compte d'Automation en si no costa res. Posat en perspectiva: el runbook d'apagada consumeix uns pocs minuts al dia i estalvia el 75 % del cost de còmput d'un entorn complet. És probablement la millor relació de tota la plataforma, i hi tornaràs al mòdul 8.

Les bones pràctiques que separen un runbook fiable d'una bomba de rellotgeria:

• Idempotent: executar-lo dues vegades produeix el mateix resultat. Comprova l'estat abans d'actuar.
• Amb paràmetres, sense res codificat a foc: noms, grups i àmbits com a paràmetres o variables del compte.
• Amb mode de simulació: per estrenar-lo sense risc i per depurar.
• Amb registre estructurat: Write-Output amb un format constant, per poder consultar-lo amb KQL.
• Amb tractament d'errors per element: una fallada aïllada no ha d'abortar el lot, però sí reflectir-se a l'estat final.
• Acotat per àmbit i per etiqueta: mai a nivell de subscripció sencera «per comoditat».
• Versionat a Git, revisat per pull request i publicat des del repositori.

I la vigilància, que tanca amb el que has après: els treballs d'Automation envien el seu estat i la seva sortida a log-contoso-pro mitjançant una configuració de diagnòstic (categories JobLogs i JobStreams), de manera que es pot alertar sobre JobStatus == "Failed" amb una alerta de cerca de registres. Un runbook que falla en silenci és pitjor que no tenir runbook, perquè l'equip creu que la tasca s'està fent.

• Editar i no publicar. La programació executa la versió publicada; l'esborrany no canvia res.
• Aturar la VM des del sistema operatiu. Continua facturant: només Stop-AzVM l'allibera (deallocated).
• Permisos excessius. Colaborador a la subscripció per comoditat converteix una fallada del runbook en un incident de producció.
• Programació en UTC. El canvi d'hora desplaça l'encesa i l'equip es troba les màquines apagades.
• Runbooks sense vigilància. Sense alerta sobre treballs fallits, la tasca deixa de fer-se i ningú no se n'assabenta.
• Actualització automàtica de mòduls en producció. Pot trencar un runbook estable; fixa les versions.
• Consell: estrena tot runbook amb $Simulacio = $true i revisa la sortida abans de deixar-lo actuar.
• Consell: selecciona per etiqueta, mai per llista de noms. Les llistes envelleixen; les etiquetes es mantenen soles si la política les exigeix.
• Consell: desa el testimoni del webhook a kv-contoso-pro tan bon punt es generi. No hi ha manera de recuperar-lo després.

Exercici 1. Dissenya un runbook que elimini les instantànies de disc amb més de 90 dies a rg-contoso-reservas-dev, exceptuant les etiquetades amb conservar=si. Descriu paràmetres, salvaguardes, permisos, programació i vigilància. No cal el codi complet.

Exercici 2. El runbook d'apagada fa tres setmanes que s'executa «correctament», però la factura de desenvolupament no ha baixat. Enumera cinc causes possibles i com comprovar cadascuna.

Exercici 3. Contoso Millas (centro-coste=CC-2077) necessita, cada nit, exportar els bescanvis del dia a un fitxer, deixar-lo a stlagocontosopro i avisar l'equip financer. Decideix entre runbook, Logic App i funció —o combinació— i justifica l'arquitectura.

Solució 1: paràmetres $GrupRecursos, $DiesAntiguitat = 90, $EtiquetaExclusio = "conservar", $Simulacio = $true per defecte, perquè és una operació destructiva i el valor segur ha de ser el predeterminat. Salvaguardes: filtrar per antiguitat amb TimeCreated i excloure les etiquetades; limitar el nombre d'esborrats per execució —per exemple 50— perquè un error de filtre no arrasi amb tot; try per instantània; i registre del nom, la data i la mida de cadascuna abans d'esborrar-la, de manera que en quedi constància. Permisos: un rol acotat a rg-contoso-reservas-dev amb permís de lectura i esborrat d'instantànies, mai Colaborador de subscripció. Programació: setmanal, en cap de setmana, fora de la finestra de manteniment per no encavalcar-s'hi. Vigilància: alerta de cerca de registres sobre JobStatus == "Failed" i, a més, sobre un nombre d'esborrats anormalment alt, que és el senyal que el filtre s'ha trencat. I la salvaguarda de fons: comprovar que existeixen còpies de seguretat vigents abans de considerar prescindible una instantània, cosa que es tracta a 07-05.

Solució 2: (a) Les màquines s'estan aturant des del sistema operatiu o l'estat és stopped i no deallocated, amb la qual cosa el còmput es continua facturant; es comprova amb Get-AzVM -Status o amb Resource Graph mirant l'estat d'energia. (b) Falten etiquetes: hi ha màquines de desenvolupament sense horario=laborable que el runbook ignora; es detecta amb la consulta de Resource Graph de l'apartat 9. (c) El cost no és de còmput: els discos administrats, les IP públiques i les adreces reservades es facturen encara que la màquina estigui alliberada, i poden ser la major part de la despesa d'un entorn petit. (d) Algú encén les màquines i no les apaga, o hi ha un procés que les inicia; es verifica amb AzureActivity filtrant per l'operació d'inici i veient quina identitat l'executa. (e) La despesa és en un altre lloc: App Service, bases de dades o el mateix log-contoso-pro, que el runbook no toca; es confirma amb l'anàlisi de cost per recurs del mòdul 8. Comprovació transversal: revisar els registres de treballs a log-contoso-pro, perquè «s'executa correctament» pot voler dir que actua sobre zero màquines cada nit.

Solució 3: arquitectura combinada, amb cada peça en el que fa millor. Un runbook de PowerShell programat a les 23:30 executa la consulta KQL de bescanvis sobre log-contoso-pro amb Invoke-AzOperationalInsightsQuery, genera el fitxer CSV i el puja a stlagocontosopro autenticant-se amb la identitat administrada d'aa-contoso-operaciones; és l'opció correcta perquè és una tasca d'infraestructura, pot durar minuts i l'escriuria un administrador. La notificació la resol una Logic App que reacciona a un esdeveniment de blob creat —Event Grid, mòdul 6— i envia l'avís a Teams i per correu amb l'enllaç: és integració amb persones, no infraestructura, i l'equip financer pot demanar canvis al missatge sense tocar codi. No cal una funció: no hi ha lògica de negoci complexa ni requisit de latència. Permisos mínims: Lector de Log Analytics sobre l'àrea i Colaborador de datos de Storage Blob només sobre el contenidor de destinació. Vigilància: alerta sobre treballs fallits i una segona alerta si el fitxer no apareix abans de les 00:30, perquè un runbook que no s'executa no genera cap error. Etiquetes: entorno, proyecto=contoso-millas, centro-coste=CC-2077 i propietario.

Ja saps què és Azure Automation i per a què serveix: executar la feina repetitiva que consumia les setmanes de la Marta Ríos, sense servidors, amb identitat pròpia i amb registre de tot. Coneixes els seus components —compte, runbooks, programacions, treballs, variables, credencials, certificats, connexions i mòduls— i l'Hybrid Runbook Worker que porta la mateixa automatització als servidors locals de l'oficina de Barcelona. Saps triar el tipus de runbook, amb PowerShell com a opció per defecte i els gràfics descartats per no ser versionables. Has creat aa-contoso-operaciones amb identitat administrada i permisos mínims acotats a rg-contoso-reservas-dev, aplicant l'RBAC del mòdul 4 en lloc de repartir Colaborador per comoditat.

El runbook estrella t'ha deixat un patró complet i reutilitzable: autenticació sense secrets, selecció per etiqueta en comptes de per llista, idempotència comprovant l'estat abans d'actuar, mode de simulació per estrenar-lo sense risc, tractament d'errors per màquina, registre estructurat i throw final perquè el treball es marqui com a fallit i s'hi pugui alertar —a més del detall que decideix si l'automatització estalvia o no: només deallocated deixa de facturar—. Saps provar-lo al tauler de prova, publicar-lo —perquè la programació executa la versió publicada, no l'esborrany—, programar-lo amb la seva zona horària correcta i versionar-lo a contoso-infra amb control de codi font, tancant el cercle amb el mòdul 5.

Has tancat també el cercle amb 07-01: una alerta d'Azure Monitor dispara un runbook per webhook, amb el seu testimoni desat a kv-contoso-pro, i tens la taula de decisió per triar entre runbook, Logic App i funció segons si manipules infraestructura, integres sistemes o executes lògica de negoci. Situes Azure Update Manager com a successor de la gestió d'actualitzacions, amb les seves configuracions de manteniment mc-contoso-dev-mensual i mc-contoso-pro-mensual, i Machine Configuration com a hereu de DSC dins d'Azure Policy, amb la distinció clau: el runbook actua una vegada, la configuració manté un estat. I t'endus Azure Resource Graph com a instrument d'inventari a escala per saber sobre què automatitzar, més els costos per minut amb la seva franja gratuïta i les bones pràctiques que fan un runbook fiable.

Queda l'última peça, i és la que decideix si tota la resta serveix d'alguna cosa. Contoso té ara una plataforma que veu el que passa i que s'opera sola en bona mesura, però res d'això no respon a la pregunta del dia dolent: un esborrat accidental, un xifratge per ransomware, una regió sencera que deixa de respondre. La lliçó 07-05, Còpies de seguretat i recuperació davant desastres, tanca el mòdul amb els dos números que governen aquesta conversa —RPO i RTO—, Azure Backup i els seus magatzems, la protecció davant l'esborrat maliciós, què resguarda cada servei PaaS pel seu compte i què continua sent teu, Azure Site Recovery, l'estratègia entre West Europe i North Europe, i el pla escrit que s'ha de provar, perquè un pla no provat no existeix.