[LaTeX] Mon rapport de stage ST40
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

436 lines
26KB

  1. %%
  2. %
  3. % Skia
  4. % skia@libskia.so
  5. %
  6. %%
  7. \documentclass[a4paper]{report}
  8. %packages
  9. \usepackage[utf8]{inputenc}
  10. \usepackage[francais]{babel}
  11. \usepackage{graphicx}\graphicspath{{pictures/}}
  12. \usepackage{float}
  13. \usepackage[T1]{fontenc}
  14. \usepackage{color}
  15. \usepackage{fancyhdr}
  16. \usepackage{listings}
  17. \usepackage[colorlinks=true,linkcolor=black]{hyperref}
  18. %pdf metadata
  19. \hypersetup{
  20. unicode=true,
  21. colorlinks=true,
  22. citecolor=black,
  23. filecolor=black,
  24. linkcolor=black,
  25. urlcolor=black,
  26. pdfauthor={Skia <skia@libskia.so>},
  27. pdftitle={},
  28. pdfcreator={pdftex},
  29. pdfsubject={},
  30. pdfkeywords={},
  31. }
  32. %inner meta
  33. \title{}
  34. \author{Florent JACQUET}
  35. \date{\today}
  36. \begin{document}
  37. \maketitle
  38. \tableofcontents
  39. \chapter*{Introduction}
  40. \addcontentsline{toc}{chapter}{Introduction}
  41. \chapter*{Remerciements}
  42. \addcontentsline{toc}{chapter}{Remerciements}
  43. \chapter{Faurecia}
  44. \section{Un groupe mondial}
  45. \subsection{Historique}
  46. \subsection{Présentation des activités}
  47. \section{Le centre technique de Seloncourt}
  48. \subsection{Historique}
  49. \subsection{Les différents services}
  50. \section{Mon service: Global Infrastructure and Systems Operations}
  51. \subsection{Rôle dans Faurecia}
  52. \subsection{Activités}
  53. \chapter{Context du stage}
  54. \section{SAP}
  55. \subsection{Qu'est-ce qu'un ERP?}
  56. \par
  57. Un ERP (Enterprise Resource Planning) est un progiciel, c'est à dire un ensemble de logiciels n'en constituant qu'un
  58. seul, et capable de répondre au besoin d'une entreprise dans autant de domaines qu'il a de modules. Les plus courants de
  59. ces modules sont généralement les achats, les stocks, la production, les ventes, la distribution, les salaires, la
  60. comptabilité, les finances et la trésorerie.
  61. \par
  62. Pour faire simple, l'ERP est l'application centrale entre les très nombreux et divers services d'une entreprise. Les
  63. ouvriers sur les chaînes de fabrication, les comptables, les ingénieurs de recherche et développement, et beaucoup
  64. d'autre personnes sont amené à utiliser l'ERP pour synchroniser toutes les informations à partir d'un outil unique et
  65. global.
  66. \par
  67. SAP (Systems, Applications and Products for data processing) est un des ERP les plus connus. Son architecture modulaire
  68. et multi-fonctionnelle en font un outil d'une grande flexibilité pouvant s'adapter à la majorité des entreprises. De
  69. plus, si des fonctionnalités viennent à manquer il est toujours possible de les développer à l'aide de son environnement
  70. de développement et du language ABAP qu'il intègre.
  71. \subsection{SAP chez Faurecia}
  72. \subsubsection{Déploiement et historique}
  73. \par
  74. Le déploiement de SAP au sein de Faurecia remonte à 2009, avec le lancement du projet FCS (Faurecia Core System).
  75. L'application est mise en place dans un centre de données informatiques en Allemagne, à Hagenbach (HGB). L'entreprise
  76. bénéficie alors d'un ERP commun à toutes les usines, soit plus de 183 sites à travers le monde, pour environ 41500
  77. utilisateurs quotidiens.
  78. \par
  79. Les conséquences de l'utilisation de SAP sont nombreuses, en bien comme en mal. Il apporte certes, entre autre,
  80. l'avantage d'être centralisé, c'est à dire que tout le monde a le même outil, et on évite ainsi les problèmes de
  81. synchronisation de production, mais en revanche, cela apporte un point très critique pour la gestion informatique de cet
  82. ERP. En effet, la moindre indisponibilité ralenti, voir stoppe la production, ce qui empêche alors de livrer les
  83. clients, et a donc des conséquences financières directes.
  84. \subsubsection{Architecture}
  85. \par
  86. La quasi totalité des modules SAP existants sont utilisés chez Faurecia:
  87. \begin{description}
  88. \item[ECC] logistique, gestion comptable et ressources humaines
  89. \item[PI/PO] échange de fichiers (clients/fournisseurs en interne et en externe)
  90. \item[BW/BI4] reporting \& consolidation de données
  91. \item[SRM] achats
  92. \item[CPS] ordonnanceur des traitements informatiques
  93. \item[Portal] portail informatique permettant les connexions utilisateurs
  94. \item[VPSX] impression des documents
  95. \item[SolMan] gestion des comptes utilisateurs et outil de surveillance applicative
  96. \item[Archiving] gestion de l’archivage des données
  97. \item[HANA] accélérateur d’accès aux données
  98. \end{description}
  99. \vskip 7mm
  100. \par
  101. De plus, pour chaque module, plusieurs environnements, c'est à dire plusieurs instances, sont déployés:
  102. \begin{description}
  103. \item[Développement] permet de développer de nouvelles fonctionnalités
  104. \item[Simulation/Qualité] permet de valider les nouveaux développements
  105. \item[Pré-production] permet de tester et valider avant la mise en production les développements dans un contexte
  106. (physique, applicative et données) identique à l’environnement de production
  107. \item[Production] permet de délivrer les fonctionnalités aux utilisateurs
  108. \end{description}
  109. \vskip 3mm
  110. L'environnement de production étant utilisé en permanence par les utilisateurs finaux, c'est celui qui est le plus
  111. critique, contrairement aux autres, qui ne servent globalement que pour des tests.
  112. \section{FCS Business Continuity}
  113. \subsection{Origine}
  114. \par
  115. \emph{FCS Business Continuity} est le projet sur lequel j'ai travaillé pendant mon stage. Il a été démarré en Juin 2015,
  116. à la suite de plusieurs incidents au niveau de SAP. Ces incidents étaient d'ordre technique, liés principalement aux
  117. serveurs, et la versions des logiciels utilisés dessus. La décision fût donc prise de mettre en place une sécurisation
  118. de l'ERP, et le projet FCS BC fûr donc confié à Murielle.
  119. \subsection{Objectifs du projet}
  120. \par
  121. Il a pour but de supprimer les activités informatiques centrales du site de Hagenbach pour les transférer à Marcoussis
  122. (EDC), et de sécuriser les environnements SAP. Cela passe par plusieurs points critiques:
  123. \begin{itemize}
  124. \item Transférer les environnements SAP hébergés à Hagenbach dans le Data Center de Marcoussis
  125. \item Mettre en place une séparation physique et logique des environnements transférés entre les différentes régions
  126. géographiques de Faurecia (Europe/Asie/Amérique/Central)
  127. \item Déplacer les environnements SAP hors production dans le nouveau Data Center de Clichy (depuis HGB et/ou depuis
  128. EDC)
  129. \end{itemize}
  130. \vskip 3mm
  131. \par
  132. Ce projet apporte plusieurs avantages non négligeables:
  133. \begin{itemize}
  134. \item Éviter de perdre tous les modules SAP de toutes les régions en cas de problème en les séparant tant
  135. physiquement que logiquement
  136. \item Réduire les impacts pour les sites de production FAURECIA:
  137. \begin{itemize}
  138. \item Limite du périmètre affecté en cas de problème
  139. \item Être capable de planifier des opérations plus facilement région par région
  140. \end{itemize}
  141. \item Standardiser les serveurs et solutions informatiques SAP quelque soit la région géographique qu'ils supportent
  142. \item Sécuriser la production FAURECIA avec une solution de reprise d'activité disponible dans un Data Center distant
  143. \item Libérer le site d'Hagenbach des contraintes liées à un Data Center
  144. \end{itemize}
  145. \subsection{Ma position dans FCSBC}
  146. \par
  147. Mon rôle dans le projet Business Continuity a été d'assurer le suivi du monitoring pendant les phases de déplacement (ou
  148. \emph{move}) des environnements SAP.
  149. \section{Nagios}
  150. \subsection{Le monitoring en général}
  151. \par
  152. Si l'on traduit le terme \emph{monitoring}, on obtient \emph{surveillance}, ou \emph{supervision}. Cela définit
  153. parfaitement le concept, puisque le but de mettre en place un système de monitoring dans une infrastructure est de
  154. surveiller en permanence. Surveiller le réseau, mais aussi les machines, ou encore les services et processus eux-même
  155. qui tournent sur ces dernières.
  156. \par
  157. Surveiller, c'est une chose, mais le rôle du monitoring est aussi beaucoup de prévenir, lorsque quelque chose ne va pas.
  158. Dans ce cas, des mails sont généralement envoyés automatiquement, mais on peut aussi faire beaucoup plus, comme par
  159. exemple déclancher des scripts qui vont tenter d'autoréparer le système.
  160. \subsection{Nagios chez Faurecia}
  161. \subsubsection{Nagios}
  162. \par
  163. \emph{Nagios} est une solution libre et open-source de monitoring apparut en 1996, et qui a depuis fait ses preuves dans
  164. bon nombre d'infrastructures. Il permet de surveiller la (quasi?) totalité des équipements, comme les machines
  165. physiques, virtuelles, mais aussi les routeurs et autre materiel réseau.
  166. \par
  167. Il se découpe généralement en trois partie:
  168. \begin{description}
  169. \item[Le moteur] qui sert de point central, traite la base de donnée, et synchronise le tout.
  170. \item[L'interface web] qui permet de visualiser l'état des système, et d'avoir une vue sur l'ensemble. Il y en a
  171. plusieurs de disponible.
  172. \item[Les plugins] qui sont les petits programmes servant à récupérer les informations de supervision pour les
  173. faire remonter au moteur. Il y en a une centaine officiels, mais on peut très facilement développer les siens
  174. pour superviser quelque chose de particulier.
  175. \end{description}
  176. C'est le logiciel qui a été retenu par \textbf{Faurecia} pour superviser l'ensemble de ses
  177. systèmes à l'échelle mondiale.
  178. \section{Cadre de travail}
  179. \subsection{Un grand open space}
  180. \par
  181. L'open space dans lequel j'ai été installé était relativement grand. En effet il ne comptait pas moins d'une trentaine de
  182. personne. Il était cependant assez calme, malgré les nombreuses discussions téléphoniques qui pouvaient durer plusieurs
  183. heures. Mon bureau était assez grand, et mon siège plutôt confortable, ce qui fait que je n'ai pas eu à souffrir d'une
  184. mauvaise installation, ou d'un mauvais cadre de travail.
  185. \subsection{Du matériel adapté}
  186. J'ai été équipé d'un laptop de prêt au début, installé avec \emph{Windows Seven}, afin de pouvoir dès le début
  187. accéder à ma messagerie fonctionnant avec \emph{Outlook} exclusivement. J'ai gardé ce laptop jusqu'à la fin de mon stage
  188. uniquement pour la messagerie.\\
  189. En revanche, j'ai rapidement demandé à être équipé d'un système \emph{Linux}, et j'ai donc dès le deuxième jour récupéré
  190. la tour d'un ancien stagiaire sur laquelle j'ai pu installer Ubuntu 14.04 avec Awesome WM. Deux mois plus tard, j'ai pu
  191. troquer cette tour contre un laptop beaucoup plus récent, celui d'un salarié qui quittait Faurecia, sur lequel j'ai pu
  192. remettre ce même système.
  193. \par
  194. En bref, j'ai pu travailler avec un environnement et une suite logiciel que j'ai pu choisir à 100\%, totalement libre et
  195. open-source, en ayant juste la contrainte d'un second laptop sous \emph{Windows} pour la messagerie.
  196. \chapter{Travail réalisé}
  197. \section{Les sujets de travail}
  198. \begin{center}
  199. "Assistant gestion de projet FCS (SAP Application)"
  200. \end{center}
  201. \par
  202. Tel était le sujet marqué dans la fiche réponse, et pour lequel une convention a été signée. C'est en réalité assez
  203. vague, mais cela représente tout de même assez bien la réalité, puisque l'ensemble des tâches qui m'ont été attribuées
  204. tournaient autour de ce fameux outil, SAP, hormis les trois premières semaines.
  205. \subsection{Les débuts}
  206. \par
  207. Lorsque je suis arrivé dans l'entreprise, ma tutrice était alors en congés. C'est donc M. Gueutal qui m'a accueilli et
  208. qui m'a présenté aux équipes, fait visité les locaux, décrit le fonctionnement des différents services, en bref, qui m'a
  209. familiarisé avec mon environnement. Mme Mathieu n'étant pas de retour avant trois semaines, j'ai été provisoirement
  210. intégré à l'équipe de Jean-Noël, le PLM, afin de réaliser diverses tâches sans grand rapport les unes avec les autres,
  211. mais qui toutes allégaient un peu le travail de l'équipe.
  212. \par
  213. Il m'a principalement été demandé d'automatiser une procédure de génération de "Monthly report", c'est à dire aller
  214. collecter des données diverses pour en faire des statistiques et des graphiques utilisables, le tout très rapidement.
  215. C'est un travail qui est réalisé une fois par mois, et qui permet de présenter au management un résumé chiffré des
  216. actions des 30 derniers jours. Ce travail est fastidieux, car on a besoin de se connecter à de nombreuses pages Web, et
  217. d'en extraire des données sous la forme en général de tableaux Excel. La contrainte était de ne pas avoir aux bases de
  218. données de façon direct, et l'on devait alors simuler les actions de l'utilisateur dans le naviguateur, ce que j'ai
  219. réalisé à l'aide de la bibliothèque Selenium, et de son module pour Python.
  220. \par
  221. Ce projet a marché pendant une petite période, de l'ordre de quelques semaines, mais par la suite, une mise à jour des
  222. pages Web a cassé toute la démarche du script et l'idée fût abandonnée. De plus, avec le départ de Jean-Noël pour un
  223. autre service, et le retour de Murielle, j'ai été affecté à d'autres missions.
  224. \par
  225. Par ailleurs, les autres tâches que j'ai eu à faire ont été plus courtes, mais néanmoins pas inintéressantes.
  226. \par
  227. J'ai eu à personnaliser la page d'accueil de l'instant de Etherpad, un outil libre d'édition de texte collaboratif dont
  228. une instance venait d'être déployée.
  229. \par
  230. J'ai également réalisé deux petits scripts Python à l'aide de Fabric, une bibliothèque elle aussi libre servant à lancer
  231. facilement des commandes shells depuis Python, que ce soit sur la machine locale, ou bien à distance à l'aide d'SSH. Ces
  232. scripts servaient à automatiser la création de machines virtuelles dans VirtualBox et de les convertir en environnement
  233. Vagrant, afin de pouvoir rapidement réaliser des fichiers d'environnement virtuels à jour.
  234. \subsection{Première mission à long terme}
  235. \par
  236. Lorsque Murielle m'a pris en charge, j'ai commencé à travailler sur ma première mission à long terme. Il s'agissait de
  237. servir de point centrale entre trois équipe.
  238. Premièrement, celle qui gérait le projet FCS Business Continuity, c'est à dire Murielle elle même, entre autres.
  239. Venaient ensuite les équipes systèmes qui gèraient les machines ciblées par le projet FCS.
  240. Enfin, il y avait les équipes monitoring, basées en Chine, mais dont le responsable était mon voisin de bureau, et dont
  241. le rôle était de gérer la configuration de l'outil Nagios afin d'assurer le monitoring de ce que le système mettait en
  242. place.
  243. \par
  244. Mon rôle là dedans était d'observer ce que Nagios monitorait réellement, de me renseigner sur ce qu'il y avait à
  245. monitorer et qui ne l'était pas, et de faire réagir les bonnes personnes en conséquence. En général, le schéma était
  246. toujours le même. Je constatais que quelque chose n'était pas monitoré, ou était mal monitoré. Je contactais donc la
  247. personne du système en charge de cette machine afin soit qu'elle me transmettre les informations manquantes, et je
  248. créais ensuite un ticket pour les équipes chinoises, soit qu'elle fasse elle-même le ticket dans le cas où il y aurait
  249. des informations trop complexes pour être relayées correctement.
  250. \par
  251. Cette première mission me familiarisa beaucoup avec ce qu'était SAP, et l'environnement gigantesque qui en découlait. Je
  252. découvrais aussi les différents problèmes qui faisaient perdre beaucoup de temps, notamment le manque cruel d'un
  253. inventaire des machines, commun aux différentes équipes. C'est ce qui m'a mené par la suite à faire évoluer un peu le
  254. sujet de mon stage.
  255. \subsection{Seconde mission à long terme}
  256. \par
  257. Lorsque j'ai eu passé un certain temps dans l'interface de Nagios, à traquer les défauts, les manques, et les surplus
  258. d'informations, j'ai commencé à chercher comment je pourrais automatiser tout cela. Je me suis déjà renseigné à propos
  259. d'une interface qui me permettrait de faire des requêtes dans la base de donnée du monitoring, et on m'a dirigé vers
  260. Livestatus, un module pour Nagios qui fourni une API semblable à du SQL, et que je pouvais requêter comme je le
  261. souhaitais.
  262. \par
  263. J'ai donc commencé par un petit script s'utilisant en ligne de commande qui me servait à classer les machines trouvées
  264. sur Nagios, en les triant par environnements SAP. Cela fonctionnait bien, mais j'étais le seul à savoir m'en servir, et
  265. je constatais que certaines questions que l'on me posait avaient leur réponse facilement à travers ce petit script.
  266. \par
  267. Il a donc fallu réfléchir à un moyen de rendre ma petite base de donnée accessible facilement, tant à des personnes
  268. techniques, que parfois à des gens dont le corp de métier n'est pas l'informatique. Quoi de mieux qu'une interface Web
  269. pour arriver à cela!
  270. \par
  271. Ma seconde mission a donc été de développer cette interface et de la rendre la plus ergonomique possible. J'ai même peu
  272. à peu abandonné la ligne de commande, puisqu'elle ne suivait plus les dernières fonctionnalités. Début Janvier, il m'a
  273. même été demandé d'installer cette interface sur un serveur dédié afin de continuer à la faire fonctionner après mon
  274. départ, ce qui fût plutôt gratifiant.
  275. \section{Rôles et objectifs des travaux}
  276. \subsection{Concernant le monitoring}
  277. \par
  278. Pour cette tâche, les objectifs étaient simples, mais c'est la tâche elle-même qui était délicate, pas sur le plan
  279. technique, mais plus au niveau des responsabilités. Le but était de s'assurer que pendant les phases de déplacement des
  280. environnement SAP, le monitoring soit toujours correctement assuré.
  281. Il y avait plusieurs cas quand je suis arrivé:
  282. \begin{itemize}
  283. \item Des environnements déjà déplacés, et il fallait alors s'assurer que Nagios avait suivit le mouvement et
  284. monitorait donc les nouvelles machines tout en ayant supprimé les anciennes.
  285. \item Des environnements en cours de déplacement, qu'il fallait donc monitorer deux fois: la vieille instance, et la
  286. nouvelle, sans qu'il y ait de conflits, sur les noms de machines par exemple.
  287. \item Des environnements qui ne seraient pas déplacés, les plus facile, puisque normalement, le monitoring était
  288. déjà en place. J'ai cependant eu parfois quelques correctifs à faire.
  289. \end{itemize}
  290. \par
  291. La difficulté résidait donc dans le fait de ne pas se tromper lorsque l'on faisait une requête. Il fallait d'une part
  292. s'assurer que la requête avait bien lieu d'être, puis la créer en faisant attention à bien mettre l'ensemble des
  293. informations nécéssaires. En cas d'erreur, cela pouvait mener au mieux à une requête inutile, au pire à un service
  294. complet qui se serait retrouvé sans monitoring. Cela n'est heureusement jamais arrivé, mais la criticité des requêtes
  295. m'a forcé à beaucoup de communication avec les personnes concernées afin d'être sûr de toujours avoir les bonnes
  296. informations.
  297. \subsection{Objectif de l'outil d'inventaire}
  298. \par
  299. J'ai pu remarqué que lorsque je cherchais à me documenter sur les environnement SAP, il était très difficile, voire
  300. impossible d'obtenir une liste précise des machines. L'inexistence à travers plusieurs équipe d'un inventaire commun
  301. rendait la tâche particulièrement difficile, puisqu'il fallait toujours aller chercher les informations là où elles se
  302. trouvaient, et pas toujours là où l'on s'y attend.
  303. \par
  304. On m'avait demandé, lorsque l'on m'a chargé de vérifier le monitoring, de construire en même temps un diaporama
  305. Powerpoint présentant chaque environnement, et contenant toutes les machines dans chacun d'eux, avec un certain nombre
  306. d'information. Mais le problème que j'ai constaté d'un tel document, est que d'une part, il n'est pas dynamique, et donc
  307. qu'il devra être maintenu à la main, et d'autre part, qu'il n'est pas centralisé, ce qui engendrera rapidement des
  308. différences de version chez chacune des personnes possédant le document.
  309. \par
  310. L'objectif de faire l'inventaire était donc clair: il fallait que je concoive un outil très simple à utiliser, construit
  311. sur une base de donnée dynamique se mettant à jour automatiquement, qui soit centralisé, et qui permettrait aux
  312. différentes équipes SAP d'accéder à tout moment et rapidement à la plupart des informations de base concernant les
  313. environnements.
  314. \section{Déroulement}
  315. \subsection{Vérifier le monitoring}
  316. \subsubsection{Bien utiliser Nagios} % Attention au rangement dans les bonnes sous-parties
  317. \par
  318. En réalité, ce n'est pas directement Nagios que nous utilisions, mais simplement une de ses nombreuses interface Web .
  319. Cette interface facilite grandement la surveillance en fournissant principalement un moteur de recherche très puissant
  320. permettant de trouver rapidement n'importe quelle machine, voire même des groupes de machines, pour ensuite accéder à
  321. des informations très détaillées sur les services de monitoring appliqués à cette ou ces machine(s).
  322. \par
  323. Je devais donc suivre le \emph{paysage}, ou \emph{landscape}, et chercher environnement par environnement la liste des
  324. machines, en contactant à chaque fois les personnes responsable du dit environnement pour vérifier que l'ensemble
  325. existait bel et bien dans Nagios.
  326. \par
  327. Lorsqu'une anomalie était détectée, elle pouvait être de plusieures sorte, avec différents niveaux de criticité:
  328. \begin{description}
  329. \item[Critique] \hfill \\
  330. Lorsqu'une machine est sensé exister, mais est introuvable. Cela la rend totalement
  331. invisible aux yeux du monitoring, et on ne peut absoluement pas savoir quand cette machine a un problème,
  332. excepté en allant voir manuellement.
  333. \item[Critique] \hfill \\
  334. La machine est trouvable, mais elle s'affiche en rouge, et le ping échoue. Cela signifie
  335. généralement que la machine a subit un déplacement mais que le monitoring n'a pas été mis à jour. Il faut donc
  336. rapidement l'équipe systèmes pour trouver qui contrôle la machine et lui demander de transmettre les
  337. informations de base la concernant, comme son nom et son adresse IP, afin de régulariser au plus vite.
  338. \item[Peu critique] \hfill \\
  339. On voit la machine en vert, et celle-ci répond au ping, mais un grand nombre de ses
  340. services sont rouges. Cela signifie qu'elle a subit un important changement d'architecture pendant le
  341. déplacement, et que les services à monitorer ont changé. Il faut donc contacter l'équipe applicative afin de
  342. savoir ce qu'il font tourner dessus, et donc demander à l'équipe monitoring de suivre les bons services.
  343. \item[Très peu critique] \hfill \\
  344. La machine est correctement monitorée, mais on s'appercoit qu'elle est rangée
  345. dans le mauvais groupe, ou que les commentaires sur cette machine sont incomplets. Ce n'est pas grave, mais cela
  346. peut être gênant quand on cherche une information précise, car cette dernière peut alors être éronnée. On
  347. cherche alors auprès de toutes les équipes concernées pour trouver qui possède les informations manquantes.
  348. \end{description}
  349. \subsubsection{Redmine, puis MosaiC}
  350. \par
  351. \emph{Redmine} et \emph{MosaiC} sont les bugs-trackers utilisé dans le projet FCS-BC. Redmine était présent au début,
  352. puis le changement vers MosaiC a été opéré en Novembre.
  353. \paragraph{Redmine} est un outil libre de bug tracking et gestion de projet, intégrable facilement avec le gestionnaire
  354. de révision Git, et qui permettait de facilement trier les issues entre les différents projets. De plus, on pouvait
  355. suivre l'évolution des tickets dans le temps, on faisant évoluer la priorité, en ajoutant des informations si besoin, le
  356. tout dans une sorte de dialogue avec l'équipe affectée à la résolution du ticket.
  357. \paragraph{MosaiC} est arrivé début Novembre pour remplacer Redmine. Il remplissait moins bien son rôle de bug tracker
  358. puisque c'est un outil de gestion du changement, mais avait une plus grande base de connaissance sur les projets, on
  359. triant jusqu'au niveau de l'environnement dans le projet FCS. Je m'en suis finalement peu servi. En effet, c'est à cette
  360. période que j'ai commencé à développer \emph{Sappin}.
  361. \par
  362. C'est au travers de ces deux outils que j'ai fait remonté les demandes de modifications de Nagios pour assurer un
  363. monitoring optimal pendant les phases de \emph{move}.
  364. \subsubsection{La communication: mail et IM}
  365. \par
  366. La communication était une partie très importante de mon travail. En effect il me fallait en permanence contacter les
  367. différents responsables de tel ou tel service afin d'obtenir les informations là où elles se trouvaient. Par conséquent,
  368. plusieurs moyen de communication ont été mis à ma disposition dès le premier jour de mon stage.
  369. \par
  370. \emph{Microsoft Outlook} était mon client de mail principal, car le système d'utilisateur de \textbf{Faurecia} étant
  371. \emph{Active Directory}, il était très facile de disposer d'une messagerie dans cet outil. De plus, un certain nombre de
  372. plug-in y étaient installé, afin de pouvoir également gérer les conférences téléphoniques, ainsi que les rendez-vous, en
  373. synchronisation avec la liste des salles et le gestionnaire d'emploi du temps de chacun. L'annuaire interne de
  374. \textbf{Faurecia} y était évidemment présent également.
  375. \par
  376. L'autre moyen de communication utilisé était la messagerie instantanée. Le client officiel de Faurecia était
  377. \emph{Spark}, mais étant donnée que tout passait par un serveur \emph{XMPP}, et qu'il s'agit d'un protocol ouvert,
  378. n'importe quel client pouvait faire l'affaire, et j'ai donc utilisé \emph{Gajim}, ce dernier étant plus léger.
  379. \par
  380. Ce type de messagerie avait l'avantage d'être moins formel et beaucoup plus efficace pour poser une simple question à
  381. des personnes que je contactais régulièrement. Elle remplacait presque une discussion orale, avec même l'avantage de
  382. pouvoir transmettre des liens très facilement pour pointer un problème en particulier rapidement, tout en ayant chaque
  383. interlocuteur présent sur sa machine de travail, et ayant dont accès rapidement à ses informations numériques.
  384. % Parler des alertes: demander au bon gugus de vérifier les services présents sur les machines pour le system ou la team
  385. % SAP fasse le ticket en demandant de monitorer les bons services, ce que les chinois règlaient par la suite.
  386. \subsection{Développer un inventaire}
  387. \chapter*{Conclusion}
  388. \addcontentsline{toc}{chapter}{Conclusion}
  389. \chapter*{Bibliographie}
  390. \addcontentsline{toc}{chapter}{Bibliographie}
  391. \url{http://mathias-kettner.de/checkmk_livestatus.html}
  392. \url{https://docs.python.org/3/}
  393. \url{http://docs.sqlalchemy.org/en/rel_1_0/}
  394. \url{http://flask.pocoo.org/}
  395. \url{http://jinja.pocoo.org/}
  396. \chapter*{Annexes}
  397. \addcontentsline{toc}{chapter}{Annexes}
  398. \end{document}