Gains :
- Capacité à produire des scripts d'automatisation Bash, PowerShell et Python avec des contraintes claires et des garde-fous de sécurité avec intelligence artificielle
- Possibilité d'ajouter des principes tels que l'idempotence, l'exécution à sec, la gestion des erreurs et la restauration à chaque script et d'appliquer le cycle « générer, renforcer, vérifier »
- Capacité à comprendre que l'exécution du script produit ne signifie pas qu'il est sûr et à acquérir l'habitude d'assumer ses responsabilités en lisant et en testant des lignes destructrices.
Scripts d'automatisation : générer Bash, PowerShell et Python en toute sécurité avec l'IA
Le pire ennemi de l'administrateur système est le travail manuel répétitif : se connecter à chaque machine et nettoyer les logs, ouvrir le même utilisateur sur vingt serveurs, faire le même bilan de santé tous les matins. Cette répétition est ouverte à la fois au temps et à l’erreur humaine. Un script d'automatisation est un petit programme qui délègue ces itérations à l'ordinateur. Le plus souvent écrit en Bash (langage de commande shell) dans le monde Linux, en PowerShell (shell d'automatisation de Microsoft) dans le monde Windows et en Python pour un travail indépendant de la plate-forme. L’IA est incroyablement rapide pour produire, expliquer et améliorer la première ébauche de ces scripts. Mais le script n’est pas un texte, c’est une force agissant dans votre système ; Contrairement à une formule Excel, si elle est incorrecte, elle supprime le fichier, arrête le service et coupe l'accès. C'est pourquoi la promesse de cette unité est la suivante : l'IA écrit le script, vous le lisez, le testez et l'exécutez en prenant vos responsabilités.
Dans cette unité, vous apprendrez à produire des scripts sûrs, lisibles et récupérables avec l'IA ; Principes vitaux tels que l'idempotence (exécuter deux fois le même script ne cause pas de dommages) et l'exécution à sec ; et vous apprendrez les vérifications qu'un script doit subir avant de le mettre en production.
Pourquoi les scripts avec l’IA sont-ils si puissants ?
Même un administrateur expérimenté peut ne pas connaître par cœur la syntaxe exacte d'une boucle Bash, les paramètres d'une applet de commande PowerShell (commande) ou d'un bloc try/sauf Python. L’IA comble cette lacune instantanément : vous expliquez l’intention en turc simple et elle produit un plan de travail. De plus, vous pouvez donner un script existant à l'IA et dire "expliquer ceci", "ajouter une gestion des erreurs", "le rendre plus lisible". Cela raccourcit la courbe d’apprentissage et met les membres juniors de l’équipe au courant.
Mais le pouvoir implique des responsabilités. La plupart du temps, un script généré par l’IA écrit correctement le « chemin heureux » (si tout va bien) ; mais il peut manquer des cas extrêmes (fichier manquant, disque plein, réseau en panne) ou faire des hypothèses dangereuses. Pensez donc à la génération de scripts avec l’IA en trois étapes : générer, durcir, vérifier.
Pas à pas : génération de scripts sécurisés
- Écrivez clairement l’intention et la contrainte. Quel système d'exploitation, quelle version du shell, quels chemins de fichiers, quels droits ? Comme "Ubuntu 22.04, Bash 5, sudo pas root, exécuté uniquement sous /opt/app/logs". Une demande ambiguë produit des hypothèses dangereuses.
- Demandez des garde-corps de sécurité. Exiger que le script « s'arrête en cas d'échec » (définir -euo pipefail dans Bash), demander la confirmation des opérations destructrices, la sauvegarde avant l'opération et le mode d'exécution à sec. Ces garde-corps capturent les états de bord que l’IA contourne.
- Écrivez idempotent. Le script ne doit provoquer aucune erreur ni aucun dommage lors de sa deuxième exécution. Etablir une logique de « sauter si l'utilisateur existe déjà », « créer le répertoire s'il n'existe pas, ne pas y toucher s'il existe ». Cela permet à l'automatisation de fonctionner en toute sécurité encore et encore.
- Lisez et comprenez. Lisez chaque ligne produite. Demandez à l'IA de marquer séparément les commandes destructrices (rm, Remove-Item, DROP).
- Testez avec un essai à sec. Tout d’abord, exécutez-le en mode « dire quoi faire » au lieu des opérations réelles. Si le résultat correspond à vos attentes, passez en mode réel – et d’abord sur la machine de test.
- Préparez votre retour. Le script effectue-t-il des sauvegardes ? Savez-vous comment restaurer la sauvegarde ? Y a-t-il une journalisation, pouvez-vous voir ce qu'il fait plus tard ?
Astuce : demandez à chaque script destructeur d'inclure une variable DRY_RUN=true et un indicateur --apply. Le comportement par défaut est d'écrire ce qui va se passer sans rien supprimer ; Ne laissez la suppression réelle fonctionner que si --apply est donné explicitement. Cette seule habitude évite les désastres qui durent toute une carrière.
trois mini-cases
Cas 1 — L'idempotence a permis de gagner 3 heures. Un administrateur a écrit un script qui a installé le même agent de surveillance sur 25 serveurs. La première version n'était pas idempotente : elle cassait la configuration dès la deuxième exécution si l'agent était déjà installé. L'ingénieur a demandé à l'IA d'ajouter la logique "vérifiez s'il est installé, ignorez-le si c'est le cas". Au cours de la fenêtre de maintenance suivante, le script s'est déclenché accidentellement deux fois, mais cela n'a fait aucun mal. L'idempotence a rendu inutile une récupération de 25 serveurs.
Cas 2 — L'exécution à sec a enregistré un répertoire racine. Une équipe a reçu un script Bash qui purgeait les anciennes sauvegardes. Si la variable était vide, le chemin devenait / au lieu de /backups/ — un danger classique. L'ingénieur l'a d'abord exécuté en mode DRY_RUN, s'est figé lorsqu'il a vu une ligne similaire à rm -rf / dans la sortie et a ajouté une vérification de variable (: "${BACKUP_DIR:?cannot be empty}"). Le fonctionnement à sec a détecté un bug qui effacerait l’intégralité du disque avant sa mise en production.
Cas 3 — La gestion des erreurs l'a empêché de se réveiller une nuit. Un script PowerShell archivait les journaux lorsque le disque était plein. La première version échouerait silencieusement si le partage réseau était inaccessible et continuerait à remplir le disque. "Vérifiez le succès à chaque étape, en cas d'échec, notifiez-le par e-mail et arrêtez" a été ajouté à l'IA. Au bout d'une semaine, le courrier était cassé ; Le script s'est arrêté et a averti, le disque n'était pas plein, personne ne s'est réveillé à 3 heures du matin.
Quatre modèles copiables
1) Génération de script Bash sécurisé :
Votre rôle : ingénieur senior en automatisation Linux. Écrivez un script pour Ubuntu 22.04 / Bash 5. Objectif :[objectif]. Règles :- Commencez par "set -euo pipefail".- Validez les variables requises avec ": ${VAR:?}".- Effectuez des opérations destructives avec par défaut DRY_RUN=true ; Laissez la véritable application s'exécuter uniquement avec l'indicateur --apply. - Enregistrez chaque étape sur la sortie standard, arrêtez-vous avec un message d'erreur significatif. - Rendre le idempotent (afin qu'il ne cause pas de dégâts au deuxième passage). Ensuite : marquez séparément les lignes potentiellement destructrices et écrivez 3 cas que je dois tester avant la production.
2) Renforcement du script existant :
Préparez le script suivant pour la production : (1) ajoutez la gestion des erreurs et la journalisation, (2) rendez-le idempotent, (3) placez les commandes destructrices derrière une exécution à sec, (4) extrayez les chemins et les secrets codés en dur vers la variable. Décrivez brièvement chaque ligne que vous avez modifiée et pourquoi. Scénario : [scénario]
3) Automatisation sécurisée PowerShell :
Votre rôle : Expert en automatisation Windows. Écrivez un script compatible PowerShell 5.1. Objectif : [objectif]. Règles : - Commencez par "$ErrorActionPreference = 'Stop'". - Ajoutez la prise en charge de -WhatIf aux applets de commande destructeurs (WhatIf par défaut). - Enveloppez chaque action avec try/catch, enregistrez les erreurs. - Codage en dur des informations d'identification ; Utilisez un paramètre ou une entrée sécurisée. Marquez les lignes destructrices et écrivez les étapes d’annulation.
4) Décodage et vérification des expressions Cron/schedule :
Expliquez l'instruction cron suivante en turc simple et écrivez les 3 environnements d'exécution suivants : [expression] De plus, si mon objectif est "[objectif]", cette affirmation est-elle correcte ou proposez-vous un correctif ? Notez également l’effet de période.
Invite faible/Invite forte
Invite faible :
Écrivez-moi un script qui nettoie le journal.
Cette invite est dangereuse : on ne sait pas quel système d'exploitation, quel répertoire, quelle limite d'âge, quel garde-fou de sécurité. L’IA peut fournir une approche unique, destructrice et invérifiable.
Invite puissante :
Votre rôle : ingénieur senior en automatisation Linux. Écrivez un script de nettoyage de journaux pour Ubuntu 22.04 / Bash. Supprimez uniquement les fichiers .log sous /opt/app/logs datant de plus de 30 jours. Règles : set -euo pipefail ; Valider les variables BACKUP_DIR et LOG_DIR (arrêter si vide) ; liste des fichiers journaux avant la suppression ; Soit DRY_RUN=true la suppression par défaut, réelle uniquement avec --apply ; Que ce soit idempotent. Marquez les lignes destructrices et écrivez 3 scénarios que je devrais tester.
fonctionnalité
Script faible/rapide
script renforcé
Gestion des erreurs
Non, échec silencieux
set -euo pipefail, essayer/attraper
action destructrice
Fonctionne directement
Essai à sec + drapeau de contrôle ouvert
Redémarrer
peut causer des dommages
Idempotent, sûr
gestion secrète
codé en dur
Entrée variable/cachée
annuler
Aucun
Étape de sauvegarde + restauration
Erreurs courantes
- Exécution d'un script destructeur sans essai. Ne pas voir le script contenant rm, Remove-Item, DROP en premier en mode sec coûte du disque.
- Ignorer la vérification des variables nulles. Une variable de chemin vide crée / au lieu de /backups/ ; : Assurez-vous de vérifier avec "${VAR:?}".
- Oublier l'idempotence. Le script s'interrompt lorsqu'il est exécuté deux fois, ce qui rend l'automatisation peu fiable.
- Des secrets codés en dur. L'écriture du mot de passe et de la clé dans le script constitue une fuite lorsque vous partagez ce script.
- Tests en production. Faire la première diffusion en production signifie répéter sur scène ; Testez d'abord la machine.
Attention : N'acceptez pas un script donné par l'IA simplement parce que "ça a marché, ça veut dire qu'il est correct". Ce n’est pas parce que cela fonctionne que ce n’est pas destructeur. Un script peut s'exécuter sur le chemin heureux et supprimer des données dans l'état Edge ; Le véritable test concerne les cas extrêmes.
En résumé
Les scripts d'automatisation éliminent les répétitions et réduisent les erreurs humaines ; L'IA est incroyablement rapide pour générer, expliquer et renforcer ces scripts. Mais le script est une force de travail : s'il se trompe, il supprime, s'arrête, interrompt. Établissez donc le cycle « produire, durcir, vérifier ». Incluez la gestion des erreurs, l’idempotence, l’exécution à sec et le repli dans chaque script destructeur. Extrayez les secrets de la variable, effectuez la première exécution sur la machine de test. Le script AI écrit ; C'est votre travail de le lire, de le tester et d'assumer la responsabilité de son exécution.
Tâche de candidature
Choisissez une tâche que vous répétez manuellement dans votre travail (par exemple, nettoyage des journaux, ouverture d'utilisateur, vérification de l'état). Demandez un aperçu à AI avec le modèle « Script Secure Bash » ou « Automation sécurisée PowerShell » ci-dessus. Lisez le script généré ligne par ligne et marquez les lignes destructrices. Exécutez-le d’abord en mode essai sur une machine de test, comparez le résultat avec vos attentes. Remettez ensuite le script à AI et affinez-le avec le template "harden" et notez les 5 différences entre les deux versions.
liste de contrôle
- [ ] Ai-je inclus des restrictions telles que le système d'exploitation, la version du shell, les chemins et les droits dans l'invite ?
- [ ] Le script est-il tolérant aux pannes avec set -euo pipefail / $ErrorActionPreference='Stop' ?
- [ ] Les opérations destructrices sont-elles derrière un essai à sec/-WhatIf et nécessitent-elles un indicateur de contrôle explicite ?
- [ ] Le script est-il idempotent (sûr lors de la deuxième exécution) ?
- [ ] Ai-je extrait les secrets de l'entrée variable/secrète au lieu de les coder en dur ?
- [ ] Ai-je effectué le premier essai sur la machine de test et préparé un plan de retour ?