Le coût d’une panne est un chiffre que vous calculez à partir de vos propres données, parce que les moyennes publiées par l’industrie décrivent d’autres entreprises. Additionnez les revenus, les remboursements, les dépenses de campagne gaspillées, le temps du personnel et le risque au renouvellement pour une heure hors ligne, à une heure moyenne et à votre heure la plus achalandée. Achetez ensuite la résilience un échelon à la fois. Arrêtez-vous quand l’échelon suivant coûte plus par année que les pertes liées aux pannes qu’il doit prévenir.
Cet article s’adresse au propriétaire, au directeur financier ou au responsable des opérations dont le site fonctionne bien la plupart du temps. Il vous donne une grille de calcul pour justifier une dépense d’infrastructure, ou pour la refuser avec une raison.
Comment calculer ce qu’une heure de panne coûte à votre entreprise ?
Vous calculez le coût d’une heure de panne en additionnant cinq postes, chacun tiré de registres que votre entreprise tient déjà. Un coût à la minute largement cité décrit des entreprises d’une autre taille et d’un autre modèle d’affaires.
| Poste de coût | D’où vient le chiffre | Qui détient les données |
|---|---|---|
| Revenus perdus ou reportés | Commandes, inscriptions ou demandes par heure, multipliées par leur valeur moyenne | Rapports de ventes ou de commerce électronique, analytique web |
| Remboursements et crédits dus | Crédits de service, clauses de remboursement et pénalités dans vos propres contrats avec vos clients ou vos annonceurs | Contrats, finances |
| Dépenses de campagne gaspillées | Publicité payée qui continue d’envoyer des visiteurs vers un site en panne | Marketing, plateformes publicitaires |
| Temps du personnel | Heures consacrées à l’incident par les développeurs, le soutien et les gestionnaires, à leur coût horaire complet | Paie, feuilles de temps |
| Risque au renouvellement et pour la réputation | Revenus des clients qui sont en cycle de renouvellement ou en période d’essai au moment de la panne | Dossiers de relation client, gestionnaires de compte |
Trois remarques rendent l’estimation honnête.
Une partie des revenus est reportée plutôt que perdue. Un client qui ne peut pas commander à midi reviendra peut-être plus tard. Si vous avez déjà eu une panne, comparez les commandes des heures suivantes à celles d’une journée normale.
Une entreprise d’abonnement perd peu de revenus par heure et beaucoup par incident. Une entreprise de logiciel-service (SaaS, de l’anglais software as a service) facture au mois, alors le premier poste est faible. Son exposition réelle se trouve dans le deuxième et le cinquième poste. Dans un mandat avec une entreprise SaaS canadienne interentreprises, le travail a commencé après une release ratée du client lui-même, qui avait empêché ses clients de se connecter pendant trente-huit heures. Le scénario type rapporte que deux de ces clients ont déposé des demandes de crédit, et que l’un d’eux a mis en doute l’avenir du fournisseur pendant sa discussion de renouvellement.
Le moment de la panne et les clauses de contrat peuvent peser plus que tout le reste. Une panne pendant une campagne payée expose aux conditions de vos ententes avec les annonceurs. Dans un mandat avec un éditeur national, deux pannes en huit semaines, dont une pendant le lancement d’une campagne de contenu commandité, ont précédé le projet.
Pourquoi une panne coûte-t-elle plus cher à certaines heures qu’à d’autres ?
Une panne coûte plus cher à certaines heures parce que les revenus, le trafic et l’exposition contractuelle ne sont pas répartis également sur l’année. Calculez les cinq postes pour une heure moyenne, puis pour votre heure la plus achalandée, comme des soldes, un lancement de produit ou une échéance de rapport en fin de mois. Le trafic de pointe est aussi le moment où les limites de capacité risquent le plus d’être atteintes, si bien que l’heure la plus coûteuse peut aussi être l’une des plus risquées.
La durée change aussi le chiffre. Une interruption de cinq minutes peut ne coûter presque rien. Une journée complète hors ligne peut coûter plus de vingt-quatre fois le chiffre horaire, parce que les clients commencent à partir et que les clauses des contrats commencent à s’appliquer. Estimez trois cas : une courte interruption, une panne d’une demi-journée et une panne de plusieurs jours.
Le crédit prévu par le SLA d’un hébergeur couvre-t-il le coût d’une panne ?
Le crédit prévu par le SLA d’un hébergeur ne couvre pas le coût d’affaires d’une panne, et c’est la pratique courante chez les hébergeurs et les fournisseurs de cloud. Un accord de niveau de service (SLA) est le document contractuel qui énonce les engagements de service d’un fournisseur et le recours prévu quand il ne les respecte pas. Ce recours est normalement un crédit de service, soit un remboursement partiel des frais d’hébergement.
Le SLA de Stack Harbor prévoit un engagement de 99,9 % de disponibilité mensuelle pour son réseau et son infrastructure en tant que service (IaaS), et il désigne le crédit de service comme le seul et unique recours. Le crédit est plafonné au total des frais mensuels des services touchés. Cet engagement couvre le réseau et l’IaaS de Stack Harbor, et non un environnement que l’entreprise exploite sur le cloud d’un autre fournisseur. Le crédit n’est pas calculé à partir des revenus perdus, des remboursements, des dépenses de campagne ou du temps du personnel d’un client.
La protection contre le coût d’affaires d’une panne vient de l’architecture et de l’intervention, et non du libellé du contrat. Un autre article explique comment lire un accord de niveau de service d’hébergement clause par clause.
Que pouvez-vous acheter pour réduire les pannes ? Les quatre échelons de la résilience
Vous pouvez acheter la résilience en quatre échelons, et chaque échelon coûte plus cher que celui du dessous. Chaque échelon protège contre un type de défaillance différent, alors un échelon supérieur ne remplace pas un échelon inférieur.
| Échelon | Ce contre quoi il protège | Ce qu’il ne fait pas | Reprise typique |
|---|---|---|---|
| 1. Sauvegardes dont la restauration est testée | Perte de données, corruption, serveur détruit | Raccourcir la panne pendant que la restauration s’exécute | Souvent des heures, selon le volume de données |
| 2. Surveillance avec intervention humaine | Pannes que personne ne remarque, première action lente | Éliminer la défaillance qui a causé la panne | Détection en quelques minutes, puis le temps de réparation |
| 3. Un deuxième nœud ou un cluster haute disponibilité | Défaillance d’un serveur, pannes pendant l’application des correctifs | Survivre à la perte d’une région complète, ou annuler une mauvaise release | Le service continue à capacité réduite |
| 4. Un secours chaud dans une deuxième région | Perte d’un centre de données ou d’une région | Empêcher toute perte de données, puisque la réplication accuse habituellement un retard sur la région principale | Une bascule répétée en exercice, décidée par une personne |
Échelon 1 : des sauvegardes dont la restauration est testée. Une sauvegarde qui n’a jamais été restaurée reste une hypothèse. Le test vous indique combien de temps prend une restauration, soit la durée de votre pire panne ordinaire. La base de connaissances explique comment vérifier qu’une restauration de base de données fonctionne.
Échelon 2 : une surveillance avec intervention humaine. Un outil de surveillance envoie une alerte. Cet échelon achète une personne qui prend en charge l’alerte et agit dans un délai établi, pendant les heures ouvrables, en couverture étendue ou 24/7.
Échelon 3 : un deuxième nœud. Un cluster haute disponibilité (HA) fait tourner l’application sur deux serveurs ou plus derrière un répartiteur de charge, avec une base de données répliquée. Un serveur peut tomber, ou recevoir ses correctifs, pendant que le service reste en ligne.
Échelon 4 : une région de secours chaud. Un secours chaud est une copie réduite de l’environnement dans une deuxième région, tenue à jour par réplication et démarrée par une bascule répétée en exercice. Le mode actif-actif, où deux régions servent le trafic en même temps, se situe au-dessus de cet échelon et coûte cher à exploiter pour la plupart des PME.
Une cause de panne se trouve hors de cette échelle. Les releases, les mises à jour de plugins et les changements de configuration figurent parmi les causes courantes de panne, et la redondance copie un mauvais changement sur chaque nœud. Une panne causée par une release sans environnement de staging et sans retour arrière n’est pas une défaillance d’infrastructure. La protection contre ce risque est un processus de release, comme un pipeline de déploiement avec staging et retour arrière.
De combien de disponibilité avez-vous besoin ?
Il vous faut assez de résilience pour que votre plus longue panne reste plus courte que ce que l’entreprise peut absorber. Ce besoin se mesure en durée plutôt qu’en pourcentage, et deux termes servent à le formuler. L’objectif de temps de reprise (RTO, de l’anglais recovery time objective) est la durée pendant laquelle le service peut rester en panne. L’objectif de point de reprise (RPO, de l’anglais recovery point objective) est la quantité de données récentes que vous pouvez vous permettre de perdre.
Fixez ces deux chiffres à partir de la grille de calcul. Si le coût annuel attendu des pannes de quatre heures est inférieur au coût annuel d’un deuxième nœud, un RTO de quatre heures est une décision d’affaires défendable. Si une panne de quatre heures contrevient à un contrat client, il ne l’est pas. La base de connaissances explique comment traduire RTO et RPO pour un PDG non technique ainsi que les compromis entre RTO, RPO et coût de l’architecture.
Un pourcentage masque cette question. Un chiffre mensuel de 99,9 % permet environ 43 minutes d’arrêt dans un mois de 30 jours. Quarante-trois minutes un dimanche soir et quarante-trois minutes pendant un lancement sont deux événements différents avec le même pourcentage.
Avez-vous besoin d’un cluster haute disponibilité, ou de bonnes sauvegardes suffisent-elles ?
De bonnes sauvegardes suffisent quand l’entreprise peut tolérer d’être hors ligne pendant la durée d’une restauration testée. Un cluster haute disponibilité devient nécessaire quand elle ne le peut pas.
Dans les conditions suivantes, choisissez des sauvegardes testées et une surveillance, et arrêtez-vous là.
- Le coût d’une panne à l’heure de pointe est faible par rapport au coût annuel d’un deuxième nœud.
- Aucun contrat client ne fixe un temps de reprise plus court que votre restauration testée.
- Vos clients et votre personnel ont les mêmes heures, alors une panne de nuit ne nuit à personne.
Choisissez un deuxième nœud ou un cluster dans les conditions suivantes.
- La défaillance d’un serveur unique pendant des soldes, une campagne ou une journée de travail a un coût tangible.
- L’application des correctifs est sans cesse reportée parce que chaque redémarrage cause une panne.
- Vos clients ont commencé à poser des questions sur la disponibilité dans leurs contrats ou leurs questionnaires de sécurité.
Choisissez une deuxième région dans les conditions suivantes.
- Un contrat client ou un organisme de réglementation exige un plan de reprise après sinistre écrit, avec un temps de reprise.
- Une restauration testée ne peut pas respecter ce temps de reprise.
Quand ne vaut-il pas la peine d’acheter plus de résilience ?
Il ne vaut pas la peine d’acheter plus de résilience quand l’échelon suivant coûte plus chaque année que les pertes qu’il doit prévenir. Trois situations sont courantes.
- Une heure de panne coûte peu. Achetez des sauvegardes avec tests de restauration et une couverture pendant les heures ouvrables, et arrêtez-vous là.
- Vos clients dorment aux mêmes heures que vous. Une couverture 24/7 paie des heures pendant lesquelles personne n’est lésé. Une couverture pendant les heures ouvrables ou une couverture étendue peut être le choix le plus juste.
- Une restauration testée respecte déjà votre temps de reprise contractuel. Une deuxième région ajoute des coûts et du travail d’exploitation sans réduire une perte que vous subissez.
Une conception qui limite ce qui peut tomber en panne en même temps peut aussi coûter moins cher que de tout dupliquer. La base de connaissances explique la conception par rayon d’impact.
Quels facteurs déterminent le coût de chaque échelon ?
Le coût de la résilience dépend du nombre de composants dupliqués et du nombre d’heures pendant lesquelles une personne est disponible pour intervenir. Chaque échelon comporte aussi le travail d’exploitation des tests et des exercices.
- Sauvegardes : volume de données, durée de conservation, copies hors site et temps consacré aux tests de restauration.
- Surveillance et intervention : fenêtre de couverture, délai de réponse convenu pour chaque niveau de gravité et nombre d’environnements.
- Cluster : serveurs supplémentaires, répartiteurs de charge, réplication de la base de données, stockage partagé et toute modification à l’application nécessaire pour fonctionner sur plus d’un nœud.
- Deuxième région : capacité de secours, réplication, outillage de bascule et exercices planifiés.
La résilience fait habituellement augmenter la facture d’hébergement. Dans un mandat qui a déplacé une application d’affaires vers une plateforme infogérée, le scénario type rapporte une hausse de 11 % du coût d’infrastructure. Ce chiffre appartient à un seul client et n’est pas un résultat typique. La grille de calcul vous dit si cette hausse se justifie. Un article complémentaire explique comment l’hébergement cloud infogéré est tarifé.
Un cadre de décision à apporter à votre réunion avec les finances
Suivez ces sept étapes avec vos propres chiffres.
- Calculez les cinq postes de coût pour une heure moyenne et pour votre heure la plus achalandée.
- Estimez trois durées de panne : une courte interruption, une demi-journée et plusieurs jours.
- Dressez la liste de vos pannes des deux dernières années, avec leurs causes et leurs durées.
- Multipliez le coût d’une panne typique par le nombre de pannes que vous prévoyez en une année. Vous obtenez votre perte annuelle attendue.
- Associez chaque panne passée à l’échelon qui l’aurait prévenue ou raccourcie.
- Demandez aux fournisseurs un devis pour cet échelon seulement, et comparez son coût annuel à la perte qu’il élimine.
- Mettez par écrit le RTO et le RPO que vous acceptez, et faites-les signer par un responsable de l’entreprise.
Pour comparer des fournisseurs, consultez ce qu’il faut rechercher chez un fournisseur d’hébergement infogéré.
Où se situe Stack Harbor
Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) de propriété canadienne pour les environnements de production, dont le siège est à Montréal. Stack Harbor sert des entreprises SaaS, des agences et des éditeurs qui exploitent des systèmes de production sans avoir leur propre équipe d’exploitation 24/7. Elle exploite des environnements sur sa propre infrastructure canadienne et sur des clouds comme AWS, Azure et Google Cloud.
Trois solutions de Stack Harbor correspondent aux échelons décrits plus haut. Avec la surveillance infogérée et l’intervention de garde, une personne formée prend en charge l’alerte et exécute un runbook conçu par des ingénieurs seniors, et des ingénieurs seniors sont mobilisés sur les incidents de gravité 1 (Sev-1). Les cibles d’intervention sont échelonnées selon la gravité et inscrites dans l’entente. La couverture est cadrée en heures ouvrables, en couverture étendue ou en 24/7. Les clusters HA sont conçus pour que la perte d’un nœud réduise la capacité pendant que le service reste disponible. Il s’agit d’une propriété de conception, et non d’une promesse de disponibilité. La reprise après sinistre multi-régions repose sur un secours chaud, une bascule approuvée par une personne et un exercice trimestriel. Les chiffres de RTO et de RPO sont cadrés à l’évaluation et signés par un responsable désigné du côté du client.
Quand les sauvegardes font partie du périmètre, la page Confiance et sécurité énumère des sauvegardes planifiées avec tests de restauration vérifiés et une répétition de restauration trimestrielle. Ce sont des pratiques, et non la promesse d’un résultat de reprise. Stack Harbor ne publie aucun prix. Les mandats sont cadrés selon leurs facteurs et font l’objet d’un devis fixe après une évaluation écrite.
Stack Harbor n’est pas le bon choix si votre grille de calcul exige un engagement de disponibilité supérieur au chiffre mensuel de 99,9 % de son SLA, un engagement de disponibilité pour l’application elle-même ou une compensation pour des pertes d’affaires. Ce n’est pas non plus le bon choix quand toute l’empreinte se résume à une instance et à un compartiment de stockage, parce qu’un contrat d’opérations infogérées serait une charge superflue. Si votre grille de calcul mène à un échelon supérieur, la prochaine étape est une conversation de cadrage sur votre environnement.
