Titre de votre présentation GT Orchestration - Automatisation Présentation du Livre Blanc Hugues Fondeux Chargé de mission évolution de l’infrastructure

Introduction Les outils d’orchestration sont récents, leur mise en exploitation chez les participants au GT remonte au maximum à 2 ans. Une synthèse des expériences vécues par quelques sociétés aux organisations différentes permet cependant de dessiner un premier paysage qui peut intéresser les nouveaux candidats ...

L’orchestration après l’automatisation L’automatisation existe depuis longtemps … mais cantonnée à des silos techniques : Stockage, Serveurs, Réseau, etc. ► passer à une automatisation transversale Là où il existe déjà de l’automatisation, aller vers l’orchestration ► récupération des scripts existants Le spectre des CI (Configuration Items ou Composants Informatiques) sur lesquels on peut agir est très important ►les orchestrateur disposent de nombreux protocole d’accès ► ne pas confondre orchestrateur généraliste et mono-environnement

Une automatisation qui « traverse » les métiers de l’IT Processus automatisé

Qu’est ce qui caractérise un orchestrateur ? Une génération d’outils d’automatisation apparus au début des années 2000 Une description des processus sous forme graphique (du type BPML) => la lisibilité fonctionnelle y gagne, la réalité technique sous-jacente devient de ce fait plus abstraite. Utilisation directe de cette représentation pour créer les « flows » (processus automatisés d’exécution) Un jeu de Lego, utilisant des briques paramétrables d’action sur les CI Fortes réutilisabilité des briques et sous-ensembles développés Récupération possible des scripts d’automatisation existants De nombreux connecteurs sont fournis (avec les hyperviseurs, OS, logiciels du marché) Traçabilité et audit des opérations Un orchestrateur impose de prendre en charge toutes les exceptions, l’oubli ne peut être que volontaire …

Les besoins adressés Provisioning, déploiement Réaliser le provisioning automatique complet de nouveaux serveurs (physiques ou virtuels) : Créer les VM Déployer les OS, les logiciels, les outils de gestion des infrastructures … Déployer les applicatifs techniques ou métiers Mettre en place la sécurité, le paramétrage réseau Gérer le changement au sens ITIL Dé commissionner puis recréer de façon automatisée des environnements de pré-production (environnements souvent maintenus en place mais peu utilisés) Gestion des applications Arrêter et relancer de façon contrôlée des applications complexes multi-tiers pouvant mettre en jeu plusieurs dizaines de serveurs. Effectuer des contrôles sur la bonne marche des applications (« health check »).

Les besoins adressés Contrôle, maintenance   Analyser automatiquement le taux d’utilisation des ressources (suivi capacitaire) Effectuer des vérifications de retour à la normale suite à une résolution d’incident. Gérer les sauvegardes de bout en bout (déclenchement, vérification du bon déroulement des opérations …) Auditer de façon récurrente des bases de données, et générer des tickets d’incidents sur les bases hors service. Détection d’agents de contrôle/supervision indisponibles. Créer des rapports automatiques sur l’état de fonctionnement de différents équipements. Effectuer des mises à jour forcées de mots de passe à grande échelle.

Les besoins adressés Résolution d’incidents   Traitement automatisé d’incidents récurrents (total ou partiel) Traitement automatisé de changements planifiés Possibilité de coupler l’outil de gestion des changements avec l’orchestrateur => l’outil d’enregistrement et d’approbation des changements peut devenir un scheduler pour une réalisation automatisée via des flows.

Choisir son orchestrateur Voir le livre blanc

Le rythme et ordre de déploiement Fort impact sur les processus et ressources Définition des besoins, étude de marché, PoC (Proof of Concept) Achat de l’orchestrateur, définition du contrat de prestation associé qui inclut en particulier l’accompagnement par le fournisseur <= 50 à 100 JH   Formation des développeurs et des administrateurs de l’outil.  Définition de l’architecture à mettre en place, sizing des ressources. Mise en place des différents environnements d’orchestration (dév, préprod …)  Paramétrage initial du produit, définition de la sécurisation interne, tests de bon fonctionnement en autarcie. Intégration à l’écosystème local (outil de ticketing, outils de métrologie …). Industrialisation des environnements d’orchestration : mise en place de la supervision, des sauvegardes, tests de restauration, formation des équipes des Opérations. Définition des normes de développement et de fonctionnement : codification des objets, procédures de passage des flows en pré production puis production …   Développement des connecteurs « d’utilité publique » : vers la CMDB, l’outil des gestion des changements et incidents, les logiciels non pris en compte par l’éditeur. Développement des premiers flows Passage en exploitation Avec une équipe de 2 à 3 personnes à temps plein 6 mois à 1 an de travail

Impact sur les processus d’exploitation et sur les organisations Impact à étudier dès le début du projet sur les processus incidents 1 flow crée 1 incident 1 incident déclenche 1 flow changements 1 flow crée 1 changement 1 changement déclenche 1 flow utilisation de la CMDB 1 flow utilise la CMDB 1 flow met à jour la CMDB approvisionnement des ressources (serveurs, stockage …) Impact sur les personnes et les organisations l’orchestrateur est un nouveau venu dans le SI. Comme toute nouveauté, son apparition peut provoquer des résistances. Comme tout changement, il demande une démarche d’accompagnement. => organiser des présentations aux utilisateurs : « l’orchestrateur va me prendre mon travail » seulement la partie la plus ennuyeuse … => montrer aux équipes techniques les capacités de l’outil, pour alimenter les réflexions qui déboucheront sur l’automatisation des processus répétitifs. => faire la promotion des flows développés. Ne pas négliger l’aspect marketing

La gestion de la sécurité La technologie est puissante et donne accès à de vastes pans du système d’information => bien protéger les flows et les comptes techniques embarqués. Problème majeur de la sécurité = cohérence de la protection entre composants et composés. Flow 1 Flow 2 Flow 3 Chaque élément est protégé. Pour exécuter un flow, il faut disposer des droits sur tous ses composants Subflow 1 Brique A Brique B Brique C Brique D Brique E

Le portail ne voit que les flows à lancer La gestion de la sécurité La solution la plus fréquemment adoptée est l’utilisation d’un Portail. L’accès direct à l’orchestrateur est réservé aux administrateurs Les utilisateurs n’ont accès qu’au Portail Les protections d’accès sont définies au niveau du Portail Le portail ne voit que les flows à lancer Flow 1 Flow 2 Flow 3 Subflow 1 Brique A Brique B Brique C Brique D Brique E

Traçabilité et audit Un audit régulier (trimestriel ?) de la sécurité est nécessaire pour éviter des dérives Comment sont protégés les flows, les briques de base ? Comment sont protégés les comptes techniques utilisables dans des flows ? Qui a lancé les flows « sensibles » depuis le dernier audit ? Les outils d’analyse des traces d’exécution fournis avec les orchestrateurs mériteraient de l’avis des participants au GT d’être renforcés. Pour voir ce qui a été réalisé sur des CI à travers un flow : OK Pour retrouver quel flow a pu modifier un CI : insuffisant Pas de dispositif simple pour contrôler le périmètre des CI impactés par les flows Le périmètre du SI adressable n’est pas borné de manière native. En particulier, vous aurez du mal à empêcher vos développeurs de flows d’agir sur des CI de production à partir d’un orchestrateur de développement.

La suite au sein du GT … Pour notre prochaine saison, nous nous proposons d’aller beaucoup plus dans le détail sur : Le provisioning Le traitement automatisé d’incidents La réalisation de campagnes de changements (par exemple pour une nouvelle version d’Oracle) Les méthodologies mises en place et l’exploitation au quotidien. Par exemple comment fait-on pour s’assurer en permanence que ce qui doit « tourner » sur l’outil d’orchestration tourne ? Le processus de développement des flows + cycle de vie des flows. Comment contourner certaines limitations des outils ?

Des questions ? La vie avant l’orchestration et après …