Automatisez le remplacement de disque avec Ansible

Bonjour à tous. Je travaille en tant qu'administrateur système de premier plan dans OK et je suis responsable du fonctionnement stable du portail. Je veux parler de la façon dont nous avons construit le processus de remplacement automatique des disques, puis, en tant qu'administrateur, il a été exclu de ce processus et l'a remplacé par un bot.

Cet article est une sorte de translittération des performances de HighLoad + 2018

Construire un processus de remplacement de disque

Quelques chiffres d'abord

OK est un gigantesque service utilisé par des millions de personnes. Il est desservi par environ 7 000 serveurs, qui sont situés dans 4 centres de données différents. Les serveurs coûtent plus de 70 000 disques. Si vous les empilez les uns sur les autres, vous obtenez une tour d'une hauteur de plus de 1 km.

Les disques durs sont un composant du serveur qui plante le plus souvent. Avec de tels volumes, nous devons changer environ 30 disques par semaine, et cette procédure est devenue une routine peu agréable.

Incidents

Nous avons introduit une gestion des incidents à part entière dans notre entreprise. Chaque incident que nous enregistrons à Jira, puis nous le résolvons et le démontons. Si l'incident a eu un effet pour les utilisateurs, nous allons certainement réfléchir à la manière de réagir plus rapidement dans de tels cas, à réduire l'effet et bien sûr à éviter une récidive.

Les lecteurs ne font pas exception. Leur statut est surveillé par Zabbix. Nous surveillons les messages dans Syslog pour les erreurs d'écriture / lecture, analysons l'état des raids HW / SW, surveillons SMART et calculons l'usure des SSD.

Comment les disques ont changé avant

Lorsqu'un déclencheur s'allume dans Zabbix, un incident est créé dans Jira et est automatiquement transmis aux ingénieurs appropriés dans les centres de données. Nous le faisons avec tous les incidents matériels, c'est-à-dire ceux qui nécessitent une sorte de travail physique avec l'équipement du centre de données.
Un ingénieur d'un centre de données est une personne qui résout les problèmes liés au matériel, est responsable de l'installation, de la maintenance, du démontage des serveurs. Ayant reçu un ticket, l'ingénieur commence à travailler. Dans les étagères à disques, il change les disques par lui-même. Mais s'il n'a pas accès à l'appareil souhaité, l'ingénieur se tourne vers les administrateurs système de garde pour obtenir de l'aide. Tout d'abord, vous devez retirer le disque de la rotation. Pour ce faire, vous devez apporter les modifications nécessaires sur le serveur, arrêter l'application, démonter le disque.

L'administrateur système en service pendant le quart de travail est responsable du fonctionnement de l'ensemble du portail. Il enquête sur les incidents, les réparations, aide les développeurs à effectuer de petites tâches. Il ne s'occupe pas seulement des disques durs.

Auparavant, les ingénieurs du centre de données discutaient avec l'administrateur système. Les ingénieurs ont envoyé des liens vers des tickets Jira, l'administrateur les a parcourus, a gardé un journal de travail dans un bloc-notes. Mais les chats ne sont pas pratiques pour de telles tâches: les informations ne sont pas structurées et sont rapidement perdues. Et l'administrateur pouvait simplement s'éloigner de l'ordinateur et pendant un certain temps ne pas répondre aux demandes, et l'ingénieur se tenait devant le serveur avec un tas de disques et attendait.

Mais le pire, c'est que les administrateurs n'ont pas vu la situation dans son ensemble: quels incidents de disque existent, où le problème pourrait potentiellement survenir. Cela est dû au fait que nous confions tous les incidents matériels aux ingénieurs. Oui, il était possible d'afficher tous les incidents sur le tableau de bord d'administration. Mais il y en a beaucoup, et l'administrateur n'était impliqué que dans certains d'entre eux.

De plus, l'ingénieur n'a pas pu établir correctement les priorités, car il ne sait rien de l'objectif de serveurs spécifiques, de la distribution des informations sur les disques.

Nouvelle procédure de remplacement

La première chose que nous avons faite a été de prendre tous les incidents de disque dans un type distinct de «disque HW» et d'y ajouter les champs «nom de périphérique de bloc», «taille» et «type de disque» afin que ces informations soient enregistrées dans le ticket et n'aient pas à bavarder constamment.


Nous avons également convenu que dans le cadre d'un incident, nous ne changerons qu'un seul disque. Cela a grandement simplifié le processus d'automatisation, la collecte de statistiques et le travail.

De plus, le champ «administrateur responsable» a été ajouté. L'administrateur système y est automatiquement remplacé. C'est très pratique, car maintenant l'ingénieur voit toujours qui est responsable. Pas besoin d'aller au calendrier et de chercher. C'est ce champ qui a permis de mettre des tickets sur le tableau de bord de l'administrateur, dans lequel, peut-être, son aide serait nécessaire.


Pour s'assurer que tous les participants bénéficient au maximum des innovations, nous avons créé des filtres et des tableaux de bord, en ont parlé aux gars. Lorsque les gens comprennent les changements, ils ne se distancient pas d'eux comme de quelque chose d'inutile. Il est important pour un ingénieur de connaître le numéro de rack où se trouve le serveur, la taille et le type de disque. L'administrateur doit tout d'abord comprendre de quel type de groupe de serveurs il s'agit, de quel type d'effet il peut s'agir lors du remplacement d'un disque.

La présence de champs et leur affichage est pratique, mais cela ne nous a pas épargné la nécessité d'utiliser des chats. Pour ce faire, j'ai dû modifier le workflow.

C'était comme ça:


Aujourd'hui, les ingénieurs continuent de travailler comme ça quand ils n'ont pas besoin d'aide de l'administrateur.

La première chose que nous avons faite a été d'introduire un nouveau statut d' enquête . Le ticket est dans ce statut lorsque l'ingénieur n'a pas encore décidé s'il aura besoin d'un administrateur ou non. Grâce à ce statut, l'ingénieur peut transmettre le ticket à l'administrateur. De plus, nous marquons les tickets avec ce statut lorsqu'un remplacement de disque est requis, mais il n'y a pas de disque lui-même sur le site. Cela se produit avec les CDN et les sites distants.

Nous avons également ajouté le statut Prêt . Le ticket lui est transféré après avoir remplacé le disque. Autrement dit, tout a déjà été fait, mais HW / SW RAID est synchronisé sur le serveur. Cela peut prendre beaucoup de temps.

Si un administrateur est impliqué, le schéma est un peu plus compliqué.


À partir du statut Ouvert , un ticket peut être transféré à la fois par un administrateur système et un ingénieur. Dans l'état En cours , l'administrateur supprime le disque de la rotation afin que l'ingénieur puisse simplement le supprimer: il allume le rétroéclairage, démonte le disque et arrête les applications, selon le groupe de serveurs spécifique.

Ensuite, le ticket est converti en prêt à changer : c'est un signal à l'ingénieur que le disque peut être retiré. Tous les champs de Jira sont déjà remplis, l'ingénieur sait quel type et quelle taille du disque. Ces données sont apposées automatiquement sur l'état précédent ou par l'administrateur.

Après avoir remplacé le disque, le ticket est transféré à l'état Changé . Il est vérifié que le bon disque a été inséré, le balisage est effectué, l'application est lancée et certaines tâches de récupération de données sont effectuées. En outre, le ticket peut être transféré à l'état Prêt , auquel cas l'administrateur restera responsable, car il a démarré le disque en rotation. Le contour complet ressemble à ceci.


L'ajout de nouveaux champs a rendu notre vie beaucoup plus facile. Les gars ont commencé à travailler avec des informations structurées, il est devenu clair quoi et à quelle étape faire. Les priorités sont devenues beaucoup plus pertinentes car elles sont désormais définies par l'administrateur.

Le besoin de chats a disparu. Bien sûr, l'administrateur peut écrire à l'ingénieur "vous devez remplacer plus vite ici" ou "déjà le soir, aurez-vous le temps de remplacer?". Mais nous ne discutons plus quotidiennement sur ces questions.

Les disques ont commencé à changer en packs. Si l'administrateur est venu travailler un peu plus tôt, il a du temps libre et rien ne s'est passé, il peut préparer un certain nombre de serveurs pour le remplacement: déposer des champs, retirer les disques de la rotation et transférer la tâche à l'ingénieur. Un ingénieur arrive plus tard au centre de données, voit la tâche, prend les disques nécessaires de l'entrepôt et les change immédiatement. En conséquence, la vitesse de remplacement a augmenté.

Leçons apprises dans la création d'un flux de travail

• Lors de la création d'une procédure, vous devez collecter des informations auprès de différentes sources.
  Certains de nos administrateurs ne savaient pas que l'ingénieur avait changé les disques par eux-mêmes. Certains pensaient que les ingénieurs surveillaient la synchronisation MD RAID, bien que certains d'entre eux n'y aient même pas accès. Certains ingénieurs de premier plan l'ont fait, mais pas toujours, car le processus n'était décrit nulle part.
• La procédure doit être simple et directe.
  Il est difficile pour une personne de garder plusieurs étapes dans sa tête. Les statuts voisins les plus importants de Jira doivent être affichés sur l'écran principal. Vous pouvez les renommer, par exemple, En cours, nous appelons Prêt à changer. Et les statuts restants peuvent être cachés dans le menu déroulant afin qu'ils ne callent pas les yeux. Mais il vaut mieux ne pas limiter les gens, donner la possibilité de faire la transition.
  Expliquez la valeur de l'innovation. Lorsque les gens comprennent, ils feraient mieux d'accepter la nouvelle procédure. Il était très important pour nous que les gens n'appellent pas tout le processus, mais le suivent. Ensuite, nous avons construit sur cette automatisation.
• Attendez, analysez, comprenez.
  Il nous a fallu environ un mois pour élaborer la procédure, la mise en œuvre technique, les réunions et les discussions. Et pour la mise en œuvre - plus de trois mois. J'ai vu comment les gens commencent lentement à utiliser l'innovation. Au début, il y avait beaucoup de négativité. Mais il était complètement indépendant de la procédure elle-même, de sa mise en œuvre technique. Par exemple, un administrateur n'a pas utilisé Jira, mais le plugin Jira dans Confluence, et certaines choses n'étaient pas disponibles pour lui. Lui a montré Jira, l'administrateur a augmenté la productivité et les tâches globales, ainsi que le remplacement des disques.

Automatisation du remplacement des disques

Nous sommes passés à l'automatisation du remplacement des disques à plusieurs reprises. Nous avions déjà du temps de fonctionnement, des scripts, mais tous fonctionnaient de manière interactive ou en mode manuel, ils nécessitaient un lancement. Et seulement après l'introduction de la nouvelle procédure, nous avons réalisé que c'était juste que nous manquions.

Depuis maintenant, le processus de remplacement est divisé en étapes, chacune ayant un exécuteur et une liste d'actions, nous pouvons activer l'automatisation par étapes, et pas toutes en même temps. Par exemple, l'étape la plus simple - Prêt (vérification de la synchronisation RAID / données) peut être facilement déléguée au bot. Lorsque le bot apprend un peu, vous pouvez lui confier une tâche plus responsable - mettre le disque en rotation, etc.

Configurations du zoo

Avant de parler du bot, nous ferons une courte excursion dans notre zoo d'installation. Tout d'abord, cela est dû à la taille gigantesque de notre infrastructure. Deuxièmement, pour chaque service, nous essayons de choisir la configuration optimale du fer. Nous avons environ 20 modèles RAID matériels, principalement LSI et Adaptec, mais il existe à la fois HP et DELL de versions différentes. Chaque contrôleur RAID possède son propre utilitaire de gestion. L'ensemble des commandes et leur émission peuvent différer d'une version à l'autre de chaque contrôleur RAID. Si HW-RAID n'est pas utilisé, il peut avoir peur.

Presque toutes les nouvelles installations que nous faisons sans sauvegarde sur disque. Nous essayons de ne plus utiliser de RAID matériel et logiciel, car nous réservons nos systèmes au niveau des centres de données, pas des serveurs. Mais bien sûr, de nombreux serveurs hérités doivent être pris en charge.

Quelque part, les disques des contrôleurs RAID lancent des périphériques bruts; quelque part, ils utilisent JBOD. Il existe des configurations avec un disque système sur le serveur, et si vous devez le remplacer, vous devez reformater le serveur avec l'installation du système d'exploitation et des applications, avec les mêmes versions, puis ajouter des fichiers de configuration, lancer des applications. Il existe également de nombreux groupes de serveurs où la redondance n'est pas effectuée au niveau du sous-système de disque, mais directement dans les applications elles-mêmes.

Au total, nous avons plus de 400 groupes de serveurs uniques qui exécutent environ 100 applications différentes. Pour couvrir un si grand nombre d'options, nous avions besoin d'un outil d'automatisation multifonctionnel. Il est conseillé avec une simple DSL, afin que non seulement la personne qui l'a écrit puisse la supporter.

Nous avons choisi Ansible car il est sans agent: pas besoin de préparer l'infrastructure, démarrage rapide. De plus, il est écrit en Python, qui est accepté comme standard dans l'équipe.

Schéma général

Examinons un schéma d'automatisation général utilisant un incident comme exemple. Zabbix détecte que le lecteur sdb est hors service, le déclencheur s'allume, un ticket est créé dans Jira. L'administrateur l'a regardé, s'est rendu compte qu'il ne s'agissait pas d'un doublon et non d'un faux positif, c'est-à-dire que vous devez changer le disque et traduire le ticket en cours.


L'application DiskoBot écrite en Python interroge périodiquement Jira pour de nouveaux tickets. Il remarque qu'un nouveau ticket En cours est apparu, le thread correspondant est déclenché, ce qui lance le playbook dans Ansible (cela se fait pour chaque statut dans Jira). Dans ce cas, Prepare2change démarre.

Ansible se rend sur l'hôte, supprime le disque de la rotation et signale l'état à l'application via des rappels.


Selon les résultats, le bot transfère automatiquement le ticket à Ready to change. L'ingénieur reçoit une notification et va changer le disque, après quoi il transfère le ticket à Changed.


Selon le schéma ci-dessus, le ticket revient au bot, il lance un autre playbook, va à l'hôte et entre le disque en rotation. Le bot ferme le ticket. Hourra!


Parlons maintenant de certains des composants du système.

Diskobot

Cette application est écrite en Python. Il sélectionne les billets de Jira selon JQL . Selon le statut du ticket, ce dernier parvient au gestionnaire correspondant, qui à son tour lance le statut du playbook Ansible correspondant.

JQL et les intervalles d'interrogation sont définis dans le fichier de configuration de l'application.

jira_states: investigate: jql: '… status = Open and "Disk Size" is EMPTY' interval: 180 inprogress: jql: '… and "Disk Size" is not EMPTY and "Device Name" is not EMPTY' ready: jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)' interval: 7200 

Par exemple, parmi les tickets dont l'état est En cours, seuls ceux avec les champs Taille du disque et Nom du périphérique sont remplis. Le nom du périphérique est le nom du périphérique de bloc nécessaire pour exécuter le playbook. La taille du disque est nécessaire pour que l'ingénieur sache quelle taille de disque est nécessaire.

Et parmi les tickets avec le statut Prêt, les tickets avec le label dbot_ignore sont filtrés. Soit dit en passant, nous utilisons les étiquettes Jira à la fois pour ce filtrage, pour marquer les tickets en double et collecter des statistiques.

Si le playbook plante, Jira attribue le label dbot_failed afin que vous puissiez le découvrir plus tard.

Interaction avec Ansible

L'application interagit avec Ansible via l' API Ansible Python . Dans playbook_executor, nous transmettons le nom de fichier et l'ensemble de variables. Cela vous permet de conserver le projet Ansible sous la forme de fichiers yml standard, plutôt que de le décrire en code Python.

Également dans Ansible via * extra_vars *, le nom du périphérique de blocage, l'état du ticket, ainsi que callback_url, dans lequel la clé de problème est cousue, est utilisé - il est utilisé pour le rappel en HTTP.

Pour chaque lancement, un inventaire temporaire est généré, composé d'un hôte et du groupe auquel appartient cet hôte afin que group_vars soit appliqué.

Voici un exemple de tâche dans laquelle le rappel HTTP est implémenté.

Le résultat des playbooks que nous obtenons en utilisant callaback (s). Ils sont de deux types:

• Plugin de rappel ansible , il fournit des données sur les résultats d'un playbook. Il décrit les tâches qui ont été lancées, exécutées avec succès ou sans succès. Ce rappel est appelé à la fin du playbook.
• Rappel HTTP pour obtenir des informations lors de la lecture d'un playbook. Dans Ansible, nous effectuons une requête POST / GET à côté de notre application.

Via le (s) callback (s) HTTP, les variables qui ont été définies lors de l'exécution du playbook et que nous voulons sauvegarder et utiliser dans les runs suivants sont transmises. Nous écrivons ces données dans sqlite.

De plus, via le rappel HTTP, nous laissons des commentaires et modifions le statut du ticket.


Comme beaucoup de tâches du même type, nous les mettons dans un fichier commun séparé et les incluons si nécessaire, afin de ne pas répéter constamment dans les playbooks. L'URL de rappel_apparaît ici, dans laquelle la clé du problème et le nom d'hôte sont protégés. Quand Ansible exécute cette requête POST, le bot se rend compte qu'elle est venue dans le cadre d'un tel incident.

Et voici un exemple d'un playbook, dans lequel nous avons affiché un disque à partir d'un périphérique MD:

  # Save mdadm configuration - include: common/callback.yml vars: callback_post_body: status: 'Ready to change' msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}" data: mdadm_data: "{{ mdadm_remove_disk.removed }}" parted_info: "{{ parted_info | default() }}" when: - mdadm_remove_disk | changed - mdadm_remove_disk.removed 

Cette tâche place le ticket Jira dans l'état «Prêt à changer» et ajoute un commentaire. De plus, la variable mdam_data stocke la liste des périphériques md dont le disque a été supprimé et le vidage parted_ de la partition partitionnée dans parted_info.

Lorsque l'ingénieur insère un nouveau disque, nous pourrons utiliser ces variables pour restaurer le vidage de partition, ainsi que pour insérer le disque dans les périphériques md dont il a été supprimé.

Mode de vérification impossible

Activer l'automatisation était effrayant. Par conséquent, nous avons décidé d'exécuter tous les playbooks en mode
exécution à sec , dans laquelle Ansible n'exécute aucune action sur les serveurs, mais les émule uniquement.

Un tel lancement est exécuté via un module de rappel séparé et le résultat du playbook est enregistré dans Jira en tant que commentaire.



Tout d'abord, il a permis de valider le travail du bot et des playbooks. Deuxièmement, cela a accru la confiance des administrateurs dans le bot.

Lorsque nous avons effectué la validation et réalisé que vous pouvez exécuter Ansible non seulement en mode de fonctionnement à sec, nous avons créé le bouton Exécuter Diskobot dans Jira pour démarrer le même playbook avec les mêmes variables sur le même hôte, mais en mode normal.

De plus, le bouton permet de redémarrer le playbook en cas de panne.

Structure des Playbooks

J'ai déjà mentionné qu'en fonction du statut du ticket Jira, le bot lance différents playbooks.

Premièrement, il est tellement plus facile d'organiser l'entrée.
Deuxièmement, dans certains cas, c'est tout simplement nécessaire.

Par exemple, lorsque vous remplacez un disque système, vous devez d'abord vous rendre sur le système de déploiement, créer une tâche, et après le déploiement correct, le serveur sera accessible via ssh et vous pourrez y faire rouler l'application. Si nous faisions tout cela dans un playbook, Ansible ne serait pas en mesure de l'exécuter en raison de l'inaccessibilité de l'hôte.

Nous utilisons des rôles Ansible pour chaque groupe de serveurs. Ici, vous pouvez voir comment les playbooks sont organisés dans l'un d'eux.



C'est pratique, car il est immédiatement clair où se trouvent les tâches. Dans main.yml, qui est l'entrée pour le rôle Ansible, nous pouvons simplement inclure par statut de ticket ou tâches générales nécessaires pour tout le monde, par exemple, passer une identification ou recevoir un jeton.

Investigation.yml

Fonctionne pour les tickets ayant le statut Enquête et Ouvert. La chose la plus importante pour ce playbook est le nom du périphérique de bloc. Ces informations ne sont pas toujours disponibles.

Pour l'obtenir, nous analysons le résumé Jira, la dernière valeur du déclencheur Zabbix. Il peut contenir le nom du périphérique de bloc - chanceux. Ou il peut contenir un point de montage, - alors vous devez vous rendre sur le serveur, analyser et calculer le lecteur souhaité. De plus, un déclencheur peut transmettre une adresse scsi ou d'autres informations. Mais il arrive aussi qu'il n'y ait aucun indice et que vous deviez analyser.

Après avoir découvert le nom du périphérique de bloc, nous collectons des informations sur le type et la taille du disque à remplir dans les champs de Jira. Nous supprimons également les informations sur le fournisseur, le modèle, le micrologiciel, l'ID, SMART et insérons tout cela dans un commentaire dans le ticket Jira. L'administrateur et l'ingénieur n'ont plus besoin de rechercher ces données. :)

prepare2change.yml

La sortie du disque de rotation, préparation pour le remplacement. L'étape la plus difficile et cruciale. C'est là que vous pouvez arrêter l'application lorsqu'elle ne peut pas être arrêtée. Ou retirez un disque qui ne disposait pas de suffisamment de répliques, et donc avoir un effet sur les utilisateurs, perdez certaines données. Ici, nous avons le plus de contrôles et de notifications dans le chat.

Dans le cas le plus simple, nous parlons de la suppression d'un disque dur HW / MD RAID.

Dans des situations plus complexes (dans nos systèmes de stockage), lorsque la sauvegarde est effectuée au niveau de l'application, vous devez accéder à l'application à l'aide de l'API, signaler la sortie du disque, la désactiver et démarrer la récupération.

Nous migrons maintenant massivement vers le cloud , et si le serveur est cloud, alors Diskobot accède à l'API cloud, dit qu'il va fonctionner avec ce séide - le serveur sur lequel les conteneurs s'exécutent - et demande «migrer tous les conteneurs de ce séide». Et en même temps, il allume le rétro-éclairage pour que l'ingénieur voit immédiatement lequel retirer.

changé.yml

Après avoir remplacé un disque, nous vérifions d'abord sa disponibilité.

Les ingénieurs ne mettent pas toujours de nouveaux disques, nous avons donc ajouté une vérification des valeurs SMART qui nous satisfont.


Si le lecteur échoue au test, l'ingénieur est informé d'un remplacement. Si tout est en ordre, le rétro-éclairage s'éteint, le balisage est appliqué et le disque est inséré en rotation.

ready.yml

Le cas le plus simple: vérifier la synchronisation du raid HW / SW ou terminer la synchronisation des données dans l'application.

API d'application

J'ai mentionné à plusieurs reprises que le bot accède souvent aux API d'application. Bien sûr, toutes les applications n'avaient pas les méthodes nécessaires, j'ai donc dû les affiner. Voici les méthodes les plus importantes que nous utilisons:

• Statut Le statut d'un cluster ou d'un disque pour comprendre s'il est possible de travailler avec lui;
  
• Démarrer / arrêter. Activation-désactivation du disque;
  
• Migrer / restaurer. Migration et récupération de données pendant et après le remplacement.
  

Leçons apprises par Ansible

J'adore vraiment Ansible. Mais souvent, quand je regarde différents projets open source et que je vois comment les gens écrivent des playbooks, j'ai un peu peur. Tissage logique complexe à partir de quand / boucle, manque de flexibilité et d'idempotence en raison de l'utilisation fréquente de shell / commande.

Nous avons décidé de tout simplifier au maximum, en profitant de la modularité d'Ansible. Au plus haut niveau se trouvent les playbooks, ils peuvent être écrits par n'importe quel administrateur, un développeur tiers qui connaît un peu Ansible.

 - name: Blink disk become: True register: locate_action disk_locate: locate: '{{ locate }}' devname: '{{ devname }}' ids: '{{ locate_ids | default(pd_id) | default(omit) }}' 

Si une logique est difficile à implémenter dans les playbooks, nous la plaçons dans un module ou un filtre Ansible. Les scripts peuvent être écrits à la fois en Python et dans n'importe quelle autre langue.

Ils sont faciles et rapides à écrire. Par exemple, le module de mise en évidence du disque, dont un exemple d'utilisation est donné ci-dessus, se compose de 265 lignes.



Au niveau le plus bas se trouve la bibliothèque. Pour ce projet, nous avons écrit une application distincte, une sorte d'abstraction sur les RAID matériels et logiciels qui exécutent les requêtes correspondantes.



Les plus grandes forces d'Ansible sont sa simplicité et ses playbooks compréhensibles. Je crois que vous devez utiliser cela et ne pas générer de fichiers Yaml effrayants et un grand nombre de conditions, de code shell et de boucles.

Si vous souhaitez répéter notre expérience avec l'API Ansible, gardez à l'esprit deux choses:

• Playbook_executor et généralement le playbook ne peuvent pas être dépassés. Il y a un timeout sur la session ssh, mais il n'y a pas de timeout sur le playbook. Si nous essayons de démonter un lecteur qui n'existe pas déjà dans le système, le playbook fonctionnera indéfiniment, nous avons donc dû le mettre dans un emballage séparé et le tuer par timeout.
  
• Ansible est forké, donc son API n'est pas thread-safe. Nous lançons tous nos playbooks et monofils.
  

En conséquence, nous avons pu automatiser le remplacement d'environ 80% des disques. En général, le taux de remplacement a doublé. Aujourd'hui, l'administrateur ne regarde que l'incident et décide de changer le disque ou non, puis fait un clic.

Mais maintenant, nous commençons à faire face à un autre problème: certains nouveaux administrateurs ne savent pas comment changer de lecteur. :)