Automatisation des opérations avec Systems Manager

Les sujets précédents construisaient et livraient de l'infrastructure. Celui-ci parle des serveurs déjà en marche et du travail qui ne s'arrête jamais : les atteindre, les patcher, tenir leur configuration en place, et automatiser les parties de la semaine qui se répètent. C'est aussi le sujet où une seule fondation porte tout le reste, puisque aucun outil Systems Manager ne fonctionne tant qu'une instance n'est pas un nœud géré, et que la plupart des pannes dans ce domaine sont cette unique condition non remplie.

Ce que couvre ce sujet

• Les 3 conditions qui font d'une instance EC2 un nœud géré, et l'ordre de diagnostic qui trouve la condition cassée le plus vite
• Instance profile ou Default Host Management Configuration, dont la permission qui fait silencieusement gagner l'un sur l'autre
• Session Manager en remplacement des clés SSH et des bastions, et les sessions que sa journalisation n'atteint pas
• Le ciblage Run Command par ID, par tag et par resource group, avec les valeurs par défaut de concurrence et de seuil d'erreur qui décident du comportement d'une commande sur toute la flotte
• Fleet Manager et Inventory, et la resource data sync qui rend l'inventaire interrogeable à travers les comptes
• Patch Manager : Scan ou Install, les règles d'approbation d'un baseline et le délai de 7 jours, la résolution du baseline par patch group, et les états de conformité avec l'option de redémarrage derrière eux
• Les maintenance windows avec durée et cutoff, les patch policies pour une organisation, et les associations State Manager pour une configuration qui se remet en place
• Parameter Store : les 3 types, les hiérarchies et le piège IAM des chemins, les tiers, les policies, les versions et les labels, le plafond de 40 TPS, et les dynamic references CloudFormation
• Les S3 Event Notifications, EventBridge Scheduler, et le choix de l'endroit où doit vivre un calendrier opérationnel
• Change Calendar, le garde-fou qui dit à une automatisation en marche de se tenir tranquille

Pourquoi c'est important

Le domaine 3 pèse 22 % du SOA-C03, et ce sujet fournit les questions qui ressemblent à un ticket de support plutôt qu'à un exercice de conception : une instance qui refuse d'apparaître dans la console, un patch sorti hier qui ne s'est pas installé, un nœud qui se déclare conforme alors qu'un patch critique manque, une application limitée en débit sur ses lectures de configuration dès qu'elle monte en charge. Chacune a un réglage précis derrière elle.

Sur le terrain, la pression a la même forme. Ce qui sépare une équipe d'exploitation qui passe à l'échelle d'une équipe qui plafonne, c'est de savoir si le travail courant est décrit une fois et appliqué par un service, ou exécuté par une personne qui doit s'en souvenir.