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.

1. Automatisation de la production
Dans le contexte technique de
l’infrastructure des serveurs

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. Définitions
3

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. L’existant
5

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. Cible (fin 2014)
7

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. 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. 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. 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. Cible (fin 2015)
12

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. 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. 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. 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. 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. 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. 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. Questions ?
20