Le webinaire a un mauvais son, nous l'avons donc décrypté.
Je m'appelle Edward Medvedev. Aujourd'hui, je vais parler de ce qu'est le SRE, de son apparence, des critères pour lesquels les ingénieurs SRE travaillent, un peu des critères de fiabilité, un peu de sa surveillance. Nous monterons à l'étage, parce que vous ne direz pas grand-chose en une heure, mais je vous donnerai du matériel pour des connaissances supplémentaires, et nous vous attendons tous au Slerm SRE . à Moscou fin janvier.
Tout d'abord, parlons de ce qu'est SRE - Site Reliability Engineering. Et comment il est apparu comme une position distincte, comme une direction distincte. Tout a commencé avec le fait que dans les cercles de développement traditionnels, Dev et Ops sont deux équipes complètement différentes, généralement avec deux objectifs complètement différents. L'objectif de l'équipe de développement est de déployer de nouvelles fonctionnalités et de répondre aux besoins de l'entreprise. L'objectif de l'équipe Ops est que tout fonctionne et que rien ne se casse. De toute évidence, ces objectifs se contredisent directement: pour que tout fonctionne et que rien ne casse, déployer de nouvelles fonctionnalités est le moins possible. Pour cette raison, il existe de nombreux conflits internes que la méthodologie, qui s'appelle désormais DevOps, tente de résoudre.
Le problème est que nous n'avons pas de définition claire de DevOps et une implémentation claire de DevOps. J'ai pris la parole lors d'une conférence à Ekaterinbourg il y a 2 ans, et jusqu'à présent, la section DevOps a commencé avec une présentation de «Qu'est-ce que DevOps». En 2017, le devo a presque 10 ans, mais nous discutons toujours de ce que c'est. Et c'est une situation très étrange que Google a essayé de résoudre il y a plusieurs années.
En 2016, Google a publié un livre intitulé Site Reliability Engineering. Et en fait, c'est à partir de ce livre que le mouvement SRE a commencé. SRE est une option spécifique pour implémenter le paradigme DevOps dans une entreprise particulière. Les ingénieurs SRE se sont fixé pour objectif de garantir des performances système fiables. Ils proviennent principalement de développeurs, parfois d'administrateurs ayant une solide expérience en développement. Et ils font ce que les administrateurs système faisaient auparavant, mais une solide expérience dans le développement et la connaissance du système en termes de code conduit au fait que ces personnes ne sont pas sujettes au travail administratif de routine, mais sujettes à l'automatisation.
Il s'avère que le paradigme DevOps dans les équipes SRE est mis en œuvre par le fait qu'il existe des ingénieurs SRE qui résolvent les problèmes structurels. Le voici, le lien même entre Dev et Ops dont on parle depuis 8 ans. Le rôle du SRE est similaire au rôle d'un architecte dans le sens où les nouveaux arrivants ne le font pas. Les personnes en début de carrière n'ont pas encore d'expérience, n'ont pas l'étendue des connaissances nécessaires. Parce que SRE nécessite une connaissance très fine de ce qui peut exactement et quand mal tourner. Par conséquent, une certaine expérience est nécessaire ici, en règle générale, à l'intérieur et à l'extérieur de l'entreprise.
Ils demandent si la différence entre SRE et devops sera décrite. Elle vient d'être décrite. On peut parler de la place du SRE dans l'organisation. Contrairement à cette approche DevOps classique, où Ops est toujours un département distinct, SRE fait partie de l'équipe de développement. Ils sont impliqués dans le développement de produits. Il existe même une approche où SRE est un rôle qui passe d'un développeur à un autre. Ils participent aux revues de code de la même manière que, par exemple, les concepteurs UX, les développeurs eux-mêmes et parfois les chefs de produit. SRE fonctionne au même niveau. Nous avons besoin de leur mise à jour, nous avons besoin de leur examen, de sorte que pour chaque déploiement SRE, il est dit: «Eh bien, ce déploiement, ce produit n'affectera pas négativement la fiabilité. Et si c'est le cas, dans une certaine mesure. » Nous en parlerons également.
En conséquence, le SRE dispose d'un droit de veto sur la modification du code. Et en général, cela conduit également à une sorte de petit conflit si le SRE est implémenté de manière incorrecte. Dans le même livre sur l'ingénierie de la fiabilité du site, de nombreuses parties, pas même une seule, expliquent comment éviter ces conflits.
Ils demandent comment le SRE est lié à la sécurité de l'information. SRE n'est pas directement impliqué dans la sécurité de l'information. Fondamentalement, dans les grandes entreprises, les particuliers, les testeurs et les analystes le font. Mais SRE interagit également avec eux dans le sens où certaines opérations, certaines validations, certains déploiements qui affectent la sécurité peuvent également affecter la disponibilité du produit. Par conséquent, le SRE dans son ensemble a une interaction avec toutes les équipes, y compris les équipes de sécurité, y compris les analystes. Par conséquent, la plupart des SRE sont nécessaires lorsqu'ils essaient d'implémenter DevOps, mais en même temps, la charge sur les développeurs devient trop importante. Autrement dit, l'équipe de développement elle-même ne peut plus faire face au fait qu'elle doit désormais également être responsable des opérations. Et un rôle distinct apparaît. Ce rôle est prévu dans le budget. Parfois, ce rôle réside dans la taille de l'équipe, une personne distincte apparaît, parfois elle devient l'un des développeurs. Le premier SRE apparaît donc dans l'équipe.
La complexité du système, qui est affectée par SRE, la complexité qui affecte la fiabilité du travail, est nécessaire et aléatoire. La complexité nécessaire est lorsque la complexité d'un produit augmente dans la mesure où de nouvelles fonctionnalités du produit l'exigent. La complexité aléatoire se produit lorsque la complexité du système augmente, mais les caractéristiques du produit et les exigences commerciales n'affectent pas directement cela. Il s'avère que le développeur a fait une erreur quelque part, ou que l'algorithme n'est pas optimal, ou que certains intérêts supplémentaires sont introduits qui augmentent la complexité du produit sans besoin particulier. Un bon SRE devrait toujours mettre fin à cette situation. C'est-à-dire que toute validation, tout déploiement, toute demande d'extraction où la complexité augmente en raison d'ajouts aléatoires doit être bloquée.
La question est, pourquoi ne pas simplement embaucher un ingénieur, un administrateur système avec beaucoup de connaissances dans l'équipe. Un développeur dans le rôle d'un ingénieur, nous dit-on, n'est pas la meilleure solution de dotation. Un développeur dans le rôle d'un ingénieur n'est pas toujours la meilleure solution de dotation, mais le point ici est que le développeur qui est impliqué dans les opérations a un peu plus de désir d'automatisation, a un peu plus de connaissances et de compétences pour mettre en œuvre cette automatisation. Et en conséquence, nous réduisons non seulement le temps pour des opérations spécifiques, non seulement la routine, mais aussi des paramètres commerciaux importants tels que MTTR (Mean Time To Recovery, temps de récupération). Ainsi, et ce sera également un peu plus tard, nous économisons de l'argent pour l'organisation.
Parlons maintenant des critères pour le travail de SRE. Et tout d'abord sur la fiabilité. Dans les petites entreprises, les startups, il arrive très souvent que les gens supposent que si le service est bien écrit, si le produit est bien et correctement écrit, cela fonctionnera, il ne cassera pas. C'est tout, nous écrivons du bon code, donc il n'y a rien à casser. Le code est très simple, il n'y a rien à casser. Ce sont les mêmes personnes qui disent que nous n'avons pas besoin de tests, parce que, regardez, ce sont trois méthodes VPI, pourquoi le casser.
C'est tout faux, bien sûr. Et ces gens très souvent un tel code mord dans la pratique, parce que les choses se cassent. Les choses se brisent parfois de la manière la plus imprévisible. Parfois, les gens disent non, cela n'arrivera jamais. Et tout se passe exactement. Cela arrive assez souvent. Et par conséquent, personne ne vise jamais une disponibilité à 100%, car la disponibilité à 100% ne se produit jamais. C’est la norme. Et donc, quand on parle de la disponibilité d'un service, on parle toujours de neuf. 2 neuf, 3 neuf, 4 neuf, 5 neuf. Si vous traduisez cela en temps d'arrêt, alors, par exemple, 5 neuf, cela représente un peu plus de 5 minutes de temps d'arrêt par an, 2 neuf correspond à 3,5 jours de temps d'arrêt.
Mais il est évident qu'à un moment donné il y a une diminution du POI, retour sur investissement. Passer de deux à trois, cela signifie réduire les temps d'arrêt de plus de 3 jours. Passer de quatre à cinq réduit le temps d'arrêt de 47 minutes par an. Et il s'avère que pour une entreprise, cela peut ne pas être critique. Et en général, la fiabilité requise n'est pas un problème technique, tout d'abord, c'est un problème commercial, c'est un problème de produit. Quel niveau d'indisponibilité est acceptable pour les utilisateurs du produit, à quoi s'attendent-ils, combien paient-ils, par exemple, combien d'argent ils perdent, combien d'argent le système perd.
Une question importante dans ce cas est de savoir quelle est la fiabilité des composants restants. Parce que la différence entre 4 et 5 neuf ne sera pas visible sur un smartphone avec 2 neuf de fiabilité. En gros, si quelque chose tombe en panne sur un smartphone dans votre service 10 fois par an, il est très probable que l'échec se soit produit 8 fois précisément du côté du système d'exploitation. L'utilisateur est habitué à cela et n'y fera pas attention une fois par an. Il est nécessaire de corréler le prix de l'augmentation de la fiabilité et de l'augmentation du profit.
Juste dans le livre sur le SRE, il y a un bon exemple d'augmentation à 4 neuf contre 3 neuf. Il s'avère que l'augmentation de la disponibilité est légèrement inférieure à 0,1%. Et si les revenus de service sont de 1 million de dollars par an, alors l'augmentation des revenus est de 900 dollars. Si l'augmentation de l'accessibilité de neuf nous coûte moins de 900 $ par année, cette augmentation est logique sur le plan financier. Si cela coûte plus de 900 $ par an, cela n'a plus de sens, car la croissance des revenus ne compense tout simplement pas les coûts de main-d'œuvre, les coûts des ressources. Et 3 neuf nous suffiront.
Il s'agit bien sûr d'un exemple simplifié où toutes les requêtes sont égales. Et de 3 à 4 neuf, il est assez facile de changer, mais en même temps, par exemple, passer de 2 à 3 représente déjà une économie de 9 000 dollars, cela peut avoir un sens financier. Naturellement, en réalité, un échec d'une demande d'enregistrement est pire qu'un échec d'affichage d'une page; les demandes ont un poids différent. Ils peuvent avoir des critères très différents du point de vue des affaires, mais en règle générale, si nous ne parlons pas de services spécifiques, il s'agit d'une approximation assez fiable.
Nous nous sommes demandé si SRE était l'un des coordinateurs lors du choix d'une solution architecturale pour un service. Supposons en termes d'intégration dans l'infrastructure existante afin qu'il n'y ait pas de perte de stabilité. Oui, les SRE ont le même effet sur les demandes d'extraction, les validations, les versions, ils affectent l'architecture, l'introduction de nouveaux services, les microservices et l'introduction de nouvelles solutions. Pourquoi ai-je dit avant que j'avais besoin d'expérience, j'ai besoin de qualifications. En fait, SRE est l'une des voix bloquantes de toute solution architecturale et logicielle. En conséquence, SRE en tant qu'ingénieur doit, tout d'abord, non seulement comprendre, mais aussi comprendre comment des solutions spécifiques affecteront la fiabilité, la stabilité et comprendre comment cela se rapporte aux besoins de l'entreprise, et de quel point de vue cela peut être c'est permis, et avec quoi pas.
Par conséquent, nous pouvons maintenant parler des critères de fiabilité, qui dans SRE sont traditionnellement définis comme SLA (Service Level Agreement). Probablement un terme familier. SLI (indicateur de niveau de service). SLO (objectif de niveau de service). L'accord de niveau de service est peut-être un terme historique, surtout si vous avez travaillé avec des réseaux, avec des fournisseurs, avec de l'hébergement. Il s'agit d'un accord général qui décrit les performances de l'ensemble de votre service, la pénalité, certaines pénalités pour les erreurs, les métriques, les critères. Et SLI est la mesure de disponibilité elle-même. Autrement dit, ce qui peut être SLI: temps de réponse du service, le nombre d'erreurs en pourcentage. Cela peut être de la bande passante s'il s'agit d'une sorte d'hébergement de fichiers. Si nous parlons d'algorithmes de reconnaissance, un indicateur peut être, par exemple, même l'exactitude de la réponse. SLO (Service Level Objective) est une combinaison de l'indicateur SLI, de sa valeur et de sa période, respectivement.
Disons que le SLA peut être comme ça. Le service est disponible 99,95% du temps tout au long de l'année. Ou 99 tickets de support critiques seront fermés dans les 3 heures par trimestre. Ou 85% des demandes recevront une réponse dans les 1,5 secondes chaque mois. Autrement dit, nous en venons progressivement à comprendre que les erreurs et les échecs sont tout à fait normaux. C'est une situation acceptable, nous la planifions, nous comptons même sur elle dans une certaine mesure. Autrement dit, SRE construit des systèmes qui peuvent faire des erreurs, qui devraient répondre normalement aux erreurs qui devraient en tenir compte. Et si possible, ils doivent gérer les erreurs de manière à ce que l'utilisateur ne les remarque pas ou les remarque, mais il existe une solution de contournement pour laquelle tout ne tombera pas complètement.
Par exemple, si vous téléchargez une vidéo sur YouTube et que YouTube ne peut pas la convertir immédiatement, si la vidéo est trop grande, si le format n'est pas optimal, alors la demande ne tombera naturellement pas hors du temps, YouTube ne donnera pas d'erreur 502, YouTube dira: "Nous avons tout créé, Votre vidéo est en cours de traitement. Il sera prêt dans environ 10 minutes. » C'est le principe de la dégradation gracieuse, qui est familier, par exemple, dans le développement du frontend, si vous l'avez déjà fait.
Les termes suivants dont nous parlerons qui sont très importants pour travailler avec fiabilité, avec des erreurs, avec des attentes sont MTBF et MTTR. MTBF est le temps moyen entre les échecs. MTTR Temps moyen de récupération, temps moyen de récupération. C'est-à-dire combien de temps s'est écoulé depuis le moment où l'erreur a été détectée, depuis le moment où l'erreur est apparue jusqu'au moment où le service est entièrement rétabli à la normale. MTBF est principalement corrigé en travaillant sur la qualité du code. Autrement dit, en ce que le SRE peut dire non. Et vous avez besoin de la compréhension de toute l'équipe que lorsque le SRE dit «non», il le dit non pas parce qu'il est nuisible, non pas parce qu'il est mauvais, mais parce que sinon tout le monde en souffrira.
Encore une fois, il y a beaucoup d'articles, beaucoup de méthodes, beaucoup de façons, même dans le livre même auquel je me réfère si souvent, comment empêcher d'autres développeurs de commencer à détester SRE. MTTR, d'autre part, travaille sur votre SLO (Service Level Objective). Et c'est surtout l'automatisation. Parce que, par exemple, notre SLO est un temps de disponibilité de 4 neuf par trimestre. Cela signifie qu'en 3 mois, nous pouvons accorder 13 minutes de temps d'arrêt. Et il s'avère que nous ne pouvons pas avoir MTTR pendant plus de 13 minutes. Si nous réagissons pendant au moins 1 temps d'arrêt pendant 13 minutes, cela signifie que nous avons déjà épuisé la totalité du budget du trimestre. Nous brisons SLO. 13 minutes pour une réaction et réparer un échec, c'est beaucoup pour la voiture, mais très peu pour une personne. Parce que tant qu'une alerte arrive à une personne, pendant qu'elle réagit, jusqu'à ce qu'elle comprenne l'erreur, c'est déjà plusieurs minutes. Jusqu'à ce qu'une personne comprenne comment le réparer, quoi corriger exactement, quoi faire, alors c'est encore quelques minutes. Et en fait, même si vous avez juste besoin de redémarrer le serveur, comme il se trouve, ou d'augmenter un nouveau nœud, le MTTR manuel est déjà d'environ 7 à 8 minutes. Lors de l'automatisation d'un processus, MTTR atteint très souvent une seconde, parfois une milliseconde. Google parle généralement de millisecondes, mais en réalité, bien sûr, les choses ne sont pas si bonnes.
Idéalement, SRE devrait automatiser son travail presque complètement, car il affecte directement MTTR, ses métriques, le SLO de l'ensemble du service, et donc le profit de l'entreprise. Si le temps est dépassé, demandez-nous si la faute en incombe au SRE. Pour de bon, personne n'est à blâmer. Et c'est une culture distincte appelée postmortem sans baume, dont nous ne parlerons pas aujourd'hui, mais que nous analyserons sur Slurme. C'est un sujet très intéressant dont on peut beaucoup parler. En gros, si le temps alloué pour le trimestre est dépassé, alors tout le monde est à blâmer un peu, ce qui signifie que blâmer tout le monde n'est pas productif; au lieu de cela, peut-être qu'au lieu de blâmer qui que ce soit, nous corrigerons la situation et travaillerons avec ce que nous avons. D'après mon expérience, cette approche pour la plupart des équipes, en particulier en Russie, est un peu étrangère, mais elle a du sens et fonctionne très bien. Par conséquent, je recommanderai à la fin de l'article et la littérature qui peut être lue sur ce sujet. Ou venez à Slurm SRE.
Je vais vous expliquer. Si le temps de SLO par trimestre est dépassé, si le temps d'arrêt n'est pas de 13 minutes, mais de 15, qui pourrait en être responsable? Bien sûr, SRE pourrait être à blâmer, car il a évidemment fait une sorte de mauvais commit ou déploiement. L'administrateur du centre de données peut être à blâmer pour cela, car, peut-être, une maintenance imprévue a été effectuée. Si l'administrateur du centre de données est à blâmer, la personne Ops qui n'a pas calculé la maintenance lors de la coordination du SLO est à blâmer. Le responsable, le directeur technique ou quelqu'un qui a signé le contrat du centre de données et n'a pas prêté attention au fait que le centre de données SLA n'est pas conçu pour le temps d'arrêt requis est à blâmer. En conséquence, peu à peu tout le monde est à blâmer pour cette situation. Et cela signifie que cela n'a aucun sens de blâmer quiconque dans cette situation. Mais bien sûr, vous devez le réparer. Par conséquent, il existe des autopsies. Et si vous lisez, par exemple, l'autopsie de Github, qui est toujours une histoire très intéressante, petite et inattendue dans chaque cas particulier, vous pouvez remplacer que personne ne dit jamais que cette personne en particulier était à blâmer. La culpabilité est toujours attribuée à des processus imparfaits spécifiques.
Passons à la question suivante. Automatisation Habituellement, lorsque je parle d'automatisation dans d'autres contextes, je me réfère très souvent à un tableau qui indique combien de temps vous pouvez travailler sur l'automatisation d'une tâche afin de ne pas prendre plus de temps pour l'automatiser que vous n'en enregistrez généralement. Il y a un hic. Le hic, c'est que lorsque SRE automatise une tâche, il économise non seulement du temps, mais aussi de l'argent, car l'automatisation affecte directement MTTR. Ils sauvent, pour ainsi dire, le moral des employés et des développeurs, qui est également une ressource épuisable. Ils réduisent la routine. Et tout cela affecte positivement le travail et, par conséquent, l'entreprise, même s'il semble que l'automatisation n'a pas de sens en termes de coûts de temps.
En fait, il l'a presque toujours été et il y a très peu de cas où cela ne vaut pas la peine d'automatiser quelque chose dans le rôle de SRE. Plus loin, nous parlerons de ce qu'on appelle le budget des erreurs, le budget des erreurs. En fait, il s'avère que si tout est beaucoup mieux pour vous que le SLO que vous vous êtes fixé, ce n'est pas très bon non plus. C'est plutôt mauvais, car SLO fonctionne non seulement comme une limite inférieure, mais aussi comme une limite supérieure approximative. Lorsque vous vous définissez SLO dans une accessibilité de 99%, et en fait, vous avez 99,99%, il s'avère que vous avez un espace d'expérimentation qui ne nuira pas du tout à l'entreprise, parce que vous avez vous-même déterminé cela ensemble, et vous êtes l'espace ne pas utiliser. Vous disposez d'un budget pour les erreurs qui ne sont pas dépensées dans votre cas.
Que faisons-nous avec lui. Nous l'utilisons littéralement pour tout. Pour les tests dans des conditions de production, pour le déploiement de nouvelles fonctionnalités susceptibles d'affecter les performances, les versions, la maintenance et les temps d'arrêt planifiés. La règle inverse s'applique également: si le budget est épuisé, nous ne pouvons pas décharger quoi que ce soit de nouveau, car sinon SLO sera dépassé. Le budget a déjà été épuisé, nous n'avons pas publié quelque chose, s'il affectera négativement la productivité, c'est-à-dire que si ce n'est pas une sorte de correctif qui augmente directement SLO, alors nous allons au-delà du budget, et c'est une mauvaise situation, cela nécessite une analyse , post-mortem, et éventuellement une sorte de correction de processus.
Autrement dit, il s'avère que si le service lui-même fonctionne mal et que SLO est dépensé et que le budget n'est pas dépensé pour des expériences, pas pour certaines versions, mais par lui-même, alors au lieu de correctifs intéressants pour les développeurs, au lieu de fonctionnalités intéressantes, au lieu d'intéressantes versions. Au lieu d'une sorte de travail créatif, vous devrez faire des corrections stupides pour remettre le budget à l'ordre, ou modifier SLO, et c'est aussi un processus qui ne devrait pas se produire trop souvent.
Par conséquent, il s'avère que dans une situation où nous avons plus de budget pour les erreurs, tout le monde est intéressé: SRE et les développeurs. Pour les développeurs, un budget important pour les erreurs signifie que vous pouvez gérer les versions, les tests et les expériences. Pour SRE, le budget pour les erreurs et l'entrée dans ce budget signifie qu'ils font effectivement bien leur travail directement. Et cela affecte la motivation pour une sorte de collaboration. Si vous écoutez vos SRE en tant que développeurs, vous aurez plus d'espace pour un bon travail et beaucoup moins de routine.
Il s'avère que l'expérimentation en production est une partie assez importante et presque intégrale du SRE dans les grandes équipes. Et cela s'appelle généralement l'ingénierie du chaos, qui vient de l'équipe Netflix qui a publié un utilitaire appelé Chaos Monkey.
Chaos Monkey se connecte au pipeline CI / CD et abandonne aléatoirement le serveur en production. Encore une fois, dans la structure SRE, nous parlons du fait qu'un serveur en panne n'est pas mauvais en soi, il est attendu. Et si elle est incluse dans le budget, elle est acceptable et ne nuit pas à l'entreprise. , , , , , .
- , , Chaos Gorilla, . , -, , , , . , , , . , , , - , , , , , . . , , , , , CI/CD . , , , , , , , . , , , . , .
: ? . , . , SRE . , , . , , SRE , , , , , , , . SRE , - . , SRE, - .
, , . , SRE , , . , , . , , , , , , .
, . SRE , . , , SLA, SLI, SLO. , SLA SLO, . - , , , - , , . 4 , IT , . , - .
. , - , , Objectives, , 3 .
, , . SLA, SLI, SLO, , , Objectives, SLA. , : - , , . . , -. , , , , , -, , : - . -, , . , SRE , , .
3 . , , . – , . , , , . – , . , - , - , , . – , , , . , - - , . - . , , .
, , , , , . , . . . . . , .
, Observability. . , . , Observability . - , , , . : , . , , , . , - Kubernetes, , . Observability MTTR. Observability , , , , MTTR.
, , , , SRE. . , , , SRE . , - . , , -, SRE . , , , - . , . SRE . . .
, , , . - , - . SRE, -, , . , , , .
. , , , , , , . . , . canary, , , , - , , , . , , , , .
SRE. , - , SRE, . - , - , , , canary A/B . SRE , . SRE . , , . SRE , , , , 50 50 , , SRE . . , .
. - . , SRE . , , . , , , , , , . SRE.
SRE — , , , , , , . . . Booking.com . , . - . .
, . SRE. , 2 SRE, . SLA, SLI, SLO , . 3 SRE . – Keys to SRE , . — SRE . SRE . SRE , 5 SRE 190 . , DevOps , SRE , .
2 chaos ingeneering: (1) , (2) . 3 Awesome Lists chaos ingeneering , SRE SRE . SRE , , 200 . capacity planning blameless postmortem.
: SRE as a life choice
, . , - . , , . . .
.
PS: pour ceux qui aiment lire, Edward a donné une liste de références. Ceux qui préfèrent comprendre dans la pratique sont les bienvenus à Slörme SRE .