Lorsque nous hébergeons nous-mêmes nos applications Web, les risques d'avoir un bris de service peuvent être plus élevés. Une mise à jour qui ne s'est pas bien déroulée ou l'ajout d'un nouveau logiciel peut provoquer bien des incidents. Certains de ceux-ci peuvent être plus graves que d'autres.
Je souhaite aujourd'hui revenir sur un incident de production qui m'est personnellement arrivé cette année et qui a impacté mon site Web www.benjaminrancourt.ca. Heureusement, aucun de mes clients n'a été touché comme ils sont sur d'autres serveurs! 😅
Résultat : le dimanche 22 mai 2022, mon site Web a été indisponible pendant près de 10 h. Voici ci-dessous un retour sur les événements.
Retour sur les événements
10 h
Après avoir effectué la mise à jour mensuelle de mes applications, je commence à regarder pour mettre en place ma stratégie personnelle pour sauvegarder les bases de données de mon serveur. Je souhaite en effet avoir une meilleure fréquence de sauvegarde que celle que mon fournisseur, DigitalOcean, me propose.
10 h 45
Ayant fini de coder mon script de sauvegarde, je le téléverse sur mon serveur, mais je me rends compte rapidement qu'il ne fonctionne pas à cause qu'une des dépendances de mon script, Git, n'est pas à jour. 😅
Je tente de la mettre à jour, mais j'avais déjà la dernière version stable pour ma distribution, Debian. En effet, à ce moment-là, mon serveur roulait sur Debian 10 (buster), qui était la précédente version stable.
Je me suis donc dit qu'afin de mettre facilement Git à jour, je n'avais qu'à passer ma distribution à Debian 11 (bullseye), qui est sortie peu de temps après que j'aie initialement monté mon serveur.
Je ne savais pas à ce moment que je venais de commettre une erreur fatale! 😓
11 h
Quelques lectures plus tard, je lance des commandes pour passer à Debian 11. Les commandes ne semblent pas bien se dérouler et je constate que mon site Web ne répond plus. Je redémarre mon Droplet, mais le problème persiste. 😯
Je continue de fouiller, d'essayer des commandes, de redémarrer mon serveur : rien ne fonctionne. 😖
Voyant le temps s'écouler rapidement et ayant besoin de me préparer pour un événement familial, je me résouds : j'ai décidé de laisser mon site Web non disponible pour la journée. Je poursuivrai le rétablissement de mon site Web à mon retour ou le lendemain.
Hey oui, comme mon seul client était moi-même, j'ai pu décider que cet incident de production n'était pas ma priorité #1 à très court terme. Aucune vie humaine n'était en jeu et cela n'engendrerait pas de perte financière! Ma décision aurait probablement été différente si c'était le site d'un client, mais ce n'était pas le cas ici! 🙃
Le nombre exact de visiteurs est probablement beaucoup plus petit, étant donné que c'était un dimanche et que mes articles sont principalement lus en semaine. 😏
21 h
De retour à la maison, je vérifie si mon site Web est soudainement revenu à la vie; mais ce n'était pas le cas! 😞
J'avais donc deux choix qui s'offraient à moi :
- Je récupère la dernière sauvegarde effectuée par DigitalOcean.
- Je remonte complètement un autre serveur à côté et je réplique mon architecture.
Ne souhaitant pas perdre entre 3 et 4 jours de données, j'ai finalement opté pour le deuxième choix.
Heureusement pour moi, je tente toujours de laisser quelques notes des actions et des commandes que j'effectue! J'ai donc pu facilement recréer un serveur quasi identique en parallèle. J'en ai également profité pour documenter un peu plus certains bouts qui en avaient besoin. 😎
De plus, comme j'avais encore accès à mon ancien serveur, j'ai été en mesure de copier tous les fichiers nécessaires à mes applications.
Une demi-heure plus tard, mon site Web était de nouveau en ligne après que j'ai pu faire pointer mon domaine vers mon nouveau serveur. 🥳
J'ai pu aller me coucher en paix et je me suis dit qu'il y avait beaucoup d'apprentissages à tirer de cette expérience! 😅
Ce que j'ai appris
Cela m'était déjà arrivé par le passé de rendre mon site Web personnel non-disponible pendant quelques instants, mais c'était la première fois que l'interruption a duré plusieurs heures. 😥
Afin qu'une telle situation ne se reproduise plus, j'en ai tiré quelques leçons et j'ai procédé à quelques actions. 😉
Augmenter la fréquence de sauvegarde
Bien que j'avais en ma possession une sauvegarde complète de mon serveur, j'ai préféré ne pas l'utiliser. Pourquoi? Car j'aurais perdu quelques jours de données, principalement des statistiques. Et comme je ne me souvenais pas si j'avais écrit des articles dans les derniers jours, j'ai préféré ne pas prendre de chance. 😕
Bien que cela soit pratique que DigitalOcean prenne une sauvegarde complète du serveur une fois par semaine (moyennant des frais), cette fréquence n'était visiblement pas élevée à mon goût...
Je me suis donc créé un script de sauvegarde qui s'exécute à une fréquence plus régulière : 15 minutes. Si pour une raison ou une autre je devais remonter mon serveur, je pourrais perdre au maximum 15 minutes de travail, ce qui est plus raisonnable pour moi. 😅
Privilégier Docker pour la création de mes scripts
En souhaitant aller plus vite, je me suis planté sur des dépendances système qui n'étaient pas à jour et cela a été le déclencheur qui a mené à rendre mon serveur non fonctionnel. 😤
En privilégiant des conteneurs Docker, s'il y a un logiciel qui fait des bêtises, il y aurait eu moins de chance qu'il entraîne l'indisponibilité du serveur au complet. Du moins, si l'on suit les bonnes pratiques et qu'on le limite correctement dans ses interactions envers les ressources du serveur. 😋
Apprendre comment mettre à jour à la version majeure de Debian
Après avoir infructueusement tenté de passer à la prochaine version majeure de Debian, il est clair que je n'étais pas préparé à faire cette action!
Je souhaite donc me renseigner sur la procédure à suivre pour effectuer la prochaine migration sans souci. Selon mon estimation, j'aurai approximativement jusqu'à septembre 2023 pour acquérir ces connaissances, d'ici la prochaine version LTS (Long Term Support), Debian 12 (bookworm). 😆
Conclusion
Des incidents de production peuvent arriver à n'importe qui à n'importe quel moment! En fonction des risques, cela peut valoir la peine d'investir du temps dans la sauvegarde ET la récupération d'une sauvegarde!
Et vous, vous est-il déjà arrivé de mettre hors production votre site Web personnel? Qu'avez-vous appris de cela? 🤗
