Integration de morceaux du DevOps Handbook

chapters/architecture.tex

@@ -794,7 +794,7 @@ Dans le cadre de l'utilisation de Django, c'est un point critique à prendre en
     \item
         Les droits d'accès et permissions seront en grosse partie gérés par le frameworks
     \item
-La sécurité dépendra de votre habilité à suivre les versions
+		La sécurité dépendra de votre habilité à suivre les versions
     \item
         Et les fonctionnalités complémentaires (que vous n'aurez pas voulu/eu le temps de développer) dépendront de la bonne volonté de la communauté
 \end{itemize}
@@ -803,15 +803,8 @@ Le point à comprendre ici n'est pas que "Django, c'est mal", mais qu'une fois q
 Cette décision ne sera pas irrévocable, mais difficile à contourner.
 
 \begin{quote}
-    At some point in their history most DevOps organizations were hobbled by
-    tightly-coupled, monolithic architectures that while extremely
-    successfull at helping them achieve product/market fit - put them at
-    risk of organizational failure once they had to operate at scale (e.g.
-    eBay's monolithic C++ application in 2001, Amazon's monolithic OBIDOS
-    application in 2001, Twitter's monolithic Rails front-end in 2009, and
-    LinkedIn's monolithic Leo application in 2011). In each of these cases,
-    they were able to re-architect their systems and set the stage not only
-    to survice, but also to thrise and win in the marketplace.
+    At some point in their history most DevOps organizations were hobbled by tightly-coupled, monolithic architectures that while extremely successfull at helping them achieve product/market fit - put them at risk of organizational failure once they had to operate at scale (e.g. eBay's monolithic C++ application in 2001, Amazon's monolithic OBIDOS application in 2001, Twitter's monolithic Rails front-end in 2009, and LinkedIn's monolithic Leo application in 2011).
+	In each of these cases, they were able to re-architect their systems and set the stage not only to survice, but also to thrise and win in the marketplace.
 
     \cite[182]{devops_handbook}
 \end{quote}

chapters/forms.tex

@@ -46,7 +46,7 @@ Ils agissent come une glue entre l'utilisateur et la modélisation de vos struct
 \textbar{} .Validation \textbar{} .is\_valid \textbar{} .clean\_fields ↓
 .clean\_fields\_machin
 
-A compléter ;-)
+Tout comme pour le modèle (+ ref), l'idée est simplement de définir plusieurs niveaux de validation.
 
 \section{Dépendance avec le modèle}
 
@@ -81,7 +81,11 @@ Sinon, ils peuvent l'être directement au niveau du champ.
 
 \subsection{Squelette par défaut}
 
-On a d'un côté le \{\{ form.as\_p \}\} ou \{\{ form.as\_table \}\}, mais il y a beaucoup mieux que ça ;-) Voir les templates de Vitor et en passant par \texttt{widget-tweaks}.
+\subsubsection{as\_p}
+
+\subsubsection{as\_table}
+
+\subsubsection{Vitor}
 
 \subsection{Crispy-forms}
 

chapters/infrastructure.tex

@@ -50,8 +50,10 @@ Ce sont les "petites mains" qui aident à ce que l'application soit résiliente
 Il s'agit des composants comme le proxy inverse ou les distributeurs de charge: ce sont des composants qui sont fortement recommandés, mais pas obligatoires à au bon fonctionnement de l'application.
 
 \begin{quote}
-  Hard disks are reported having a mean time to failure (MTTF) of about 1° to 50 years.
-  Thus, on a storage cluster with 10,000 disks, we should expect on average one disk to die per day. \cite[p. 7]{data_design}
+  Focusing on resilience often means that a firm can handle events that may cause crises for most organizations in a manner that is routine and mundane.
+  Specific architectural patterns that they implemented included fail fasts (settings aggressive timeouts such that failing components don't make the entire system crawl to a halt), fallbacks (designing each feature to degrade or fall back to a lower quality representation), and feature removal (removing non-critical features when they run slowly from any given page to prevent them from impacting the member experience).
+  Another astonishing example of the resilience that the netflix team created beyond preserving business continuity during the AWS outage, was that they went over six hours into the AWS outage before declaring a Sev 1 incident, assuming that AWS service would eventually be restored (i.e., "AWS will come back... it usually does, right ?").
+  Only after six hours into the outage did they activate any business continuity procedures. \cite[p. 282]{devops_handbook}
 \end{quote}
 
 Avoir des composants périphériques correctement configurés permet d'anticiper ce type d'erreurs, et donc d'augmenter la résilience de l'application. \index{Résilience}
@@ -132,6 +134,38 @@ Le
 
 \subsubsection{Supervision des processus}
 
+La récupération de métriques augmente la confiance que l'on peut avoir dans la solution.
+L'analyse de ces métriques garantit un juste retour d'informations, sous réserve qu'elles soient exploitées correctement.
+La première étape consiste à agréger ces données dans un dépôt centralisé, tandis que la seconde étape exigera une structuration correcte des données envoyées.
+
+La collecte des données doit récupérer des données des couches métiers, applicatives et d'environnement.
+Ces données couvrent les évènements, les journaux et les métriques - indépendamment de leur source - le pourcentage d'utilisation du processeur, la mémoire utilisée, les disques systèmes, l'utilisation du réseau, ...
+
+\begin{enumerate}
+  \item
+    \textbf{Métier}: Le nombre de ventes réalisées, le nombre de nouveaux utilisateurs, les résultats de tests A/B, \ldots
+  \item
+    \textbf{Application}: Le délai de réalisation d'une transaction, le temps de réponse par utilisateur, \ldots
+  \item
+    \textbf{Infrastructure}: Le trafic du serveur Web, le taux d'occupation du CPU, \ldots
+  \item
+    \textbf{Côté client}: Les erreurs applicatives, les transactions côté utilisateur, \ldots
+  \item
+    \textbf{Pipeline de déploiement}: Statuts des builds, temps de mise à disposition d'une fonctionnalité, fréquence des déploiements, statuts des environnements, \ldots
+\end{enumerate}
+
+Bien utilisés, ces outils permettent de prévenir des incidents de manière empirique.
+
+\begin{quote}
+  Monitoring is so important that our monitoring systems need to be more available and scalable than the systems being monitored.
+
+  -- Adrian Cockcroft \cite[p. 200]{devops_handbook}
+\end{quote}
+
+Histoire de schématiser, toute équipe se retrouve à un moment où un autre dans la situation suivante: personne ne veut appuyer sur le gros bouton rouge issu de l'automatisation de la chaîne de production et qui dit "Déploiement".
+Et pour cause: une fois que nous aurons trouvé une joyeuse victime qui osera braver le danger, il y aura systématiquement des imprévus, des petits détails qui auront été oubliés sur le côté de la route, et qui feront lâchement planter les environnements.
+Et puisque nous n'aurons pas (encore) de télémétrie, le seul moment où nous comprendrons qu'il y a un problème, sera quand un utilisateur viendra se plaindre.
+
 \subsubsection{Journaux}
 
 La présence de journaux, leur structure et de la définition précise de leurs niveaux est essentielle; ce sont eux qui permettent d'obtenir des informations quant au statut de l'application:

chapters/security.tex

@@ -1,5 +1,24 @@
 \chapter{Sécurité}
 
 \begin{quote}
+    We put all security issues into JIRA, which all engineers use in their daily work, and they were either 'P1' or 'P2', meaning that they had to be fixed immediately or by the end of the week, even if the issue is only an internally-facing application.
 
+    Any time we had a security issue, we would conduct a post-mortem, because it would result in better educating our engineers on how to prevent it from happening again in the future, as well as a fantastic mechanism for transferring security knowledge to our engineering team.
+
+    -- Nick Galbreath \cite[p. 315]{devops_handbook}
 \end{quote}
+
+L'objectif final est d'utiliser les mêmes méthodes de travail pour les équipes de développement, pour les équipes d'opérations, et pour la sécurité de l'information, en poussant jusqu'à l'intégration de la télémétrie à chaque niveau de la chaîne de production, mais aussi en prouvant aux développeurs (en début de chaîne) qu'ils sont constamment sous attaque informatique, afin de les sensibiliser.
+
+Il conviendra d'ajouter au dépôt de source: Au niveau du dépôt de sources, il convient d'y ajouter:
+
+\begin{enumerate}
+    \item
+        Les librairies standards, leur utilisation et leur configuration (2FA, \ldots)
+    \item
+        Comment gérer les injections SQL, le cross-site-scripting, \ldots
+    \item
+        Comment gérer les secrets dans les applications: comment gérer les mots de passe, les journaux de logs, \ldots
+    \item
+        Les paquets à utiliser et à compiler (NTP pour synchroniser les horloges, les paramètres d'OpenSSL, \ldots), les configurations d'Nginx/Apache, \ldots
+\end{enumerate}

chapters/tests.tex

@@ -184,6 +184,10 @@ Le plus important est de toujours corréler les phases de tests indépendantes d
     -- Robert C. Martin, Clean Architecture
 \end{quote}
 
+De manière plus générale, si nous nous rendons compte que les tests sont trop compliqués à écrire ou coûtent trop de temps à être mis en place, c'est sans doute que l'architecture de la solution n'est pas adaptée et que les composants sont couplés les uns aux autres.
+Dans ces cas, il sera nécessaire de refactoriser le code, afin que chaque module puisse être testé indépendamment des autres.
+Le plus important est de toujours corréler les phases de tests au reste du travail (de développement, ici), en les automatisant au plus près de leur source de création.
+
 \subsection{Tests unitaires}
 
 \begin{quote}

chapters/working-in-isolation.tex

@@ -286,6 +286,8 @@ Dans la suite, nous détaillerons Vagrant et Docker, qui constituent deux soluti
 
 \subsection{Vagrant}
 
+\includegraphics{images/logo-vagrant.png}
+
 Vagrant consiste en un outil de création et de gestion d'environnements virtualisés, en respectant toujours une même manière de travailler, indépendamment des choix techniques et de l'infrastructure que vous pourriez sélectionner.
 
 \begin{quote}
@@ -302,9 +304,10 @@ La partie la plus importante de la configuration de Vagrant pour votre projet co
     \item
         Le choix du \emph{fournisseur} (\textbf{provider}) de virtualisation (Virtualbox, Hyper-V et Docker sont natifs; il est également possible de passer par VMWare, AWS, etc.)
     \item
-        Une \emph{box}, qui consiste à lui indiquer le type et la version attendue du système virtualisé (Debian 10, Ubuntu 20.04, etc. - et \href{https://app.vagrantup.com/boxes/search}{il y a du choix}).
+        Une \emph{box}, qui indique le type et la version attendue du système virtualisé (Debian 10, Ubuntu 20.04, etc. - et \href{https://app.vagrantup.com/boxes/search}{il y a du choix}).
     \item
-        La manière dont la fourniture (\textbf{provisioning}) de l'environnement doit être réalisée : scripts Shell, fichiers, Ansible, Puppet, Chef, \ldots\hspace{0pt} Choisissez votre favori :-) même s'il est toujours possible de passer par une installation et une maintenance manuelle, après s'être connecté sur la machine.
+        La manière dont la fourniture (\textbf{provisioning}) de l'environnement doit être réalisée : scripts Shell, fichiers, Ansible, Puppet, Chef, \ldots
+        Il est toujours possible de passer par une installation et une maintenance manuelle, après s'être connecté sur la machine.
     \item
         Si un espace de stockage doit être partagé entre la machine virtuelle et l'hôte
     \item
@@ -338,11 +341,9 @@ Vous trouverez ci-dessous un exemple, généré (et nettoyé) après avoir exéc
     \end{minted}
 \end{listing}
 
-Dans le fichier ci-dessus, nous créons:
+Dans le fichier ci-dessus, nous créons une nouvelle machine virtuelle (ie. \emph{invitée}) sous Ubuntu Bionic Beaver, en x64
 
 \begin{itemize}
-    \item
-        Une nouvelle machine virtuelle (ie. \emph{invitée}) sous Ubuntu Bionic Beaver, en x64
     \item
         Avec une correspondance du port \texttt{80} de la machine vers le port \texttt{8080} de l'hôte, en limitant l'accès à celui-ci - accédez à \texttt{localhost:8080} et vous accéderez au port \texttt{80} de la machine virtuelle.
     \item