Projet Cloud / Big Data - Optimisation de la QOS

710 vues

Publié le

QOS optimization project using 6 Sigma method

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
710
Sur SlideShare
0
Issues des intégrations
0
Intégrations
11
Actions
Partages
0
Téléchargements
18
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Projet Cloud / Big Data - Optimisation de la QOS

  1. 1. Projet QOS : Bigger Data      Mastère Spécialisé Cloud Computing et SaaS, 2014/2015     Benoît Foussier  Eric Guillard  Sébastien Kieger  Clément Marche      1/26 
  2. 2. Table des matières   1. Define  Présentation de Datatweet  Présentation du SI  Les acteurs  Les acteurs : OVH  Les acteurs : GNIP  Méthodologie  Critères clés de qualité  Analyse SWOT  Analyse des processus clés  Objectifs identifiés  2. Mesure  KPI de mesure identifiés  3. Analyze  Problèmes identifiés  Analyse des causes profondes  Choix de l’axe à traiter  Diagramme des causes profondes  Fiches labels  4. Improve  5. Control  Les contrôles  Les outils de pilotage  Tableau de Bord  Backlog  Sondage  Réunion  Conclusion  Annexes  Remerciements        2/26 
  3. 3. 1. Define Présentation de Datatweet   Datatweet est une start­up fondée en 2011 par 3 ingénieurs avec comme idée de base de se servir des                                      tweets pour suivre des tendances et analyser la e­reputation d’entreprises. Concrètement ils proposent une                            solution SaaS basée sur des technologies liées au traitement massif de données, qui permet aux clients                                d’observer les flux de conversations Twitter en temps réel et de les analyser pour cibler les origines, les                                    influenceurs et ainsi adapter leur communication de manière optimale.  Un des principaux usages de la solution Dataweet réside dans la détection anticipée de crises (affaire « La                                    parisienne », ou l’arrivée de Netflix en France par exemple) ainsi que la gestion de leurs résolution.     source : Blog datatweet    Âgée de 3 ans, Datatweet possède en 2014 une vingtaine de clients, et arrive à un point critique de son                                        évolution : la plateforme SaaS est fonctionnelle et stabilisée, l’outil de production et d’exploitation doit                              maintenant évoluer pour s’industrialiser et permettre à Datatweet d’aborder l’avenir sereinement et de                          manière pérenne. Ainsi elle pourra se concentrer sur son cœur de métier : l’évolution des fonctionnalités de                                  sa plateforme et la vente de cette solution à de nouveaux clients.  Consciente de cela, Datatweet souhaite faire évoluer son système d’information en utilisant, si besoin et                              malgré des réticences évidentes, la puissance du cloud et les outils SaaS.     3/26 
  4. 4. Présentation du SI   Actuellement on peut distinguer deux parties dans le SI :  ● Le SI « core business » : qui permet de développer, de maintenir et de proposer aux clients la                                      plateforme SaaS de e­reputation  ● Le SI « fonctions transverses » : qui regroupe les outils informatiques dédiés aux fonctions                              transverses de la société (RH, CRM, Paie…)        Les acteurs   Le SI « core business » est un SI hébergé, basé sur une architecture de type “offre serveurs dédiés” avec                                        un minimum de services (gestion uniquement physique des machines). Cette prestation est contractualisée                          avec OVH.    Le métier de Datatweet est basé sur l’analyse des flux de tweets, ils sont sa matière première. La                                    disponibilité de ces derniers est donc critique. Ces tweets sont disponibles via flux fourni par un prestataire                                  (GNIP, société appartenant à Twitter), qui vend l’accès aux flux de tweets. La contractualisation avec ce                                prestataire est stratégique pour Datatweet : en effet d’une part cela constitue la majeur partie de ses                                  dépenses récurrentes, et d’autre part la disponibilité et l’exhaustivité des tweets est la base du modèle de                                  Datatweet.    Enfin, les clients finaux, qui accèdent directement aux SI de Datatweet en se connectant sur la plateforme                                  SaaS, sont également des acteurs important. En effet il est impératif qu’ils accèdent à un site performant qui                                    évolue régulièrement et où les problèmes sont résolus avec le minimum de délais. Ils contractualisent avec                                4/26 
  5. 5. Datatweet via un abonnement de type SaaS qui leur donne accès à la plateforme et à un certain volume de                                        tweets à analyser.    Les acteurs : OVH OVH, créé en 1999, est un hébergeur français de sites web. Il propose des serveurs dédiés, des serveurs                                    privés, de l'hébergement mutualisé, du housing (ou colocation), des services de Cloud computing, de la                              fourniture d'accès Internet par lignes ADSL, VDSL ainsi que SDSL, l'enregistrement de noms de domaine,                              ainsi que de la téléphonie sur IP. Avec environ 180 000 serveurs en octobre 2014, OVH dispose de l'un des                                        plus grands parcs de serveurs au monde.  De plus, OVH a déployé son propre réseau de fibre optique, géré avec des équipements DWDM, à travers                                    le monde (Europe, Amérique et Asie). L'hébergeur avance une capacité totale de 3 Tbps.  (Cf. annexe 4)      Le réseau OVH Europe.  3000 Gbps de capacité vers l'Internet. (ovh)    Les acteurs : GNIP GNIP est une société américaine d’agrégation et d’analyse des données issues des réseaux sociaux, parmi                              lesquels Twitter, qui l’a rachetée en 2014. GNIP est une des rares sociétés possédant l’accès à la totalité du                                      flux Twitter.  La société Datatweet possède un contrat avec GNIP pour mise à disposition des données Twitter. Le flux de                                    données entre GNIP et Datatweet est un stream http (Comet).  Ce contrat confère un accès exhaustif aux tweets en temps réel, ce qui permet à Datatweet de garantir                                    l’exhaustivité des tweets et la quasi instantanéité de l’analyse des données.    Il est important de souligner que GNIP est le fournisseur exclusif de données de Datatweet. Ce dernier est                                    par conséquent très dépendant du flux de données fourni par GNIP.  (Cf. annexe 3)    5/26 
  6. 6. Méthodologie   Le projet sera réalisé en se basant sur la méthode DMAIC :   En effet, cette méthodologie est adaptée au contexte : Datatweet est une start­up ayant 3 ans d’existence,                                  avec le besoin de consolider (voire industrialiser) ses processus, ses outils, le tout avec une qualité de                                  service améliorée afin de pouvoir proposer un service performant à ses clients, maintenant ou dans les                                années à venir.    Pour cela, nous analyserons tout d’abord le contexte de Datatweet, ainsi que ses priorités (métier,                              techniques, fonctionnelles) pour déterminer quels sont les enjeux de leur activité.   En fonction de ces enjeux, nous mettrons en place des indicateurs qualitatifs et quantitatifs qui nous                                permettront de mesurer la qualité de service actuelle (ainsi que la qualité de service perçue) au sein de la                                      société. Cette étude nous permettra de mettre en lumière les points faibles de l’activité en terme de QoS,                                    pour comprendre ensuite les causes profondes de ces problèmes.   Puis nous proposerons des points précis à mettre en place ou à faire évoluer pour améliorer la qualité de                                      service ­ ces points nous permettront d'identifier des solutions du marché qui pourront supporter cette                              amélioration.   Enfin nous nous assurerons de la bonne implémentation de cette solution en décrivant les points à contrôler                                  pour assurer une constante amélioration de la qualité de service.   Critères clés de qualité   Suite à nos entretiens, trois critères ressortent comme majeurs et critiques pour l'activité de la société :    ● Performance : La plateforme de Datatweet traite des requêtes liées parfois à plusieurs millions de                              tweets. Chaque tweet porte les informations de son créateur, son contenu, et son éventuel lien vers                                un site web. Pour garantir une utilisation fluide et efficace de la plateforme, Datatweet doit assurer                                des performances optimales. C’est une problématique au coeur de leur métier.  L’exigence se mesure ainsi : disponibilité des tweets 1 minute après leur parution, et traitement des                                requêtes client en 4 secondes.     ● Maîtrise : Elle se décline en deux sous­critères :   ○ Tout d’abord la gestion de l’infrastructure pour garantir une intégration optimale avec le                          logiciel et ainsi obtenir les meilleures performances possibles.   ○ Ensuite la nature de l’activité de Datatweet l’oblige à maîtriser complètement ses données.                          Si les flux Twitter sont publics, l’identité de ses clients et la nature des requêtes qu’ils                                effectuent sur la plateforme sont confidentielles. Ainsi la maîtrise des données est garante                          de la confidentialité.    ● Sécurité : L’actualité nous montre que la sécurité reste la clef de voûte d’un SI industriel. Datatweet                                  y apporte une attention particulière. Les exigences pour Datatwet portent sur :   ○ La disponibilité : hors période de maintenance planifiée la nuit (heure française), Datatweet                          garantit une disponibilité de 99,99% pour sa plateforme. En cas d’indisponibilité partielle,                        l’accessibilité àla plateforme Datatweet proposée à ses clients reste prioritaire par rapport                        6/26 
  7. 7. au flux GNIP. Le but étant de privilégier les requêtes sur les tweets déjà “en cache” et ainsi                                    de permettre aux clients de continuer à travailler;  ○ L'intégrité : Datatweet garantit sur sa plateforme l'exhaustivité des tweets publiés sur                        Twitter via son contrat avec GNIP ;   ○ La confidentialité des données des Clients de Datatweet.      Analyse SWOT     Positif  (pour atteindre l’objectif)  Négatif  (pour atteindre l’objectif)  Facteurs Internes  “(Organisationnel)  ­ Plateforme performante    ­ Réactivité face aux bugs et          évolutions    ­ Fonctionnement faisant une      utilisation forte de l’agilité    ­ Architecture maîtrisée  ­ Pas de processus définis    ­ Une maintenance manuelle qui        prend du temps    ­ Une expertise peu documentée    ­ Manque de temps/de      ressources    ­ Réticence au Cloud    ­ Peu/pas d’outils de support    Facteurs Externes  ­ Le besoin de connaissances        sur les réseaux sociaux se          développe (= nouveaux clients        potentiels)    ­ Les outils Cloud arrivant à          maturité, ils peuvent répondre        au besoin d’élasticité, de        performance et de maîtrise    ­ Processus et infrastructure      insuffisants face à      l’augmentation du nombre de        clients    ­ Fournisseur exclusif de donnée        : risque    Il ressort de cette matrice les éléments suivants :  ● Besoin d’industrialisation des techniques et des processus ;  ● Besoin d’outils de support ;  ● Besoin d’une infrastructure évolutive (“scalable”) pour répondre aux demandes croissantes de                      nouveaux clients et pour permettre des évolutions fonctionnelles.    7/26 
  8. 8. Analyse des processus clés   Compte tenu de la taille (start­up de 10 personnes) et de la structure de la société, nous avons identifié trois                                        processus clés : la gestion des demandes, la gestion de la maintenance, et les mises en production.        Les déploiements des nouvelles versions de la plateformese font avec l’aval du directeur technique, d’abord                              sur l’environnement de test, puis sur l’environnement de production.    Ce processus ITIL peut encore être amélioré en incluant la gestion des changements et des configurations.                                Voici des exemples d’évolutions:    ● intégrer des collaborateurs Datatweet métiers dans des comités consultatifs des changements                      (CAB) qui pourront faire des recommandations sur le contenu des développements et leur                          calendrier de déploiement;  ● intégrer les nouvelles versions logicielles et les modifications sur le matériel dans une CMDB                            (Configuration Management Database) pour aider à contrôler ces éléments tout au long de leur                            durée de vie.  8/26 
  9. 9.   Lorsqu’un client formule une demande, celle­ci est gérée par les équipes IT de Datatweet au moyen d’un                                  fichier Excel. La gestion pourrait être améliorée avec un logiciel de ticketing ouvert au client.                                          Datatweet dispose de la solution Pingdom, un logiciel de supervision très complet et très performant.                              Cependant, il n’y a pas de processus de gestion des incidents chez les équipes IT au sens ITIL du terme.                                        C’est un axe qui devra être amélioré.  9/26 
  10. 10. Objectifs identifiés   Actuellement, le SI "core business" est hébergé et le SI "fonctions transverses" se limite à une gestion sur                                    tableur.   Le choix de ces solutions repose sur des décisions et des contraintes, pensées et définies pour une start­up                                    au démarrage de son activité. Arrivée dans une phase de développement, Datatweet doit initier une                              réflexion autour des ces aspects.    L'objectif premier de ce projet est d'optimiser la partie "core­business" de l'activité de la société, ainsi que de                                    lui donner une architecture SI pérenne qui lui permettra de faire face à sa croissance importante. Il inclue le                                      support de sa plateforme SaaS ainsi que le hub d’échange entre les données Twitter (GNIP) et les requêtes                                    des clients. C’est un aspect critique pour la société car de lui dépendent la performance, la sécurité des                                    données ainsi que l’exhaustivité des données traitées.    L'objectif secondaire est de créer un SI "fonctions transverses” qui permettra de supporter l'activité sur le                                long terme. Aujourd’hui basé sur des processus et des outils basiques, et n’ayant pas été le fruit d’une étude                                      poussée des besoins, il est à repenser et à créer. Si ce n’est pas un aspect stratégique pour Datatweet, ne                                        pas le traiter peut s’avérer dangereux pour la pérennité de son développement.    Ces deux parties ont pour but ultime d'améliorer l'efficacité de la société : en effet, en réduisant le temps de                                        traitement manuel (création d'un client, maintenance infra...) tout en maintenant des critères de performance                            et de maîtrise à des niveaux acceptables, la société sera en mesure de répondre aux demandes croissantes                                  de ses clients, tout en dégageant du temps pour se concentrer sur son cœur de métier (développement de                                    l'activité et évolutions de la solution). De plus une plus grande automatisation améliorera la qualité de                                service, et limitera les risques liés à la sécurité.    Cette industrialisation du SI facilitera de surcroît les évolutions fonctionnelles de l’offre Datatweet. En effet                              un SI solide, industrialisé, et évolutif, permet de supporter les nouvelles fonctionnalités envisagées par la                              société (rapport de “e­réputation” public hebdomadaire, mise à disposition d’API pour ses clients pour                            intégrer des rapport Datatweet au sein même de leur SI…).          10/26 
  11. 11. 2. Mesure KPI de mesure identifiés   Nous avons effectué une série de mesures quantitatives et qualitatives pour identifier les points forts et les                                  points faibles de Datatweet.   Ces données ont été obtenues par des entretiens qualitatifs, des questionnaires quantitatifs, ainsi que par                              des mesures effectuées directement par nos équipes sur une période de 15 jours dans la société (analyse                                  des logs, prise de temps…). Les tests de charge on été exécutés la nuit pour ne pas pénaliser les clients de                                          Datatweet.    Performances/Capacité  ­ Temps de traitement d’une requête depuis la plateforme SaaS : 4 secondes  Cette prise de mesure est effectuée dans le contexte suivant :  ○ 20 clients ouverts sur la plateforme  ○ 4 clients connectés  ○ Requêtes traitant 400 000 tweets   ­ Test complémentaire :  ○ Prise de mesure 1 client connecté, et une requête de 3 000 000 de tweets : 10 secondes  ­ Temps de mise à disposition des tweets : 1 minute (GNIP)  ­ Taux de tweets disponibles par rapport à l’ensemble des tweets postés : 100%  ­ Maximum de tweets traitable sans ralentissement (2014) :  1 000 000   ­ Simulation de l’augmentation du nombre de Clients simultanément connectés et mesure du temps                          moyen d’une requête de référence (400 000 tweets traités) exécutée sur tous les postes clients                              (simulés par des machines virtuelles)  ­ 1 Client ⇒ 4 secondes  ­ 5 Clients => 4 secondes  ­ 10 Clients => 10 secondes  ­ 15 Clients => 1 minutes ; note la GUI client est ralentie  ­ 20 Clients => non mesurable ; la plateforme Datatweet n’est plus utilisable    Sécurité  ­ Sécurité: firewall géré par le client  ­ Disponibilité des serveurs dédiés: pas de garantie en cas de panne.  ­ Pas de définition d’un mode dégradé qui pourrait parer à un manque de ressource provisoire  ­ Traçabilité ­ archivage des logs: 2 ans    Élasticité  ­ Temps de mise en place d’un nouveau serveur physique : 4h  ­ Temps de mise en place d’une nouvelle VM : 15 minutes    Qualité processus :  ­ Temps moyen d’ouverture d’un nouveau client : 3 jours  ­ Temps moyen de maintenance SI / jour : 4 heures   ­ Temps de réponse à une question client : 6 heures  ­ Temps de résolution d’un incident : au plus vite, pas de SLA.  11/26 
  12. 12. ­ Temps de mise en prod d’une correction : une fois/mois  ­ Temps de mise en prod d’une évolution : 3 fois par mois    Définitions des tâches avec temps moyen passé par mois et leur classification en termes de valeur ajoutée :    Tâches  Valeur ajoutée?  Temps passé en      heures par mois  Monitor PLTF  Faible  40  Ajout Serveur  Faible  24  Livraison Bug  Faible  23  Reboot des VMs (maintenance OVH)  Faible  10  Alertes OVH (console)  Faible  4  Suppr. client  Faible  0  Bug Fix  Moyenne  36  Assistance  Moyenne  32  Ajout client  Moyenne  20  MongoDB  Forte  3  GNIP  Forte  2      12/26 
  13. 13. 3. Analyze Problèmes identifiés   Voici les problèmes mis en lumière à partir des mesures quantitatives et des entretiens qualitatifs effectués:    1. Temps passé sur la gestion manuelle des SI sur des tâches avec une faible valeur ajoutée  2. Risque lié à la confidentialité des données  3. Processus ralentis par la structure SI   4. Risque lors d’un besoin fort d’élasticité pour assurer la robustesse du système en cas de montée de                                  charge  5. Dépendance à un seul fournisseur de données    La structure SI est adaptée à une start­up mais pas assez structurée et puissante pour affronter l’évolution                                  forte de l’activité à venir. De plus le SI support et les processus sont trop faibles.    Analyse des causes profondes   Tout d’abord nous allons étudier de manière approfondie les résultats des mesures liées aux actions                              manuelles effectuées sur le SI, en fonction du temps passé, et de la valeur ajoutée (en terme d’avantage                                    compétitif métier) de l’action effectuée :        La tendance suivante apparaît : plus de 63% du temps passé sur la gestion du SI l’est sur des tâches avec                                          une faible valeur ajoutée.   13/26 
  14. 14. Si l’on analyse le détail de ces tâches, trois catégories consommatrices de temps et à faible valeur ajoutée                                    ressortent :  ­ Le monitoring   ­ Les actions “infra” basiques  ­ La gestion des clients    Quels sont les causes profondes liées à ces problèmes ?    1. La volonté de maîtrise. Pour quelles raisons est­ce si important pour Datatweet? Pour la sécurité                              principalement. Dans ce cadre il ressort un manque d’organisation, de structure, et surtout pas de                              gestion de la sécurité en tant que telle ­ hormis au niveau développement.   2. Le manque de connaissances et de temps sur l’état de l’art du Cloud computing, la peur de la perte                                      de maîtrise, du manque de contrôle et de confidentialité : de fait l’élasticité est quasi inexistante.                                Une action manuelle est requise pour l’ajout de chaque nouvelle VM. De plus il y a un risque                                    sous­jacent de sous­dimensionnement en cas d’augmentation forte de l’activité du service, et donc                          des possibilités de baisse de performance et d’indisponibilité.  3. Des processus insuffisants ­ et limités à Datatweet ; il n’existe pas de processus définis pour les                                  relations avec les fournisseurs comme OVH (passages de modifications en production, reboot                        serveurs)  4. Un SI support sous développé, et qui ne peut supporter l’activité : beaucoup d’actions manuelles, un                                manque d’automatisation, forte implication des ressources de l’entreprise dans des actions sans                        valeur ajoutée.    En conclusion le coût de non­qualité dans la maîtrise de l’infra est énorme (environ 5 jours homme/mois)                                  pour une entreprise de 7 personnes avec 20 clients. Si le nombre de clients augmente, cette tendance sera                                    accentuée, et les risques liés ne feront qu’augmenter.  Le risque est accentué par une infrastructure SI peu flexible, et des processus “maison” non­industrialisés.   Techniquement, une solution permettant l’élasticité du SI est indispensable pour améliorer l’efficacité du SI à                              répondre aux demandes métier (nouveaux clients, requêtes plus importantes) et garantir la disponibilité du                            SI en cas de fluctuation des besoins de ressources, par exemple lors d’un pic de charge coté client.     Choix de l’axe à traiter   En termes de priorités, les choix stratégiques d’architecture sont à remettre en cause. Ce n’est pas                                uniquement une question d’infrastructure, mais bien également de processus à redéfinir et de SI                            “transverse” à améliorer.    Dans le cadre du projet, nous analyserons en détail la première partie ­ le SI “core business”, et nous                                      donnerons des recommandations plus succinctes sur le SI “fonctions tranverses”.    14/26 
  15. 15. Diagramme des causes profondes       Fiches labels   La mise en lumière de ces causes profondes nous permet de définir des points de contrôle qui permettront                                    de résoudre les problèmes identifiés et d’améliorer de manière continue la qualité de service de Datatweet.    Les fiches labels abordent la sécurité, l'élasticité, la disponibilité, la bande passante et la gestion d’un type                                  de demande : les incidents. Ces aspects ne sont pas exhaustifs mais sont apparus comme les plus                                  critiques.    Le détail des fiches labels se trouve en annexe à ce document.        15/26 
  16. 16. 4. Improve   Nos analyses ont indiqué que la situation actuelle ne répondait pas aux besoins d’évolution du SI de                                  Datatweet. Nous en avons déduit les principaux facteurs clés de qualités, à savoir: la performance, la                                sécurité, la localisation des données, l'élasticité, l’intégration des processus métiers et les coûts                          d’exploitation, afin d’identifier une solution du marché pouvant répondre à ces besoins.  Nous allons comparer ces critères par rapport à différents scénarios possible et ainsi déterminer la meilleure                                solution:        Solutions  No.  Critères clés  Serveurs  dédiés  Cloud  public  Cloud  hybride  Cloud  “dédié”  Nombre  d'importance  1  Performances  ­  +  +  ++  1  2  Sécurité  ­  +  +  ++  3  3  Localisation  ++  ­  ­  ++  4  4  Elasticité  ­  ++  ++  +  5  5  Processus métiers  ­  +  +  ++  6  6  Coûts d'exploitation  ­  ++  ++  ++  2    Somme des ++  1  2  2  5      Somme des +  0  3  3  1      Somme des ­  5  1  1  0      ● Performances: la solution actuelle ne répond pas aux exigences de performances de la société                            Datatweet. L’offre Cloud “dédié” d’OVH offre le meilleur niveau de performances avec un hardware et                              un réseau 100% dédiés. Le Cloud public offre de bonnes performances car la plateforme de                              virtualisation est gérée par OVH. Dans le cas du cloud hybride, les performances sont garanties en cas                                  de débordement sur le cloud public, mais pas sur les données hébergées sur les serveurs du client.    ● Sécurité: ce critère regroupe la disponibilité, la confidentialité, l’intégrité et la traçabilité des données. La                              solution actuelle ne permet pas d’y répondre car Datatweet ne dispose pas des moyens et des                                compétences pour assurer la sécurité des données. Le cloud hybride et public offrent également un bon                                niveau de sécurité, mais Datatweet ne souhaite pas que ses données se trouvent sur une plateforme                                partagée avec d’autres clients. Enfin, l’offre cloud dédié garantit le meilleur niveau de sécurité avec des                                SLA à 100% sur le réseau et le stockages et des SLA de 99,99% sur les serveurs hosts. De plus, l’offre                                          cloud dédié est certifiée ISO27001.    ● Localisation des données: la société Datatweet veut s’assurer de la localisation exacte des données.                            Seuls les serveurs dédiés et l’offre cloud dédié proposent cette garantie.    ● Elasticité: les offres cloud public, hybride et dédié permettent d’absorber les pics de charge. Néanmoins,                              la capacité d’élasticité est limitée dans le cloud dédié par l'espace dont dispose l'infrastructure détenue.   16/26 
  17. 17.   ● Processus métiers: par rapport aux autres offres, le cloud dédié offre la maîtrise et l’agilité nécessaire                                au SI pour permettre à Datatweet l’intégration des processus métiers basés sur le référentiel ITIL.     ● Coûts d'exploitation: le cloud permet grâce à la virtualisation de consolider les serveurs ainsi que les                                applications. Conjugués au “pay as you go”, il facilite la maîtrise des coûts d’exploitation.     Après comparatif, la solution “cloud dédié” d’OVH a été retenue.    Elle répond aux critères majeurs et critiques pour l'activité de la société:    ● Performance: le cloud dédié offre suffisamment de puissance de calcul, grâce à l’élasticité, et                            d’espace de stockage pour permettre à la base de donnée MongoDB de traiter des requêtes clients                                sur plusieurs millions de tweets. La bande passante est suffisante pour que tous les clients puissent                                se connecter en même temps.      ● Maîtrise: le cloud dédié est le seul qui permette de s’assurer de la localisation exacte des données.                                  La maîtrise intégrale de l’infrastructure facilite l’intégration des applications et des processus                        métiers. Les coûts d’exploitation sont également mieux maîtrisés.    ● Sécurité: OHV garantit une disponibilité de l’infrastructure proche de 100%. Les connexions                        extérieures sont sécurisées par des solutions Anti­DDoS et VPN SSL. Le cloud dédié est certifié                              ISO 27001. L’attestation SOC 1 type I atteste qu’OVH a bien défini et mis en place des contrôles                                    pour la protection des données de ses clients  Le principal changement dans notre projet est la migration des serveurs physiques de la société Datatweet                                vers l’offre cloud dédié d’OVH. Cette migration nécessite la virtualisation de la plateforme Datatweet. Un                              mode de fonctionnement dégradé de la plateforme est également défini ; il implémente les critères de                                qualité définis par Datatweet (i.e. accessibilité de l’interface prioritaire sur le flux GNIP).      Les principaux gains de cette solution sont les suivants:  ­ Excellents niveaux de sécurité et de performance;  ­ Les processus métiers sont plus efficaces car basés sur les bonnes pratiques ITIL;  ­ Les coûts d’exploitation sont maîtrisés;  ­ L’élasticité permet de répondre plus efficacement aux besoins métiers.  17/26 
  18. 18.   Les échanges sont décrits dans le schéma suivant :        Planning de migration:        Le planning s’étend sur 2 mois, du 6 avril au 29 mai 2015  et comprend deux phases:   ● une phase de build, qui correspond à l’analyse de la solution cible et du budget;  ● une phase de run, avec la migration des serveurs et des données, ainsi que la recette.    Budget prévisionnel:    Build  Coût  Run  Coût    Analyse de la solution  5 000  Migration des  serveurs  10 000    Définition du budget  5 000  Migration des  données  20 000    Sous­total  10 000  Sous­total  30 000          Total  40 000  Les tâches d’analyse de la solution cible et de définition du budget comptent chacune 10 jours­homme et                                  sont facturées 500€ par jour.    18/26 
  19. 19. Les tâches de migration des serveurs et des données font appels à plusieurs équipes de spécialistes, ce qui                                    explique qu’elles soient facturées plus cher, respectivement 1 000€ et 2 000€ par jour.    Planning des ressources:        Les ressources intervenant sur le projet ont été réparties de la façon suivante:  ● Le chef de projet supervise toute la phase de BUILD et de RUN;  ● L’architecte technique intervient dans l’élaboration de la solution et apporte son expertise technique                          dans la phase de migration des serveurs;  ● Le responsable MOA apporte son expertise métier dans la phase de migration des données;  ● L’équipe infrastructure prend en charge toute la phase de RUN.    Prévention des défaillances (FMEA):    Etapes  Erreurs potentielles  Causes potentielles  Contre­mesures  Migration des serveurs  Plantage serveur  Panne matériel  Serveurs de backups  Migration des serveurs  Mauvaises performances  Besoins mal définis  Elasticité dans le cloud  Migration des données  Données corrompues  Erreur de copie  Backup des données  Migration des données  Données manquantes  Manque de volumétrie  Disques en spare  Migration des données  Données piratées  Captation transfert  Canal de transfert sécurisé    Process sigma du pourcentage de tweets traités sans erreur:      Ancien  Nouveau  1. Déterminer le nombre d'opportunités de défauts par unité O=  1  1  2. Déterminer le nombre d'unités traitées N=  10 000  10 500  3. Déterminer le nombre total de défauts D=  365  125  4. Calculer le nombre de défauts par opportunité DPO=D/(NxO)=  36  12  5. Calculer le rendement (1­DPO)x100=  96,40%  98,80%  6. Relever la valeur du "Process sigma" dans une table Sigma=  3,3  3,8  19/26 
  20. 20. 5. Control   Suite à la mise en place de cette nouvelle solution décrite en partie 4. (“Improve”) pour répondre aux                                    besoins d’amélioration du SI “core business” décrits en partie 3. (“Analyze”), nous allons maintenant détailler                              nos recommandations afin de permettre à Datatweet de tirer profit au maximum de ces nouveaux outils, en                                  conservant et améliorant continuellement sa qualité de service au travers des 5 indicateurs clés identifiés                              précédemment.    Les contrôles Suite aux points identifiés par notre analyse, des labels (KPI) ont étés définis. Leur objectif est de cadrer les                                      points clés d’une solution pouvant soutenir la croissance de datatweet. Ces KPI assureront la continuité puis                                l’amélioration continue de la qualité de service.    Pour cela des contrôles définis et réguliers seront pratiqués selon les procédures définies dans les fiches                                labels. Selon la logique de la roue de Deming, ils correspondent à l’étape “Check”.    Afin d’améliorer la qualité de service, ou à défaut de la maintenir à un niveau acceptable, deux types                                    d’actions (“Act”) seront entreprises suite au résultat de la mesure du KPI :  ­ Premièrement des actions de corrections immédiates : le but est de régler le problème mis en                                lumière par le point de mesure, dans le but de faire revenir le KPI à un niveau acceptable en                                      fonction des seuils définis en amont (“Plan”),  ­ Deuxièmement des actions d’améliorations : le but est d’identifier la cause profonde du problème,                            pour les analyser et définir des actions pour empêcher le problème de se produire à nouveau. Bien                                  sûr les actions devront être analysées (coût, besoin, …) avant implémentation.    Enfin, une nouvelle série de contrôles permettra de vérifier les résultats des actions correctives entreprises.    Toutes ces étapes de contrôle et d’amélioration du SI reposent sur une double mécanique :  ­ Des rôles et responsabilités clairement définis chez Datatweet  ­ Un contrat de service précis, qui permet de donner maitrise et confiance à Datatweet sur des                                aspects du service gérés par OVH. Pour cela le contrat doit reprendre les mêmes points                              structurants, définir des seuils d’alertes, des responsabilités, et des contreparties en cas de non                            respect des clauses. Ce contrat est détaillé en annexe.  20/26 
  21. 21. Les outils de pilotage   KPI  Actions de correction      envisageable  Actions d’amélioration envisagable  KPI#1 (sécurité)  ­ Audit : corriger le problème              (révoquer des accès…)  ­ PenTest : identifier la faiblesse,              corriger le code ou mettre en place              une règle complémentaire  ­ Audit : Améliorer les processus (ex :                départ d’un employés, mise en production            d’un changement ou d’une correction…),          automatisation de certaines actions, pour          éviter qu’elles ne soient oubliées,          campagnes de prévention...  KPI#2 (indisponibilité)  ­ revenir sur une version de la              plateforme précédente car plus fiable  ­ communiquer le planning de          maintenance en interne et le          respecter en cas de livraison  ­ redonder provisoirement certains        équipements OVH ou applicatifs        Datatweet  ­ communiquer procédure de        contournement à nos clients  ­ revoir conception du SI pour permettre              une maintenance par module => limiterait            l’indisponibilité perçue  ­ mettre en place une maintenance            préventive (OVH+Datatweet)  ­ améliorer process de Release          Management (plus de tests E2E)  ­ automatiser le contournement  KPI#3 (bande passante      réseau)  ­ provisoirement augmenter la bande          passante ou la configuration de          certains équipements ou les redonder  ­ passer les requêtes Datatweet sans            impacts client pendant la nuit  ­ optimiser les flux GNIP en regroupant les                requêtes des clients  ­ implémenter des requêtes différées et            étudier une offre commerciale attractive          pour inciter nos clients à passer les              requêtes la nuit  ­ établir les statistiques des tweets dans le                but d’anticiper les besoins de bande            passante  KPI#4 (incidents)  ­concentrer ses efforts sur les          incidents majeurs qui impactent les          clients et le business  ­définir des indicateurs de seuil sur            l’outil de supervision pour distinguer          incidents et avertissements et        détecter les incidents plus rapidement  ­étudier l’implémentation du processus ITIL          de gestion des problèmes pour traiter les              causes racines des incidents.  ­ étudier la création d’une équipe de              résolution d’incidents “niveau 2” sur de            l’expertise métier.  KPI#5 (élasticité)  ­faire un audit rapide des ressources            actuelles pour mieux anticiper les          besoins d’élasticité futurs.  ­faire une revue des environnements          de travail virtuels de chaque client            pour les rendre plus “propres” et les              délivrer plus rapidement.  ­étudier l’évolution vers le cloud hybride            pour améliorer les performances        d’élasticité.  ­ améliorer le process interne Datatweet            pour mieux anticiper les besoins métiers            (i.e. nouveaux clients) et donc mieux lisser              les demandes de capacités  ­ étudier les débordements dans un autre              data center OVH en France ou chez un                partenaire d'OVH en France    Tableau de Bord Un tableau de bord opérationnel permet de piloter le SI de Datatweet et donc d’améliorer la qualité du                                    Qualité du Service d’eReputation.  21/26 
  22. 22. Il est construit par Datatweet et revu de façon mensuelle avec ses partenaires. Il peut être publié sur le site                                        internet de Datatweet, partiellement, comme gage de garantie de la qualité de service.    Catégorie  Etat   (vert/orange/rouge )   Tendance   (↗ → ↘)  KPI    Valeur  Actions immédiate  Action d’amélioration  Sécurité       ↗    Sécurité    14,3% de points KO:  GO  Erreur : accès ouvert pour un            développeur ne travaillant plus        chez DT  Correction : fermer les accès   Amélioration : revoir le        processus de gestion      des changements    (départs/ arrivés) voir      l’automatiser pour limiter      les erreurs  Disponibilité      ↗  Disponibilité    plusieurs clients n’ont  pas pu se connecter    Un incident le 25/12/2014        indique qu’un pic de charge n’a            pas pu être absorbé par la            plateforme cloud. La plateforme        était indisponible pour plusieurs        clients.  Correction:’ajout en urgence de        serveurs physiques d’OVH.  Analyser les ressources      du cloud dédié pour        déterminer si elles sont        suffisantes.  Performance  ↗  Bande passante      utilisation de la bande        passante à 115%    Congestion sur le réseau lors          d’un pic de charge pendant les            fêtes de fin d’année.    Le log du 25/12/2014 indique          que des clients ont fait des            requêtes simultanées en très        grande quantité.  Définir des seuils      d’alerte plus pertinents      sur les liens réseaux        pour prévenir les pics de          charge.  Maîtrise  ↗  Gestion des incidents     incident bloquant à      solutionner dans les 4h  Incident majeur le 25/12/2014.        Certains clients n’ont pas pu se            connecter.  L’incident a été géré en          urgence par une cellule de          crise.  Analyser les causes      racines de l’incident.  Performance  ↗  Elasticité    charge au niveau CPU        des serveurs à 120%  L’incident du 25/12/2014      indique que les CPU des          serveurs n’étaient pas assez        puissants pour absorber la        charge.  Des serveurs ont été rajoutés          par OVH en urgence.  Refaire une étude sur        les besoins réels et les          capacités en élasticité      de la plateforme    22/26 
  23. 23. Backlog Le backlog recense la liste des actions en cours. Son objectif est d’aider à la priorisation des actions sur des                                        critères d’impact métier et de difficulté technique. Il est construit en collaboration avec les partenaires de                                Datatweet.    Sondage Datatweet propose à ses clients un sondage en ligne trimestriel dont l’objectif est de recueillir les remarques                                  et les propositions dans le but d’améliorer la qualité de service générale de la société et de comprendre                                    quelle est la qualité de service perçue par ses clients.    Réunion Datatweet met en place une réunion téléphonique tous les seconds mardi de chaque mois avec ses                                partenaires. L’objectif de cette réunion est de :  ● Faire les points les actions en cours,  ● Établir de nouvelles actions si besoin,  ● Mettre à jour le Backlog et le prioriser,  ● Mettre à jour le Tableau de Bord            23/26 
  24. 24. Conclusion   Suite à ce projet, le SI “core business” a atteint le niveau de qualité qui va permettre à Datatweet de  s'appuyer sur des systèmes et des processus solides pour son développement. Il sera en mesure de  supporter l’activité croissante de la société, qui pourra grâce aux outils (KPI) mis en place améliorer la  qualité de service de manière continue.    La prochaine étapes est clairement identifiée : il est nécessaire de faire le même travail d’industrialisation  avec le SI “fonctions transverses”. En effet ce dernier doit être optimisé tant en termes techniques qu’en  termes organisationnels, afin de pouvoir soutenir au maximum l’activité de Datatweet. La jeunesse et la forte  croissance de la société suggère que des logiciels SaaS du marché pourraient à moindre coût constituer  une base idéale à ce SI “fonctions transverses”.    Ce n’est que lorsque ces deux parties du SI seront optimisées et maîtrisées que Datatweet pourra  sereinement appréhender ses évolutions, qu’elles soient liées au volume de clients ou à la nature des  service proposés. Par exemple, l'ouverture de la plateforme par des API semble être une évolution naturelle  et pertinente ­ qui ne pourra se faire qu’au moyen d’un SI performant, sécurisé, et surtout où la qualité de  service est maîtrisée à chaque niveau organisationnel.        24/26 
  25. 25. Annexes   1. L’interview de Raja Chiky le 17/11/2014. Mme Chiky est une experte reconnue dans le domaine du  Big Data et elle nous a éclairé sur les concepts de la eReputation.  2. Le questionnaire qui nous a aidé à recueillir les besoins de Datatweet. Il contient ses réponses.  3. L’analyse de l’offre GNIP, fournisseur pour Datatweet.  4. L’analyse de l’offre OVH, fournisseur pour Datatweet.  5. La charte du projet.  6. Le sondage client qui va aider Datatweet à recueillir la qualité de son service telle qu’elle est perçue  par ses clients.  7. Aperçu des indicateurs qualité entre Datatweet et son fournisseur OVH        25/26 
  26. 26. Remerciements   Toute notre équipe souhaite remercier l’équipe de Visibrain, en particulier Nicolas Huguenin et  Jean­Christophe Gatuingt, qui nous ont accordé beaucoup de temps, afin que cette étude soit la plus  réaliste et intéressante possible.  Nous voulons également remercier Mme Raja Chiky, pour avoir partagé avec nous sa vision et ses  connaissances sur le traitement de données massives.    26/26 

×