Pensez SRE: regardez les projets avec les yeux d'un ingénieur SRE

Dans les critiques de Slurm, Kubernetes a sonné la phrase: "Kubernetes s'est avéré être plus facile que je ne le pensais." Maintenant ça ne sonne plus, le mythe de la complexité des k8 n'est plus. Il est passé dans la catégorie des outils faciles à apprendre, difficiles à maîtriser.

Nous voulons répéter la même chose avec SRE. Montrez que le SRE est plus facile et plus compréhensible qu'il n'y paraît. Changer le paradigme: laisser les gens voir le projet à travers les yeux d'un ingénieur SRE.

Comme toujours au début, l'équation comporte de nombreuses inconnues. Et comme toujours au départ, les plus intéressants iront en premier.

Du 3 au 5 février, nous accueillerons Slurm SRE à Moscou. Un billet intensif de trois jours coûte 60 mille. Qu'obtiendra le participant pour son argent?

Quand je parle de SRE à mes amis et collègues, je rencontre un scepticisme sain:

• Pour la première fois que j'entends parler de SRE, c'est une sorte d'alchimie.
• La mise en œuvre de SRE est difficile, pour des géants comme Google.
• C'est cher et long, ils ne donneront pas de temps, ils n'alloueront pas de budget.
• Ce que vous décrivez est trop beau pour être vrai.

Je veux faire ressortir ces questions.

Il est temps de découvrir ce qu'est le SRE.

Au niveau du slogan: SRE est l'une des implémentations de DevOps. Il est apparu il y a plus de 10 ans sur Google, mais n'a commencé que récemment à pénétrer le marché «normal», principalement en raison du livre Site Reliability Engeneering, publié par Google en 2016.

La connexion entre SRE et DevOps est bien décrite dans cette vidéo:

La mauvaise chose est que les slogans ne sont rien. Eh bien DevOps, eh bien, l'implémentation, la prochaine "pour tout bon contre tout mauvais".

Vous pouvez lire le livre (et ça vaut le coup). Mais le lecteur se retrouvera dans la position d'une personne étudiant le karaté à partir de dessins. Le livre décrit le concept sans application à la réalité. L'enseignant guide la main le long d'un chemin spécifique et signale les erreurs dans le processus.

Le prix comprend un examen rapide et approfondi de l'approche et des outils SRE.

La mise en œuvre de SRE est plus facile qu'il n'y paraît

Chez Slurma, nous toucherons SRE de nos mains: nous choisirons des métriques, configurerons leurs mesures, alertes, rencontrerons des incidents, les résoudrons et les analyserons, reconstruirons le projet selon tous les canons SRE.

Autrement dit, nous vous donnerons des instructions étape par étape que vous pouvez mettre en œuvre à votre retour de retour intensif.

Je mens. En fait, nous ne donnerons pas d'instructions, mais un échantillon à partir duquel vous pourrez tirer un tas d'idées et de solutions.

Le prix comprend un échantillon pour la mise en œuvre.

Le principal problème est que vous devez convaincre ceux qui ne sont pas allés à Slurm. Par conséquent, dans l'idéal, cela vaut la peine de participer intensivement à l'ensemble de l'équipe. Par conséquent, nous accordons de grandes remises pour les groupes.

Ce serait bien de venir à Slerm dirigé par la station-service. Et le PDG est également utile, et à propos de cette section ...

... comment convaincre la direction que le SRE est utile et nécessaire.

Il y a généralement un conflit de tâches entre le PDG (direction générale), la STO (gestion informatique), les développeurs et l'exploitation.

Je ne dis pas intentionnellement «conflit d'intérêts», c'est précisément un conflit de tâches.

Le PDG a besoin de performances financières. STO - une situation compréhensible, gérable et aussi confortable que possible. Autrement dit, des tâches compréhensibles avec une valeur commerciale compréhensible, des délais respectés, une pile normale, plus de fonctionnalités et moins de fakaps. Les développeurs doivent déployer plus de fonctionnalités et d'exploitation - pour garantir l'accessibilité (qui est clairement en conflit avec «plus de fonctionnalités»).

SRE dit que tous les participants au processus ont une seule tâche: le bonheur de l'utilisateur. L'utilisateur est satisfait d'un équilibre sain entre les nouvelles fonctionnalités et la fiabilité du service. L'utilisateur heureux paie plus d'argent. Pour gérer le bonheur des utilisateurs, vous avez besoin d'outils spécialisés.

De plus, SRE, basé sur des métriques, vous permet de traduire des indicateurs financiers en indicateurs cibles de différentes métriques, et ceux-ci, à leur tour, en tâches des équipes DevOps.

Vous permet de traduire - j'ai exagéré. La présence de ces métriques vous permet de trouver la relation entre l'état des métriques et les indicateurs financiers. Il s'agit d'une tâche distincte, grande mais compréhensible.

Il existe un projet DORA, DevOps Research & Assessments , il publie des études annuelles sur la valeur pour l'entreprise et le ROI DevOps et sa sous-classe SRE. Nous traduisons maintenant le rapport actuel en russe. Il existe des formules d'évaluation qui peuvent être appliquées à votre entreprise avec un certain degré de précision.

Résumé: SRE donne aux entreprises la capacité de gérer la performance financière en fixant des objectifs de mesure, et l'équipe DevOps, en examinant les mesures actuelles, comprend clairement ce qui doit être fait pour tirer le meilleur parti de la performance financière. Quel PDG refusera un tel outil?

Il est tout à fait possible d'obtenir des ressources pour la mise en œuvre de SRE.

Le prix du cours comprend un ensemble d'arguments en faveur du passage à SRE et DevOps.

Et même dans les petites entreprises, il y a une place pour le SRE.

Le SRE est divisé en outils, culture et structure organisationnelle.

Certains outils, par exemple, Service Mesh, sont nécessaires pour les projets volumineux et complexes. Mais les mêmes tentatives, interruptions, injections d'échecs, dégradations gracieuses peuvent être implémentées dans de petits projets, et elles donnent un énorme retour.

La culture est également utile dans toute entreprise. L'administrateur classique, qui configure Prometheus, agira conformément à la norme: il comprendra la surveillance de la mémoire et de la consommation de disque, et d'autres surveillances familières. L'ingénieur SRE ira d'abord discuter des indicateurs clés des processus métier avec l'entreprise, puis mettra en place leur suivi. Il est immédiatement évident que la culture d'ingénierie SRE est utile même dans les micro-startups.

Mais la structure organisationnelle dans les petites entreprises n'est probablement pas nécessaire et même nuisible. Lorsque tous les employés sont généralistes, il n'est pas nécessaire d'affecter de force les commandes SRE.

Tout ce que nous décrivons fonctionne déjà

Le cours a été créé par ceux qui ont longtemps mis en œuvre le SRE dans leurs équipes et qui ont longtemps vécu dans ce paradigme. Ivan Kruglov et Ben Tyler, tous deux sont développeur principal chez Booking.com. Eugene Varavva, développeur à profil large chez Google. Eduard Medvedev, CTO chez Tungsten Labs, qui a grandi à partir d'un ingénieur SRE.

Edward organise un webinaire «SRE - HYIP ou le futur?» Le 12 décembre à 11h00.

À propos du programme

Quant au programme. Je reçois déjà des commentaires d'experts que le programme ne combat pas: il est trop large et parfois illogique. Ça l'est vraiment.

En fait, nous avons un cadre pour le programme, un ensemble d'idées que nous voulons révéler. Nous avons deux mois de dur labeur devant nous, alors que nous nous préparons, le programme sera clarifié: nous supprimons les inutiles et spécifions les restants.

Mais déjà sous sa forme actuelle, le programme montre clairement la direction dans laquelle nous travaillons.

Tout ce qui précède vaut-il l'argent?

PS. Quel est le rapport avec le hub Kubernetes

Toutes les pratiques se font à Kubernetes. Ceux qui possèdent Kubernetes ont une route directe vers les ingénieurs SRE. Pour ceux qui ne sont pas propriétaires, consultez nos cours Kubernetes .

Inscription au Slurm SRE