Manuel de Survie Technique

Rappel: Chaque erreur = -30 secondes. 3 erreurs sur un module = partie perdue. La difficulte augmente: niveau 1 = 2 modules, puis +1 module par niveau avec moins de temps.

Module: Serveur Legacy

Le serveur affiche plusieurs indicateurs. La priorite de diagnostic suit un ordre strict.

Etape 1: Verifier le statut du VENTILATEUR en priorite

Le statut du ventilateur determine l'action principale:

  • ACTIF (tournant): Passer a l'etape 2
  • INVERSE: Action = Inverser la polarite
  • BLOQUE: Action = Maintenance percussive
  • ETEINT: Passer a l'etape 2

Etape 2: Si ventilateur OK, verifier la TEMPERATURE

La temperature critique (rouge, > 100C) change tout:

  • Temperature > 100C ET Disque CORRUPTED: Action = Arret urgence
  • Temperature > 100C ET disque autre: Action = Refroidissement urgence
  • Temperature < 100C: Passer a l'etape 3

Etape 3: Verifier RAM + CPU combines

  • RAM > 90% ET CPU > 90% simultanement: Action = Tuer processus zombies
  • Sinon: Action par defaut = Redemarrer le service

Etape 4: Determiner la COMMANDE selon l'OS

Le systeme d'exploitation affiche change la commande a taper:

  • OS contient "DOS": Commande = CTRL+ALT+DEL
  • OS contient "Temple": Commande = PRAY
  • OS = Solaris, HP-UX, ou AIX: Commande = shutdown -y -g0 -i6
  • OS = FreeBSD: Commande = shutdown -r now
  • Disque = CORRUPTED (et pas urgence): Commande = fsck -y && reboot
  • Autres cas: Commande = sudo reboot

Reseau FIREWALL-BLOCKED: Si le reseau affiche ce statut, une action secondaire apparait - choisir Desactiver firewall.

Module: Messagerie CEO

Le CEO envoie 3 messages paniques. Pour chaque message, choisir la bonne reponse parmi 4 options. Repondre correctement aux 3 messages pour reussir. La bonne reponse depend des indicateurs de contexte affiches.

Etape 1: Lire les indicateurs de contexte (ordre de priorite)

Regarder la barre de contexte sous le message du CEO. Le PREMIER indicateur actif determine la reponse:

  1. INVESTISSEURS (icone actif vert) → reponse avec: "investisseurs", "demo", "pitch", "roadmap"
  2. BOARD (icone actif jaune) → reponse avec: "board", "proposition", "rapport", "presentation"
  3. URGENCE 4-5 (barre rouge) → reponse avec: "immediatement", "crisis", "sur le pont", "15 minutes"
  4. VENDREDI/WEEKEND → reponse avec: "weekend", "nuit blanche"
  5. HUMEUR (emoji) → si colere: reponse proactive. si excite: "super", "parfait". si stresse: "compile", "finalise"

Etape 2: Eliminer les mauvaises reponses

Les mauvaises reponses contiennent TOUJOURS un de ces elements:

  • "pas sur", "impossible", "ne peut pas", "difficile"
  • "il faudrait", "on devrait", "prendre du recul"
  • "plus de temps", "au moins une semaine", "negocier"
  • Tout ce qui semble raisonnable ou prudent = FAUX

Si aucun indicateur special n'est actif

Choisir la reponse positive mais mesuree: "Je planifie", "J'evalue", "Je mobilise". Eviter les superlatifs ("immediatement", "crisis") si pas d'urgence.

Regle d'or: Le CEO ne veut JAMAIS entendre de probleme. Toute reponse qui suggere un obstacle, un delai, ou une difficulte est FAUSSE.

Module: Git Blame Investigation

Un bug est en production. Il faut identifier le commit coupable parmi l'historique git.

Indices pour trouver le coupable

  • Messages de commit suspects: "fix typo", "WIP", "oops", "quick fix", "hotfix"
  • Commits le vendredi apres 17h sont tres suspects
  • Un seul fichier modifie est plus suspect que plusieurs
  • Le dernier deploiement recent indique souvent la zone du bug

Methode de resolution

  1. Chercher un commit avec un message suspect (voir liste ci-dessus)
  2. Verifier si le fichier affecte correspond au fichier du bug
  3. Les commits du milieu de la liste sont plus probables (ni trop vieux, ni trop recents)

Astuce: Si un developpeur a un message de commit vague ET a commis un vendredi, c'est probablement lui. Vous avez 3 tentatives pour accuser le bon commit.

Module: Conflit de Reunions

3 reunions en meme temps! Il faut choisir la bonne selon la hierarchie politique de la startup.

Hierarchie de priorite (dans l'ordre)

  1. Convoquee par CEO: TOUJOURS prioritaire, sans exception
  2. Critique avec agenda: Prioritaire sur critique sans agenda
  3. Client VIP: Prioritaire si pas de CEO et pas de critique avec agenda
  4. Important avec agenda: Sinon, choisir celui qui a un agenda
  5. En dernier recours: Choisir la reunion la plus importante restante

Indicateurs a surveiller

  • Couronne = Reunion du CEO
  • Document = A un agenda (plus serieux)
  • Organisateur = Client VIP est tres important
  • Derniere reunion declinee = Attention a ne pas froisser la meme personne

Attention: Seulement 2 tentatives! Decliner la mauvaise reunion peut couter cher politiquement.

Module: Facturation Cloud

Des instances cloud coutent cher. Il faut entrer la bonne commande de suppression selon le provider et le contexte.

Etape 1: Identifier le PROVIDER et sa commande de base

  • Amazon/AWS: aws ec2 terminate-instances --instance-ids [ID]
  • Google/GCP: gcloud compute instances delete --zone=auto
  • Azure: az vm delete --yes
  • Alibaba: aliyun ecs DeleteInstance --Force true
  • Autre: api DELETE /instances

Etape 2: Ajouter les FLAGS selon les indicateurs

  • PRODUCTION affiche: Ajouter --force-production
  • AUTOSCALING actif: Ajouter --disable-autoscaling-first
  • Type = RESERVED: Ajouter --release-reservation
  • Services lies affiches: Ajouter --cascade-delete

Etape 3: Code de confirmation

Le code utilise les 4 derniers caracteres de l'instance ID:

  • AWS: terminate-[4 derniers chars]
  • GCP: delete-[4 derniers chars]
  • Azure: remove-[4 derniers chars]
  • Autre: confirm-[4 derniers chars]

Module: Dette CSS

Le bouton "Acheter" est casse. Le symptome affiche determine le fix CSS.

Etape 1: Identifier le SYMPTOME du bouton

  • "Trop a gauche": Propriete = margin-left / Valeur = auto
  • "Cache derriere une image": Propriete = z-index / Valeur = grand nombre (ex: 9999999)
  • "Clignotant": Propriete = animation / Valeur = none + !important
  • "Invisible": Propriete = opacity / Valeur = 1
  • "Hors ecran" ou "Sous le footer": Propriete = position / Valeur = fixed
  • "Dans un iframe": Propriete = pointer-events / Valeur = auto
  • "Couvert par une modale": Propriete = z-index / Valeur = 999999999 + !important
  • "Taille 0px": Propriete = min-width / Valeur = 44px
  • "Rotation 180deg": Propriete = transform / Valeur = rotate(0deg)
  • "Flou gaussien": Propriete = filter / Valeur = none
  • "Mix-blend-mode casse": Propriete = mix-blend-mode / Valeur = normal

Etape 2: Verifier les modificateurs

  • Navigateur IE ou Safari 9: Cocher !important
  • Appareil tactile: Fix additionnel doit mentionner min-height: 44px
  • RTL layout actif: Utiliser margin-right au lieu de margin-left

Module: Labyrinthe Microservices

Un service est DOWN (rouge). Il faut rediriger vers un service sain.

Etape 1: Identifier le service de REDIRECTION

Par defaut, rediriger vers le premier service VERT (healthy) de la liste.

  • Si Circuit Breaker = OPEN: Preferer un service JAUNE (half-open) s'il existe
  • Sinon: Prendre le premier service vert

Etape 2: Calculer le PORT selon le protocole affiche

  • HTTP: Entrer le port affiche tel quel (ex: 3000 → 3000)
  • gRPC: Port affiche + 1 (ex: 3000 → 3001)
  • WebSocket: Toujours 8080
  • GraphQL: Entrer le port affiche tel quel

Circuit Breaker half-open + Timeout > 5000ms: Forcer protocole HTTP comme override.

Module: Pipeline CI/CD

Le pipeline est bloque. L'action depend de l'etape en echec et du contexte.

Etape 1: Identifier l'ETAPE bloquee et son action

  • Linter: Action = eslint --fix
  • Unit Tests: Action = retry-with-cache (sauf si coverage < 50% alors skip-coverage-check)
  • Build Docker: Action = docker system prune -f (sauf si artifact > 500MB alors docker build --squash)
  • SonarQube: Action = skip-quality-gate (sauf si vulnerabilite critical/high alors acknowledge-vulnerability)
  • Security Scan: Action = rescan (sauf si vulnerabilite alors security-exception)
  • E2E Tests: Action = retry-flaky + skip flag --retries=3
  • Performance Tests: Action = skip-perf (sauf sur main/master alors baseline-reset)

Etape 2: Determiner l'ENV selon le runtime

  • Node Version contient "Python": USE_PYTHON=true
  • Node Version contient "bun": PACKAGE_MANAGER=bun
  • Autre: CI=true

Etape 3: Verifier le flag SKIP

  • Build precedent = unstable: Ajouter --force
  • Branch non-main: Ajouter --no-verify pour Linter
  • Unit Tests: Toujours ajouter --testTimeout=30000

Module: Blocage Jira

Un ticket bloque le deploiement. La resolution depend du statut du PO et de la priorite.

Etape 1: Verifier le TYPE de ticket

  • Tech Debt ET pas client-facing: Field = backlog / Value = tech-debt-bucket (pas d'escalation)
  • Autre type: Continuer etape 2

Etape 2: Verifier le STATUT DU PO

  • Conge ou Hors Bureau: Field = approver / Value = backup-po
    • Si priorite P0 ou P1: Escalation = management-override
  • Reunion ou Focus Time: Field = skip-approval / Value = true
    • Si compliance required: Escalation = compliance-exception
  • Conference ou Formation: Field = delegate-to / Value = scrum-master
  • Autre: Field = force-push / Value = --no-verify

Etape 3: Verifier les MODIFICATEURS

  • Jour de sprint > 12: Escalation = sprint-rescue
  • Dependencies bloquees > 2 ET stakeholder escalation: Field = escalation-matrix / Value = level-2
  • Client-facing ET priorite P0: Escalation = war-room