Vous aimez dormir et les week-ends. Les clients détestent perdre l’accès à votre système en raison de la maintenance. L'ingénieur des opérations de PagerDuty, Doug Barth, a la solution :

Abandonnez complètement l’entretien programmé.

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

Maintenance planifiée Les opérations de maintenance ont tendance à se dérouler tard le soir le week-end, ce qui constitue une situation difficile pour les ingénieurs d'exploitation et les administrateurs. Les clients ont besoin d'un accès à toute heure, pas seulement à la lumière du jour. De plus, la maintenance programmée implique que votre système est moins fiable que vous ne le pensez, car vous avez peur de le modifier pendant la journée de travail.

La solution ? Évitez-la complètement et remplacez-la 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 facile que vous ne le pensez. Dans son exposé, Doug a proposé quatre façons de procéder.

Déployer par étapes

Tout d'abord, si vous abandonnez la maintenance planifiée, vos déploiements doivent être solides comme le roc. Ils doivent être scriptés, rapides et restaurés rapidement, ainsi que testés périodiquement pour garantir que les restaurations ne prennent pas de retard.

Elles doivent également être compatibles avec les versions antérieures et postérieures. Il n'est pas envisageable d'arrêter les presses lorsque vous lancez 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 à un moment donné.

Enfin, les applications sans état doivent être la norme. Vous devez pouvoir redémarrer une application sans aucun effet sur le client (comme des déconnexions forcées ou des paniers d'achat perdus).

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'un petit segment de votre système, de sorte qu'un code erroné ou une erreur inattendue ne signifie pas un désastre pour l'ensemble de votre service.

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

• Les fonctionnalités de Gate vous permettent de diffuser 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 enregistrez 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 répétées votre nouveau meilleur ami

Votre système doit être chargé de tentatives. Intégrez-les à tous les sauts de couche de service et utilisez des backoffs exponentiels pour éviter de submerger 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 à de nouveaux serveurs sans appliquer deux fois les modifications.

Utilisez des files d'attente dans lesquelles la réponse ne vous intéresse pas pour découpler le client du serveur. Si vous êtes bloqué avec un flux de requête/réponse, utilisez une approche de disjoncteur, où votre bibliothèque cliente renvoie des résultats minimaux si un service est en panne, réduisant ainsi la latence et les erreurs du 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 mise à l'échelle verticale. Ils utilisent également plusieurs serveurs de bases de données comme Cassandra : aucun serveur n'est si spécial, ce qui signifie que le travail opérationnel peut avoir lieu 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 les opérations, le tout en avance sur le calendrier.

Des questions ? Partagez vos réflexions dans les commentaires ci-dessous.