Heureusement, étant donné que Site Reliability Engineering s'est développé en interne chez Google et n'a commencé que récemment à faire son chemin dans la communauté au sens large, il est assez bien défini. Ce qui n'est pas , cependant, ce sont les opérations Web (ou «administration des systèmes» - comme exemple du manque de clarté, vous utilisez les deux dans votre question). Il est difficile de discuter des différences entre deux choses lorsque vous n'êtes pas tout à fait sûr de ce que c'est.
Mais je suis un gars aventureux, donc je vais essayer.
Dans les magasins très traditionnels, les développeurs et les administrateurs système sont très cloisonnés les uns des autres. Les développeurs créent une application, puis considèrent que leur travail est terminé dès que leur code a été validé. Les administrateurs système prennent les artefacts de génération (qui peuvent être uniquement le code, s'il s'agit d'un langage interprété) et les déploient sur les serveurs de production. C'est le travail des administrateurs système de maintenir le bon fonctionnement de l'application et, en général, de gérer l'environnement de production. Cependant, les problèmes de performances proviennent souvent de problèmes d'architecture dans l'application; les administrateurs système n'ont pas les connaissances en programmation pour savoir ce que fait l'application, et les développeurs ne savent pas comment l'application agit dans la topologie de production avec le trafic de production, donc personne n'est équipé par eux-mêmes pour résoudre le problème.
De plus, les développeurs sont généralement jugés sur la rapidité avec laquelle ils peuvent produire de nouvelles fonctionnalités, tandis que les administrateurs système sont jugés sur la fréquence à laquelle l'application interrompt la production. Étant donné que le changement est l'une des principales causes de rupture, cela met les deux départements en désaccord - une ancienne rivalité qui nuit à l'entreprise et aux personnes impliquées.
À un moment donné, certaines entreprises axées sur les développeurs se sont tellement ennuyées par cela qu'elles ont commencé à pratiquer les "NoOps" - elles ont supprimé leurs services d'exploitation et les obstacles perçus qui les accompagnaient. En réalité, cela signifiait que les développeurs assumaient des rôles d'exploitation, mais conservaient leurs anciens titres.
Dans une discussion autour de NoOps , John Allspaw, alors vice-président des opérations techniques chez Etsy et éditeur du livre Web Operations très respecté , a défini les rôles chez Etsy de cette façon:
Etsy Operations est responsable de:
- Répondre aux pannes, prend sur appel
- Systèmes d'alerte seuillage, conception
- Conception et révision de l'architecture
- Création d'une collection de métriques
- Configuration d'application
- Construction / gestion de l'infrastructure
Etsy Development est responsable de:
- Répondre aux pannes, prend sur appel
- Systèmes d'alerte seuillage, conception
- Conception et révision de l'architecture
- Création d'une collection de métriques
- Configuration d'application
- Expédition de code accessible au public
Aucune de ces listes n'est exhaustive, je suis sûr qu'il me manque quelque chose. Bien que Etsy Ops ait apporté des modifications aux applications de production, elles sont rares mais réelles (et parfois assez profondes). Bien qu'Etsy Dev apporte des changements au chef, ils sont peu nombreux mais réels. S'il y a tellement de chevauchements dans les responsabilités, pourquoi la différence, vous demandez-vous? Expertise et antécédents du domaine. Peu de développeurs ont une connaissance approfondie du fonctionnement du démarrage lent TCP, contrairement à Ops. Peu d'Ops ont une connaissance approfondie des algorithmes de tri ou de pertinence, contrairement à Dev. Ops a des années d'expérience dans la prévision rapide de l'utilisation des ressources avec une précision acceptable, contrairement à Dev. Dev peut ne pas être conscient des avantages et des inconvénients de la distribution des options de charge de travail sur toutes les couches 1 à 7, peut-être seulement à 7 heures, Ops le fait. La modélisation des relations d'entité peut être naturelle pour un développeur, pas pour les opérations. En fin de compte, ils découvrent tous deux des solutions à diverses formes de scénarios de défaillance byzantins et de modèles de résilience, à tous les niveaux et à toutes les couches.
Dans son monde, les développeurs et les ingénieurs opérationnels avaient des compétences et des responsabilités de haut niveau très similaires; où ils différaient était dans leur expertise. Leurs spécialités différentes les ont encouragés à travailler ensemble pour résoudre des problèmes, et leurs compétences communes au niveau de base leur ont donné une langue pour le faire.
Il s'agit généralement de la définition des opérations Web sur laquelle j'atterris dans la plupart des cas. C'est donc celle avec laquelle nous allons continuer.
Alors, quelle est l'ingénierie de fiabilité du site?
Le livre Google SRE s'ouvre avec une définition de SRE ... puis une autre ... et passe ensuite un chapitre en continuant à définir le rôle et un livre entier couvrant les spécificités. Même lorsqu'il est développé dans une seule organisation, il semble qu'il soit difficile de condenser le travail à une seule définition convenue.
Pour commencer, nous devons remonter à 2003, lorsque Ben Traynor a rejoint Google et a fondé ce qui allait devenir la première équipe d'ingénierie de fiabilité de site. Rappelons qu'il y a quelques paragraphes, nous étions au début des années 2010; mais en 2003, l'industrie était encore assez encline à diviser sysadmin / développeur comme la voie naturelle des choses. Donc, quand Ben dit que SRE était ce qui se passerait si un ingénieur logiciel créait une équipe d'exploitation, c'était une fusion beaucoup plus radicale des deux mondes qu'il n'y paraît maintenant.
La définition donnée dans la préface met l'accent sur chacun des trois mots individuellement:
- Génie - l'utilisation de concepts informatiques et d'ingénierie pour résoudre des problèmes
- Fiabilité - une priorité pour rendre les systèmes plus évolutifs, plus fiables et plus efficaces
- Service - l'évolution ultérieure du "site", soulignant que les SRE sont responsables des services en réseau
Le chapitre d'introduction répertorie les principes de l'ingénierie de fiabilité des sites comme suit:
- Assurer une concentration durable sur l'ingénierie - prendre des mesures préventives pour éviter les pages fréquentes et autres "travaux"
- Persistance de la vitesse de changement maximale sans violer le SLO d'un service - un sujet qui peut facilement avoir sa propre réponse de plusieurs centaines de mots, mais qui se résume en gros à aider les développeurs à apporter des modifications, à condition qu'ils ne causent pas trop de problèmes
- Surveillance - alertes automatiques en cas de problème
- Réponse d'urgence - réparer les choses quand elles sont cassées
- Gestion du changement
- Planification des capacités
- Provisioning
- Efficacité et performances - garantir qu'un service fonctionne au niveau attendu - les goulots d'étranglement nuisent aux utilisateurs, mais la capacité excédentaire coûte de l'argent
Je classerais l'ingénierie de fiabilité de site comme un sous-ensemble spécialisé des opérations Web modernes. Une organisation SRE se concentre fortement sur l'automatisation de tout , à un degré qui n'est rentable que dans des entreprises assez grandes. Des idées comme les budgets d'erreur ne peuvent fonctionner que lorsque votre service a de très nombreuses demandes, sinon vous perdez de la granularité (pour un service plus petit, une erreur particulière peut affecter 0 à 20% de vos demandes, selon la minute). Des domaines connexes comme la sécurité sont absents de la définition du SRE, car les entreprises suffisamment grandes pour disposer de véritables équipes SRE ont des équipes dédiées à la sécurité.
Le programme SRE, tel que défini par Google, est des opérations Web développées pour les besoins spécifiques de Google, et pas nécessairement applicables ailleurs.
Cependant, l'ingénierie de fiabilité du site s'est récemment développée dans une utilisation plus large de l'industrie. Mon titre de poste actuel est un SRE, même si je travaille dans une entreprise beaucoup plus petite et que ma description de poste correspond assez bien à la définition d'opérations Web Etsy 2012 de John Allspaw. Ma théorie est que nous avons progressé à travers les titres comme raccourci pour épouser l'évolution d'un seul domaine:
- Nous avons commencé comme administrateurs système .
- Puis, à mesure que les sites Web devenaient de plus en plus une «chose», les offres d'emploi ont commencé à se référer aux ingénieurs des opérations Web pour distinguer les administrateurs système spécialisés dans le Web de ceux qui s'occupaient également de l'informatique de bureau générale.
- Ensuite, DevOps était censé séparer ceux qui étaient à l'aise avec la programmation pour réduire la charge de travail de leurs opérations Web.
- Mais alors que DevOps était embrouillé par l'absence d'une définition claire , nous avons adopté l' ingénierie de fiabilité du site pour spécifier que nous recherchons des personnes qui sont sur appel pour soutenir les services de production.
Quelle est donc la différence entre un administrateur système et un SRE? L'année où ils ont reçu leur titre. Quelle est la différence entre les opérations traditionnelles et l'ingénierie de fiabilité du site? Le SRE n'est que l'incarnation actuelle des opérations, utilisant de nouveaux outils (bonjour, conteneurs!) Et, à mesure que les programmes en réseau continuent de devenir plus importants et plus importants, une concentration accrue sur les pratiques qui permettent à un ingénieur d'en faire plus .
