Comment Atlassian assure la préparation opérationnelle

Tier 0 : infrastructure de base critique

Un service de tier 0 fournit une infrastructure de support et des composants de services partagés sur lesquels les services de tier 1 s'appuient pour fonctionner. Les composants sont considérés comme critiques si l'une des conditions suivantes est remplie :

• Ils sont nécessaires pour qu'un service de tier 1 fonctionne ou soit accessible pour ses utilisateurs
• Ils sont nécessaires pour qu'un client puisse s'inscrire à un service de tier 1
• Ils sont nécessaires au personnel pour soutenir ou exécuter des fonctions opérationnelles clés dans le cadre d'un service de tier 1, notamment :

- Démarrer/Arrêter/Redémarrer le service
- Procéder à un déploiement, à une mise à niveau, à une restauration ou à un correctif
- Déterminer l'état actuel (hausse, baisse, dégradation)

Tier 1 : services essentiels

Un service de tier 1 fournit une fonction vitale pour l'entreprise, le client ou le produit. Il s'agit de services orientés client ou de services internes essentiels. Lorsque le service est dégradé ou indisponible, l'entreprise perd de l'argent ou n'est pas en mesure d'exécuter des fonctions essentielles, ou des fonctionnalités de base pour le client sont perdues. Les services de tier 1 nécessitent un support 24 h/24, 7 j/7, des SLA stricts pour les métriques clés et un ensemble d'exigences de déploiement strictes.

Tier 2 : services non essentiels

Un service de tier 2 fournit un service orienté client qui ne fait pas partie des fonctionnalités de base. Ces services apportent une valeur ajoutée ou une expérience utilisateur supplémentaire qui peut être considérés comme facultative ou « intéressante ».

A tier-2 service includes public services that function mainly in a marketing capacity, such as public company websites. They don’t offer customers direct business-grade services and internal services used by teams to perform aspects of their roles, such as collaboration tools, work tracking, and more.

Les services de tier 2 peuvent ou non nécessiter un support 24 h/24, 7 j/7, des SLA moins stricts et des exigences de déploiement moindres.

Tier 3 : fonctionnalités internes uniquement ou non critiques

Un service de tier 3 fournit des fonctionnalités internes à l'entreprise ou des services bêta expérimentaux. Cette classe peut également inclure des services qui constituent actuellement une fonctionnalité expérimentale pour les premiers utilisateurs. La qualité du service pourrait se dégrader durant la phase bêta. Ce niveau fournit des SLA faibles pour les services pris en charge uniquement sur la base des meilleurs efforts.

Perte de données (RPO)

Ce chiffre représente la quantité maximale de données qui seront perdues par le service en cas de défaillance. Un service de tier 0 perdra moins d'une heure de données en cas de défaillance.

Restauration du service (RTO)

Ce chiffre représente la durée maximale avant que le service ne soit de nouveau opérationnel. Un service de tier 0 sera complètement rétabli en moins de quatre heures.

Back-ups

En cas d’interruption de service, les équipes peuvent avoir besoin d’utiliser des sauvegardes pour restaurer les données à un moment donné. Il est important de sauvegarder régulièrement les données, d’implémenter un processus de restauration et de tester régulièrement le processus de sauvegarde et de restauration. Ce dernier doit être fiable et efficace. La documentation et les tests sont essentiels à cet égard.

Définition de « Terminé »

• Vous avez implémenté un processus de sauvegarde et de restauration.
• Vous avez documenté et testé le processus de sauvegarde et de restauration.
• Vous testez régulièrement le processus de sauvegarde et de restauration.
  

Gestion de la capacité

Définissez clairement les capacités que le service fournit aux consommateurs. En particulier, identifiez les limites que le service leur impose. Implémentez des tests de performance pour vous assurer que le service fonctionne dans les limites prévues.

Voici quelques exemples d'informations à tester et à mettre à la disposition des consommateurs.

• Le service est limité à X exigences par seconde.
• Le service garantit un temps de réponse de X.
• La fonction X du service est répliquée ou n'est pas répliquée entre les régions.
• Le consommateur ne devrait pas faire X :
  - Surcharger le service
  - Importer des fichiers dont la taille est supérieure à X

Définition de « Terminé »

• Les limites de service sont identifiées et documentées.
• Des tests de performance sont en place pour vérifier que les limites sont appliquées.
  

Sensibilisation des clients

La capacité de prise en charge constitue un aspect important de la qualité du service, qui va de pair avec la fiabilité et la facilité d'utilisation. Les équipes doivent mettre en place des processus de support pour un service ou une nouvelle fonctionnalité d'un service avant son déploiement. La capacité de prise en charge peut inclure un processus de support client, un processus de contrôle des changements, des runbooks de support et d'autres tâches axées sur le support.

Processus de support client

Les développeurs doivent comprendre ce qui se passe lorsque les clients contactent l'équipe de support pour obtenir de l'aide, ainsi que leurs responsabilités dans le cadre du processus de support. Cela peut inclure le fait de participer à une rotation d'astreinte ou d'être invité à résoudre les problèmes de production au fur et à mesure qu'ils surviennent.

Processus de contrôle des changements

Tous les changements n'ont pas le même impact sur les clients. Certains ne sont pas perceptibles pour eux. Par exemple, une petite correction de bug. Certains se traduisent par de gros efforts pour eux, comme la réécriture complète d'une API. Le contrôle des changements permet d'évaluer l'ampleur de l'impact que les changements peuvent avoir sur les clients.

Runbooks de support

Les runbooks fournissent une vue d'ensemble du fonctionnement d'un service, ainsi que des explications détaillées sur les problèmes qui peuvent survenir et sur la manière de les résoudre. Il est important de mettre à jour régulièrement les runbooks et de vérifier que les procédures de support documentées sont exactes au fur et à mesure de l'évolution du service.

Définition de « Terminé »

• Documentation répondant à la plupart des questions dont l'équipe de support aurait besoin pour enquêter sur un ticket
• Un processus efficace de contrôle des changements
  
  

Reprise d'activité

La perte d'une zone de disponibilité s'apparente à une catastrophe. Les services doivent être suffisamment résilients pour fonctionner normalement en cas de défaillance d'une zone de disponibilité. La reprise d'activité comporte deux volets : tout d'abord, développer et documenter un processus de reprise d'activité ; et, deuxièmement, tester en permanence le processus documenté. La reprise d'activité doit être testée régulièrement. Testez votre capacité à gérer une défaillance de zone de disponibilité à l'aide du plan de reprise d'activité documenté.

Définition de « Terminé »

• Le plan de reprise d'activité est documenté.
• Le plan de reprise d'activité est testé.
• Des tests récurrents du plan de reprise d'activité sont prévus.
  

Journalisation

Les journaux sont utiles pour de nombreuses raisons, comme la détection d'anomalies, les enquêtes pendant ou après une panne de service, et le suivi des activités malveillantes en connectant les événements connexes entre les services à l'aide d'identifiants uniques. Il existe de nombreux types de journaux. Voici quelques journaux très utiles que la plupart des services devraient inclure :

• Journaux d'accès
• JOURNAUX D'ERREUR

Définition de « Terminé »

• Les journaux appropriés sont générés.
• Les journaux sont stockés dans un endroit où ils sont faciles à trouver et à consulter.
  

Contrôles d'accès logiques

Les contrôles d'accès logiques se concentrent sur la manière de gérer l'accès des utilisateurs internes et externes, l'accès service à service et le chiffrement des données. Comment le service empêchera-t-il tout accès non autorisé aux fonctionnalités et aux données ? Comment les autorisations utilisateur sont-elles définies, vérifiées, mises à jour et marquées comme obsolètes ? Ces contrôles offrent-ils une protection suffisante des données sensibles ?

Utilisateurs internes

Voici quelques questions importantes à se poser : comment les utilisateurs internes sont-ils authentifiés ? Comment l'accès est-il accordé/provisionné ? Comment est-il supprimé ? Comment fonctionne la remontée des privilèges ? Quel est le processus pour les revues et audits réguliers des accès ?

Utilisateurs externes

Comment l'authentification des clients est-elle gérée ? Comment l'accès est-il accordé/provisionné ? Comment est-il supprimé ? Comment fonctionne la remontée des privilèges ? Quel est le processus pour les revues et audits réguliers des accès ?

Service à service

Cet accès est similaire à celui des utilisateurs internes et externes. Les équipes doivent déterminer comment les services vont s'authentifier les uns auprès des autres. Par exemple, en configurant OAuth 2.0.

Chiffrement

Les équipes souhaiteront probablement chiffrer leurs données au repos et en transit. Expliquez comment le service gère le chiffrement des données. Comment l'équipe gère-t-elle les clés ? Quelle est la politique de rotation des clés ?

Définition de « Terminé »

• Les contrôles d'accès logiques sont documentés, implémentés et testés pour les utilisateurs internes et externes ainsi que pour les accès service à service.
• Chiffrement des données au repos
• Chiffrement des données en transit
• Le chiffrement est implémenté et testé.
  

Versions

Le déploiement d'une nouvelle version du service ne doit pas perturber le trafic client au-delà de ce qui est défini dans le SLA du service. Tous les changements doivent être revus par les pairs, testés et déployés via des pipelines de CI/CD. Après chaque déploiement, vérifiez que le déploiement a réussi et qu'aucune fonctionnalité n'a été interrompue. La vérification automatique post-déploiement est préférable. Utilisez plusieurs environnements, notamment de test, de staging, de préproduction et de production, afin de tester les déploiements.

Définition de « Terminé »

• Le service est déployé sans temps d'arrêt.
• Dans certains environnements, le service doit être déployé et testé avant d'être déployé en production.
  

Checklist de sécurité

La checklist de sécurité est un ensemble de pratiques et de normes visant à développer et à maintenir une infrastructure et des logiciels sécurisés. Ces normes réduisent le risque de violations de la vie privée et des données et, par conséquent, renforcent la confiance des clients. Les équipes doivent élaborer une checklist de sécurité qui tient compte de la nature du service qu'elles sont en train de créer. Voici quelques exemples d'exigences :

Définition de « Terminé »

• Il est prouvé qu'aucune vulnérabilité critique ou élevée n'existe pour le service.
• Le chiffrement au repos est utilisé pour toutes les bases de données.
• Il est prouvé que le service n'autorise pas les connexions HTTP non sécurisées.
  

Métriques de service

Les métriques de service fournissent des informations de santé et de diagnostic essentielles sur un service et permettent aux équipes de surveiller les incidents et d'y répondre. Commencez par définir un ensemble de métriques surveillées pour chaque service. Ensuite, créez un tableau de bord avec ces métriques dans un outil tel que Datadog ou New Relic. Déclenchez des alarmes lorsqu'une métrique dépasse les limites et créez des tickets d'incident en cas d'alarme.

Définition de « Terminé »
Voici quelques exemples d'éléments à mesurer :

• Latence : temps nécessaire pour traiter une demande
• Trafic : charge placée sur le service par des utilisateurs externes
• Erreurs : nombre d'utilisateurs concernés par des erreurs ou des échecs
• Saturation : niveau d'activité du service et durée pendant laquelle il peut encore gérer
• Utilisation des ressources sous-jacentes : CPU, mémoire, disque
• Éléments internes de l'application, tels que les files d'attente, les délais et le flux
• Utilisation et fonctionnalités principales de votre service : utilisateurs actifs, actions par minute
  

Résilience du service

Les exigences de résilience du service déterminent si un service est capable ou non de gérer les variations de charge et/ou les défaillances de différents composants. Un service résilient évoluera probablement automatiquement et résistera à la défaillance d'un seul nœud.

Mise à l'échelle automatique

Si le service est capable d'évoluer automatiquement, assurez-vous que le dimensionnement automatique est correctement configuré et testé. Déterminez quelle métrique déclenchera la mise à l'échelle automatique et testez-la pour vous assurer qu'elle fonctionne. Par exemple, si le service nécessite de stocker des données sur disque, il peut contrôler le pourcentage d'espace libre sur les disques et évoluer automatiquement en ajoutant de l'espace de stockage lorsque ce pourcentage tombe en dessous d'un seuil.

Test de défaillance d'un seul nœud

Il est souhaitable de disposer de services capables de survivre aux défaillances d'un seul nœud. Si un nœud de service tombe en panne, le service devrait continuer à fonctionner, peut-être avec une capacité réduite. Testez cette capacité en arrêtant au moins un nœud du service et en observant le comportement du système. Votre service est censé gérer une défaillance d'un seul nœud. L'environnement dans lequel vous allez simuler la défaillance d'un seul nœud doit être surveillé.

Définition de « Terminé »

• Il est prouvé que la mise à l'échelle automatique a été implémentée et testée.
• Il est prouvé que les environnements de production et/ou de staging exécutent plusieurs nœuds.
• La résilience du service est prouvée en cas de défaillance d'un seul nœud.
  

Support

Le support est le processus qui consiste à soutenir un service après sa livraison. Les équipes doivent disposer de runbooks, d'outils opérationnels et de rotations d'astreinte, et travailler avant la mise en ligne afin qu'un processus de résolution soit mis en place pour les services qui rencontrent des problèmes.

Runbooks

Les runbooks fournissent aux intervenants d'astreinte le contexte et les instructions dont ils ont besoin pour répondre rapidement aux incidents et fournir des efforts de remédiation.

Outils opérationnels

L'exécution d'un service selon un standard suffisant signifie qu'un tableau de service d'astreinte est en place et qu'un outil opérationnel tel qu'Opsgenie est configuré pour alerter les personnes d'astreinte en cas de problème avec le service.

Astreinte

Pour un service de tier 2 ou 3, un tableau de service d'astreinte est requis.

Pour un service de tier 0 ou 1, un tableau de service d'astreinte en continu est requis.

Définition de « Terminé »

• Les runbooks sont écrits et trouvables par le support.
• L'outil opérationnel est configuré et testé.
• Des rotations d'astreinte sont en place, et les intervenants sont contactés en cas de problème.
  

Contrôles de préparation opérationnelle suggérés pour le tier 3

• Back-ups
• Journalisation
• Versions
• Checklist de sécurité
• Métriques de service
• Support
  

Les services de tier 3 démarrent par les exigences de base en matière de préparation opérationnelle.

Contrôles de préparation opérationnelle suggérés pour les tiers 1 et 2

• Back-ups
• Reprise d'activité
• Journalisation
• Versions
• Checklist de sécurité
• Métriques de service
• Résilience du service
• Support

Les services de tier 1 et 2 ajoutent des exigences de préparation opérationnelle en matière de reprise d'activité et de résilience du service. Il est important de noter que les services de tier 1 et 2 peuvent avoir des exigences de préparation opérationnelle différentes. Il n'est pas nécessaire que les tiers aient des exigences différentes. Si une autre exigence de préparation opérationnelle est jugée nécessaire pour un tier de service spécifique, ajoutez-la. Les tiers 1 et 2 peuvent diverger selon les besoins de l'équipe.

Contrôles de préparation opérationnelle suggérés pour le tier 0

• Back-ups
• Gestion de la capacité
• Sensibilisation des clients
• Reprise d'activité
• Journalisation
• Contrôles d'accès logiques
• Versions
• Checklist de sécurité
• Métriques de service
• Résilience du service
• Support

Les services de tier 0 ajoutent la gestion de la capacité, la sensibilisation des clients et les contrôles d'accès logiques.