Transforme les données du monitoring en notifications qui réveillent l'astreinte -> réduit le MTTD (temps de détection). Le piège : trop d'alertes non critiques -> l'alert fatigue, où on finit par ignorer même les graves.

Automatisation IT open source, agentless (pas d'agent à installer, tout passe par SSH) -> tu décris l'état voulu dans un Playbook YAML, Ansible applique les tâches (modules), idempotentes par design.

Application Programming Interface: (quoi?) un moyen de communication entre deux logiciels.
REST: (comment?) style d'architecture qui manipule des ressources via HTTP, plutôt qu'un protocole à part entière.
On manipule les ressources via des URLs et des verbes HTTP standards (GET, POST, PUT,DELETE) => CRUD.
Une API REST est stateless: chaque requête est indépendante et porte tout le contexte nécessaire à son traitement, sans session conservée côté serveur.

Remplacer une tâche manuelle répétitive par un script/outil -> moins d'erreurs humaines, plus rapide, et rejouable à l'identique (idempotence) -> c'est ce qui fait que tu passes du ClickOps au DevOps, en passant par l'IaC.

Le TDD mais en langage humain -> on décrit le comportement attendu en scénarios Given/When/Then pour que dev, testeur et métier lisent la même chose.

Deux environnements identiques ("bleu" et "vert") -> l'un sert le trafic en prod, l'autre reçoit la nouvelle version. Une fois validée, le load balancer bascule tout le trafic d'un coup. Rollback instantané en cas de pépin.

Les cinq piliers de la culture DevOps :

• C -> Culture : casser les silos entre dev et ops.
• A -> Automation : automatiser les tâches manuelles répétitives.
• L -> Lean : optimiser les flux, réduire le gaspillage.
• M -> Measurement : mesurer pour piloter (cf. métriques DORA).
• S -> Sharing : partager la connaissance et la responsabilité.

Fonctionnalité du noyau Linux qui limite, priorise et mesure la consommation de ressources (CPU, RAM, I/O) d'un groupe de processus. Avec les namespaces, c'est un des deux piliers noyau qui rendent possibles Docker, LXC et Kubernetes -> sans cgroups, un conteneur qui fuit en mémoire pourrait faire planter toute la machine hôte.

Intégrer, tester et déployer le code automatiquement à chaque changement -> le CD a deux niveaux : Delivery s'arrête juste avant la prod (prêt, mais un humain clique), Deployment va jusqu'au bout sans intervention.

Tu sais, quand tu utilises ta souris pour faire une VM ou un nouveau conteneur LXC, et que tu te perds dans les onglets Proxmox...

De l'infra (calcul, stockage, réseau) à la demande (sur internet), facturée à l'usage -> on loue de la capacité chez AWS/GCP/Azure & co.

Pas juste déplacer une appli existante sur le cloud (lift & shift) -> la concevoir dès le départ pour exploiter le cloud à fond : microservices, conteneurs, orchestrée (Kubernetes), pilotée en IaC/CI-CD, élastique et résiliente par design.

Empaqueter une appli et son environnement d'exécution dans un conteneur qui partage le noyau de l'hôte. Deux familles : conteneurs applicatifs (Docker) et conteneurs système (LXC). Cf. article virtualisation

Un programme qui tourne en arrière-plan en permanence, sans interaction utilisateur, à l'écoute d'événements -> nginx, PHP-FPM ou le dockerd de Docker en sont des exemples : tant qu'ils tournent, ils répondent aux requêtes qui arrivent.

Au niveau conceptuel, on place le domaine métier et sa modélisation au coeur du développement. On utilise un même vocabulaire (Ubiquitous Language) et un contexte délimité (Bounded Context).

Implémenter le code, mais pas que ! Les trois piliers du DEV : analyse, conception et réalisation ( o/ hey, c'est mon job !).

Culture et un ensemble de pratiques visant à unifier le développement logiciel (Dev) et les opérations informatiques (Ops) afin de raccourcir le cycle de vie du développement et de livrer des logiciels en continu.

Le DevOps + la sécurité comme responsabilité partagée, pas une étape finale isolée. Son principe clé : le Shift-Left.

Résultat d'une fonction de hachage (SHA-256 le plus courant) appliquée à un fichier ou une image -> une empreinte de taille fixe, qui change du tout au tout si la source change ne serait-ce que d'un octet. Sert à vérifier l'intégrité d'un téléchargement, ou à épingler une image de façon immuable (image@sha256:abcd...).

On met tout dans un conteneur : l'application et ses dépendances. Pas d'OS, moins isolé mais rapide à démarrer.

Le registre cloud public par défaut où stocker et partager des images de conteneurs Docker.

• Images officielles -> vérifiées/maintenues pour les OS, langages et bases de données les plus courants.
• Tags -> versionnent une image (:1.4, :latest...) ; :latest est mutable (peut changer sans prévenir) -> pas de :latest en prod, un tag figé ou un digest SHA à la place.
• Digest -> empreinte SHA256 du contenu exact de l'image (image@sha256:abcd...), immuable -> garantit de déployer exactement le même binaire, même si un tag est réattribué à une autre image sur le registre entre-temps.

L'orchestrateur de conteneurs natif de Docker -> regroupe plusieurs hôtes en un cluster (le "Swarm") pour déployer, gérer et mettre à l'échelle des applications conteneurisées. Le cluster repose sur des Managers (pilotent le cluster, planifient les tâches) et des Workers (exécutent les conteneurs).

Fichier texte qui décrit, instruction par instruction, comment construire une image de conteneur -> la "recette" de l'image, reproductible à chaque build.

• FROM -> image de base sur laquelle construire (ex: alpine, ubuntu).
• RUN -> exécute une commande pendant le build (installer un paquet, compiler...).
• COPY / ADD -> copie des fichiers de l'hôte vers l'image.
• WORKDIR -> fixe le répertoire de travail pour les instructions suivantes.
• ENV -> définit des variables d'environnement dans le conteneur.
• EXPOSE -> documente le port sur lequel le conteneur écoutera.
• CMD / ENTRYPOINT -> commande exécutée par défaut au lancement du conteneur.

Et donc je n'aime pas me répéter !

Le département qui pilote toute l'infrastructure, les réseaux et les services logiciels d'une entreprise.

Un DTO (Data Transfer Object) est un objet dont le seul rôle est de porter des données entre deux couches.

Processus qui consiste à mettre une nouvelle version d'une application (cela peut être aussi un service ou une config.) dans un environnement donné (dev, prod, ...). Et cela de manière automatisée via un pipeline CI/CD.

On grab la donnée, on l'arrange à notre sauce et on stocke.

Au sens technique du terme, c'est un logiciel qui traduit chaque instruction du système invité pour que l'hôte la comprenne -> permet de simuler une archi différente (ARM sur x86), mais beaucoup plus lent que la virtualisation, qui elle exploite directement le matériel réel. Cf. article virtualisation

Basculer automatiquement vers un système de secours quand le principal tombe, pour garder le service dispo. Trois niveaux : cold (démarrage manuel, lent), warm (standby, rapide), hot (actif en temps réel, quasi instantané).

Une boîte à outils. La boîte (structure) dispose d'outils à disposition, où je peux ajouter des outils externes ou fabriquer mes propres outils.

Les 4 métriques à surveiller en priorité (SRE) pour juger la santé d'un service du point de vue utilisateur :

• Latence -> temps de traitement d'une requête (mesuré en p95/p99 pour capter les cas lents, pas juste la moyenne).
• Trafic -> la demande exercée sur le système (ex: requêtes/seconde).
• Erreurs -> le taux de requêtes qui échouent (codes 5xx, mauvais contenu, etc.).
• Saturation -> à quel point les ressources contraintes (CPU, RAM, I/O) sont pleines.

Le logiciel qui crée et pilote les VMs sur un serveur physique, en répartissant CPU/RAM/stockage entre elles. Deux familles : bare-metal (type 1) - installé direct sur le matériel, ex. KVM, ESXi, Hyper-V, Proxmox VE - et hosted (type 2) - tourne sur un OS existant, ex. VirtualBox/VMware. Cf. article virtualisation

Gérer et provisionner son infra (serveurs, réseaux, config) via des fichiers versionnés (Terraform, Ansible...) plutôt qu'à la main. \o bye bye le ClickOps.

Une opération produit le même résultat qu'on l'applique une fois ou plusieurs fois -> en IaC/Ansible/Terraform, relancer la même tâche ne change rien si l'état voulu est déjà atteint.

La brique purement technique (matériel, réseaux, logiciels) du SI. <= Alors les Teckos, ça ping?

Framework de bonnes pratiques pour gérer les services IT : incidents, changements, SLA.

Keep It Simple, Stupid. Je dois vraiment expliquer ça ?!

Une mesure choisie pour vérifier si un objectif précis est atteint -> pas juste une métrique brute (CPU, RAM...), mais un chiffre qui a du sens stratégique.

L'orchestrateur de conteneurs de référence pour le cloud native -> tu déclares l'état voulu (nombre de Pods, ressources), le Control Plane (API Server, etcd, Scheduler) le fait respecter sur les Worker Nodes : scaling, rolling updates, self-healing.

Méthodologie (héritée du Toyota Production System) qui vise à créer de la valeur en éliminant le gaspillage, via des pratiques comme le Kaizen (kai = changement, zen = bon/meilleur) -> chez DevOps, c'est le pilier derrière le VSM.

LXC est une technologie de conteneurisation open source pour Linux qui permet d'isoler des processus ou des systèmes d'exploitation complets sur un même hôte. LXC utilise des fonctionnalités du noyau Linux (comme les namespaces et les cgroups) pour créer des environnements. Moins isolé que les VM mais plus léger et performant d'un point de vue ressource.

Les magic bytes sont les premiers octets situés au tout début d'un fichier (dans l'en-tête) qui servent d'identifiant unique pour déterminer son format réel. Ils permettent à un programme de reconnaître la nature du fichier (image, exécutable, archive, etc.) plus fiable que l'extension (comme .pdf ou .exe) ou le Content-Type.

Collecter et visualiser en continu des métriques/logs/traces pour surveiller la santé d'un système -> les voyants sont au vert ? En sécu, la difficulté est de repérer l'anormal dans le normal.

Temps moyen entre le début réel d'un incident et sa détection. C'est la première brique du MTTR : plus il est bas, plus vite l'équipe peut réagir.

Temps moyen entre la détection d'un incident et l'identification de sa cause racine -> la phase de diagnostic.

Temps moyen pour rétablir un service après une panne. Plus il est bas, plus l'organisation est résiliente face aux incidents.

4 indicateurs pour mesurer la maturité DevOps d'une équipe -> vélocité (les 2 premiers) sans sacrifier la stabilité (les 2 derniers) :

• Deployment Frequency -> à quelle fréquence on déploie en prod.
• Lead Time for Changes -> temps entre un commit et sa mise en prod.
• Change Failure Rate -> % de déploiements qui causent un incident/rollback.
• Time to Restore Service -> temps moyen pour rétablir le service après un incident.

Mécanisme d'isolation logique qui partitionne des ressources pour créer des environnements séparés sur une même infrastructure. Recouvre deux usages courants en DevOps :

• Noyau Linux -> avec les cgroups, un des deux piliers qui rendent possible la conteneurisation (Docker, LXC) ; isole ce qu'un processus peut voir (fichiers, PID, réseau, utilisateurs).
• Kubernetes -> découpe un cluster en périmètres logiques (par équipe, par environnement) ; sert de portée aux RBAC, ResourceQuotas et NetworkPolicies.

Capacité à comprendre l'état interne d'un système complexe en observant uniquement ses signaux externes, pour investiguer des questions inattendues sur son fonctionnement.
Repose sur les three pillars of observability - IBM :

• Métriques -> données quantitatives (CPU, latence...) pour voir les tendances.
• Logs -> événements textuels détaillés pour comprendre le contexte.
• Traces -> parcours d'une requête à travers les microservices, indispensable en architecture distribuée.

Faire tourner la prod et la garder debout, coûte que coûte. Les piliers des OPS : monitoring, gestion d'incidents et astreintes (on-call) ( Alors ça ping ?).

Coordonner plusieurs tâches/systèmes automatisés en un workflow cohérent (pas juste une tâche isolée) -> tu déclares l'état voulu ("3 réplicas"), l'orchestrateur (Kubernetes en tête) le maintient tout seul : scaling, redémarrage des composants en panne (self-healing), etc.

La séquence automatisée d'étapes (build, test, déploiement) qu'un changement traverse du commit à la prod -> défini en code versionné (Pipeline as Code), le même artefact est testé puis promu d'environnement en environnement sans être reconstruit.

Le fichier YAML qui décrit l'état désiré d'un système -> Ansible l'exécute séquentiellement (les "Plays") pour l'atteindre, de façon idempotente.

La plus petite unité déployable dans Kubernetes -> un ou plusieurs conteneurs qui partagent le même réseau et le même stockage, toujours créés et détruits ensemble. Ils sont éphémères : si un Pod tombe, on ne le répare pas, on en recrée un (cf. réplicas).

Une classe simple, sans héritage imposé par un framework, avec des champs privés et des getters/setters publics.

Analyse "blameless" (sans chercher un coupable, enfin presque xD) déclenchée par un incident de prod, pour trouver la cause racine et éviter que ça se reproduise. Un cousin du REX, mais toujours lié à un échec.

Un hyperviseur bare-metal (type 1) qui embarque deux moteurs : KVM pour les VMs (l'hyperviseur à proprement parler) et LXC pour des conteneurs système, plus légers -> le tout piloté depuis une seule UI web.

Cousin proche d'un POJO. Contrairement à ce dernier, un record est immuable (pas de setters) et génère automatiquement des getters ainsi que equals(), hashCode() et toString().

Un retour d'expérience sur les événements passés — incidents, projets ou expérimentations techniques.

Méthode d'investigation qui vise à remonter à la cause profonde d'un incident plutôt que de s'arrêter à ses symptômes -> comprendre le "pourquoi" pour éviter que ça se reproduise. La technique la plus simple pour ça, les 5 Why -> enchaîner les "Pourquoi ?" jusqu'à toucher la cause racine, pas juste le symptôme du dessus.

Le responsable de la politique de sécurité (PSSI) d'une entreprise -> gestion des risques, conformité, réponse aux incidents.

Le guide pas-à-pas pour résoudre un incident connu -> prérequis, commandes exactes, validation, rollback. Une bonne alerte pointe directement dessus, pour réduire le MTTR au lieu de chercher les commandes en pleine crise.

Des copies identiques d'une ressource (instance d'appli, donnée) réparties sur plusieurs nœuds -> si l'une tombe, les autres continuent de servir. En Kubernetes, c'est le nombre de Pods identiques que l'orchestrateur maintient en permanence.

Cérémonie Agile (non c'est pas une secte, enfin je crois) en fin de sprint -> On debrief. Contrairement au post-mortem, c'est périodique, pas lié à un incident précis.

Les objectifs SMART constituent un cadre méthodologique utilisé pour définir des objectifs:

• S -> Spécifique
• M -> Mesurable
• A -> Atteignable (Achievable)
• P -> Pertinent (Relevant)
• T -> Temporellement défini (Time-bound)

La capacité d'un système à absorber une charge croissante sans dégrader ses perfs. Scale-up (vertical) -> plus de CPU/RAM sur la même instance, limité par le matériel et SPOF. Scale-out (horizontal) -> plus d'instances en parallèle, l'approche cloud native.

Le système observe son état réel, le compare à l'état désiré, et corrige tout seul l'écart -> ex. un Pod crashe, l'orchestrateur en recrée un sans attendre qu'un humain s'en aperçoive. Ça écrase le MTTR et allège le toil des équipes ops.

Déplacer les contrôles de qualité et de sécurité le plus tôt possible dans le cycle de développement -> les traiter au moment où le code s'écrit, plutôt qu'en bout de chaîne juste avant la prod. Plus un problème est détecté tôt, moins il coûte cher à corriger. Se traduit concrètement par :

• SAST -> analyse statique du code source pendant l'écriture.
• SCA -> scan des dépendances tierces pour repérer les vulnérabilités connues.
• Secret scanning -> détection des mots de passe/clés d'API en clair avant le commit.

L'ensemble organisé (matériel, logiciels, données, process, humains) qui gère l'information d'une entreprise -> plus large que l'IT, qui n'en est que la brique technique.

Promesse contractuelle faite au client sur le niveau de service (ex: 99,9% de dispo, temps de résolution d'une panne).

La mesure brute d'un aspect du service (latence, taux d'erreur, dispo...) -> elle alimente le SLO (l'objectif visé, ex. "95% sous 200ms") qui lui-même sous-tend le SLA (la promesse contractuelle au client).

La cible interne que l'équipe s'impose sur un SLI (ex: 99,9% de dispo) -> l'écart tolérable devient le budget d'erreurs. Tant qu'il n'est pas épuisé, on privilégie la vélocité ; s'il fond trop vite, on stabilise avant de livrer.

5 principes à suivre en POO:

• S -> Single Responsibility : une seule responsabilité (seul rôle métier).
• O -> Open/Closed : ouvert à l'extension, fermé à la modification.
• L -> Liskov Substitution : une sous-classe doit pouvoir remplacer sa classe mère.
• I -> Interface Segregation : préférer plusieurs interfaces à une seule interface généraliste.
• D -> Dependency Inversion : dépendre d'abstractions, pas d'implémentations concrètes.
• Bob Martin SOLID Principles of Object Oriented and Agile Design

Un composant unique dont la panne fait tomber tout le système. L'inverse, c'est la haute dispo : redondance, plusieurs instances, failover automatique.

Passe 50% de son temps en ops (astreinte, incidents, interventions manuelles) et 50% à automatiser -> le temps gagné sert à construire des systèmes scalables et self-healed. Ses 5 piliers, hérités de CALMS :

• Share -> réduire les silos organisationnels.
• Culture -> accepter les pannes comme normales.
• Lean -> implémenter des changements graduels.
• Automatisation -> s'appuyer sur des outils plutôt que sur l'humain.
• Mesure -> tout mesurer (cf. SLI/SLO/SLA).

On écrit le test, on code (do it), on refactorise (do it better)... à chaque fois on démarre du test vers l'implémentation.
Schéma Red-Green-Refactor

Terraform est un outil open source d'IaC (HashiCorp) qui permet de construire, modifier et versionner des infrastructures -> tu décris l'état final voulu (déclaratif, en HCL), il calcule et applique les changements nécessaires.

Le temps que met une feat. pour passer du DEV à la PROD. C'est un indicateur de réactivité. Un pipeline CI/CD vise à réduire ce délai.

Une tâche manuelle, répétitive, automatisable, qui ne règle pas la cause racine et dont le volume grandit avec la taille du service -> chez Google, on le plafonne à 50% du temps d'un SRE, le reste doit servir à l'automatiser pour de bon.

Cartographier chaque étape du flux, de la demande client à la livraison, pour repérer les goulots d'étranglement et éliminer le gaspillage (pilier Lean du CALMS).

La virtualisation consiste à faire fonctionner des machines virtuelles (VM) sur une machine physique, l'hôte.

Pas la peine de généraliser trop tôt (refactoriser inévitable tu devras ... mais pas tout de suite).