Projet libre «OpenCMDB» Cahier des charges

Transcription

1 Projet libre «OpenCMDB» Cahier des charges D ocument rédigé par : Tom ARÉDO D ate de création : 01/01/2013 D ernière mise à jour : 03/01/2013 V ersion : 0.50

2 Table des matières I -Description du projet Origine du projet Objectif et périmètre Diffusion et licence...4 II -Étude de l'existant Gestion des licences Gestion des stocks et Inventaire Monitoring et gestion des alertes Gestion de configurations Déploiement de postes/serveurs Gestion du SA et contrôle du niveau de qualité de service Gestion de cluster de serveurs (calcul) Gestion des tickets utilisateurs/clients Gestion des mots de passe des serveurs...7 III -Organisation fonctionnelle Équipe (actuelle et future) Responsabilités et engagement Spécifications applicatives Architecture logicielle Architecture physique Technologies utilisées Sécurité et processus de mises à jour...10 IV -Spécifications techniques...11 V -Conduite du projet Bug Tracker Dépôt SVN / Git Indicateurs de qualité...12

3 I - Description du projet 1. Origine du projet es métiers de l'administration système et réseau font aujourd'hui partie intégrante de la vie même de l'internet. Dans ces métiers, la gestion de parc informatique est un aspect incontournable. Aussi, il convient de travailler avec des outils permettant de faire avec facilité et rapidité toutes les tâches inhérentes à la gestion de son parc. e projet OpenCMDB part d'un constat simple : toutes les tâches de gestion d'un parc de postes utilisateurs ou de serveurs ont toujours comme lien le matériel qu'il y a à administrer. es alertes de monitoring se rapportent à un matériel qui a sa configuration, ses caractéristiques, mais également son historique de demandes à associées (tickets par exemple), ses spécificités etc. Il faut donc réussir à lier simplement tout cela. R appel : Une CMDB (Configuration Management DataBase) est un outil essentiel dans le modèle ITI. Ce dernier permet une synchronisation des informations relatives à une entité physique ou virtuelle tout en permettant une gestion fine de cette entité et un suivi optimisé. 2. Objectif et périmètre 'objectif final est de fournir une application web modulaire (type ERP ) et extensible rassemblant tous les aspects de la gestion de parc informatique, tels la gestion des stocks, de l'inventaire, des tickets clients, de l'historique des machines, le management des configurations OS, matérielles et logicielles etc ainsi que des fonctionnalités de suivi du SA et de la qualité de service associée. U n second objectif est de proposer une alternative aux outils existants afin d'offrir une vision différente des fonctionnalités qu'offrent déjà les applications connues dans ce domaine. U n tel outil étant se voulant être un élément central de l'infrastructure du parc informatique, il devient nécessaire que ses performances et sa disponibilité soient assurés. Ainsi, des spécifications claires et définies sont obligatoires pour assurer une bonne conduite du projet, but premier de ce document. O pencmdb (en tant que projet) naît le 1 er janvier 2013, il sera donc de mise que l'application soit parfaitement fluide, esthétique, et qu'elle utilise toute la puissance des technologies actuelles (AJAX, CSS3, HTM5). A ttention : il est important de comprendre que le but du projet N'EST PAS de re-développer un outil de monitoring, un outil de SA etc. mais bien de faire office d'interface centrale entre toutes les données, en ajoutant des fonctionnalités choisies comme le ticketting ou encore la

4 gestion de facture. OpenCMDB fournira donc des API de communication en plus de ses fonctionnalités de base afin de stopper la suprématie de GPI en la matière (qui est d'ailleurs déjà un très bon logiciel). 3. Diffusion et licence e futur mode de diffusion du logiciel sera régi par une licence. e choix de la licence sera déterminé dans les premières phases du projet et sera probablement une licence réservant aux utilisateurs un maximum de droits tout en empêchant l'utilisation commerciale du produit final. Si tel est le cas, il s'agira sans doute d'une licence Creative Commons. C ependant, il serait sans doute profitable que le projet soit «porté» par la voix d'un groupe comme celle du projet Debian. En effet, si le projet arrivait à satisfaire la majorité des besoins connus en matière de CMDB, il serait peut-être envisageable de faire promouvoir ce dernier par Debian, à la manière d'openstack par exemple (et j'insiste, c'est un exemple!). Cela impliquerait la mise en place d'une licence plus permissive, comme par exemple la licence GP.

5 II - Étude de l'existant vant de faire une étude de l'existant, voici les différents points que A regroupe la gestion d'un parc informatique : G estion des licences logicielles G estion des stocks / inventaire M onitoring et gestion des alertes G estion des configurations de postes/serveurs D éploiement des postes/serveurs G estion du SA et contrôle du niveau de qualité de service G estion de cluster de serveurs (calcul) G estion des tickets utilisateurs/clients G estion des mots de passe des serveurs C hacun de ces points est à étudier séparément pour ne rien oublier. 1. Gestion des licences a gestion des licences logicielles (Windows, RedHat, ogiciels propriétaires...) est une tâche fastidieuse, d'autant plus si aucun outil n'aide à l'effectuer avec rigueur. Ainsi, voici quelques applications qui répondent à cette fonction : N om : P rix : S ite : F onctionnalités : C ommentaire : 2. Gestion des stocks et Inventaire I nventorier et gérer son matériel et ses stocks doit être une tâche prise au sérieux si l'on veut éviter les imprévus. es logiciels permettant d'effectuer cette tâche sont nombreux, en voici quelques uns parmi les plus populaires :

6 N om : P rix : S ite : F onctionnalités : C ommentaire : 3. Monitoring et gestion des alertes orsque l'on gère des serveurs et services critiques, on se doit d'être proactif ET réactif. Cela nécessite donc d'être informé dès que certains services subissent une grosse charge ou même qu'ils sont indisponibles. Pour ce faire, plusieurs solutions OpenSource existent : N om : P rix : S ite : F onctionnalités : C ommentaire : 4. Gestion de configurations es administrateurs systèmes oublient souvent cet aspect de leur domaine qui permet souvent de gagner énormément de temps et de simplifier la maintenance de leurs postes/serveurs. Pour cette partie, voici quelques applications de gestion de configurations : N om : P rix : S ite : F onctionnalités : C ommentaire : 5. Déploiement de postes/serveurs 6. Gestion du SA et contrôle du niveau de qualité de service

7 7. Gestion de cluster de serveurs (calcul) 8. Gestion des tickets utilisateurs/clients 9. Gestion des mots de passe des serveurs

8 III - Organisation fonctionnelle 1. Équipe (actuelle et future) C hef de projet / Coordinateur : Tom AREDO D éveloppeurs : recherche 2 bénévoles expérimentés + 2 juniors A rchitecte système : Tom AREDO A rchitecte applicatif : Tom AREDO + recherche 1 bénévole D esigner : recherche 2 bénévoles C hercheurs : 3 bénévoles e projet est scindé en deux parties : e développement/design de l'application OpenCMDB (2 seniors) e développement/design du site du projet (2 juniors) e rôle des chercheurs est triple : F aire une étude complète de l'existant (remplir le chapitre II) et chercher les concurrents directs ister l'ensemble des fonctionnalités à développer (à partir de celles trouvées dans les applications existantes, voire manquantes). R édiger les Use Cases (cas d'utilisation) définissant les fonctionnalités et l'utilisation de l'application 2. Responsabilités et engagement e projet OpenCMDB est un projet à grande valeur ajoutée mais qui ne vivra que si des bénévoles motivés se prennent au jeu. Bon nombre des grands projets ibre et/ou OpenSource connus à l'heure actuelle reposent sur ce prérequis et il en sera toujours ainsi. U n tel fonctionnement doit donc s'articuler autour d'une hiérarchie connue et déclarée dès le départ, non pas pour soumettre certains aux idées d'un autre mais simplement pour assurer une cohésion de l'équipe et une cohérence dans l'application développée par ses soins. C haque membre de l'équipe du projet OpenCMDB s'engage à mettre tout son savoir faire, son expérience et son jugement à disposition du projet dans le temps qu'il se réserve au projet tout en acceptant la critique et les conseils.

9 S ouvenez-vous de ce que l'on peut faire avec beaucoup de motivation et très peu de moyens. Souvenez-vous comment Google est né. Souvenez-vous que 5 personnes développent à elles-seules le Kernel Debian. Souvenez-vous de tout cela et sentez vous forts de ce que vous savez faire et de ce vous saurez faire! D ernier point, soyez sûrs que les développeurs n'auront pas moins de poids que les architectes dans les multiples décisions à venir sur ce projet. En cas de conflit de choix et/ou de doute, seul le chef de projet aura le dernier mot. 3. Spécifications applicatives es présentes spécifications applicatives sont une ébauche qui sera travaillée en collaboration avec le futur architecte applicatif et les futurs programmeurs. 4. Architecture logicielle R este à écrire avec le futur architecte logiciel. D e jolis schémas sont à venir! 5. Architecture physique 'application OpenCMDB a pour objectif d'être extensible à souhait. Ainsi, elle pourra tourner sur plusieurs types d'architectures physiques telles que : U ne seule machine (qui héberge serveur web et SGBD) D eux machines (une pour le serveur web, une pour la base SQ) 3 machines (deux frontaux et un serveur de base ou l'inverse) 4 machines (deux frontaux et deux serveurs de base) D e jolis schémas sont à venir! 6. Technologies utilisées 'application sera entièrement développée avec les technologies suivantes : HTM (5 probablement ou xhtm strict), CSS 3, JavaScript / AJAX, PHP et SQ (sur une base relationnelle).

10 e choix des logiciels qui feront tourner l'application (OS, logiciel de serveur web, SGBD...) sera fait d'ici quelques temps. 7. Sécurité et processus de mises à jour 'application sera testée au fur et à mesure de son évolution et une documentation précise sera produite. Un BugTracker sera mis en place pour le projet et des patchs seront écrits au fil des corrections et des mises à jour. a totalité du projet sera versionnée via un hébergement SVN ou Git où le code source sera divisé en trois branches : unstable, testing, stable pour assurer un développement plus fluide.

11 IV - Spécifications techniques estent à écrire en collaboration avec les développeurs et R l'architecte applicatif. 1. Use Cases A jouter un équipement M ettre à jour les données d'un équipement S upprimer un équipement A fficher la liste des équipements A fficher la liste des équipements avec filtrage A jouter une licence M ettre à jour les données d'une licence S upprimer une licence A fficher la liste des licences A fficher la liste des licences avec filtrage C hercher un équipement (recherche rapide) C hercher un équipement (recherche avancée) A jouter un utilisateur M ettre à jour les données d'un utilisateur S upprimer un utilisateur A fficher la liste des utilisateurs A fficher la liste des utilisateurs avec filtrage A jouter un groupe d'utilisateurs M ettre à jour les données d'un groupe d'utilisateurs S upprimer un groupe d'utilisateurs A fficher la liste des groupes d'utilisateurs A fficher la liste des groupes d'utilisateurs avec filtrage A jouter un groupe d'équipements M ettre à jour les données d'un groupe d'équipements

12 S upprimer un groupe d'équipements A fficher la liste des groupes d'équipements A fficher la liste des groupes d'équipements avec filtrage A fficher un graphique réseau Z oomer/dézoomer dans le graphique réseau V érifier la connectivité d'un équipement C réer un ticket M odifier un ticket R éassigner un ticket S upprimer un ticket I mporter des données d'inventaire depuis un logiciel tiers I mporter des données de monitoring depuis un logiciel tiers I mporter des données de facturation depuis un logiciel tiers what else?

13 V - Conduite du projet 1. Bug Tracker a solution de Bug Tracker / ToDo ist reste à déterminer. 2. Dépôt SVN / Git a solution de dépôt de versionnage (SVN / Git) reste à déterminer. 3. Indicateurs de qualité es indicateurs de qualité seront mis en place au fil de l'avancement D du projet par le chef de projet.