Automatisation de la production

Automatisation de la production

Dans le contexte technique de

l’infrastructure des serveurs

Contexte

De plus en plus de serveurs à gérer

Cluster applicatifs

Cluster de données

Outils centraux en cluster

…

Environnement hétérogène linux/windows

Un socle technique commun à tous

DNS, NTP, …

2

Définitions

3

Besoins

De standardisation et d’automatisation

Des méthodes

Des configurations

Des traces

Des versions

Des métriques

Besoin de scalabilité horizontale

Besoin de documentations auto gérée

Besoin de simplicité

4

L’existant

5

L ’existant

Etude en cours pour un outil de gestion des

configurations serveurs

Etude en cours pour un outil de gestion d’alertes

Outil de gestion de traces en maquette

Pas de capacity planning généralisé

SVN utilisé par le SED et pour partie par le SIE

Tout fait manuellement

Standardisation par la documentation

6

Cible (fin 2014)

7

Réalisations à faire en 2014

Après le choix des 2 outils en cours

Leur déploiement et configuration

Intégration des outils entre eux

Mise en œuvre de modules dédiés à notre infra

Mise en œuvre d’outils de gestion de capacité

et performance

8

Détails 2014

Sur l’outils de gestion des configurations

Création de l’infrastructure technique et logique

Création de règles de bon fonctionnement

(connexions ssh, règles de firewall, gestion des

ports applicatifs, …)

Création de modules standards (ntp, dns, nginx…)

Création de modules spécifiques ( rproxy, …)

Documentation et formation des agents

9

Détails 2014

Sur la supervision

Création de l’infrastructure technique et logique

Création des règles de supervision

Mise en œuvre de configuration automatique

Reprise de l’existant de solarwinds si nécessaire

Création de checks spécifiques

Généralisation de logstash

Mise en œuvre de statsd et collectd

Documentation et formation des agents

10

Détails 2014

Impact sur le reste de l’infra

Mise en place de gestionnaire central pour les RPM et MSI

Mise en place d’un ordonnanceur

Mise en place d’une interface de visualisation du gestionnaire de sources (git + gitlab couplé à redmine)

Industrialisation de processus infra (déploiement d’appli, mises à jour de sécurité, homogénéisation du parc serveur, …)

Adaptation de l’existant aux nouveaux outils (tomcat, postgres, drupal, sharepoint ? …) s’il reste du temps !

11

Cible (fin 2015)

12

Réalisations à faire en 2015

Amélioration continue (modèle de Deming)

Etude pour le Software Defined Network

Interactions entre outils

Réflexions sur l’intégration continue des

éléments de configurations des serveurs

(gestion de tests automatisés et notions de

build automatiques)

13

Détails 2015

Amélioration continue des configurations, monitoring et de l’automatisation des serveurs

Interactions entre outils (auto-documentation dans redmine à partir des rapports puppet par exemple)

Généralisation de la gestion de configuration centralisée aux équipement réseau (prémices pour le Software Defined Network)

Étude/réalisation pour le provisionning et le déploiement (autour de vmware)

Réflexions sur l’intégration continue des éléments de configurations des serveurs (gestion de tests automatisés et notions de build automatiques)

14

Eléments de macro planning

L’ensemble du projet va prendre 1 an et demi –

2 ans environ, selon l’acceptation par les

équipes et le temps à y consacrer.

Les 6-8 premiers mois : mise en œuvre et

formations

Ensuite sera plus de l’amélioration continue et

augmentation du périmètre couvert

15

Les Freins/Risques

Il faut du temps : pour mettre en œuvre mais surtout pour documenter, sensibiliser l’équipe, et améliorer continuellement le processus.

Implique une évolution des activités et compétences des administrateurs systèmes : de nouvelles méthodes à appréhender qui nécessiteront un accompagnement

C’est souvent un projet ‘non visible’ pour les usagers donc laissé en priorité basse.

16

Les bénéfices 1/2

Mesure de la performance du SI

Visibilité sur les incidents et métriques du SI

Efficacité dans la gestion de problème accrue

Facilité de déploiement et d’évolution du SI

Qualité constante des modifications

Meilleur suivi de l’infrastructure

Augmentation du niveau de sécurité général

17

Les bénéfices 2/2

Plus de temps pour l’amélioration continue

interne et d’autres projets

C’est une des étapes du développement lean et

agile coté infra

C’est le début de la mise en œuvre de la

philosophie DevOps

18

Les références

Des fournisseurs de PAAS et IAAS utilisent

les outils proposés

Des grands noms (google, amazon, facebook,

linkedin…) utilisent ces outils aussi

Ces méthodes et philosophies (DevOps,

lean…) sont aujourd’hui les bonnes pratiques

pour infra et études

19

Questions ?

20