A Song of Ice (Bloody Enterprise) et Fire (DevOps et IaC)

Le sujet de DevOps et IaC est très populaire et se développe rapidement. Cependant, la plupart des auteurs traitent des problèmes purement techniques en cours de route. Je vais décrire les problèmes propres à une grande entreprise. Je n'ai pas de solution - les problèmes, en général, sont fatals et se situent dans le domaine de la bureaucratie, de l'audit et des "compétences générales".

A Song of Ice (Bloody Enterprise) et Fire (DevOps et IaC)
Puisque le titre de l'article est comme ça, alors Daenerys agira comme un chat, étant passé du côté d'Enterprise

Sans aucun doute, il y a maintenant un choc entre l'ancien et le nouveau. Et souvent, dans ces collisions, il n'y a ni bien ni mal. C'est juste arrivé. Mais, pour ne pas être infondé, on va commencer par cet écran :

A Song of Ice (Bloody Enterprise) et Fire (DevOps et IaC)

C'est ce qu'on appelle la demande de modification. Vous voyez environ un tiers des champs qui doivent être remplis à partir de divers répertoires, le reste des champs se trouve dans d'autres onglets. Un tel document doit être rempli afin d'appliquer le script au serveur de production, ou de télécharger de nouveaux fichiers et, en général, de changer quelque chose.

Le nombre de champs est tel que j'ai écrit ma petite automatisation pour remplir ces champs. De plus, cette page est écrite de telle manière qu'aucun outil d'automatisation ne voit ses champs, et la seule solution possible était d'utiliser AutoIt pour frapper bêtement les coordonnées avec la souris. Évaluez le degré de désespoir pour en décider :

A Song of Ice (Bloody Enterprise) et Fire (DevOps et IaC)

Donc, vous prenez jenkins, chef, terraform, nexus et ainsi de suite, et déployez joyeusement tout cela sur votre dev. Mais il est temps de l'envoyer à QA, UAT et PROD. Vous avez un artefact Nexus et vous recevez une lettre du DBA avec quelque chose comme ceci :

Cher

Premièrement, votre lien, vous pouvez imaginer que je n'ai pas accès à votre lien
Deuxièmement, toutes les modifications doivent être déposées en tant que demande de modification.
Vous devez isoler les scripts SQL de Nexus et les joindre à la demande de modification.
Si le changement n'est pas urgent, il doit être effectué dans les 7 jours suivant la sortie (exclusivement le week-end)
Lorsque votre demande de modification est approuvée par un groupe de personnes, le DBA exécutera votre script et enverra même une capture d'écran du résultat par courrier.

Cordialement, votre DBA, qui travaille ici depuis le mainframe.

Savez-vous ce que cela me rappelle ? Semi-automatisation : le robot tient le cadre et le travailleur le frappe avec un marteau. Bon, vraiment, à quoi sert ce Nexus, si tout se fait entièrement manuellement ?

Mais ne blâmez pas Enterprise pour cela ! C'est bien sûr sanglant, mais toute cette bureaucratie avec les demandes de changement est forcée et vient des auditeurs. L'entreprise doit fonctionner de cette façon, point final. Il ne peut pas faire autrement. Et l'audit est une chose très conservatrice. Combien, par exemple, a-t-on dit sur le fait que les mots de passe longs pseudo-complexes et fréquemment changés sont mauvais, mais les entreprises seront le dernier endroit pour changer cela. Aussi avec les déploiements et tout le reste.

Au fait, à un moment donné, j'ai essayé de créer un fichier pour terraform, mais je n'ai pas réussi. Je suis tombé sur la signification de la balise "Project Accounting Billing Code", que je n'ai jamais réussi à découvrir - je n'avais pas assez de soft skills.

Je ne prends même pas le sujet du luddisme passif - oh, votre automatisation menace ma sécurité d'emploi, je ne veux rien apprendre de nouveau, alors je vais saboter tranquillement.

Alors, quelle pourrait être la solution ? Le système ITSM dispose d'une API extrêmement primitive pour générer automatiquement des documents. Et en général, la plupart de ces systèmes datent de l'époque des mainframes. Peut-être que quelqu'un connaît les systèmes ITSM vraiment modernes ? Peut-être que quelqu'un a une expérience réussie d'intégration de DevOps et de bureaucratie modernes ? Il ne s'agit bien sûr pas de sites purement corrompus, où il peut vraiment être déployé tous les jours, mais, par exemple, du secteur bancaire, qui est sous audit et très fortement isolé des environnements supérieurs.

N'oubliez pas que tous vos fantasmes se limitent à l'audition. Et ça change tout. Je vous attends dans les commentaires !

Source: habr.com

Ajouter un commentaire