Automatisation de la production

487 vues

Publié le

Présentation faite dans le cadre du début du projet d'automatisation du SI de la Mairie de Noumea.
Elle avait pour but d'expliquer au DSI l'intérêt d'un tel changement.

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
487
Sur SlideShare
0
Issues des intégrations
0
Intégrations
92
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Automatisation de la production

  1. 1. Automatisation de la production Dans le contexte technique de l’infrastructure des serveurs
  2. 2. 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
  3. 3. Définitions 3
  4. 4. 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
  5. 5. L’existant 5
  6. 6. 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
  7. 7. Cible (fin 2014) 7
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. Cible (fin 2015) 12
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. Questions ? 20

×