Bon j'ai une mauvaise nouvelle: empêcher les attaques, les pannes matérielles ou les erreurs de manipulation est impossible.
Heureusement, il est possible de contourner ces problèmes en mettant en place différentes stratégies pour aboutir à une solution à la fois fiable et évolutive.
La plupart des hébergeurs offrent un contrat de SLA (Service Level Agreement) qui garantit une disponibilité minimale de bon fonctionnement de leurs services.
Pour les solutions courantes, il est difficile de trouver un hébergement qui offre un SLA supérieur à 99,9%. Ca à l'air beaucoup comme ça, mais sur un an, ça fait tout de même 265 x 24 x 60 x 0,1 /100 = 525 minutes, soit presque dix heures (on est loin des 13 minutes d'Amazon !).
Conseils d’ami
- La définition de la couche logicielle (software stack) et de l'environnement serveur doivent faire partie du "code source" de votre produit digital
- Tirez parti du versionning et de l'intégration continue
- Utilisez un environnement virtuel : couplé avec la définition de votre environnement, ça permet une duplication rapide pour des environnements de staging, de test ou de développement
- Utilisez des IP fail-over et du load-balancing
- Au niveau infrastructure, privilégiez les machines virtuelles VPS (virtual private server), cela vous permettra de scaler le moment venu pour peu de frais
Ci-dessous, je reprends les stratégies qui peuvent être mises en places concernant les points abordés précédemment : sécurité, développement et technologies (si ça vous paraît trop technique, n’hésitez pas à passer directement au point suivant intitulé « Concrètement »).
La visibilité de la sécurité
Le plus important d’après moi est d’avoir une vision claire sur l'état du système :
- points d'entrées identifiés et minimisés : au niveau des services (daemon : firewall / ports) et des applications (scripts & users) ;
- suivi des tentatives d'échec de connexion ;
- système de centralisation des mots de passe qui permet de valider leur niveau de sécurité et de les (faire) modifier à intervalle régulier.
Le développement continu
Si vous êtes à tout moment en mesure de :
- dupliquer l’instance de production de votre produit pour tester de nouvelles fonctionnalités sur une instance temporaire ;
- vérifier que les dernières mises à jour ne « cassent » pas des fonctionnalités existantes ;
- faire travailler plusieurs équipes en parallèle sur la dernière version de votre produit,
alors vous êtes sur la bonne voie !
Dans le cas contraire, vous avez besoin d’outils vous permettant de faire :
- de l’intégration continue (Travis CI, Jenkins)
- de la gestion de version (git, svn)
- de la virtualization (docker, lxc)
Le levier des technologies
Au niveau technique, voici les mécanismes qui devraient être mis en place de manière systématique (ou presque) :
- redondance matérielle (RAM, HD)
- IP FO (fail-over)
- load balancing
- monitoring (downtime tracking)
Dans tous les cas, vous aurez aussi besoin de planifier les moments de maintenance : pour pouvoir minimiser le downtime et l'organiser au bon moment (si vous avez un service worldwide, ce sera sans doute le week-end, sinon en dehors des heures de bureau devrait être acceptable).
Concrètement
Les questions à vous poser ou à poser à votre hébergeur, à votre agence de communication, à votre équipe de développement, ou à votre ami « hyper-doué-en-informatique » :
Maîtriser les backups (et donc en avoir !)
- quand sont réalisés les backups ?
- comment sont sauvegardées les données (backup incrémental ou complet) ?
- où sont sauvegardées les données : même serveur / autre serveur ?
- comment restaurer à partir d'un backup ?
- combien de temps pour restaurer une version sauvegardée ?
- que se passe-t-il pendant cet intervalle de temps (que voit-on sur le site) ?
Prévoir les défaillances
En cas de défaillance :
- en cas de défaillance matérielle, le système est-il redondant (RAID, RAIM) ?
- en cas de défaillance logicielle, y a-t-il un fail-over ?
- est-il possible à tout moment de basculer vers une page de maintenance ?
Anticiper les surcharges
En cas de surcharge :
- y a t-il un load balancer ?
- est-il possible d'augmenter les ressources allouées (ou de passer à un hébergement plus robuste avec un downtime raisonnable - de moins de 2 heures) ?
