Le webinaire a un son de mauvaise qualité, nous l'avons donc transcrit.
Je m'appelle Medvedev Eduard. Aujourd'hui, je vais parler de ce qu'est le SRE, de la façon dont le SRE est apparu, des critères de travail des ingénieurs SRE, un peu des critères de fiabilité, un peu de son suivi. Nous marcherons sur les sommets, car on ne peut pas dire grand-chose en une heure, mais je donnerai du matériel pour un examen plus approfondi, et nous vous attendons tous sur . à Moscou fin janvier.
Parlons d’abord de ce qu’est le SRE – Site Reliability Engineering. Et comment cela 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, avec généralement 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 de s'assurer que tout fonctionne et que rien ne se casse. Évidemment, ces objectifs se contredisent directement : pour que tout fonctionne et que rien ne casse, déployez le moins possible de nouvelles fonctionnalités. Pour cette raison, il existe de nombreux conflits internes que la méthodologie désormais appelée DevOps tente de résoudre.
Le problème est que nous n’avons pas de définition claire du DevOps ni de mise en œuvre claire du DevOps. J'ai pris la parole lors d'une conférence à Ekaterinbourg il y a 2 ans, et jusqu'à présent, la section DevOps commençait par le rapport « Qu'est-ce que DevOps ». En 2017, Devops a presque 10 ans, mais nous discutons encore de ce que c'est. Et c’est une situation très étrange que Google a tenté de résoudre il y a quelques années.
En 2016, Google a publié un livre intitulé Site Reliability Engineering. Et c’est d’ailleurs avec ce livre que le mouvement SRE a débuté. Le SRE est une implémentation spécifique du paradigme DevOps dans une entreprise spécifique. Les ingénieurs SRE s'engagent à garantir que les systèmes fonctionnent de manière fiable. Ils proviennent pour la plupart de développeurs, parfois d’administrateurs ayant une solide expérience en développement. Et ils font ce que faisaient les administrateurs système, mais une solide expérience en développement et une solide connaissance du système en termes de code conduisent au fait que ces personnes ne sont pas enclines au travail administratif de routine, mais sont enclines à 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. La voici, la même connexion entre Dev et Ops dont les gens parlent depuis 8 ans. Le rôle d'un SRE est similaire à celui d'un architecte dans la mesure où les nouveaux arrivants ne deviennent pas SRE. 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 le SRE nécessite une connaissance très subtile de ce qui peut mal se passer et quand exactement. Par conséquent, une certaine expérience est généralement nécessaire ici, tant à l’intérieur qu’à 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 des produits. Il existe même une approche où le SRE est un rôle qui passe d'un développeur à un autre. Ils participent aux revues de code au même titre que, par exemple, les UX designers, les développeurs eux-mêmes, parfois les chefs de produits. Les SRE travaillent au même niveau. Nous devons les approuver, nous devons les examiner, afin que pour chaque déploiement, SRE dise : « D'accord, ce déploiement, ce produit n'affectera pas négativement la fiabilité. Et si c’est le cas, alors dans certaines limites acceptables. Nous en parlerons également.
Le SRE dispose donc d’un droit de veto pour modifier le code. Et en général, cela conduit également à une sorte de petit conflit si le SRE n'est pas mis en œuvre correctement. Dans le même livre sur l'ingénierie de fiabilité des sites, de nombreuses parties, pas même une, expliquent comment éviter ces conflits.
Ils demandent quel est le lien entre le SRE et la sécurité de l'information. SRE n'est pas directement impliqué dans la sécurité de l'information. Fondamentalement, dans les grandes entreprises, cela est fait par des particuliers, des testeurs, des analystes. Mais SRE interagit également avec eux dans le sens où certaines opérations, certains commits, certains déploiements qui affectent la sécurité peuvent également affecter la disponibilité du produit. Par conséquent, SRE dans son ensemble interagit avec toutes les équipes, y compris les équipes de sécurité, y compris les analystes. Par conséquent, les SRE sont principalement nécessaires lorsqu’ils tentent de mettre en œuvre DevOps, mais en même temps, la charge pesant sur les développeurs devient trop lourde. 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 il y a un rôle distinct. Ce rôle est prévu dans le budget. Parfois, ce rôle est déterminé par la taille de l'équipe, une personne distincte apparaît, parfois c'est l'un des développeurs qui le devient. C'est ainsi qu'apparaît le premier SRE dans l'équipe.
La complexité du système affecté par le SRE, la complexité qui affecte la fiabilité du fonctionnement, est nécessaire et accidentelle. On parle de complexité nécessaire lorsque la complexité d'un produit augmente dans la mesure requise par les nouvelles fonctionnalités du produit. On parle de complexité aléatoire lorsque la complexité du système augmente, mais que les fonctionnalités du produit et les exigences commerciales n'affectent pas directement cela. Il s'avère que soit le développeur a fait une erreur quelque part, soit l'algorithme n'est pas optimal, soit des 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. Autrement dit, tout commit, tout déploiement, toute pull request, dont la difficulté est augmentée en raison d'un ajout aléatoire, doit être bloqué.
La question est de savoir pourquoi ne pas simplement embaucher un ingénieur, un administrateur système possédant de nombreuses connaissances dans l'équipe. Un développeur dans le rôle d’un ingénieur, nous dit-on, n’est pas la meilleure solution en matière de recrutement. Un développeur dans le rôle d'ingénieur n'est pas toujours la meilleure solution de recrutement, mais le fait est qu'un développeur engagé 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 de certaines opérations spécifiques, non seulement la routine, mais également des paramètres commerciaux aussi importants que le MTTR (Mean Time To Recovery, temps de récupération). Ainsi, et nous en reparlerons également un peu plus tard, nous économisons de l'argent pour l'organisation.
Parlons maintenant des critères de fonctionnement du SRE. Et tout d’abord sur la fiabilité. Dans les petites entreprises, les startups, il arrive souvent que les gens supposent que si le service est bien écrit, si le produit est bien et correctement écrit, il fonctionnera, il ne tombera pas en panne. Ça y est, 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 à peu près les mêmes personnes qui disent que nous n’avons pas besoin de tests, car, regardez, ce sont les trois méthodes VPI, pourquoi s’arrêter ici.
Bien sûr, tout cela est faux. Et ces gens sont très souvent mordus par un tel code dans la pratique, car les choses se cassent. Les choses se cassent parfois de la manière la plus imprévisible. Parfois les gens disent non, cela n’arrivera jamais. Et ça arrive tout le temps. Cela arrive assez souvent. Et c'est pourquoi personne ne s'efforce jamais d'atteindre une disponibilité à 100 %, car une disponibilité à 100 % n'arrive jamais. C'est la norme. Et donc, quand on parle de disponibilité d'un service, on parle toujours de neuf. 2 neuf, 3 neuf, 4 neuf, 5 neuf. Si nous traduisons cela en temps d'arrêt, alors, par exemple, 5 neuf, alors cela représente un peu plus de 5 minutes d'arrêt par an, 2 neuf équivalent à 3,5 jours d'arrêt.
Mais il est évident qu’à un moment donné, il y a une diminution du POI, le retour sur investissement. Passer de deux neuf à trois neuf signifie moins de temps d'arrêt de plus de 3 jours. Passer de quatre neuf à cinq réduit les temps d'arrêt de 47 minutes par an. Et il s'avère que pour les entreprises, cela n'est peut-être pas critique. Et d’une manière générale, la fiabilité requise n’est pas une question technique, c’est avant tout une question commerciale, c’est une question de produit. Quel niveau de temps d'arrêt est acceptable pour les utilisateurs du produit, ce qu'ils attendent, combien ils paient, par exemple combien d'argent ils perdent, combien d'argent le système perd.
Une question importante ici est de savoir quelle est la fiabilité des composants restants. Car la différence entre 4 et 5 neuf ne sera pas visible sur un smartphone doté de 2 neuf de fiabilité. En gros, si quelque chose tombe en panne sur un smartphone de votre service 10 fois par an, la panne s'est probablement produite 8 fois du côté du système d'exploitation. L'utilisateur y est habitué et n'y prêtera pas attention une fois de plus par an. Il est nécessaire de corréler le prix d’une fiabilité croissante et d’une augmentation des bénéfices.
Rien que dans le livre sur le SRE, il y a un bon exemple d'augmentation de 4 neuf à 3 neuf. Il s'avère que l'augmentation de la disponibilité est d'un peu moins de 0,1 %. Et si les revenus du service sont de 1 million de dollars par an, alors l’augmentation des revenus est de 900 dollars. S’il nous en coûte moins de 900 $ par an pour augmenter l’abordabilité de neuf, l’augmentation est financièrement logique. Si cela coûte plus de 900 dollars par an, cela n’a plus de sens, car l’augmentation des revenus ne compense tout simplement pas les coûts de main-d’œuvre et de ressources. Et 3 neuf nous suffiront.
Il s'agit bien entendu d'un exemple simplifié où toutes les demandes sont égales. Et passer de 3 neuf à 4 neuf est assez facile, mais en même temps, par exemple, passer de 2 neuf à 3, c'est déjà une économie de 9 mille dollars, cela peut avoir un sens financier. Naturellement, en réalité, l'échec de la demande d'inscription est pire que l'échec de l'affichage de la page, les demandes ont des poids différents. Ils peuvent avoir un critère complètement différent d'un point de vue commercial, mais quoi qu'il en soit, en règle générale, si nous ne parlons pas de certains services spécifiques, il s'agit d'une approximation assez fiable.
Nous avons reçu une question de savoir si SRE était l'un des coordinateurs lors du choix d'une solution architecturale pour le service. Disons en termes d'intégration dans l'infrastructure existante, afin qu'il n'y ait aucune perte de stabilité. Oui, les SRE, de la même manière que les pull request, les commits, les releases affectent l'architecture, l'introduction de nouveaux services, les microservices, la mise en œuvre de nouvelles solutions. Pourquoi ai-je dit avant qu'il fallait de l'expérience, des qualifications étaient nécessaires. En fait, le SRE est l’une des voix bloquantes dans toute solution architecturale et logicielle. En conséquence, un SRE en tant qu'ingénieur doit, tout d'abord, non seulement comprendre, mais également comprendre comment certaines décisions 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 acceptable et ce qui n'est pas le cas.
On ne peut donc désormais parler que des critères de fiabilité, qui sont traditionnellement définis dans le SRE comme SLA (Service Level Agreement). Très 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 symbolique, 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, les pénalités, certaines pénalités pour erreurs, les mesures, les critères. Et SLI est la mesure de disponibilité elle-même. C'est-à-dire ce que peut être le SLI : le temps de réponse du service, le nombre d'erreurs en pourcentage. Cela pourrait être de la bande passante s'il s'agit d'une sorte d'hébergement de fichiers. Lorsqu'il s'agit d'algorithmes de reconnaissance, l'indicateur peut être, par exemple, même l'exactitude de la réponse. SLO (Service Level Objective) est respectivement une combinaison de l'indicateur SLI, de sa valeur et de sa période.
Disons que le SLA pourrait être comme ça. Le service est disponible 99,95% du temps tout au long de l'année. Ou 99 tickets d’assistance critiques seront clôturés dans les 3 heures par trimestre. Ou 85 % des requêtes recevront une réponse dans un délai de 1,5 seconde chaque mois. Autrement dit, nous comprenons progressivement 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 capables de commettre des erreurs, qui doivent réagir normalement aux erreurs, qui doivent en tenir compte. Et dans la mesure du possible, ils doivent gérer les erreurs de manière à ce que l'utilisateur ne les remarque pas ou ne les remarque pas, mais il existe une sorte de solution de contournement grâce à laquelle tout ne s'effondrera 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 volumineuse, si le format n'est pas optimal, alors la demande n'échouera naturellement pas avec un délai d'attente, YouTube ne donnera pas d'erreur 502. , YouTube dira : « Nous avons tout créé, votre vidéo est en cours de traitement. Ce 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 front-end, si vous l'avez déjà fait.
Les prochains termes dont nous parlerons, qui sont très importants pour travailler avec fiabilité, avec erreurs, avec attentes, sont MTBF et MTTR. Le MTBF est le temps moyen entre les pannes. MTTR Mean Time To Recovery, temps moyen de récupération. C'est-à-dire combien de temps s'est écoulé depuis le moment où l'erreur a été découverte, depuis le moment où l'erreur est apparue jusqu'au moment où le service a été rétabli pour fonctionner pleinement et normalement. Le MTBF est principalement fixé par des travaux sur la qualité du code. C’est-à-dire le fait que les SRE peuvent dire « non ». Et il faut que toute l'équipe comprenne que lorsque SRE dit « non », il ne le dit pas parce qu'il est nuisible, non pas parce qu'il est mauvais, mais parce que sinon tout le monde souffrirait.
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 fais si souvent référence, comment s'assurer que les autres développeurs ne commencent pas à détester SRE. MTTR, quant à lui, consiste à travailler sur vos SLO (Service Level Objective). Et c'est surtout de l'automatisation. Parce que, par exemple, notre SLO est une disponibilité de 4 neuf par trimestre. Cela signifie qu'en 3 mois, nous pouvons autoriser 13 minutes d'arrêt. Et il s’avère que le MTTR ne peut pas dépasser 13 minutes. Si nous répondons à au moins 13 temps d'arrêt toutes les 1 minutes, cela signifie que nous avons déjà épuisé la totalité du budget du trimestre. Nous brisons le SLO. 13 minutes pour réagir et réparer un crash, c'est beaucoup pour une machine, mais très court pour un humain. Car jusqu'à ce qu'une personne reçoive une alerte, jusqu'à ce qu'elle réagisse, jusqu'à ce qu'elle comprenne l'erreur, cela prend déjà plusieurs minutes. Jusqu'à ce qu'une personne comprenne comment le réparer, quoi réparer exactement, quoi faire, cela prend encore quelques minutes. Et en fait, même s'il s'avère qu'il vous suffit de redémarrer le serveur ou de créer un nouveau nœud, le MTTR manuel prend déjà environ 7 à 8 minutes. Lors de l'automatisation du processus, le MTTR atteint très souvent une seconde, parfois des millisecondes. Google parle généralement de millisecondes, mais en réalité, bien sûr, tout n'est pas si bon.
Idéalement, le SRE devrait automatiser presque complètement son travail, car cela affecte directement le MTTR, ses métriques, le SLO de l'ensemble du service et, par conséquent, le bénéfice de l'entreprise. En cas de dépassement du délai, on nous demande si SRE est en faute. Heureusement, personne n’est à blâmer. Et il s'agit d'une culture distincte appelée post-mortem sans balme, dont nous ne parlerons pas aujourd'hui, mais nous l'analyserons sur Slurm. C'est un sujet très intéressant dont on peut beaucoup parler. En gros, si le temps imparti par trimestre est dépassé, alors un peu de tout le monde est à blâmer, ce qui signifie que blâmer tout le monde n'est pas productif, ne blâmons peut-être personne, mais corrigeons la situation et travaillons avec ce que nous avons. D’après mon expérience, cette approche est un peu étrangère à la plupart des équipes, notamment en Russie, mais elle a du sens et fonctionne très bien. Par conséquent, je recommanderai à la fin de l'article la littérature que vous pouvez lire sur ce sujet. Ou venez chez Slurm SRE.
Laisse-moi expliquer. Si le temps SLO par trimestre est dépassé, si le temps d'arrêt n'était pas de 13 minutes, mais de 15, qui peut en être responsable ? Bien sûr, SRE peut être à blâmer, car il a clairement effectué une sorte de mauvais engagement ou déploiement. L'administrateur du centre de données peut en être responsable, car il a peut-être effectué une sorte de maintenance imprévue. Si l'administrateur du centre de données est responsable de cela, alors la personne des Ops est responsable, qui n'a pas calculé la maintenance lorsqu'il a coordonné le SLO. 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 SLA du centre de données n'est pas conçu pour les temps d'arrêt requis en est responsable. En conséquence, tout le monde est à blâmer petit à petit dans cette situation. Et cela signifie qu’il ne sert à rien de rejeter la faute sur qui que ce soit dans cette situation. Mais bien sûr, il faut corriger cela. C'est pourquoi il y a des post-mortems. Et si vous lisez, par exemple, les post-mortems de GitHub, et que c'est toujours une histoire très intéressante, petite et inattendue dans chaque cas, vous pouvez remplacer par le fait que personne n'a jamais dit que cette personne en particulier était à blâmer. La faute est toujours imputée à des processus imparfaits spécifiques.
Passons à la question suivante. Automatisation. Lorsque je parle d'automatisation dans d'autres contextes, je fais souvent référence à un tableau qui vous indique combien de temps vous pouvez travailler sur l'automatisation d'une tâche sans prendre plus de temps pour l'automatiser que vous n'en économisez réellement. Il y a un problème. Le problème, c’est que lorsque les SRE automatisent une tâche, ils gagnent non seulement du temps, mais aussi de l’argent, car l’automatisation affecte directement le MTTR. Ils sauvent, pour ainsi dire, le moral des salariés et des développeurs, qui est aussi une ressource épuisable. Ils réduisent la routine. Et tout cela a un effet positif sur le travail et, par conséquent, sur l'entreprise, même s'il semble que l'automatisation n'ait pas de sens en termes de coût en temps.
En fait, c’est presque toujours le cas, et il existe très peu de cas où quelque chose ne devrait pas être automatisé dans le rôle du SRE. Nous parlerons ensuite de ce qu’on appelle le budget d’erreurs, le budget des erreurs. En fait, il s'avère que si tout est bien meilleur pour vous que le SLO que vous vous êtes fixé, celui-ci n'est pas non plus très bon. C’est plutôt mauvais, car le SLO fonctionne non seulement comme une limite inférieure, mais aussi comme une limite supérieure approximative. Lorsque vous vous fixez un SLO de disponibilité de 99 %, et en fait vous en avez 99,99 %, il s'avère que vous disposez d'un espace pour des expériences qui ne nuiront pas du tout à l'entreprise, car vous avez vous-même déterminé tout cela ensemble, et vous êtes cet espace n'est pas utilisé. Vous disposez d’un budget pour les erreurs qui, dans votre cas, n’est pas épuisé.
Qu'est-ce qu'on en fait. Nous l’utilisons pour littéralement tout. Pour les tests en conditions de production, pour le déploiement de nouvelles fonctionnalités pouvant affecter les performances, pour les versions, pour la maintenance, pour les temps d'arrêt planifiés. La règle inverse s'applique également : si le budget est épuisé, nous ne pouvons rien sortir de nouveau, sinon nous dépasserons le SLO. Le budget est déjà épuisé, nous avons libéré quelque chose si cela affecte négativement les performances, c'est-à-dire que s'il ne s'agit pas d'une sorte de correctif qui en soi augmente directement le SLO, alors nous allons au-delà du budget, et c'est une mauvaise situation , il doit être analysé post-mortem et éventuellement quelques correctifs de processus.
Autrement dit, il s'avère que si le service lui-même ne fonctionne pas bien et que le SLO est dépensé et que le budget n'est pas consacré à des expériences, ni à certaines versions, mais à lui-même, alors au lieu de quelques correctifs intéressants, au lieu de fonctionnalités intéressantes, au lieu de versions intéressantes. Au lieu de tout travail créatif, vous devrez faire face à des solutions stupides pour remettre de l'ordre dans le budget, ou modifier le SLO, et c'est aussi un processus qui ne devrait pas arriver trop souvent.
Il s'avère donc que dans une situation où nous avons plus de budget pour les erreurs, tout le monde est intéressé : aussi bien le SRE que les développeurs. Pour les développeurs, un budget important pour les bugs signifie que vous pouvez gérer les versions, les tests, les expérimentations. Pour les SRE, un budget pour les erreurs et la saisie de ce budget signifie qu'ils font directement bien leur travail. Et cela affecte la motivation d'une sorte de travail commun. Si vous écoutez vos SRE en tant que développeurs, vous disposerez de plus d'espace pour un bon travail et beaucoup moins de routine.
Il s'avère que les expériences en production constituent 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 de Netflix qui a publié un utilitaire appelé Chaos Monkey.
Chaos Monkey se connecte au pipeline CI/CD et plante de manière aléatoire 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, c'est attendu. Et si cela respecte le budget, c'est acceptable et ne nuit pas à l'entreprise. Bien sûr, Netflix dispose de suffisamment de serveurs redondants, de réplications suffisantes pour que tout cela puisse être corrigé, et pour que l'utilisateur dans son ensemble ne le remarque même pas, et plus encore, personne ne quitte un serveur pour n'importe quel budget.
Netflix disposait depuis un certain temps de toute une suite d'utilitaires de ce type, dont l'un, Chaos Gorilla, ferme complètement l'une des zones de disponibilité d'Amazon. Et de telles choses aident à révéler, premièrement, des dépendances cachées, quand on ne sait pas tout à fait ce qui affecte quoi, ce qui dépend de quoi. Et ceci, si vous travaillez avec un microservice et que la documentation n'est pas tout à fait parfaite, cela vous est peut-être familier. Et encore une fois, cela aide beaucoup à détecter les erreurs dans le code que vous ne pouvez pas détecter lors de la préparation, car toute préparation n'est pas exactement une simulation exacte, du fait que l'échelle de charge est différente, le modèle de charge est différent, l'équipement est différent. aussi, très probablement, autre. Les charges de pointe peuvent également être inattendues et imprévisibles. Et de tels tests, qui, encore une fois, ne dépassent pas le budget, aident très bien à détecter les erreurs dans l'infrastructure que la mise en scène, les autotests et le pipeline CI/CD ne détecteront jamais. Et tant que tout est inclus dans votre budget, peu importe que votre service soit tombé en panne là-bas, même si cela semble très effrayant, le serveur est tombé en panne, quel cauchemar. Non, c'est normal, c'est bien, ça aide à attraper les bugs. Si vous avez un budget, vous pouvez le dépenser.
Q : Quelle littérature puis-je recommander ? Liste à la fin. Il existe beaucoup de littérature, je conseillerai quelques rapports. Comment ça marche, et le SRE fonctionne-t-il dans les entreprises sans leur propre produit logiciel ou avec un minimum de développement. Par exemple, dans une entreprise dont l’activité principale n’est pas le logiciel. Dans une entreprise où l'activité principale n'est pas le logiciel, le SRE fonctionne exactement de la même manière que partout ailleurs, car dans une entreprise il faut aussi utiliser, même s'ils ne sont pas développés, des produits logiciels, il faut déployer des mises à jour, il faut changer l'infrastructure, vous devez vous développer, vous devez évoluer. Et les SRE aident à identifier et à prévoir les problèmes possibles dans ces processus et à les contrôler après le début d'une certaine croissance et l'évolution des besoins de l'entreprise. Car il n’est absolument pas nécessaire d’être impliqué dans le développement logiciel pour avoir un SRE si vous disposez d’au moins quelques serveurs et que l’on s’attend à ce qu’on ait au moins une certaine croissance.
Il en va de même pour les petits projets, les petites organisations, car les grandes entreprises ont le budget et l’espace pour expérimenter. Mais en même temps, tous ces fruits d'expérimentations peuvent être utilisés n'importe où, c'est-à-dire que SRE, bien sûr, est apparu dans Google, dans Netflix, dans Dropbox. Mais en même temps, les petites entreprises et les startups peuvent déjà lire des documents condensés, lire des livres, regarder des rapports. Ils commencent à en entendre parler plus souvent, ils regardent des exemples précis, je pense que ça va, ça peut vraiment être utile, on a besoin de ça aussi, c'est super.
Autrement dit, tout le travail principal de normalisation de ces processus a déjà été effectué pour vous. Il ne vous reste plus qu'à déterminer le rôle spécifique du SRE dans votre entreprise et à commencer à mettre en œuvre concrètement toutes ces pratiques, là encore déjà décrites. Autrement dit, à partir de principes utiles pour les petites entreprises, c'est toujours la définition de SLA, SLI, SLO. Si vous n'êtes pas impliqué dans le logiciel, il s'agira alors de SLA internes et de SLO internes, un budget interne pour les erreurs. Cela conduit presque toujours à des discussions intéressantes au sein de l'équipe et au sein de l'entreprise, car il se peut que vous dépensiez en infrastructure, en une sorte d'organisation de processus idéaux, le pipeline idéal est bien plus que nécessaire. Et ces 4 neuf que vous avez dans le service informatique, vous n'en avez plus vraiment besoin maintenant. Mais en même temps, vous pourriez consacrer du temps, dépenser le budget des erreurs sur autre chose.
Ainsi, le suivi et l'organisation du suivi sont utiles pour une entreprise de toute taille. Et en général, cette façon de penser, où les erreurs sont quelque chose d'acceptable, où il y a un budget, où il y a des objectifs, c'est encore une fois utile pour une entreprise de toute taille, à partir de startups pour 3 personnes.
La dernière nuance technique à aborder concerne la surveillance. Parce que si nous parlons de SLA, SLI, SLO, nous ne pouvons pas comprendre sans contrôler si nous nous intégrons dans le budget, si nous respectons nos objectifs et comment nous influençons le SLA final. J'ai vu tellement de fois que la surveillance se déroule comme ceci : il y a une certaine valeur, par exemple, l'heure d'une requête au serveur, la durée moyenne ou le nombre de requêtes à la base de données. Il a une norme déterminée par un ingénieur. Si la métrique s'écarte de la norme, un e-mail arrive. En règle générale, tout cela est absolument inutile, car cela conduit à une telle surabondance d'alertes, une surabondance de messages de surveillance, alors qu'une personne doit d'abord les interpréter à chaque fois, c'est-à-dire déterminer si la valeur de la métrique signifie la nécessité d'agir. Et deuxièmement, il cesse simplement de remarquer toutes ces alertes, alors qu'aucune action n'est requise de sa part. Il s’agit d’une bonne règle de surveillance et la toute première règle lors de la mise en œuvre du SRE est que la notification ne doit être effectuée que lorsqu’une action est requise.
Dans le cas standard, il existe 3 niveaux d'événements. Il y a des alertes, il y a des tickets, il y a des journaux. Les alertes sont tout ce qui nécessite que vous preniez des mesures immédiates. Autrement dit, tout est cassé, vous devez le réparer maintenant. Ce sont les tickets qui nécessitent une action différée. Oui, vous devez faire quelque chose, vous devez faire quelque chose manuellement, l'automatisation a échoué, mais vous n'êtes pas obligé de le faire pendant les prochaines minutes. Les journaux sont tout ce qui ne nécessite aucune action et, en général, si tout se passe bien, personne ne les lira jamais. Vous n'aurez besoin de lire les journaux que lorsque, rétrospectivement, il s'avérera que quelque chose s'est cassé depuis un certain temps, nous n'en savions pas. Ou avez-vous besoin de faire des recherches. Mais en général, tout ce qui ne nécessite aucune action est consigné dans les logs.
Comme effet secondaire de tout cela, si nous avons défini quels événements nécessitent des actions et avons bien décrit quelles devraient être ces actions, cela signifie que l'action peut être automatisée. Autrement dit, que se passe-t-il. On passe de l'alerte. Passons à l'action. Passons à la description de cette action. Et puis nous passons à l'automatisation. Autrement dit, toute automatisation commence par une réaction à un événement.
De la surveillance, nous passons à un terme appelé observabilité. Il y a également eu un peu de battage médiatique autour de ce mot ces dernières années. Et peu de gens comprennent ce que cela signifie hors contexte. Mais le point principal est que l’observabilité est une mesure de la transparence du système. Si quelque chose s’est mal passé, à quelle vitesse pouvez-vous déterminer exactement ce qui s’est passé et quel était l’état du système à ce moment-là. En termes de code : quelle fonction a échoué, quel service a échoué. Quel était l'état, par exemple, des variables internes, de la configuration. En termes d'infrastructure, il s'agit de la zone de disponibilité dans laquelle la panne s'est produite, et si vous disposez de Kubernetes, dans quel pod la panne s'est produite, quel était l'état du pod. Et par conséquent, l’observabilité a une relation directe avec MTTR. Plus l'observabilité du service est élevée, plus il est facile d'identifier l'erreur, plus il est facile de corriger l'erreur, plus il est facile d'automatiser l'erreur, plus le MTTR est bas.
Revenant aux petites entreprises, il est très courant de se demander, même aujourd'hui, comment gérer la taille de l'équipe et si une petite équipe doit embaucher un SRE distinct. J'en ai déjà parlé un peu plus tôt. Aux premières étapes de développement d'une startup ou, par exemple, d'une équipe, cela n'est pas du tout nécessaire, car le SRE peut jouer un rôle transitoire. Et cela va redynamiser un peu l'équipe, car il y a au moins une certaine diversité. De plus, cela préparera les gens au fait qu'avec la croissance, en général, les responsabilités du SRE changeront de manière très significative. Si vous embauchez une personne, elle a bien sûr certaines attentes. Et ces attentes ne changeront pas avec le temps, mais les exigences changeront beaucoup. Par conséquent, comment embaucher un SRE est assez difficile au début. Cultiver le vôtre est beaucoup plus facile. Mais cela vaut la peine d'y réfléchir.
La seule exception, peut-être, concerne les exigences de croissance très strictes et bien définies. Autrement dit, dans le cas d'une startup, il peut s'agir d'une sorte de pression de la part des investisseurs, d'une sorte de prévision de croissance plusieurs fois à la fois. Alors l’embauche d’un SRE est fondamentalement justifiée car elle peut être justifiée. Nous avons des exigences de croissance, nous avons besoin d'une personne qui sera responsable du fait qu'avec une telle croissance, rien ne se cassera.
Encore une question. Que faire lorsque les développeurs suppriment à plusieurs reprises une fonctionnalité qui réussit les tests, mais interrompt la production, charge la base, interrompt d'autres fonctionnalités, quel processus implémenter. Ainsi, dans ce cas, c'est le budget des erreurs qui est introduit. Et certains services, certaines fonctionnalités sont déjà testées en production. Cela peut être un canari, lorsqu'un petit nombre d'utilisateurs seulement, mais déjà en production, une fonctionnalité est déployée, mais déjà en espérant que si quelque chose tombe en panne, par exemple, pour un demi pour cent de tous les utilisateurs, elle répondra toujours aux exigences. budget pour les erreurs. En conséquence, oui, il y aura une erreur, pour certains utilisateurs, tout va se casser, mais nous avons déjà dit que c'était normal.
Une question a été posée sur les outils SRE. Autrement dit, y a-t-il quelque chose en particulier que les SRE utiliseraient et que tout le monde n'utiliserait pas. En fait, il existe des utilitaires hautement spécialisés, il existe une sorte de logiciel qui, par exemple, simule des charges ou effectue des tests A/B Canary. Mais fondamentalement, la boîte à outils SRE est ce que vos développeurs utilisent déjà. Parce que SRE interagit directement avec l’équipe de développement. Et si vous disposez d'outils différents, il s'avérera que la synchronisation prend du temps. Surtout si les SRE travaillent dans de grandes équipes, dans de grandes entreprises où il peut y avoir plusieurs équipes, c'est la standardisation à l'échelle de l'entreprise qui aidera ici beaucoup, car si 50 utilitaires différents sont utilisés dans 50 équipes, cela signifie que le SRE doit les connaître. tous. Et bien sûr, cela n’arrivera jamais. Et la qualité du travail, la qualité du contrôle d'au moins certaines équipes diminueront considérablement.
Notre webinaire touche à sa fin. J'ai réussi à dire quelques choses de base. Bien entendu, rien sur le SRE ne peut être raconté et compris en une heure. Mais j'espère avoir réussi à transmettre cette façon de penser, les principaux points clés. Et puis il sera possible, si vous êtes intéressé, d'approfondir le sujet, d'apprendre par vous-même, de voir comment il est mis en œuvre par d'autres personnes, dans d'autres entreprises. Et donc, début février, venez nous voir au Slurm SRE.
Le Slurm SRE est un cours intensif de trois jours qui parlera de ce dont je parle maintenant, mais avec beaucoup plus de profondeur, avec des cas réels, avec de la pratique, tout l'intensif est orienté vers des travaux pratiques. Les gens seront répartis en équipes. Vous travaillerez tous sur des cas réels. En conséquence, nous avons les instructeurs Booking.com Ivan Kruglov et Ben Tyler. Nous avons un merveilleux Eugene Barabbas de Google, de San Francisco. Et je vais te dire quelque chose aussi. Alors n'hésitez pas à nous rendre visite.
Donc, la bibliographie. Il existe des références sur SRE. sur le même livre, ou plutôt sur 2 livres sur le SRE, écrits par Google. Un autre , où les termes et leur application sont légèrement plus détaillés. Les 3 suivants sont des rapports sur le SRE dans différentes entreprises. D'abord - , c'est un discours de Ben Trainer de Google. Deuxième - . Le troisième est encore . Quatrième rapport de , qui ne compte que 5 collaborateurs clés SRE dans 190 pays. C'est très intéressant d'examiner tout cela, car tout comme DevOps signifie des choses très différentes selon les entreprises et même les équipes, le SRE a des responsabilités très différentes, même dans des entreprises de taille similaire.
2 liens supplémentaires sur les principes de l'ingénierie du chaos : , . Et à la fin il y a 3 listes de la série Awesome Lists sur , à propos de et environ . La liste sur SRE est incroyablement énorme, il n'est pas nécessaire de la parcourir en entier, il y a environ 200 articles. Je recommande fortement les articles sur la planification des capacités et sur le post-mortem irréprochable.
Article intéressant:
Merci de m'avoir écouté tout ce temps. J'espère que vous avez appris quelque chose. J'espère que vous disposez de suffisamment de matériel pour en apprendre encore plus. Et à bientôt. Espérons en février.
Le webinaire était animé par Eduard Medvedev.
PS : pour ceux qui aiment lire, Eduard a donné une liste de références. Ceux qui préfèrent comprendre par la pratique sont invités à .
Source: habr.com