Processus Internes équipe technique Octopuce

Transcription

1 v. 4 juin 2014 Processus Internes équipe technique Octopuce Introduction Octopuce est un hébergeur d'infrastructures web, opérateur Internet indépendant, et fournisseur d'infogérance pour ses clients. Une garantie de qualité de service (SLA, GTR) et de redondance est proposée à nos clients, qui dépend du type de contrat qui leur est propre. Ce document décrit le fonctionnement formel de l'équipe système et réseau d'octopuce, dans son fonctionnement normal optimal quotidien. Pour les cas dépassant de ce cadre, voir le Plan de Reprise d'activité (PRA) dans sa dernière version. Administration système Toutes les infrastructures gérées par Octopuce le sont de la même manière, dans la mesure du possible (administration système centralisée). Déploiement : Nos systèmes sont déployés à partir d'image système pré-installées, qu'il s'agisse des machines physiques (host) ou des VM LXC ou KVM (guest). On dispose d'images PHY et WHEEZY prête à être déployées sur une nouvelle machine sur une IP disponible. Ces images sont sur la machine physique KOALA, dans /var/lib/lxc. Des scripts shell permettent de la déployer facilement partout ailleurs. Les adresses IP sont obtenues à l'aide du script 3freeip sur UBAL, et les adresses MAC des VM sont générées à la volée par une url sur UBAL, qui alloue au fur et à mesure des MACs de type KVM. Administration générale : Le système Debian installé est géré par Puppet, système d'administration centralisée basée sur des règles de prodution et des classes que l'on coche à la demande, pour chaque machine physique ou virtuelle via notre panel d'administration Puppet permet de gérer de manière centrale les configurations, gestion de graphiques de performance, supervision, sauvegarde etc. de tous les services utilisés : mail (postfix, dovecot, spamassassin, clamav antivirus), web (apache, nginx, tomcat, php, python, nodejs), db (mysql, postgresql, solr, mongodb), système (espace disque, etat des raid, reboot noyau requis, etat des disques physiques, nombre de processus etc.) le Puppet Master est sur UBAL, et sa configuration est centralisée dans un dépôt de source GIT auquel toute l'équipe système à accès. On y trouvera notamment :

2 les règles applicables à tous les clients Les règles spécifiques à certains clients ou serveurs, Les clés SSH de certains clients, que l'on déploie automatiquement sur les machines de ces derniers Les clés et certificats X.509 des sites en HTTPS ou serveurs SSL/TLS. Mises à jour manuelles : Les mises à jour générales et de sécurités au sein d'une même version de Debian (ex Wheezy, Jessie etc.) sont signalées par Nagios et réalisées à la main par un opérateur d'octopuce, utilisant ClusterSSH pour paralléliser ces mises à jour tout en gardant la console d'erreur sous les yeux. On utilise pour cela un script nommé «doupgrade.sh». Il lance 12, 16, consoles sur des serveurs devant être mis à jour et permet à l'opérateur de procéder à l'upgrade. On lance un script «upgrade» sur les serveurs pour procéder à l'upgrade des packages, ce qui fait l'upgrade et le consigne dans le journal de bord (/root/changelog) Ces tâches sont effectuées au quotidien par la personne chargée du support niveau 1 lorsqu'elle n'a pas de tâche de support en cours. Si elle est occupée, elle demande au niveau 2 d'effectuer les mises à jours urgentes. À la fin d'un upgrade de sécurité pour une grappe de machine donnée, l'opérateur détermine si des services doivent être redémarrés, et le cas échéant, les redémarre. Seul les redémarrages complets (noyau) ne sont pas effectués de suite et sont planifiés lors d'une intervention en datacenter (voir plus loin la documentation des interventions au datacenter). Supervision Tous les services simples ou complexes sont supervisés via Nagios sur UBAL. Une seconde supervision externe des services réseaux (ping, http etc.) est mise en place sur BENEDICT, en dehors de notre réseau, qui envoie ses alertes via SMS au téléphone d'astreinte. Chaque service réseau étant supervisé séparémment en IPv4 et IPv6. Évolutions et documentations R&D interne : L'équipe d'octopuce consacre une partie de son temps de travail (environ 10%) à effectuer de la recherche et développements dans le domaine de l'administration système centralisée, l'industrialisation des processus de gestion de services web et mail etc. Cette R&D permet l'amélioration continue de la qualité de nos services, l'adaptation de nos équipe aux nouveaux modes d'hébergement et aux nouveaux logiciels utilisés dans le milieu. Nous publions régulièrement des articles sur le site d'octopuce faisant état de nos études ou des cas pratiques que nous avons appliqués à nos clients Documentation interne Les documentations internes d'octopuce sont disponibles : sur l'intranet d'octopuce ( où l'on trouve l'ensemble des serveurs, leurs site, adressage, configuration et graphiques divers, ainsi que les contacts et sms de chaque client. sur notre outil de gestion de projets ( où l'on trouve les procedures générales d'administration, et les infrastructures spécifiques par client. Ces documentations sont répliquées quotidiennement sur notre infrastructure de supervision secondaire dans un datacenter et sur le réseau IP du groupe Iliad, indépendant d'octopuce. Chaque client disposant d'une infrastructure spécifique voit celle-ci décrite sur un projet spécifique à ce client et accessible au client avec un compte dédié.

3 Support Mail & Téléphone, astreinte, évolutions de fond Support mail & téléphone Le support d'octopuce s'effectue par mail principalement, par un envoi au mail Un support par téléphone est aussi disponible pour les cas nécessitant une interaction immédiate (panne, non disponible) au (numéro fixe non surtaxé, sans robot d'attente) Le support répond aux horaires de bureau (du lundi au vendredi de 9h à 18h). En dehors de ces horaires, voir «astreinte» plus bas. Le personnel d'octopuce est affecté aux tâches de support de niveau 1 ou 2, par journée ou demi-journée dans l'agenda interne. Les modifications à ce calendrier ne peuvent être apportées que par le directeur général. L'ingénieur au support niveau 1 (le «N1») est chargé de répondre aux appels téléphoniques, il peut traiter le sujet immédiatement si ce dernier est critique (panne) ou prend peut de temps à être réalisé. Dans le cas contraire, il traite les problèmes selon leur ordre d'importance estimée. Si un client au téléphone demande à parler à un autre salarié, le N1 essaye de déterminer si cela est nécessaire et juge s'il transmet l'appel (à éviter), annonce que le salarié demandé rappellera, ou traite le problème lui-même. En absence d'appel téléphonique, le N1 répond aux mails envoyés sur la boite mail du support, et traite et archive les mails au fur et à mesure. En début de journée, il fait le point avec la personne qui avait le N1 la veille. Si des problèmes critiques existent en fin de journée, il rapporte ces derniers à la direction Lorsque le N1 ne sait pas résoudre un problème, il demande au N2 de l'aider à le résoudre, ou, si la charge de travail est importante, de lui résoudre directement. Enfin, lorsque le N1 est déjà au téléphone et que ce dernier sonne en parallèle, le N2 prend l'appel. Astreinte hors des heures de bureau En dehors des horaires de bureau, l'astreinte est confiée (habituellement pour une semaine calendaire complète) à un membre de l'équipe, (nommé «Astreinte»). Ainsi, on assure une astreinte 24/7/365 L'Astreinte reçoit les alertes Nagios par SMS sur le téléphone rouge. Il doit s'assurer de disposer à tout moment d'un ordinateur avec accès à Internet (3G ok), d'un accès au VPN d'octopuce permettant l'accès aux LANs d'administration, de l'accès à la copie distante de l'octomanager (intranet d'octopuce), des contacts 24/7 des NOC dans les datacenters où nous disposons d'équipements réseau ou hébergement, et reste physiquement présent en Île-de-France (et s'il n'est pas à portée de métro / rer, il doit disposer d'un véhicule) Évolutions de fond Les évolutions de fond des services d'octopuce sont réalisés par les salariés dès lors qu'ils n'ont pas de support N1 ou N2 à réaliser, ou qu'ils ne sont ni N1 ni N2 ce jour là. À ce jour, les salariés sont plus particulièrement chargés des tâches de fond suivantes : Alban : développement des fiches pratiques (cheatsheets) d'octopuce, sites web de la société et de ses marques et projets internes, développements des progiciels Octopuce (FocusManager, OpenMediaKit, OffWave, AlternC ) Guillaume : évolution des systèmes (mises à jour majeurs de Debian), vérifications diverses (processus, backups, sécurité ssl...) Benjamin : évolutions de Puppet, du Panel (avec Alban), des checks Nagios, des routeurs et de BGP, de l'infrastructure réseau physique en datacenter. Ces évolutions de fond, pour la partie système et réseau, sont gérées par des tickets dans le Redmine dans le projets «admin». Benjamin gère ces tickets et les affecte. Réunion hebdomadaire.

4 Tous les lundi matin (à défaut dès que l'équipe est au 2/3 présent dans les locaux) une réunion hebdomadaire est effectuée, qui ne dépasse pas 1H. On y traite les news de la semaine passée les tâche prévues pour chacun pour la semaine à venir, par salarié L'intervention prévue si besoin en datacenter, Les tickets du redmine projet «admin» résolus et à venir, Les absences prévues pour les 2 semaines à venir. Divers Noms de domaines Les noms de domaines qu'octopuce enregistre pour ses clients ont toujours comme propriétaire le client, et jamais Octopuce ou un de ses salariés. Seule exception : à la demande signée d'un client. Réversibilité des services En cas de départ d'un client, Octopuce s'engage à faire le nécessaire pour permettre une migration d'octopuce à un autre hébergeur dans les meilleurs conditions. Ce principe est fondamental et affirmé par Octopuce, dans l'esprit du logiciel libre de transparence et de loyauté envers nos clients. Limite de notre administration Octopuce fournit de l'hébergement de serveurs administrés. Nous nous chargeons d'assurer que les services système (noyau, accès aux disque, accès au réseau etc.) fonctionnent au mieux, ainsi que les services réseaux et bases de données (web, solr, memcache, mail, db, tomcat, etc.) Les applications de nos clients (cms, erp, clouds, boutique, applictions métier etc.) ne sont jamais de notre ressort, et s'il advient qu'une application met en péril d'autres infrastructure (typiquement en mode mutualisé) nous nous réservons le droit de couper une application le temps que le client réduise le risque. Cependant, bien que nous ne gérions pas ces applications, nous faisons de telle sorte que nos compétences dans le développement logiciel aident au mieux nos clients, dans la mesure du temps disponible par l'équipe système. Ainsi il est possible que nous conseillons un client pour l'optimisation de son code, l'ajout de procédures de verrouillage de tâche planifiée, d'index dans une base de données etc. Ces conseils, bien que fournis volontairement par Octopuce, ne font en aucun cas partie du contrat et ne pourraient pas être exigés à l'avenir. Sauvegardes Enfin, si Octopuce effectue automatiquement des sauvegardes quotidiennes et hebdomadaires de toutes les données de tous les serveurs que nous administrons, il ne s'agit d'une assurance que contre les erreurs de nos propres ingénieurs système et réseau. Aussi, en cas de perte de données par un client, nous ne garantissons pas de pouvoir restaurer à partir de la sauvegarde réalisée par Octopuce. Notons que cela ne nous empêche pas de faire le maximum pour que ces sauvegardes soient fiables, mais elles ne sont en aucun cas un service fournit contractuellement à nos clients. Intervention en datacenter Lorsqu'une intervention en datacenter est prévisible et implique le reboot d'un serveur physique ou virtuel, les clients concernés par ce reboot doivent être prévenus au moins 3 jours ouvrés avant l'intervention, et doivent donner leur accord pour celle-ci. Un mail après l'intervention leur est envoyé pour signaler que celle-ci s'est bien déroulée. Si une intervention en urgence a lieu (changement d'un disque dur défectueux d'un RAID) ou en grande urgence (problème grave nécessitant une intervention immédiate) on prévient le client de cette intervention, on intervient, et on prévient le client à la fin de l'intervention, avec un sujet de mail explicite «[fin d'intervention] blabla...» Les reboot de machines physiques, pour changement de noyau, mise à jour de firmware ou changement de disque non hot-plug, doivent être effectués avec un salarié sur place pour pouvoir gérer un reboot ne se

5 déroulant pas bien. Ce salarié disposera toujours avec lui d'une clé USB debian 64 bits bootable.