Réunion comité restreint des opérations -------------------------------------- GP : Guillaume Philippon CL : Christine Leroy CB: Cécile Barbier GM : Gille Mathieu CO : Cyril L'Orphelin TG : Tristan Glatard HC : Hélène Cordier AdB: Alice de Bignicourt MA : Mirvat Aljogami DB : David Bouvet === Processus de decision et coordination stratégique Les missions de France-Grilles: * A- Responsabilité de la mise en place et de la maintenance d'une grille opérationnelle 1. Établissement, validation et révision des workflows de décision et de communication intra-NGI 2. Organisation et animation de réunions régulières ou ad-hoc entre les différents acteurs des opérations 3. Délégation des responsabilités techniques et du fonctionnement au quotidien 4. Suivi des demandes et des incidents d'opérations impliquant des acteurs de la NGI 5. Établissement de rapports d'activité (internes ou externes) à des fins de visibilité et qualité * B- Mise en œuvre des moyens d'implémentation: Donner les moyens techniques et financiers pour la stratégie globale 1. Établissement d'un catalogue de services labellisés et d'une cartographie des ressources disponibles 2. Établissement, validation et suivi des procédures d'opérations (certification, dé-commissionnement) 3. Établissement et suivi des MoU entre la NGI et différents acteurs (fournisseurs de service, utilisateurs) 4. Collecte et définition des besoins matériels, humains et financiers des opérations 5. Coordination de l'établissement d'outils collaboratifs nécessaires aux opérations * C- Veille technologique, choix stratégiques et arbitrage des choix techniques 1. Définition de plans stratégiques et techniques liés à la stratégie générale de la direction (e.g. allocation de ressources) 2. Définition de plans stratégiques et techniques liés aux évolutions technologiques (e.g. cloud académique) 3. Suivi de l'activité française dans des technologies connexes et projets d'interopérabilité avec les grilles (e.g. stratuslab, edgi...) 4. Établissement de la stratégie de la NGI en terme de régionalisation des outils 5. Validation des choix en termes d'infrastructures * D- Liaisons intra-NGI entre les opérations et les autres acteurs 1. Liaisons avec les utilisateurs 2. Coordination de la sécurité avec les partenaires du GIS 3. Activité de formation * E- Liasons à l’international 1. Représentation de la NGI à l'international pour les domaines techniques et opérationnels (meetings, conférences et réunions) 2. Établissement de rapports d'activité pour EGI 3. Établissement et suivi des MoU entre la NGI et EGI 4. Établissement des workflows de communication entre les acteurs de France-Grilles et leurs homologues d'autres NGIs 5. Passage et suivi d'information entre les sites, la NGI et EGI (Top/down) Liste à faire évoluer. Le CTE doit partager une partie des missions de la DT, il doit notammenent proceder au conseil technique auprès de la direction technique; arbitrage des choix stratégiques auprès de la direction technique; implémentation des decisions et coordinataion des groupes de travail et conseil à la DT sur qui fait quoi. CB CTE doit être aussi une arène de discussion sur les topics de EGI pour avoir une communication multi-canaux par thématiques à l'intérieur des opérations HC On doit aussi faire un point avec les autres activités EGI CO Les procèdures de décision doit être connu pour traiter les thèmes en provenance d'EGI et vice-versa. Il est nécessaire d'avoir un espace de discussion en fin de réunion pour faire remonter les hot topics CL Voir avec le CTE le mode des canaux de remontée d'info, et/ou le mode de validation des requirements GP A rapprocher de "évaluation et arbitrage des solutions possibles à un problème donné" TG La collecte des requirements via EGI est bureaucratique (UCB et USCT) et se fait sur le mode ad-hoc avec les composants. GM Le formalisme du CTE doit permettre la mise en place de solutions rapides. GM Le petit comité doit faire du bon sens pragmatique une règle : soit information, soit conseil, soit discussion. AdB Le + important est d'identifier les points de contact CL/GP Il est necesssaire d'avoir un représentant des différents sites représentant des différents EPST. DB Cela revient à définir la composition du Comité Technique. CL CE sont les sites qui ont le pouvoir de décision sur leur activité. GM Les choix stratégiques nationnaux et le pouvoir de décision vis à vis des engagements EGI relèvent de la NGI. DB/CL L'interaction entre DT/CTE et les sites d'autre part doit être formalisé* GM La prise de decision est difficile à faire avec une assemblée à 30 ainsi que l'échange des contributions. CL Un rep. du monitoring n'a pas à statuter sur les decisions affectant les sites DB Rajouter le point dans le rôle du CTE: * conseil et expertise auprès de la DT * évaluation et arbitrage des solutions possibles à un problème donné * recommandation à la prise de décision sur un choix stratégique ou technique * organisation, répartition et distribution des tâches techniques liées à une thématique donnée * representation et interaction pour l'aide à la decision : avec le CT (fournisseurs de service des sites en production) et les communautés utilisateurs DB besoin de services centraux devant être assuré par la NGI - modèle central. CL ce formalisme du CTE peut-être contre-productif et lourd; il faut faire en sorte de faire attention à la proposition à faire pour le workshop d'automne. CL Qu'est-ce c'est une NGI; comment on attribue le budget; quel est le rôle de la NGI vis à vis des sites. CL le nombre de membres du CTE doit être réduit de 10 à 5-6. GP/DB Tous les groupes de travail doivent être présents et la présence des experts adaptée au contenu CO Quid d'un noyau restreint à élargir selon l'agenda? CL Attention aux réunionites CL Il n'y a pas de groupe de travail portant sur le mw HC Le pole liaisons mw a été défini l'été dernier et il sera intégré dans le prochain workshop pour évaluer la pertinence d'un groupe de travail sur le sujet avec FSuter. CL Il y a trop de groupes de travail. HC Le comité peut être large et la présence aux réunions peut-être adaptée selon l'agenda; Le comité en entier reste informé et convié. Tour de table sur le principe d'établissement du CTE et engagement personnel MA/AdB/TG/GP/CO/CB GM : attention au formalisme TG : OK mais mandat du groupe des utilisateurs à reprendre GP : OK à réévaluer dans 6 mois CO : OK, rester pragmatique : e.g l'évaluation cloud à intégrer seulement lorsque le moment sera venu, les ressources étant limités. CB : Attention à la réunionite - personnellement, ne pas dépenser l'engagement initial de 15% CL : Faut voir. Le CTE doit réduire le nombre de participants ou préciser les objectifs de tout (CTE/NGI) DB : OK. Est-ce que les coordinateurs de groupes de travail seront supprimés et intégrés dans le CTE d'office... ===================================================================================================================== Le Modèle des Opérations: Presentation des infrastructures/ taches/ roles CL : Attention aux flêches dans le diagramme entre tâches hierachiques et roles non hierarchiques. Fig2 : Clarifier le role des personnes et les décisions TG : Formalisme lourd si c'est toujours les 3 mêmes personnes CO : OK, mais l'identification des casquettes reste possible grâce à ce formalisme GM : Dans beaucoup de cas, le formalisme sera inutile GR : Partie : Moyens materiels, financiers, humains n'est pas dans le modèle == Quel est le bénéfice pour les utilsateurs. ( representation ok) GP : L'evaluation se fait dans la strategic coordination pour que le CTE hierarchise les taches en fonction des besoins/ moyens (decideur avec report au directeur le cas échéant). GM : Etudier de mettre les workflow de la matrice de communication (RACI matrix) en schema. GM : Necessité de séparer Admin et hosting OK; Implementation et support/follow-up ( y at-il des uses -cases : monitoring ok) GP : Pour le groupe certification, on a des personnes qui dev les templates/ et les personnes qui supportent qui sont différentes GR : Quel est le but de cette représentation? comprendre comment on est organisé? HC : Comprendre si ca représente notre mode de fonctionnement pour avoir des taches mesurables. CL : realisation = 1 ligne : implementation, support, follow-up pour les taches thématiques CL : Maintenir la granularité pour les taches d'infrastructure GM : Faire dans fig3 : une seule niveau technical supervision quelle que soit l'infrastructure CO : mettre une liste de personnes derrière les 4 catégories / service admin/ hosting/ Implementation/ Support-Folluw-up CO : Le descripif de la tache d'infrastructure est suffisant en déclinant personnes et besoins plutôt que faire une séparation arbitraire. GR : Faire une représenttaion de qui/ fait quoi et besoins, ce n'est pas un arbre mais un réseau avec des rétroactions. CO : certification des sites est un workflow qui fait appel à des taches. GP : Une tache peut faire référence à plusieurs stratégies. == 14h00 GM : On peut établir la techical supervision en transverse d'ou le rôle du CTE GM : Est-ce que la liste les rôles est pertinente CO : Les rôles doivent coller aux tâches : la liste de 6 rôles ok ( + experts) colle au nouveau schéma GP: faut-il donner des noms sur un rôle / au GRIF c'est fait par un service ou un site GM: les rôles sont nécessaires pour établir les canaux de communication. GR: peut -on sortir une vision des services aux utilisateurs ? GM: Faire un seul RACI des 2 types de taches. CL: Le RACI est utile pour la DT seulement, ne pas forcément communiquer dessus. GR : Le workflow tiré du RACI est à faire car le RACI ne suffit pas , on ne peut pas le faire pour chaque tache. DB: Le RACI est utile pour savoir qui est consulté -- utile pour CTE -- il n'est pas utile de communiquer sur cela, la personne concernée le sait naturellement. HC : Ne pas communiquer dessus sur le workshop. Par contre, la liste des roles doit être communiquée de façon très précautionneuse par rapport à la fig3, pour ne pas induire de relation faussement hierarchique GM : Infrastructures/ taches/roles. OK ; definition infrastructures : OK; On en arrive à une simplification des niveaux de taches à considérér et à modéliser les taches en "réseau". On peut essayer de mapper le modèle aux groupes existants; Roles: associé à chaque type de tache + 1 role expert. Pas besoin d'associer tache et role. ne pas communiquer sur le RACI de façon inutile. GP : se laisser la possibilité de sortir du modèle. La carte n'est pas le territoire. ====