Journal Application web de cartographie applicative

Posté par  .
Étiquettes :
11
26
fév.
2010
Bonjour,

Dans le cadre de mon travail, mon service a en charge l'installation et le maintien en condition opérationnel 400 applications différentes (environnement de recette et de production, d'origine pour 99% de développement extérieur, basées sur des progiciels ou étant spécifique). Elles sont réparties sur quasiment un millier de serveurs. Nous nous sommes vite heurtés sur plusieurs problèmes que surement certains d'entre vous connaissent.

Notamment, le double point de vue que nous devons avoir pour gérer un tel parc : savoir sur quels serveurs tournent une application donnée (point de vue "application") et savoir quelles applications sont hébergées sur un serveur (point de vue "serveur"). Les premiers outils étaient de simples tableaux nécessitant une double mise à jour et donc peu fiable. Chez nous, cela s'appelle la cartographie applicative.

Une autre difficulté est de pouvoir suivre les demandes d'installations qu'on nous demande de faire. Nous appellons ce point le suivi des "Demandes de Changements Applicatifs". Vu la hausse de notre activité, le suivi par mail a vite montré ses limites.

Au vu des ces difficultés et n'ayant pas trouvé l'application idéale, j'ai commencé à développer une application web (php/mysql/ajax) pour répondre, dans un premier temps, au suivi des changements applicatifs et à la cartographie dans un deuxième temps.

Chez nous, elle vient en complément des applications GLPI et OCS :
- OCS : pour la description technique des serveurs
- GLPI : pour la répartition géographique des serveurs
- Mon appli pour le lien avec les applications

Des interfaces ont été développées pour maintenir à jour les informations partagés entre ces applications.

Les applications sont décrites en terme de briques de bases (SGBD, serveurs web, serveur d'applications, url d'accès) et de façon très souple. On cartographie aussi bien du SAP, des applications web (java, php), qu'un simple hébergement de pages html statiques.

La partie gestion des demandes est constituée d'un "Front Office" permettant aux demandeurs de saisir les demandes (dates, contenu des livraisons) et de les suivre. Ce front office est une version allégé de l'application. Les notifications des changements se sont par mails.

Cette application est maintenant utilisée par une vingtaine de personnes quotidiennement depuis 2 ans et elle occupe un rôle central dans notre activité. On se demande parfois comme on ferrait si on ne l'avait pas.

Je continue toujours son développement. Sont en prévision la gestion des "demandes de travaux" (dump de bases de données, demandes de logs, lancement de traitements, ...), étendre la cartographie aux traitements de nuits... Donc, plus le projet grossi, plus je me dis que le projet pourrait intéresser d'autres personnes.

Donc, avant de me lancer dans l'aventure de son ouverture (sachant qu'elle a été conçue en s'adaptant au plus près à notre organisation), j'écris pour tater le terrain. Est-ce que, potentiellement, ce type d'application intéresserait du monde ?

N'ayant pas l'aval de mon employeur sur la libération du code source, je ne peux pas donner trop de détails pour le moment, mais je n'ai pas rencontrer de refus sur le principe.

  • # ITIL ?

    Posté par  . Évalué à 1.

    La gestion du matériel, des logiciels, des incidents, des changements, des problèmes ... tout cela est cadré dans ITIL, je te conseille d'y jeter un oeuil et de t'en inspirer au lieu de ré-inventer complètement des processus de gestion. C'est une bonne source d'idées de choses "qui marchent".

    • [^] # Re: ITIL ?

      Posté par  . Évalué à 1.

      Notre démarche s'inscrit dans une démarche inspiré d'ITIL.

      ITIL n'est qu'une description des bonnes pratiques. Pour la mise en place d'outils sur le terrain, j'ai rien trouvé qui soit libre et pas une usine à gaz où gérer la demande est aussi long et compliqué que l'exécution de la demande elle-même.

      D'après ce que j'ai compris d'ITIL, c'est plus un répertoire de bonnes idées, mais elles ne sont pas toute applicables partout.

      Ici, on peut considérer que la CMDB décrite par ITIL serait constituée de l'union des informations gérer par les 3 applications.

      • [^] # Re: ITIL ?

        Posté par  (site web personnel) . Évalué à 2.

        Je reprends un commentaire que j'avais fait à totof2000<
        c'est une CMDB aka Configuration_Management_DataBase au sens ITIL du terme ;-)

        une recherche rapide avec open cmdb donne quelques résultats
        http://www.onecmdb.org/wiki/index.php?title=Main_Page
        http://sourceforge.net/projects/i-doit/
        http://www.cmdb.info/pd1/html/modules.php?op=modload&nam(...)
        http://sourceforge.net/softwaremap/trove_list.php?form_cat=6(...)

        tu peux peut-être regarder du côté de Eyes Of Network http://linuxfr.org/2010/02/08/26452.html ou ]project-open[ http://linuxfr.org/2009/11/26/26193.html

        àmha ça intéressera du monde ;-)
        n'oublie pas de choisir une licence qui arrange les autres projets dont tu as parlé, cf. http://faq.tuxfamily.org/Licence/Fr pour plus d'éléments

        • [^] # Re: ITIL ?

          Posté par  . Évalué à 2.

          chez nous, cela s'appelle la CMDB. Je ne connais pas de soft associé.

        • [^] # Re: ITIL ?

          Posté par  . Évalué à 1.

          Merci pour ces liens, je regarderais tout ça de plus pret.
          Mais je ne vois pas trop l'intérêt d'une tel base pour le travail quotidien, donc son alimentation va encore attendre un peu.

          Y'a-t-il des personnes qui en ont déjà implémenter une et qui ont un retour d'expérience sur le sujet ?

          Pour la licence, naturellement, je pense me tourner vers la GPL.

          • [^] # Re: ITIL ?

            Posté par  (site web personnel) . Évalué à 3.

            Mais je ne vois pas trop l'intérêt d'une tel base pour le travail quotidien, donc son alimentation va encore attendre un peu.

            Cela permet au service desk, par exemple, de savoir quand quelqu'un des études lui parle de la base de données qui est vautrée pour son appli trucmuche qu'elle est sur le serveur tartempion (avec les informations de type OS / type de base de données) pour faire appel à la bonne personne pour intervenir.
            Cela peut paraître anodin quand tu as 4-5 applications, mais dès que tu en as des dizaines voire centaines, ça devient vite ingérable ;-)

            Cela permet aussi, quand tu planifies une intervention sur un serveur, d'identifier les applications qui vont être impactées et de prévenir les personnes concernées (ah oui, il n'y a pas que le côté technique, il y a le volet organisationnel qui apparaît assez vite).
            Par exemple, cela permet de répondre à la question "il y a une coupure électrique en salle 1 du datacenter, quelles applications sont impactées, lesquelles étaient en cluster avec un serveur dans une autre salle, cela-a-t-il bien basculé, lesquelles restent à basculer en manuel ?" (bon ce n'est jamais si simple hein, mais au moins ça donne un début d'information).

            Comme tu pourras le lire dans la littérature autour de ITIL, il y a deux logiques à mettre en place :
            - coupler l'alimentation de la CMDB à la gestion des changements, en profiter pour valider les données régulièrement
            - limiter au maximum l'ajout de données qui "pourraient être utiles", soit elles répondent à un besoin concret, soit (idéalement) elles peuvent être obtenues automatiquement à partir des données déjà rentrées (tout aspect manuel sera un frein à la mise à jour et la base devient vite obsolète). Des revues régulières de la qualité des données (avec un responsable par périmètre ou par type de données entrées) permettent d'éviter l'obsolescence de la base.

            Concernant ITIL, ce n'est pas que pour les dissaïdor ; étant un "ensemble de bonnes pratiques", il y a tout le volet "hype" à enlever, mais il reste pas mal de bonnes recommandations à prendre en compte tout de même et à adapter à son contexte bien sûr. Cela permet d'avoir un vocabulaire commun entre plusieurs équipes déjà.

  • # tosca

    Posté par  . Évalué à 1.

    Pour la gestion de la demande il existe le logiciel libre Tosca : http://tosca-project.net/ en Ruby on Rails. Je ne l'ai pas essayé mais il semble plus orienté client que développeur au contraire de Redmine.

    • [^] # Re: tosca

      Posté par  . Évalué à 2.

      J'ai essayé un bon nombre d'applications basées sur des tickets.

      Mais il nous manquait la gestion de la planification (les demandes d'installation ne sont pas à réaliser immédiatement), de la répartition des tâches (uniquement 1 ou 2 personnes de l'équipe s'occupent d'une application donnée) et l'association d'une demande à un environnement applicatif.

      Je ne dis pas que cela est impossible avec les applications existantes, mais qu'à chaque fois cela allait demander plus que du paramétrage.

      En plus, la cartographie et la gestion des demandes sont liées. en effet, les demandes se font sur des éléments cartographiés.

  • # GLPI

    Posté par  . Évalué à 2.

    Tu as le plugin webapplication qui permet d'associer une application web par exemple à une pour plusieurs machines et pouvoir ouvrir des tickets dessus.

    Pour plusieurs serveurs, tu peux créer un 'ensemble' pour par exemple créer un objet Cluster et y associer plusieurs machines dedans.

    La partie helpdesk de GLPI a été grandement améliorée et la prochaine version sorts dans quelques semaines.

    Il est vrai qu'on a pas tous les détails, mais une grosse partie me semble déjà faite dans GLPI.


    Davud DURIEUX, développeur GLPI & OCS & FusionInventory

  • # sécurité

    Posté par  (site web personnel) . Évalué à 2.

    savoir sur quels serveurs tournent une application donnée (point de vue "application") et savoir quelles applications sont hébergées sur un serveur (point de vue "serveur"). Les premiers outils étaient de simples tableaux nécessitant une double mise à jour et donc peu fiable. Chez nous, cela s'appelle la cartographie applicative.

    Chez nous, on nomme cela la sécurité (par absence de centralisation facilement accessible de la répartition des informations) --> êtes vous bien sûr que cela n'existe pas déjà, mais que simplement vous n'y avez peutr être pas accès ? Cela peut paraitre paradoxal, pour des gens amenés gérer une partie, mais bon.
    Chez nous, chez notre client, ça sert aussi d'excuses pour dire "zut j'ai pas fait la doc, flute me souviens plus où j'ai centraliser cette biblio, Merde, le système utilisé pour versionner les biblio sur tel filer est différents de sur tel autre, pour un même secteur, j'ai encore fait ça un retour de vacances...tant pis, c'est un sous traitant qui fera le boulot" ;)

  • # ça m'intéresse !!!

    Posté par  . Évalué à 3.

    et beaucoup !
    on a de plus en plus d'applications (web majoritairement ou autre), et ça va devenir de plus en plus dur les localiser :-)

    donc si ton outil est dispo, même en bêta, je veux bien le tester et te faire des retours.

    par contre, en ce qui me concerne, tu peux laisser tomber ITIL.
    je préfère les outils opérationnels que les magmas pour décideurs pressés...

    • [^] # Re: ça m'intéresse !!!

      Posté par  . Évalué à 1.

      Dès que j'ai l'aval de mon employeur sur l'ouverture de l'appli, je te la ferais parvenir pour test.

      ITIL a été l'élément déclencheur, mais j'ai essayé de garder en tête qu'elle devait être utiliser tous les jours et donc tourner vers l'opérationnel. Les stats et les autres trucs dans le même genre sont venus bien après...

      • [^] # Re: ça m'intéresse !!!

        Posté par  . Évalué à 1.

        Ça m'intéresse aussi ! Je veux bien faire béta-testeur.

        À mon boulot, on a du mal à suivre quelles versions d'applis sont installées sur quelles plateformes !
        Du coup, chaque équipe se fait un tableau exxel dans son coin ! :-(

        Par contre, on a ni OCS ni GLPI...Ton appli peut faire sans ?

    • [^] # Re: ça m'intéresse !!!

      Posté par  . Évalué à 1.

      Moi ca m'interesse...

      Chez nous, on a pas du tout la meme echelle mais c'est suffisament la bazar pour qu'une appli comme ca soit utile.

      \o/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.