Save tuto corrections

tutorial/devops/devops.md

@@ -4,13 +4,13 @@ Le mouvement DevOps
 ===================
 
 Jusqu'à récemment, et encore dans de nombreuses entreprises, les développeurs
-et les administrateurs système faisaient partie de deux équipes différentes :
+et les administrateurs système faisaient partie de deux équipes différentes :
 les uns développant sur leurs machines avec les dernières bibliothèques,
 utilisant les derniers frameworks à la mode, sans se préoccuper de la sécurité
-(ils travaillent en `root` ou avec `sudo` ;)), tandis que les autres tentaient
+(ils travaillent en `root` ou avec `sudo` ;)), tandis que les autres tentaient
 tant bien que mal de déployer ces services avec les contraintes opérationnelles
 en tête.\
-Ces contraintes : tant liées à la **sécurité** (il faut s'assurer
+Ces contraintes : tant liées à la **sécurité** (il faut s'assurer
 qu'un service n'utilise pas une bibliothèque vulnérable par exemple, donc soit
 utilisé sur un système à jour, et qu'il ne tourne pas en `root`), qu'à la
 **disponibilité** (si le service est mal codé est contient beaucoup de fuites
@@ -19,13 +19,13 @@ pâtissent).
 
 Une guerre faisait donc rage entre les développeurs qui ne comprenaient pas que
 les administrateurs système ne pouvaient pas maintenir autant de versions d'une
-bibliothèque qu'il y avait de services : par exemple dans le cas de plusieurs
+bibliothèque qu'il y avait de services : par exemple dans le cas de plusieurs
 services en PHP, on pouvait leur demander de déployer des applications
 utilisant la version 5.6, et la 7.2 pour d'autres, ... lorsqu'il y avait des
 incompatibilités mineures et plus personne pour s'occuper de la maintenance
 d'un vieux service toujours utilisé.
 
-Le même principe est aussi valable pour Python, Ruby, ... : les développeurs
+Le même principe est aussi valable pour Python, Ruby, ... : les développeurs
 ont toujours eu tendance à vouloir utiliser les dernières améliorations d'un
 langage, mais les administrateurs système n'ont alors pas de paquets stables
 dans la distribution. En effet, les distributions stables telles que Debian,
@@ -64,10 +64,10 @@ charges, les pannes, ...
 
 ::::: {.warning}
 Attention par contre aux entreprises qui recrutent un profil DevOps, car cela a
-autant de sens que recruter un développeur Scrum ou un développeur cycle en V :
+autant de sens que recruter un développeur Scrum ou un développeur cycle en V :
 DevOps est une méthodologie. Les entreprises qui recrutent un DevOps
 recherchent généralement quelqu'un qui fera à la fois du développement logiciel
-d'un côté et de l'administration système de l'autre : une situation
+d'un côté et de l'administration système de l'autre : une situation
 généralement assez difficile à vivre. Alors qu'au contraire, la mouvance DevOps
 doit être prise au sérieux par l'ensemble des développeurs. Lors d'un entretien
 d'embauche pour ce genre de poste, assurez-vous bien de ne pas être le seul à
@@ -77,14 +77,14 @@ faire du DevOps.
 
 ## Intégration continue
 
-L'**intégration continue** est la première brique à mettre en place : le but
+L'**intégration continue** est la première brique à mettre en place : le but
 est de compiler automatiquement chaque commit dans un environnement proche de
 celui de production, puis de lancer les suites de tests du logiciel.
 
 Cela permet de détecter les problèmes au plus tôt dans le cycle de
 développement, mais cela permet également d'améliorer la qualité du code sur le
 long terme, car on peut y ajouter facilement des outils qui vont se charger
-automatiquement de réaliser des analyses : cela peut aller de la couverture des
+automatiquement de réaliser des analyses : cela peut aller de la couverture des
 tests, à de l'analyse statique ou dynamique de binaire, en passant par la
 recherche de vulnérabilités ou de mauvaises pratiques de programmation.
 
@@ -101,7 +101,7 @@ les développeurs considéreront avoir atteint un jalon, une version stable.
 ## Déploiement continu
 
 Une fois tous les tests passés et les objets produits (on parle d'*artifact* ou
-d'*assets*), il est possible de déclencher un déploiement : il s'agit de rendre
+d'*assets*), il est possible de déclencher un déploiement : il s'agit de rendre
 accessible aux utilisateurs finaux le service ou les objets.
 
 Dans le cas d'un programme à télécharger
@@ -113,15 +113,15 @@ vers la dernière version (pour que les utilisateurs aient la notifications).
 Ou bien dans le cas d'un service en ligne (GitHub, Netflix, GMail, ...), il
 s'agira de mettre à jour le service.
 
-Parfois les deux seront à faire : à la fois publier un paquet ou un
-conteneur et mettre à jour un service en ligne : par exemple, [le
+Parfois les deux seront à faire : à la fois publier un paquet ou un
+conteneur et mettre à jour un service en ligne : par exemple, [le
 serveur Synapse](https://buildkite.com/matrix-dot-org/synapse) du
 protocole de messagerie Matrix ou encore
 [Gitlab](https://gitlab.com/gitlab-org/gitlab/-/pipelines), tous deux
 publient des paquets à destination de leurs communautés, et mettent à
 jour leur service en ligne.\
 
-Il existe pour cela de très nombreuses stratégies : lorsque l'on n'a pas
+Il existe pour cela de très nombreuses stratégies : lorsque l'on n'a pas
 beaucoup de trafic ni beaucoup de machines, on peut simplement éteindre
 l'ancien service et démarrer le nouveau, si ça prend quelques millisecondes en
 étant automatisé, cela peut être suffisant compte tenu du faible
@@ -133,11 +133,11 @@ de tout rallumer. Déjà parce que trop de visiteurs vont se retrouver avec des
 pages d'erreur, et aussi parce qu'en cas de bug logiciel qui n'aurait pas été
 vu malgré les étapes précédentes, cela pourrait créer une situation
 catastrophique (imaginez qu'on ne puisse plus valider une commande sur Amazon à
-cause d'une ligne commentée par erreur !).\
+cause d'une ligne commentée par erreur !).\
 On va donc privilégier un déploiement progressif de la nouvelle version (que
 l'on va étendre sur plusieurs minutes, heures ou mêmes jours), en éteignant
 tour à tour les instances, et en veillant à ce que les métriques (voir la
-section suivante !) soient constantes.
+section suivante !) soient constantes.
 
 
 ## Monitoring et supervision
@@ -145,16 +145,16 @@ section suivante !) soient constantes.
 Une fois déployé, le service peut avoir des ratés, alors il convient de le
 surveiller afin d'être le plus proactif possible dans la résolution des
 problèmes. La pire situation est celle dans laquelle c'est un utilisateur qui
-nous informe d'un problème... (sur Twitter !?)
+nous informe d'un problème... (sur Twitter !?)
 
 Nous avons réalisé précédemment une partie collecte de métriques, avec nos
 conteneurs TICK. Nous n'allons donc pas nous en occuper aujourd'hui.
 \
 
 Notez tout de même qu'il y a deux grandes catégories de logiciels de
-supervision :
+supervision :
 
-**Basée sur des états** comme Nagios, Zabbix, ... : ces logiciels vont
+**Basée sur des états** comme Nagios, Zabbix, ... : ces logiciels vont
 simplement réaliser des séries de tests définis, à intervalles réguliers et
 contacter l'administrateur d'astreinte dès qu'un test ne passe plus de manière
 persistante.
@@ -163,8 +163,8 @@ Il y a rarement beaucoup d'intelligence ou d'anticipation automatique dans ces
 outils.
 \
 
-**Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la
-stack TICK que nous avons mis en place au précédent TP, nous avions placé un
+**Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la
+stack TICK que nous avons mis en place précédemment, nous avions placé un
 agent sur la machine que nous souhaitions analyser. Outre les graphiques
 présenté dans Chronograf, le dernier outil que l'on n'avait pas configuré était
 Kapacitor, qui permet après avoir analysé les données, d'alerter en fonction
@@ -196,4 +196,4 @@ des pannes, des latences, ... à n'importe quel niveau du produit, afin d'en
 tester (brulatement certes) sa résilience. Cela oblige les développeurs, les
 opérationnels et les architectes à concevoir des services hautement tolérant
 aux pannes, ce qui fait que le jour où une véritable panne survient, elle n'a
-aucun impact sur la production (enfin on espère !).
+aucun impact sur la production (enfin on espère !).