Quels sont les signes et les signaux typiques d'une équipe DevOps en sous-effectif? Comment justifier / expliquer une demande de nouvel ajout à une équipe?

J'aimerais garder la question générique, mais voici quelques informations supplémentaires:

Nous avons actuellement 2 spécialistes DevOps travaillant ensemble en équipe, mais les demandes, la quantité et la complexité des produits augmentent. Nous pensons demander un nouvel ajout à l'équipe, mais avons quelques difficultés à expliquer et à prouver pourquoi ce serait une bonne idée.

Il y a quatre raisons principales pour lesquelles vous pouvez sentir que votre équipe manque de personnel:

1. Mauvaise organisation et planification du travail
2. Faire du travail que quelqu'un d'autre devrait faire
3. Faire un travail qui ne devrait pas être fait du tout
4. Être réellement en sous-effectif

Commencez par un examen des trois premiers points. Lisez le projet Phoenix pour savoir comment faire le premier. Demandez-vous pour chaque tâche avec laquelle vous aidez quelqu'un si cela doit être fait du tout et si c'est vous qui devriez faire la tâche ou si vous devez simplement permettre à quiconque en a besoin de le faire lui-même. Cela vous donnera une documentation sur la raison pour laquelle tout le travail que vous faites est nécessaire.

Revoyez ensuite les quatre types de travaux mentionnés dans le projet Phoenix:

1. Projets commerciaux - ce que vous faites pour les autres équipes de l'organisation
2. Projets internes - ce que vous faites pour faciliter votre travail à l'avenir
3. Entretien planifié - ce que vous faites pour garder les lumières allumées
4. Interruptions non planifiées - ce que vous faites parce que quelque chose s'est mal passé

Si le travail de votre équipe est durable, vous passerez à peu près le même temps sur chacun des quatre. Si le travail imprévu commence à grimper près de 50% de votre temps, c'est un signe que vous manquez de personnel.

Vous devriez être en mesure d'embaucher pour rester environ une personne avant que le travail imprévu n'atteigne 25% de votre temps, sinon, une personne qui quittera enverra toute votre équipe dans une situation difficile dont vous ne pourrez jamais vous remettre. Le surprovisionnement en personnel et en technologie a les mêmes raisons et avantages.

Contexte: En plus de fournir un soutien à notre infrastructure actuelle et à nos développeurs, nous faisons une planification mensuelle en tant qu'équipe DevOps pour ce que nous voulons accomplir en plus d'aider les équipes de développement dans les sprints et les nouveaux projets qui sont lancés. Cependant, au cours du mois, nous remarquons souvent des choses supplémentaires qui doivent être faites et améliorées, que nous ajoutons ensuite à notre carnet de commandes. Nous sommes également responsables et aidons à diverses autres choses qui dépassent notre portée, mais nous aidons l'entreprise si nous le pouvons :)

Réponse : Dès que vous remarquez que vous ne vous déplacez pas ou ne repoussez pas beaucoup de tâches, en particulier la maintenance, je pense que c'est un bon indicateur (d'après ce que j'ai vécu). De plus, plus il y a de nouveaux projets et d'équipes de développement qui viennent plus minces, plus l'équipe DevOps se répand, plus vous aurez besoin de personnes.

C'est super facile de se laisser prendre au quotidien pour accomplir des tâches, mais je pense qu'il est super important (même une fois par mois) de prendre du recul et d'évaluer cela.

Je prends en fait une page du manuel SRE sur celui-ci, qui je pense est très pertinent. Les spécialités DevOps ne sont pas destinées à croître horizontalement avec une organisation. Au contraire, si vous voyez que les choses ne se font pas, c'est un signal que vous n'autonomisez pas correctement les développeurs au libre-service.

Évaluez vos processus et voyez comment ils s'alignent sur les principes DevOps communément acceptés et dans quelle mesure vous suivez les meilleures pratiques de l'industrie.

Je suppose que cette équipe de deux va de projet en projet et y établit des trucs DevOps (création de pipelines CI / CD, prise en charge des autres développeurs créant Dockerfiles, ou quelle que soit la technologie que vous utilisez). En d'autres termes, tapez 3, 4, 5 ou 6 selon http://web.devopstopologies.com/ .

Dans ce cas, un signe de pénurie est tout simplement trop de charge de travail pour ces deux; trop de projets sollicitant leurs services; trop de billets; heures supplémentaires; le stress, l'épuisement professionnel. Ces facteurs devraient être des raisons suffisantes pour qu'un leadership responsable ajoute plus de capacité. Je ne vois pas de signe spécifique DevOps dans cela, c'est juste une fonction qui manque de personnel.

Un autre signe pour changer quelque chose est que si vous regardez bien et si vous remarquez que vous créez un "silo DevOps", dans lequel tout le savoir-faire DevOps est concentré dans ces deux gars / filles, et tout le monde se penche simplement en arrière parce que ces deux-là "font des DevOps". Ce n'est pas le but de DevOps. Si tel est le cas, réfléchissez à l'aspect culturel et modifiez-les pour qu'ils soient davantage évangélistes / enseignants / coachs pour les autres équipes.

Dans les deux cas, la raison profonde pour laquelle avoir DevOps en premier lieu est une bonne chose (les bonnes choses générales) devrait être claire pour la direction. Si vous ne pouvez pas faire passer ce message, réduisez le travail de votre équipe en le déplaçant sur les Devs / Ops ordinaires (comme cela devrait être le cas de toute façon).

J'avais l'impression que DevSecOps était un état d'esprit, pas une équipe - si vous avez une "équipe" Dev (Sec) Ops, vous vous trompez ... J'essaie de conclure en mettant deux "ingénieurs DevOps" ensemble et en les appelant une "équipe DevOps".

Nous avons des équipes de développement, SCM, Application Security et Systems Engineers qui travaillent tous en tandem pour un modèle de déploiement / publication rapide pour pousser le code et les modifications de configuration / système jusqu'à un point final donné - soit la production soit la production

Cela n'a rien à voir avec les ingénieurs "devOps" en tant que tels.

Regroupement de tâches

Une approche que nous avons utilisée dans le passé dans des situations similaires consiste à organiser le travail d'une équipe en 4 grands groupes de tâches et à allouer l'équivalent de 2 ETP (équivalents temps plein) pour (essayer) de terminer ces tâches. Dans notre cas, cela était lié à l'exécution d'un helpdesk SCM dans un environnement mainframe, avec environ 300 développeurs demandant toutes sortes d'aide / interventions de ces 2 ETP. Les groupes de tâches sont organisés en 4 priorités possibles:

• Les tâches de priorité 1 et 2 doivent être achevées (aucune excuse / négociation possible)
• Les tâches de priorité 3 doivent être achevées " dès que le temps le permet".
• Les tâches de priorité 4 doivent être exécutées " si le temps le permet".

Lisez la suite pour plus de détails sur le type de tâches dans chacun de ces 4 groupes ...

Descriptions des tâches

Priorité 1 - Faire fonctionner le helpdesk

• Par des experts facilement accessibles et toujours disponibles.
• Par téléphone, e-mail ou système de billetterie pendant les heures d'ouverture.
• Conforme aux SLA prédéfinis.
• Enregistrement basé sur ITIL de tous les appels du service d'assistance avec rapport périodique de tous les appels.
• Appliquez des personnalisations d'urgence (solutions de contournement) pour les problèmes critiques.

Priorité 2 - Surveillance des services de garde

• Disponibilité 24h / 24, 7j / 7 sur appel.
• Conforme aux SLA prédéfinis.
• Rapport de tous les appels de garde.
• Escalade de la gestion si nécessaire.

Priorité 3 - Maintenance de routine

• Administration.
• Embarquement de l'application.
• Entretien ménager.
• Améliorations des performances.
• Gestion de l'espace.
• Réglage de la consommation des ressources.
• Suggérer des améliorations pour les personnalisations afin de réduire le nombre d'appels au helpdesk et / ou de surveiller les interventions.

Priorité 4 - Corrections et améliorations

• Créez et mettez à jour la documentation utilisateur.
• Test QA de nouvelles personnalisations.
• Développer et implémenter des demandes d'amélioration.
• Participez aux tests DRP.

Évaluation

Si vous utilisez une approche telle que décrite ci-dessus, diverses choses peuvent (vont!) Commencer à se produire:

• Si l'équipe est en sous-effectif, la plupart du temps ira probablement aux tâches de priorité 1 et 2, tandis que cela peut prendre un certain temps pour obtenir les tâches de priorité 3 ... et les tâches de priorité 4 pourraient souffrir de la famine (il ne semble jamais y avoir de temps pour ces tâches).
• Plus il y a (devient) de temps disponible pour « investir » dans les tâches de priorité 4, plus le temps nécessaire pour les tâches de priorité 1 et 2 sera réduit, de sorte que davantage de temps (sur le budget disponible de 2 ETP) pourra être «investi» "dans les tâches de priorité 4.
• Vous serez étonné de voir comment, après un certain temps, le nombre de tâches de priorité 1 et 2 diminuera. Et si vous faites des rapports adéquats sur ces tâches, c'est quelque chose que la direction aime entendre. Dans notre cas, ce nombre est passé d'environ 300 / mois à moins de 100 / mois ...
• Si toutefois les 2 ETP semblent n'avoir jamais (ou presque) de temps pour les tâches de priorité 4, alors vous avez une explication parfaite et une preuve pour votre gestion ... que vous manquez de personnel.