Une panne généralisé du système a eu lieu. Découvrez le Post-mortem de l’incident
1 – LES GRANDES LIGNES
Le 02/04/20 à 18h00 UTC+1, l’ensemble des services de la Compiègne Geek Convention sont tombées en panne.
Ce problème technique a été résolu le 02/04/20 à 18h25 UTC+1.
2 – SITUATION INITIALE ET DISRUPTIVE
Nous rencontrons depuis plusieurs jours des soucis avec les modules de PHP.
Certains services comme WordPress demandent d’utiliser des modules spécifiques, essentiels à la vie du CMS.
Seulement, depuis plusieurs jours, les services concernées (principalement le Cloud et le Site Principal) indiquent que les modules sont « introuvables » alors qu’ils sont naturellement activés dans le CPanel.
Depuis le début de l’après-midi (≈15h00), je regarde dans le CPanel ce qui aurait pu faire en sorte de faire planter PHP. LWS ne laissant pas la possibilité de modifier les fichiers sources d’Apache et de PHP, j’ai donc essayé de chercher des solutions dans différents forums.
En modifiant les versions de PHP, je me suis rendu compte que notre version « hérité » était la 5.0, version abandonnée des supports de PHP.
Après plusieurs heures à chercher une solution afin de réactiver ses modules et de les rendre « détectables » par le Cloud et le CMS Wordpress, j’ai décidé de contacter LWS pour essayer de trouver une solution avec les techniciens. Une solution m’est apportée aux environs de 18h00 : il s’agirait d’un problème de version.
Le technicien répondant me propose de passer ma version de PHP dans une version autre : ALT-PHP. C’est ainsi que je me dirige vers la page correspondant aux changements de version et que j’active cette version.
Cette version entraîne une non-reconnaissance des fichiers PHP du site web. Le serveur faisait télécharger le fichier demandé au client sans l’exécuter comme il devrait le faire originellement.
Ce souci technique a entraîné le fait que tous les services ne s’exécutaient pas aux yeux du serveur et donc a entraîné la panne générale.
Après des recherches, j’ai découvert qu’en changeant de version, Apache avait naturellement mis un nouveau gestionnaire. Après des minutes de bidouillage, tous les fichiers PHP et autres s’exécutaient comme à l’origine. Le retour progressif de tous les services avait commencé. C’est tout d’abord le site principal et le Cloud qui sont revenus à la normale très vite. Les sites secondaires, en cours de développement, ont eu plus du mal à revenir à la normale mais y sont finalement revenus.
3 – Déroulé chronologique et technique de l’incident
- 02 avril 18h00 : le technicien m’informe d’une solution probable aux soucis que nous rencontrons
- 02 avril 18h02 : j’actionne la nouvelle version de PHP (alt-php74)
- 02 avril 18h05 : nouvelle version de PHP en place, début de l’incident avec la panne soudaine de tous les services
- 02 avril 18h07 : déclenchement de l’alerte sur la page de statut du site.
- 02 avril 18h10 : découverte d’un gestionnaire Apache en trop, suppression de ces gestionnaires.
- 02 avril 18h12 : retour progressif des services suivants : Site Principal, Cloud, Serveur Mails.Les sites secondaires sont toujours en panne.
- 02 avril 18h18 : les sites secondaires reviennent progressivement avec un délai de réponse assez long.
- 02 avril 18h25 : après 20 minutes de surveillance, tous les services sont opérationnels. Fin d’incident.
3 – Postmortem: que s’est-il passé?
L’origine de cet incident n’est pas d’origine humaine d’après le fait que l’incident se soit déclaré qu’une fois la nouvelle version enclenchée.
L’incident est donc probablement lié au serveur qui n’a pas pu effectuer la mise à jour correctement.
La durée de l’incident étant de 20 minutes, nous pouvons considérer qu’il ne s’agit pas d’une issue majeure.
1) Pourquoi ses services étaient en panne ?
Les services étaient en panne suite à une mauvaise installation de la nouvelle version de PHP.
2) Pourquoi l’installation de cette version a posée problème ?
Nous ne savons pas pourquoi cette installation a posée problème.
Plan de mesures suite à cet incident :
- Mise en place d’une surveillance plus approfondie sur le site et ses services. C’est un travail qui sera effectué tout au long de l’année.
- Documenter avec précision la version de PHP et essayer de comprendre comment nous aurions pu éviter cet incident.