20 ans de leçons tirées du Site Reliability Engineering (SRE) chez Google

20 ans de leçons tirées du Site Reliability Engineering (SRE)

Leçons d’ingénierie de la fiabilité apprises chez YouTube

• Choix des mesures d’atténuation des risques

  • En cas d’erreur critique, il faut choisir des mesures d’atténuation proportionnelles à la gravité de l’incident.
  • Des mesures excessives peuvent entraîner des effets secondaires, et il ne faut contourner les procédures standard que lorsqu’il existe une raison valable de le faire.

• Tester les mécanismes de reprise pour les situations d’urgence

  • Les mécanismes de reprise et les mesures d’atténuation doivent être suffisamment répétés et testés à l’avance afin de pouvoir réagir efficacement même en situation critique.
  • Les tests permettent de réduire les risques futurs et d’améliorer la capacité de réponse.

• Introduire progressivement les changements (avec des tests canary)

  • Avant de déployer largement des changements, il faut les introduire progressivement afin qu’un problème n’affecte pas l’ensemble du système.
  • L’exemple d’un changement de configuration du cache chez YouTube a montré que même de petites modifications nécessitent une mise en œuvre structurée.

Leçons tirées de Google Calendar

• Importance d’une fonction d’arrêt d’urgence

  • Pour les changements présentant un risque potentiel, il faut une fonction comparable à un « gros bouton rouge » permettant de réagir rapidement.
  • Il faut prévoir une fonction d’arrêt d’urgence en tenant compte des dépendances de service.

• Nécessité des tests d’intégration

  • Les tests unitaires sont utiles dans un périmètre limité, mais il faut valider l’adéquation du système en le reliant à l’environnement réel via des tests d’intégration.
  • Les incidents sur Google Calendar ont mis en évidence l’importance de tests suivant les parcours réels des utilisateurs.

Les leçons de Google en 2017

• Importance des canaux de communication en situation d’urgence

  • Il est nécessaire de préparer des canaux de communication ainsi que des canaux de secours.
  • En cas d’interruption de service, il faut disposer de plusieurs moyens de communication indépendants des services touchés et en tester l’efficacité.

• Maintenir un minimum de fonctionnalités en cas de dégradation

  • Pour éviter qu’un service ne soit totalement interrompu, il faut le concevoir de manière à ce qu’il puisse fournir des fonctions de base même en mode dégradé.

Tests de résilience aux catastrophes

• Tests de résilience aux catastrophes et de capacité de reprise
  • Il faut tester la résilience des services et des systèmes afin d’assurer leur continuité même en situation de catastrophe.
  • Les tests de reprise doivent vérifier si le système peut revenir à un état normal après une interruption.

Importance des mesures d’atténuation automatisées

• Automatisation des mesures d’atténuation
  • En cas de pannes sur plusieurs réseaux, il faut réduire le temps de résolution en s’appuyant sur des mesures d’atténuation automatisées plutôt que sur un traitement manuel.

Réduire l’intervalle entre les déploiements

• Procéder à des rollouts fréquents

  • De longs intervalles entre les rollouts compliquent l’évaluation de la sécurité du système.

• Une seule version matérielle mondiale constitue un point de défaillance unique

  • Dépendre d’un seul modèle spécifique peut simplifier l’exploitation, mais si ce modèle rencontre un problème, l’exécution de fonctions critiques peut être interrompue.
  • La présence de plusieurs backbones réseau permet d’éviter une panne généralisée et de router le trafic prioritaire vers des alternatives encore opérationnelles.