Les fenêtres de maintenance sont une erreur

Il y a plusieurs années, j’ai acheté un thermostat numérique « intelligent » pour ma maison. Je souhaitais pouvoir régler la température à distance, et la regarder en mon absence. Je l’ai configuré et connecté au backend cloud du fabricant. Tout allait bien, à peu près je pensais.

Quelques semaines plus tard, j’ai reçu un e-mail du producteur au sujet d’une mise à niveau imminente de son service. Pendant la période de mise à niveau, qui durerait plusieurs mois, l’entreprise réduisait son application « pendant plusieurs heures à la fois » et le ferait à « différentes heures de la journée » (ces heures n’étaient pas spécifiées) . L’entreprise, évidemment, a excusé la gêne occasionnée à l’avance.

Quoi ? À des moments apparemment aléatoires, mon thermostat allait s’arrêter de fonctionner pendant plusieurs heures à la fois, et cela continuerait pendant des mois ? Je ne crois pas. Le lendemain, j’ai changé le thermostat avec celui d’une autre entreprise. Il n’y avait aucune autre façon pour moi de gérer ce niveau de mauvais service.

L’accessibilité est importante.

Afin d’obtenir des avantages spécifiques, mon fils doit déclarer ses revenus au gouvernement des États-Unis. Pour ce faire, il utilise une application sur son téléphone portable. Lorsqu’un mois, il se connecte à l’application pour déclarer ses revenus du mois précédent. Cette application iPhone, néanmoins, a un problème important avec elle. Lorsque vous lancez l’application à une heure incorrecte, un message s’affiche : « Cette application ne fonctionne qu’entre 8 h 00 et 17 h 00 HE, du lundi au vendredi. »

Hein ? Quoi ?

C’est vrai, cette application en ligne basée sur SaaS ne fonctionne que pendant les « heures normales de l’entreprise ». Cela rend évidemment l’application très difficile à utiliser. Pourquoi limiteraient-ils le nombre d’heures d’utilisation d’une application comme celle-ci ? En tant qu’organisation gouvernementale, ils ont certainement pensé qu’ils ne voulaient pas laisser l’application s’exécuter alors que personne n’était sur le lieu de travail pour la prendre en charge. Comment pourraient-ils potentiellement réparer un problème s’ils n’étaient pas sur leur lieu de travail ?

Les temps d’arrêt planifiés sont des temps d’arrêt

Ces deux exemples sont extrêmes. Ils illustrent un problème typique dans de nombreuses applications en ligne : l’entreprise qui exécute les applications produit des « fenêtres de maintenance » – des périodes pendant lesquelles elle met régulièrement l’application hors ligne afin d’effectuer la maintenance de routine et les mises à niveau. Ils traitent ces fenêtres comme s’il s’agissait de « temps d’arrêt gratuits ». Ils se sentent libres d’arrêter leurs applications et de travailler dessus, sans que cela « compte » comme temps d’arrêt.

Rien n’est plus éloigné de la réalité. Les temps d’arrêt sont des temps d’arrêt. Que ce soit planifié, attendu ou imprévu et imprévu, si vos clients souhaitent utiliser votre application et que l’application n’est proposée pour aucun facteur, il s’agit d’un temps d’arrêt.

Vous ne pouvez pas utiliser un appareil moderne, application ou service numérique, en ligne sans respecter un calendrier élevé. Lorsque vos clients souhaitent utiliser votre service, ils anticipent que votre service sera opérationnel. Ils n’apprécient pas les horaires. Ils ne supportent pas les temps d’arrêt. Ils utilisent votre application quand c’est sans tracas pour eux, pas quand cela vous convient.

C’est déjà assez grave lorsqu’une défaillance de l’application nuit à votre disponibilité. Mais avoir l’intention d’avoir des temps d’arrêt, à la manière d’une fenêtre de maintenance, ne fait que formaliser le mécontentement des clients.

En ces temps contemporains, avec les outils et services proposés pour une application moderne développement, il n’y a aucune raison pour qu’une application numérique nécessite un temps d’arrêt pour une maintenance ou une mise à niveau. Dans le monde d’aujourd’hui, c’est inutile. Du point de vue du client, ce n’est pas souhaitable.

Pratiquement, toute mise à niveau peut être réalisée en direct sans temps d’arrêt. Même les mises à niveau qui nécessitent des modifications de schéma de base de données et d’autres tâches de migration de données peuvent être mises en œuvre sans nécessiter de temps d’arrêt. Les tâches d’entretien peuvent être effectuées pendant que l’application continue de fonctionner. Il n’y a plus aucune raison valable pour que vous ayez l’intention de supprimer votre application moderne.

Les fenêtres d’entretien sont une obligation financière technique

Si votre application nécessite vraiment des fenêtres d’entretien en raison de un problème architectural historique, alors vous devriez le traiter comme un problème. Il s’agit d’une obligation financière technique imposée à votre application qui coûte de l’argent à votre entreprise. C’est quelque chose qui doit être traité. Vos consommateurs ne se soucient pas de pourquoi votre application est en panne. Ils se soucient simplement de quand elle est en panne.

Au fur et à mesure que votre application grandit et s’élargit, il sera plus difficile de justifier une fenêtre de temps d’arrêt régulière. Les modèles d’utilisation des consommateurs se développent et les consommateurs s’attendent à ce que l’application fonctionne à toute heure du jour et de la nuit.

En outre, la création de systèmes et de procédures pour votre société de développement qui ne nécessitent pas l’utilisation de fenêtres de maintenance encourage le respect des la mise en œuvre et les meilleures pratiques fonctionnelles. Nous, les développeurs, avons tendance à devenir paresseux lorsque nous imitons que nous savons que nous avons une fenêtre de maintenance facilement disponible pour notre utilisation.

Concevoir et exécuter des modifications qui ne nécessitent pas de fenêtre de maintenance nécessite plus de temps et de réflexion, ce qui encourage une meilleure attention aux informations. Lorsque les concepteurs doivent prendre en compte l’impact fonctionnel d’un changement, ils ont tendance à produire moins de préoccupations opérationnelles que lorsqu’ils le « lancent simplement dans la production » et en excluent les ramifications. Lorsque vous dépendez des fenêtres d’entretien, la qualité générale et l’accessibilité en pâtissent.

Même si vous avez actuellement des périodes de « faible utilisation » rapidement reconnaissables pendant lesquelles vous pensez pouvoir vous permettre de fermer votre application, cela ne signifie pas que ces mêmes périodes de « faible utilisation » vous seront facilement accessibles au fur et à mesure de votre expansion et de votre croissance. L’expansion internationale, la croissance de l’ensemble de produits et la croissance de la base de clients peuvent tous contribuer à l’exigence accrue d’un calendrier 24 × 7.

Les dépenses élevées des fenêtres d’entretien

Un ancien client à moi fréquemment planifié une fenêtre d’entretien de deux heures par semaine, afin qu’ils puissent effectuer des mises à niveau et des modifications d’informations, tout en leur permettant de continuer à fonctionner généralement le reste du temps.

Le problème est que la fenêtre d’entretien est, en elle-même, un coup dur à programmer. Une fenêtre de maintenance de deux heures indique que la plus grande disponibilité que vous pouvez offrir à vos clients est de 98,8 %. En d’autres termes, vous n’aurez pas la possibilité d’opérer plus de 98,8 % du temps.

Contrairement aux autres applications en ligne, 98,8 % est un chiffre épouvantable. Par exemple, le service Amazon S3 garantit l’accessibilité du service à 99,99 % (et a un SLA de stabilité des données encore plus élevé). Cette garantie s’élève à un maximum de 61 secondes de temps d’arrêt chaque semaine. Pour qu’Amazon S3 rende ce quartier délabré de manière cohérente, Amazon ne peut jamais prévoir de temps d’arrêt pour tout entretien, jamais. Toute panne les amènera à faire échouer leur bidonville sous contrat.

Et ils soutiennent cette politique avec de l’argent. Si Amazon S3 est en panne de 4,3 minutes au cours d’un mois fourni, alors AWS remboursera 10 % des dépenses de stockage de tout le monde pour ce mois entier. Comme vous pouvez l’imaginer, ce serait une quantité importante de perte de revenus.

Et ce n’est pas simplement S3, c’est un état d’esprit dans AWS et dans tout Amazon. Cet engagement est ancré dans l’esprit de chaque ingénieur d’Amazon. Vous construisez tout pour qu’aucun temps d’arrêt ne soit jamais nécessaire, quelle que soit la modification apportée au système. Aucun temps d’arrêt, jamais.

Oui, 99,99 % est un niveau élevé d’accessibilité à garantir, et toutes les entreprises n’ont pas besoin de ce niveau pour que leur service prospère. Mais même à une partie inférieure de la disponibilité, il y a peu d’espace pour les fenêtres d’entretien préparées :

• Une disponibilité de 99 % suggère 1,6 heure par semaine de temps d’arrêt maximal.
• Planification de 99,9 % signifie 10 minutes par semaine de temps d’arrêt optimal.
• Une accessibilité à 99,99 % signifie moins de 61 secondes par semaine de temps d’arrêt optimal.

Même à ces niveaux de planification inférieurs, un 2 heures d’indisponibilité par semaine suggèrent que votre application échouera toujours son SLA. Certaines entreprises ne comptent pas les temps d’arrêt organisés comme des temps d’arrêt, mais vos clients le font, c’est ce qui compte.