Sujet récurrent du monde des systèmes d’information (SI), les mises en production impactent fortement l’entreprise et sa capacité à faire évoluer son SI, en particulier ses services en ligne. La révolution d’internet a rendu les mises en production critiques pour tous les services fonctionnant en continu et nécessitant des arrêts de service réduits au minimum . Nous étudierons dans cette série d’articles le cas spécifique des mises en production le vendredi, un débat récurrent chaque semaine sur les réseaux sociaux de la communauté tech.
Nous étudierons trois cas spécifiques de structure de SI et d’entreprise, mais ces trois cas auront tous en commun de concerner des entreprises qui offrent des services en ligne critiques (24×7, services rapportant beaucoup d’argent à l’entreprise et/ou vitales pour son image) pour le fonctionnement de l’entreprise, le cas des structures hébergeant des services non-critiques ne nous intéressant pas.
L’entreprise pas ou peu agile sans CI/CD
Le premier cas étudié sera celui d’une entreprise peu ou pas agile dans le développement, s’étant habituée à délivrer son logiciel à date à peu près fixe dans l’année, par exemple une fois tous les deux mois. Chaque version inclut de nombreux changements. Chaque mise en production nécessite les paramètres suivants :
- une nouvelle version du code prévue pour fonctionner sur la production.
- une infrastructure prête à accueillir les nouveaux paramètres de la nouvelle version déployée (base de données, cache,…).
- un référent capable de comprendre comment va fonctionner le code en production, on l’appellera le développeur.
- un administrateur système qui va déposer le code en production et redémarrer les services concernés.
Il est important de noter que, de par le manque de CI/CD permettant de déployer automatiquement une nouvelle version du code, chaque mise en production est, dans ce type d’entreprise, un processus majoritairement manuel avec les risques inhérents que cela implique, à savoir les erreurs humaines.
Les détails de la mise en production
Dans notre exemple, pour le déploiement du mois d’avril, la date correspond à un vendredi. Une période d’indisponibilité est estimée à une heure. Elle aura lieu tôt le matin, où le pic de trafic est le plus faible. Le jour venu, le développeur et le sysadmin travaillent ensemble afin de créer la base de données manquante et redémarrer les services applicatifs concernés par la nouvelle version du code. Suite à la mise en production, des tests fonctionnels sont effectués manuellement par le développeur.
À 16h, des problèmes sont remontés par les exploitants de l’application. Le développeur et le sysadmin essaient de comprendre, un patch est livré en urgence et réinstallé sur l’infrastructure. Il est 19h, tout le monde est épuisé, dès que les tests manuels basiques passent, tout le monde rentre précipitamment chez soi. Le sysadmin part en vacances à l’étranger pour le week-end et attrape son avion in-extremis.
Le début des ennuis de la mise en production le vendredi
Samedi à 4h du matin, des processus applicatifs sont automatiquement exécutés et retournent des erreurs, des tables ne sont pas mises à jour à cause de ces erreurs et le site web tombe quelques minutes plus tard, car les données générées par les batchs ont un format qui ne correspond plus à celui attendu par la nouvelle base créée vendredi.
À 16h samedi, un manager de l’entreprise tente d’accéder à un des services lors d’une utilisation personnelle. Il se rend compte que le site web est devenu injoignable. Il tente de joindre immédiatement le sysadmin, mais le téléphone portable de ce dernier ne répond pas. En effet ce dernier est en week-end à l’étranger.
Le plus haut niveau est escaladé et le chef de l’entreprise réussit finalement à joindre le développeur sur son téléphone personnel. Ce dernier n’est pas à l’aise avec l’administration système et n’a pas les droits nécessaires lui-même à régler la situation.
Dimanche à 17h, le sysadmin de retour de son week-end, voit les nombreux messages et joint le développeur. Les deux réussissent à relancer l’application dimanche à 19h.
Le post-mortem de cette mise en production le vendredi
- La mise en production a bien eu lieu le vendredi, mais une partie a été oubliée : les batchs applicatifs du samedi.
- Un premier problème en fin de journée le vendredi a déjà fatigué l’équipe technique.
- L’indisponibilité des personnes à même de régler le problème a engendré une indisponibilité du service pendant 39 heures.
- L’absence d’une astreinte réelle et bien organisée a entraîné la prise en charge tardive du problème.
Conclusion
Ce premier article sur la mise en production du vendredi montre un cas courant d’incident dans une entreprise peu ou pas agile pour laquelle les mises en production représentent toujours aujourd’hui un problème. L’absence de CI/CD rend pénible et épuisante les livraisons logicielles en production. Aucun référent bien identifié n’était disponible et les personnes mobilisées l’ont été de manière informelle, aucune astreinte réelle n’ayant été mise en place.
Il s’agit bien sûr d’un exemple et toutes les variations sont envisageables. Le sysadmin peut ne pas partir en vacances, le développeur aurait pu anticiper les batchs… Et c’est d’ailleurs ce qui arrive le plus souvent, on arrive à mener à bout sans incident une mise en production le vendredi. Mais dans le modèle présenté aujourd’hui, les événements et les circonstances ont entraîné une indisponibilité inacceptable pour l’entreprise. Des mesures de corrections devront être prises pour éviter de le renouveler.
Dans cette situation bien précise qui représente la réalité de l’organisation et de l’état de l’art du SI de l’entreprise, interdire les mises en production le vendredi permettrait d’éviter une rupture de service aussi longue à l’avenir, tant que des améliorations décisives n’ont pas été apportées, le évolutions d’un SI demandant une volonté politique en interne et des investissement qu’il est parfois très difficile d’obtenir.
Dans le prochain article, nous étudierons le cas d’une entreprise agile dans le développement de ses applications sans astreinte.
Me suivre sur les réseaux sociaux
Carl Chenet, architecte infrastructure. N’hésitez pas à me suivre directement sur mes différents sociaux :
- Mastodon : @carlchenet
- Twitter : @carl_chenet
Merci Carl,
Cet article s’est lu comme un bon Guillaume Musso, vivement le prochain !
Plus sérieusement, cela rappelle certaines mises en prod catastrophiques auxquelles j’ai pu malheureusement assister.
A l’opposé, j’ai également pu assister à des mises en prod le vendredi qui se sont résumées à quelques commandes et qui ont duré max 10 minutes.
Mais je suis persuadé que l’on verra dans les prochains articles comment éviter tout ce stress inutile 😉
Intéressant mais tout n’est pas bien clair non plus.
La coupure le vendredi n’était pas un souci pour les utilisateurs mais un souci en cas de coupure le weekend ? (c’est pas vraiment présenté comme cela, surtout si l’admin sys est en repos le jour de la plus forte affluence du service).
Un mise à jour le lundi, avec comme cas extreme la mise en arrêt maladie de l’admin sys le mardi, n’aurait pas non plus permis un rétablissement du service rapidement (pareil s c’était le dev, vu que dans l’exemple il n’y avait que 2 personnes disponible).
De mon point de vue, l’arrêt et la mise à jour doivent être en relation avec le moment où c’est le moins critique pour la monté en charge suite à la mise à jour (donc au moment où en cas de souci, l’affluence n’est pas critique pour l’entreprise).
Si je coupe le service en milieu de semaine en milieu de journée et que c’est le moment de plus forte affluence du service, les équipes seront aussi hyper fatigué/stressé. La direction ne sera pas contente de la coupure du service, alors que bon “c’est pas fait le vendredi”.
Dans une industrie, on ne met pas à jour la production en pleins milieu de semaine quand les chaîne de montage tourne à pleins régime 🙂
Les processus applicatifs qui pointent leurs nez le samedi matin sont-ils quotidiens ou hebdomadaires ? Dans le deuxième cas, quelque soit le jour de mise en production choisi, toutes choses égales par ailleurs, l’incident du weekend aurait été similaire.
Super article.