Re: Outils/Procédures de suivi d'action en prod ?
alut, le soucis d'après ce que tu dis c'est que tu est dans un mode SCRUM, pas adapté du tout à de la prod/exploit/MCO .C'est très hype de faire le l'agile et du SCRUM mais passe plutot dans un mode kanban voir scrumban si le client y tien, mais adopte aussi une approche ITIL, certes moins souple et moins "agile" mais plus efficace dans ce type d'environnement. C'est essentiellement des process a adopter (CR après un incident en prod, mise en place d'une équipe de réponse lors de l'incident, comité de validation des changements, ...) et non un outil. Si tu ne maitrises pas fait appel à un spécialiste ou forme toi.Pour les outils type confluence je sais d'expérience que si personne ne se dévoues pour maintenir et créer une norme/process de mise à jour/intégration des informations, ce truc c'est juste un trou noir ou disparaissent les infos ...Olivier. Le mercredi 19 avril 2023 à 23:55:30 UTC+2, Ludovic Scotti <tontonlud@gmail.com> a écrit : @job on est certifié SMSI (ISO 27001). Donc toutes les actions de prod sont tracées dans notre outil ITSM.Pour faire un changement en prod (hors incident), c'est ticket obligatoire, comité d'approvisionnement de changement et une fois que tu as l'autorisation, tu peux faire le changement. Sur incident c'est un peut plus guinguette, mais c'est tracé tout de même, au bon vouloir de ce celui qui traite l'incident.Derrière on a des incident managers qui vérifient ce qui est fait sur incident. Ludovic Le mer. 19 avr. 2023, 15:38, Etienne Magro via FRsAG <frsag@frsag.org> a écrit : Bonjour à tous, Vous utilisez quoi, pour historisez vos actions en prod ? Aujourd'hui, on utilise du jira pour les actions futures à faire et ce que les clients nous demande, on a aussi un tableau dans un confluence pour y inscrire les actions (manuelles ou manuellement déclenchées) qu'on fait sur les serveurs, sans compter le chat interne et notre supervision. C'est pas génial pour s'y retrouver et faire le lien entre Toto qui a modifié une conf nginx à la main la semaine dernière en douce, suite à une alerte supervision ou une demande des chefs et Bibi qui cherche pourquoi son /var/log explose depuis. Surtout si le ticket jira n'existe pas/plus et qu'on a oublié de compléter le tableau à what-mille-lignes. Donc avec l'équipe, on est en pleine réflexion sur comment on peut standardiser ça, et "enforcer" une procédure (avec éventuellement un nouvel outil pour les remplacer tous). Vous faites comment, vous ? Etienne _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s FRsAG | | | | FRsAG | | |
Salut, Imo la meilleure méthode reste d'avoir une notification quelconque lors du déploiement en production (qui se fait, et est déclenché généralement via un outil quelconque: Kubernetes, Ansible, Puppet...). Suffit ensuite d'historiser ça quelque part pour avoir un audit trail (avec quelques labels qui vont bien: environment, host, user...), qui peut être ensuite enrichi au besoin si de nouvelles méthodes de déploiements/exécution d'actions arrivent, ou quelques logs système/API intéressants (qui a ssh sur quelle machine etc). Cela ne gère certes pas les actions manuelles mais si elles sont peu courantes (par exemple, pour gérer un incident) et qu'elles ne sont pas oubliées ce n'est pas un problème. Et si elles sont oubliées et jamais backport dans l'outil d'IaaS ou autre le problème est ailleurs, dans la procédure de suivi d'incidents par exemple pour le cas cité précédemment. mcorbin Le sam. 22 avr. 2023 à 19:06, Olivier Meyer via FRsAG <frsag@frsag.org> a écrit :
alut, le soucis d'après ce que tu dis c'est que tu est dans un mode SCRUM, pas adapté du tout à de la prod/exploit/MCO .C'est très hype de faire le l'agile et du SCRUM mais passe plutot dans un mode kanban voir scrumban si le client y tien, mais adopte aussi une approche ITIL, certes moins souple et moins "agile" mais plus efficace dans ce type d'environnement. C'est essentiellement des process a adopter (CR après un incident en prod, mise en place d'une équipe de réponse lors de l'incident, comité de validation des changements, ...) et non un outil. Si tu ne maitrises pas fait appel à un spécialiste ou forme toi. Pour les outils type confluence je sais d'expérience que si personne ne se dévoues pour maintenir et créer une norme/process de mise à jour/intégration des informations, ce truc c'est juste un trou noir ou disparaissent les infos ... Olivier.
Le mercredi 19 avril 2023 à 23:55:30 UTC+2, Ludovic Scotti < tontonlud@gmail.com> a écrit :
@job on est certifié SMSI (ISO 27001). Donc toutes les actions de prod sont tracées dans notre outil ITSM. Pour faire un changement en prod (hors incident), c'est ticket obligatoire, comité d'approvisionnement de changement et une fois que tu as l'autorisation, tu peux faire le changement.
Sur incident c'est un peut plus guinguette, mais c'est tracé tout de même, au bon vouloir de ce celui qui traite l'incident. Derrière on a des incident managers qui vérifient ce qui est fait sur incident.
Ludovic
Le mer. 19 avr. 2023, 15:38, Etienne Magro via FRsAG <frsag@frsag.org> a écrit :
Bonjour à tous,
Vous utilisez quoi, pour historisez vos actions en prod ?
Aujourd'hui, on utilise du jira pour les actions futures à faire et ce que les clients nous demande, on a aussi un tableau dans un confluence pour y inscrire les actions (manuelles ou manuellement déclenchées) qu'on fait sur les serveurs, sans compter le chat interne et notre supervision. C'est pas génial pour s'y retrouver et faire le lien entre Toto qui a modifié une conf nginx à la main la semaine dernière en douce, suite à une alerte supervision ou une demande des chefs et Bibi qui cherche pourquoi son /var/log explose depuis. Surtout si le ticket jira n'existe pas/plus et qu'on a oublié de compléter le tableau à what-mille-lignes.
Donc avec l'équipe, on est en pleine réflexion sur comment on peut standardiser ça, et "enforcer" une procédure (avec éventuellement un nouvel outil pour les remplacer tous). Vous faites comment, vous ?
Etienne _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s FRsAG <http://www.frsag.org/>
FRsAG
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour, En terme de tooling, en dehors des outils déjà mentionnés, j'avoue être friand du couple mattermost/gitlab (mais chacun son truc ...). On renseigne une issue Gitlab sur un projet qui correspondrait à des éléments de prod (ex. : un dépôt de recette ansible/saltstack/...), le ticket est remonté dans mattermost, puis on a le suivi des actions dans le ticket avec éventuellement les correctifs associés dans le dépôt. Ca n'enlève en rien les autres besoins évoqués dans ce thread (kanban, log des actions, etc...). My 2 cts, Le 23/04/2023 à 16:48, Mathieu Corbin a écrit :
Salut,
Imo la meilleure méthode reste d'avoir une notification quelconque lors du déploiement en production (qui se fait, et est déclenché généralement via un outil quelconque: Kubernetes, Ansible, Puppet...). Suffit ensuite d'historiser ça quelque part pour avoir un audit trail (avec quelques labels qui vont bien: environment, host, user...), qui peut être ensuite enrichi au besoin si de nouvelles méthodes de déploiements/exécution d'actions arrivent, ou quelques logs système/API intéressants (qui a ssh sur quelle machine etc).
Cela ne gère certes pas les actions manuelles mais si elles sont peu courantes (par exemple, pour gérer un incident) et qu'elles ne sont pas oubliées ce n'est pas un problème. Et si elles sont oubliées et jamais backport dans l'outil d'IaaS ou autre le problème est ailleurs, dans la procédure de suivi d'incidents par exemple pour le cas cité précédemment.
mcorbin
Le sam. 22 avr. 2023 à 19:06, Olivier Meyer via FRsAG <frsag@frsag.org> a écrit :
alut, le soucis d'après ce que tu dis c'est que tu est dans un mode SCRUM, pas adapté du tout à de la prod/exploit/MCO .C'est très hype de faire le l'agile et du SCRUM mais passe plutot dans un mode kanban voir scrumban si le client y tien, mais adopte aussi une approche ITIL, certes moins souple et moins "agile" mais plus efficace dans ce type d'environnement. C'est essentiellement des process a adopter (CR après un incident en prod, mise en place d'une équipe de réponse lors de l'incident, comité de validation des changements, ...) et non un outil. Si tu ne maitrises pas fait appel à un spécialiste ou forme toi. Pour les outils type confluence je sais d'expérience que si personne ne se dévoues pour maintenir et créer une norme/process de mise à jour/intégration des informations, ce truc c'est juste un trou noir ou disparaissent les infos ... Olivier.
Le mercredi 19 avril 2023 à 23:55:30 UTC+2, Ludovic Scotti <tontonlud@gmail.com> a écrit :
@job on est certifié SMSI (ISO 27001). Donc toutes les actions de prod sont tracées dans notre outil ITSM. Pour faire un changement en prod (hors incident), c'est ticket obligatoire, comité d'approvisionnement de changement et une fois que tu as l'autorisation, tu peux faire le changement.
Sur incident c'est un peut plus guinguette, mais c'est tracé tout de même, au bon vouloir de ce celui qui traite l'incident. Derrière on a des incident managers qui vérifient ce qui est fait sur incident.
Ludovic
Le mer. 19 avr. 2023, 15:38, Etienne Magro via FRsAG <frsag@frsag.org> a écrit :
Bonjour à tous,
Vous utilisez quoi, pour historisez vos actions en prod ?
Aujourd'hui, on utilise du jira pour les actions futures à faire et ce que les clients nous demande, on a aussi un tableau dans un confluence pour y inscrire les actions (manuelles ou manuellement déclenchées) qu'on fait sur les serveurs, sans compter le chat interne et notre supervision. C'est pas génial pour s'y retrouver et faire le lien entre Toto qui a modifié une conf nginx à la main la semaine dernière en douce, suite à une alerte supervision ou une demande des chefs et Bibi qui cherche pourquoi son /var/log explose depuis. Surtout si le ticket jira n'existe pas/plus et qu'on a oublié de compléter le tableau à what-mille-lignes.
Donc avec l'équipe, on est en pleine réflexion sur comment on peut standardiser ça, et "enforcer" une procédure (avec éventuellement un nouvel outil pour les remplacer tous). Vous faites comment, vous ?
Etienne
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://secure-web.cisco.com/1AokjYQ3TASB95FmrBM2dXvYhz-ETrmCaE7oll32VPAL6H5h50kuT2Yqch3H73WrHm4UeTaHtyB55Bsta7F8kaGEZE25yPv_ZityOSbc0Nj63d6ONPnb6dJfPYDQWp7hmSKweBAglDm42WqGhOmAzrtGfmz4yEgrqz6T3DZXghXIDF2rOPirbQbirv7HhENJPFz-5ijZPWRKP2UeqEn2QTMmBn_x9tuPDuvj7cTi1PuX-3rZ3jqQf6R9eX-ndlNyaZyeyOgeU-701d3AAR2xfKcwElU04U3s_1-8baf3vrjzesmI8evOaAEIKFYrLX3SRA5kyjpWfcktR-xC4rE6refFZiTGS-esmEohGTKntz4q1YdLIdtld90O8cTsRKMzYDlrYDM--8iaB4CJYXRbgYHtRHURsa2Z1BRRd5cGdFJh0sIBhDfdrx-ix2NSyHnrs/http%3A%2F%2Fwww.frsag.org%2F>
_______________________________________________ Liste de diffusion du %(real_name)s FRsAG <http://secure-web.cisco.com/1AokjYQ3TASB95FmrBM2dXvYhz-ETrmCaE7oll32VPAL6H5h50kuT2Yqch3H73WrHm4UeTaHtyB55Bsta7F8kaGEZE25yPv_ZityOSbc0Nj63d6ONPnb6dJfPYDQWp7hmSKweBAglDm42WqGhOmAzrtGfmz4yEgrqz6T3DZXghXIDF2rOPirbQbirv7HhENJPFz-5ijZPWRKP2UeqEn2QTMmBn_x9tuPDuvj7cTi1PuX-3rZ3jqQf6R9eX-ndlNyaZyeyOgeU-701d3AAR2xfKcwElU04U3s_1-8baf3vrjzesmI8evOaAEIKFYrLX3SRA5kyjpWfcktR-xC4rE6refFZiTGS-esmEohGTKntz4q1YdLIdtld90O8cTsRKMzYDlrYDM--8iaB4CJYXRbgYHtRHURsa2Z1BRRd5cGdFJh0sIBhDfdrx-ix2NSyHnrs/http%3A%2F%2Fwww.frsag.org%2F>
FRsAG
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://secure-web.cisco.com/1AokjYQ3TASB95FmrBM2dXvYhz-ETrmCaE7oll32VPAL6H5h50kuT2Yqch3H73WrHm4UeTaHtyB55Bsta7F8kaGEZE25yPv_ZityOSbc0Nj63d6ONPnb6dJfPYDQWp7hmSKweBAglDm42WqGhOmAzrtGfmz4yEgrqz6T3DZXghXIDF2rOPirbQbirv7HhENJPFz-5ijZPWRKP2UeqEn2QTMmBn_x9tuPDuvj7cTi1PuX-3rZ3jqQf6R9eX-ndlNyaZyeyOgeU-701d3AAR2xfKcwElU04U3s_1-8baf3vrjzesmI8evOaAEIKFYrLX3SRA5kyjpWfcktR-xC4rE6refFZiTGS-esmEohGTKntz4q1YdLIdtld90O8cTsRKMzYDlrYDM--8iaB4CJYXRbgYHtRHURsa2Z1BRRd5cGdFJh0sIBhDfdrx-ix2NSyHnrs/http%3A%2F%2Fwww.frsag.org%2F>
_______________________________________________ Liste de diffusion du %(real_name)s http://secure-web.cisco.com/1AokjYQ3TASB95FmrBM2dXvYhz-ETrmCaE7oll32VPAL6H5h...
-- Chef de projet SI CNRS Equipe ISI ISEM UMR5554
Bonjour à tous, Un outil comme le PAM de Wallix permet l'enregistrement de toutes les actions réalisées que ce soit principalement en ssh ou rdp par les administrateurs. Les Bastions ce mettant en frontal d'accès il permettent en plus d'avoir une gestion des droits et accès de façon précise et d'avoir toutes les tracabilitees souhaitées. On peut en discuter en MP si souhaitée. Cdt Cyrille Verger Le sam. 22 avr. 2023, 19:06, Olivier Meyer via FRsAG <frsag@frsag.org> a écrit :
alut, le soucis d'après ce que tu dis c'est que tu est dans un mode SCRUM, pas adapté du tout à de la prod/exploit/MCO .C'est très hype de faire le l'agile et du SCRUM mais passe plutot dans un mode kanban voir scrumban si le client y tien, mais adopte aussi une approche ITIL, certes moins souple et moins "agile" mais plus efficace dans ce type d'environnement. C'est essentiellement des process a adopter (CR après un incident en prod, mise en place d'une équipe de réponse lors de l'incident, comité de validation des changements, ...) et non un outil. Si tu ne maitrises pas fait appel à un spécialiste ou forme toi. Pour les outils type confluence je sais d'expérience que si personne ne se dévoues pour maintenir et créer une norme/process de mise à jour/intégration des informations, ce truc c'est juste un trou noir ou disparaissent les infos ... Olivier.
Le mercredi 19 avril 2023 à 23:55:30 UTC+2, Ludovic Scotti < tontonlud@gmail.com> a écrit :
@job on est certifié SMSI (ISO 27001). Donc toutes les actions de prod sont tracées dans notre outil ITSM. Pour faire un changement en prod (hors incident), c'est ticket obligatoire, comité d'approvisionnement de changement et une fois que tu as l'autorisation, tu peux faire le changement.
Sur incident c'est un peut plus guinguette, mais c'est tracé tout de même, au bon vouloir de ce celui qui traite l'incident. Derrière on a des incident managers qui vérifient ce qui est fait sur incident.
Ludovic
Le mer. 19 avr. 2023, 15:38, Etienne Magro via FRsAG <frsag@frsag.org> a écrit :
Bonjour à tous,
Vous utilisez quoi, pour historisez vos actions en prod ?
Aujourd'hui, on utilise du jira pour les actions futures à faire et ce que les clients nous demande, on a aussi un tableau dans un confluence pour y inscrire les actions (manuelles ou manuellement déclenchées) qu'on fait sur les serveurs, sans compter le chat interne et notre supervision. C'est pas génial pour s'y retrouver et faire le lien entre Toto qui a modifié une conf nginx à la main la semaine dernière en douce, suite à une alerte supervision ou une demande des chefs et Bibi qui cherche pourquoi son /var/log explose depuis. Surtout si le ticket jira n'existe pas/plus et qu'on a oublié de compléter le tableau à what-mille-lignes.
Donc avec l'équipe, on est en pleine réflexion sur comment on peut standardiser ça, et "enforcer" une procédure (avec éventuellement un nouvel outil pour les remplacer tous). Vous faites comment, vous ?
Etienne _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s FRsAG <http://www.frsag.org/>
FRsAG
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
+ pour du bastion. (Ssh, rdp, etc …) Ovh bastion par exemple (pas de rdp) ou du guacamole font bien le taf sur de l’opensource. J’ai aussi du teleport mais enterprise du coup je ne sais pas si la version communautaire est suffisante dans ce cas. Mais oui clairement un bastion c’est fait pour ça. Le dimanche 23 avril 2023, Cyrille Verger <cverger99@gmail.com> a écrit :
Bonjour à tous,
Un outil comme le PAM de Wallix permet l'enregistrement de toutes les actions réalisées que ce soit principalement en ssh ou rdp par les administrateurs. Les Bastions ce mettant en frontal d'accès il permettent en plus d'avoir une gestion des droits et accès de façon précise et d'avoir toutes les tracabilitees souhaitées. On peut en discuter en MP si souhaitée.
Cdt Cyrille Verger
Le sam. 22 avr. 2023, 19:06, Olivier Meyer via FRsAG <frsag@frsag.org> a écrit :
alut, le soucis d'après ce que tu dis c'est que tu est dans un mode SCRUM, pas adapté du tout à de la prod/exploit/MCO .C'est très hype de faire le l'agile et du SCRUM mais passe plutot dans un mode kanban voir scrumban si le client y tien, mais adopte aussi une approche ITIL, certes moins souple et moins "agile" mais plus efficace dans ce type d'environnement. C'est essentiellement des process a adopter (CR après un incident en prod, mise en place d'une équipe de réponse lors de l'incident, comité de validation des changements, ...) et non un outil. Si tu ne maitrises pas fait appel à un spécialiste ou forme toi. Pour les outils type confluence je sais d'expérience que si personne ne se dévoues pour maintenir et créer une norme/process de mise à jour/intégration des informations, ce truc c'est juste un trou noir ou disparaissent les infos ... Olivier.
Le mercredi 19 avril 2023 à 23:55:30 UTC+2, Ludovic Scotti < tontonlud@gmail.com> a écrit :
@job on est certifié SMSI (ISO 27001). Donc toutes les actions de prod sont tracées dans notre outil ITSM. Pour faire un changement en prod (hors incident), c'est ticket obligatoire, comité d'approvisionnement de changement et une fois que tu as l'autorisation, tu peux faire le changement.
Sur incident c'est un peut plus guinguette, mais c'est tracé tout de même, au bon vouloir de ce celui qui traite l'incident. Derrière on a des incident managers qui vérifient ce qui est fait sur incident.
Ludovic
Le mer. 19 avr. 2023, 15:38, Etienne Magro via FRsAG <frsag@frsag.org> a écrit :
Bonjour à tous,
Vous utilisez quoi, pour historisez vos actions en prod ?
Aujourd'hui, on utilise du jira pour les actions futures à faire et ce que les clients nous demande, on a aussi un tableau dans un confluence pour y inscrire les actions (manuelles ou manuellement déclenchées) qu'on fait sur les serveurs, sans compter le chat interne et notre supervision. C'est pas génial pour s'y retrouver et faire le lien entre Toto qui a modifié une conf nginx à la main la semaine dernière en douce, suite à une alerte supervision ou une demande des chefs et Bibi qui cherche pourquoi son /var/log explose depuis. Surtout si le ticket jira n'existe pas/plus et qu'on a oublié de compléter le tableau à what-mille-lignes.
Donc avec l'équipe, on est en pleine réflexion sur comment on peut standardiser ça, et "enforcer" une procédure (avec éventuellement un nouvel outil pour les remplacer tous). Vous faites comment, vous ?
Etienne _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s FRsAG <http://www.frsag.org/>
FRsAG
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
-- Nicolas GIRARDI
participants (6)
-
Cyrille Verger -
Mathieu Corbin -
Nicolas GIRARDI -
Olivier Meyer -
Rémy Dernat -
SIMANCAS Hugo