Vous aimez dormir et profiter des week-ends. Vos clients détestent perdre l'accès à votre système à cause de la maintenance. Doug Barth, ingénieur d'exploitation PagerDuty , a la solution :

Abandonnez complètement l’entretien programmé.

Cela semble être une proposition audacieuse. Mais comme Doug expliqué aux DevOps Days Chicago , en fait, cela a beaucoup de sens.

Maintenance programmée Les interventions ont tendance à avoir lieu tard le week-end, ce qui représente un défi pour les ingénieurs d'exploitation et les administrateurs. Les clients ont besoin d'un accès à toute heure, et pas seulement en plein jour. De plus, la maintenance programmée rend votre système moins fiable que vous ne le pensez, car vous craignez de le modifier pendant la journée de travail.

La solution ? L'éviter complètement et le remplacer par des stratégies de maintenance rapides et itératives qui ne compromettent pas l'ensemble de votre système.

Cela peut paraître un peu « extravagant », mais abandonner la maintenance programmée est plus simple qu'on ne le pense. Dans sa présentation, Doug a proposé quatre méthodes pour y parvenir.

Déployer par étapes

Avant toute chose : si vous abandonnez la maintenance planifiée, vos déploiements doivent être robustes. Ils doivent être scriptés, rapides et rétrogradés rapidement, et testés régulièrement pour garantir que les rétrogradations ne soient pas lentes.

Elles doivent également être compatibles avec les versions antérieures et postérieures. Il n'est pas envisageable d'arrêter la production lors du déploiement d'une nouvelle version. Les déploiements « rouge-bleu-vert » sont ici cruciaux, car ils garantissent que seul un tiers de votre infrastructure subit des modifications à la fois.

Enfin, les applications sans état doivent être la norme. Vous devez pouvoir redémarrer une application sans que cela n'ait d'impact sur le client (comme une déconnexion forcée ou un panier perdu).

Envoyez des canaris dans la mine de charbon

Utilisez judicieusement les déploiements Canary pour tester les déploiements, évaluer leur intégrité et comparer les résultats. Ces déploiements de test n'affectent qu'une petite partie de votre système ; un code erroné ou une erreur inattendue ne sèment donc pas la pagaille dans l'ensemble de votre service.

Doug a suggéré quelques moyens pratiques pour y parvenir :

• Les fonctionnalités de Gate vous permettent de publier du code dans l'obscurité et d'appliquer lentement de nouvelles fonctionnalités à un sous-ensemble de clients.

• Trouvez des moyens de transférer lentement le trafic d’un système à un autre, afin de réduire les risques liés à une mauvaise configuration ou à une infrastructure froide.

• Exécutez le code du chemin critique en parallèle. Exécutez-le et consignez les erreurs, mais ne vous y fiez pas immédiatement.

Comme Doug l’a résumé pour les participants aux DevOps Days : « Évitez les changements trop radicaux comme la peste. »

Faites des tentatives votre nouveau meilleur ami

Votre système doit être chargé de tentatives. Intégrez-les à tous les sauts de la couche de service et utilisez des intervalles de réponse exponentiels pour éviter de surcharger le système en aval. Les requêtes entre les couches de service doivent être idempotentes, a souligné Doug. Lorsqu'elles le sont, vous pourrez réémettre des requêtes vers de nouveaux serveurs sans appliquer deux fois les modifications.

Utilisez des files d'attente où la réponse ne vous importe pas pour découpler le client du serveur. Si vous êtes bloqué avec un flux requête/réponse, adoptez une approche de type « disjoncteur », où votre bibliothèque cliente renvoie des résultats minimaux en cas de panne d'un service, réduisant ainsi la latence et les erreurs front-end.

Ne mettez pas tous vos œufs dans le même panier

Distribuez vos données sur plusieurs serveurs, de sorte qu'aucun serveur ne soit si important que vous ne puissiez pas travailler dessus en toute sécurité.

Chez PagerDuty, l'équipe utilise des clusters multi-maîtres, qui facilitent les opérations et la scalabilité verticale. Elle utilise également plusieurs serveurs de bases de données comme Cassandra : aucun serveur n'est vraiment unique, ce qui permet d'effectuer les opérations opérationnelles pendant la journée.

Ensemble, ces stratégies aident les administrateurs et les ingénieurs opérationnels à dormir plus, à s’inquiéter moins et à mieux gérer leurs activités, le tout en avance sur le calendrier.

Des questions ? Partagez votre avis dans les commentaires ci-dessous.