Historiquement, il y a eu une tension naturelle entre les opérations (OPS) et les promoteurs. La Mission des OPS est de maintenir les systèmes stables et opérationnels. Pour la plupart des systèmes, si rien ne change avec le système, il aura tendance à se comporter comme il l'a fait dans le passé. Les développeurs, cependant, sont généralement incités à cultiver l'utilisation du système qui signifie, si bon ou mauvais, plus de fonctionnalités. Les nouvelles caractéristiques entraînent des changements rapides du système et un certain niveau d'instabilité et de risque est introduit dans le système. Ces incitations opposées créent une énorme tension entre les deux équipes. Il en résulte des opérations de suppression de l'accès aux machines et donc la liberté de faire quoi que ce soit opérations liées. Cela met fin à de nouvelles idées comme les micro-services au sein de l'organisation parce que l'infrastructure est toujours nécessaire pour mettre en place de nouveaux services et de nouvelles infrastructures nécessite une collaboration profonde avec une autre équipe. Cette tension n'est pas bonne et crée une division au sein de vos équipes d'ingénierie menant à aucun progrès étant fait parce que les deux équipes refusent de s'entraider. Cela ne fait pas que nuire à la productivité, mais en fin de compte le bonheur de vos employés et ils vont commencer à partir. Si j'ai appris quelque chose que mon mandat en tant que chef d'ingénierie, c'est ceci: Si vous voulez garder vos employés heureux, vous devez vous assurer qu'ils sont productifs. Happy signifie s'entendre avec d'autres équipes d'ingénierie et d'unification de la culture vs créer une division.

"Avec un grand pouvoir vient une grande responsabilité"

En tant qu'équipe, nous sommes tous responsables des logiciels que nous mettons en production, pas seulement les opérateurs ou les développeurs. Cela signifie que nous devons créer une structure d'incitation en place qui donne aux opérations et aux développeurs un objectif commun. Devops a de nombreuses significations pour différentes personnes, mais pour nous, ShareThiscela signifie qu'il y a un chevauchement important entre les domaines fonctionnels des opérations, du développement et de l'AQ. Ainsi, pour que les développeurs puissent obtenir le pouvoir de faire des changements en production, ils doivent être responsables de leurs actions. C'est pourquoi nous pensons qu'il est essentiel que les développeurs aient une rotation d'appel si quelque chose devait mal tourner. Les développeurs devraient faire l'expérience de ce que c'est que d'être alerté lorsque leur code cause des problèmes inattendus. Le fardeau de la résolution des problèmes en dehors des heures de travail est ainsi réparti sur l'ensemble de l'équipe et non pas seulement sur les épaules des opérations ou d'une seule équipe.

Allocation SLA et SLA

L'une des activités les plus importantes consiste à définir un SLA pour les services. Cela définit les attentes de stabilité dans un système pour les clients, les développeurs et les OPS. Mais l'objectif ne devrait jamais être d'avoir 100% de disponibilité, car il pourrait signifier que vous êtes en mouvement trop lent et ne pas prendre suffisamment de risques. Une startup est tout au sujet de prendre des risques calculés et se déplaçant rapidement. Pour être plus quantitative sur le risque, nous utilisons les allocations SLA. Nous pouvons calculer notre tolérance au risque en prenant l'ABOR et en soustrayant 1. Donc, si vous avez un 99,9% de disponibilité SLA nous pouvons calculer une allocation SLA par le suivant 1-0,999 = .001 qui est notre allocation SLA. Cela signifie que le site peut avoir 43m de temps d'arrêt avant d'avoir utilisé la disponibilité convenue. En utilisant cela, les développeurs peuvent déployer aussi souvent que désiré tant qu'ils ne frappent pas leurs allocations SLA. Une fois qu'ils le font, aucune nouvelle fonctionnalité ne peut être déployée et l'équipe doit plutôt se concentrer sur la stabilité. Cela met l'accent sur les tests automatisés et la surveillance pour vérifier que leurs applications ne causeront pas de problèmes dans la production. Cela met également en place un équilibre sain entre vitesse et tolérance au risque qui peut être convenu à l'avance. Tout au long du bureau, nous construisons des tableaux de bord qui peuvent rapidement afficher toutes les anomalies afin que nous puissions rétablir les modifications avant qu'elles ne provoquent des violations SLA.

Les résultats obtenus

Depuis que nous avons travaillé dans la culture "DevOps", nous avons vu une augmentation spectaculaire de la collaboration entre les équipes et aussi une augmentation de la productivité. La propriété totale des applications du développement à la production s'est propagée dans toute l'équipe et nous sommes maintenant en mesure d'obtenir des serveurs et l'infrastructure dans les secondes contre semaines. Pour nos clients, cela signifie de nouvelles fonctionnalités et la stabilité du service. Pour nos intervenants internes, cela signifie des échéanciers prévisibles. Plus important encore, pour notre équipe, ces changements leur donnent un sentiment de propriété et de productivité.

Si ce type d'environnement de travail est quelque chose que vous seriez intéressé s'il vous plaît visitez notre page opportunités:
https://sharethis.com/careers/