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

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

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

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

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

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

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

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

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

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

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

­ 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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