Quais são os sinais e sinais típicos de uma equipe de DevOps com falta de pessoal? Como você justificaria / explicaria uma solicitação para uma nova adição a uma equipe?

Gostaria muito de manter a pergunta genérica, mas aqui estão algumas informações adicionais:

Atualmente, temos dois especialistas em DevOps trabalhando juntos como uma equipe, mas as demandas, a quantidade e a complexidade dos produtos estão crescendo. Estamos pensando em solicitar uma nova adição à equipe, mas com algumas dificuldades para explicar e provar por que seria uma boa ideia.

Há quatro razões principais pelas quais você sente que sua equipe está com falta de pessoal:

1. Má organização e planejamento do trabalho
2. Fazendo o trabalho que outra pessoa deveria estar fazendo
3. Fazendo um trabalho que não deve ser feito de todo
4. Sendo realmente insuficiente

Comece com uma revisão dos três primeiros pontos. Leia o Phoenix Project sobre idéias de como fazer o primeiro. Pergunte a si mesmo todas as tarefas com as quais você ajuda alguém, se é que deve ser feito e se é você quem deve fazer a tarefa ou se deve simplesmente permitir que quem precisa seja feito para fazer sozinho. Isso fornecerá uma documentação sobre por que todo o trabalho que você faz é necessário.

Em seguida, revise os quatro tipos de trabalho mencionados no projeto Phoenix:

1. Projetos de negócios - o que você faz para outras equipes da organização
2. Projetos internos - o que você faz para facilitar seu trabalho no futuro
3. Manutenção programada - o que você faz para manter as luzes acesas
4. Interrupções não planejadas - o que você faz porque algo deu errado

Se o trabalho da sua equipe for sustentável, você gastará aproximadamente a mesma quantidade de tempo em cada um dos quatro. Se o trabalho não planejado começa a aumentar quase 50% do seu tempo, é um sinal de que você definitivamente está com falta de pessoal.

Você deve poder contratar para ficar cerca de uma pessoa à frente do trabalho não planejado, atingindo 25% do seu tempo, caso contrário, uma pessoa que sair enviará toda a sua equipe para uma situação em que você nunca se recuperará. O excesso de provisionamento de pessoas e tecnologia tem as mesmas razões e benefícios.

Histórico: Além de fornecer suporte à nossa infraestrutura atual e aos nossos Desenvolvedores, fazemos um planejamento mensal como uma equipe de DevOps para o que queremos realizar, além de ajudar as equipes de desenvolvimento nos sprints e nos novos projetos lançados. No entanto, durante o mês, geralmente observamos coisas extras que precisam ser feitas e aprimoradas, que depois adicionamos ao nosso backlog. Também somos responsáveis ​​e ajudamos com várias outras coisas que estão além do nosso escopo, mas ajudamos os negócios onde pudermos :)

Resposta : Assim que você perceber que não está cumprindo ou adiando muitas tarefas, principalmente a manutenção, acho que é um bom indicador (pelo que experimentei). Além disso, quanto mais novos projetos e equipes de desenvolvimento surgirem, mais fina a equipe de DevOps se espalhará, mais pessoas serão necessárias.

É super fácil apenas ser pego no dia a dia executando tarefas, mas acredito que é super importante (mesmo uma vez por mês) dar um passo atrás e avaliar isso.

Na verdade, pego uma página do Manual do SRE sobre esta, que acho muito relevante. As especialidades do DevOps não devem crescer horizontalmente com uma organização. Em vez disso, se você perceber que as coisas não estão sendo feitas, é um sinal de que não está capacitando adequadamente os desenvolvedores para o autoatendimento.

Avalie seus processos e veja como eles se alinham aos Princípios de DevOps comumente aceitos e quão bem você está seguindo as melhores práticas do setor.

Suponho que essa equipe de dois esteja indo de um projeto para outro e estabelecendo coisas para o DevOps (criando pipelines de CI / CD, dando suporte aos outros desenvolvedores que criam Dockerfiles ou qualquer tecnologia que você esteja usando). Em outras palavras, digite 3, 4, 5 ou 6 conforme http://web.devopstopologies.com/ .

Nesse caso, um sinal de falta é simplesmente muita carga de trabalho para esses dois; muitos projetos solicitando seus serviços; muitos ingressos; hora extra; estresse, esgotamento. Esses fatores devem ser razões suficientes para uma liderança responsável adicionar mais capacidade. Não vejo um sinal específico do DevOps nisso, é apenas uma função com falta de pessoal.

Outro sinal para mudar alguma coisa é se você der uma boa olhada e perceber que está criando um "silo do DevOps", no qual todo o conhecimento do DevOps está concentrado nesses dois caras / moças, e todo mundo simplesmente se inclina para trás porque esses dois estão "fazendo DevOps". Esse não é o objetivo do DevOps. Se for esse o caso, pense no aspecto cultural e modifique-o para ser mais evangelistas / professores / treinadores para as outras equipes.

Nos dois casos, o motivo mais profundo pelo qual ter DevOps em primeiro lugar é uma coisa boa (o Good Stuff geral) deve ficar claro para a alta gerência. Se você não conseguir transmitir essa mensagem, reduza o trabalho que sua equipe está fazendo, deslocando-o para os Devs / Ops regulares (como deve ser o caso, de qualquer maneira).

Fiquei com a impressão de que o DevSecOps era uma mentalidade, não uma equipe - se você tem um "time" de Dev (Sec) Ops, está fazendo errado ... Estou tentando entender o que é colocar dois "DevOps Engineers" juntos e chamando-os de "Equipe do DevOps".

Temos equipes de desenvolvimento, SCM, engenheiros de segurança e sistemas de aplicativos, todos trabalhando em conjunto para um rápido modelo de implantação / liberação, para levar as alterações de código e configuração / sistema a um determinado ponto final - preparação ou produção

Isso não tem nada a ver com nenhum engenheiro de "devOps", como tal.

Agrupamento de tarefas

Uma abordagem que usamos no passado em situações semelhantes é organizar o trabalho de uma equipe em 4 grupos principais de tarefas e alocar o equivalente a 2 ETI (Equivalentes em Tempo Integral) para (tentar) concluir essas tarefas. No nosso caso, estava relacionado à execução de um serviço de assistência do SCM em um ambiente de mainframe, com cerca de 300 desenvolvedores solicitando todos os tipos de ajuda / intervenções desses dois FTEs. Os grupos de tarefas estão organizados em 4 prioridades possíveis:

• As tarefas das Prioridades 1 e 2 devem ser concluídas (sem desculpas / negociações possíveis)
• As tarefas de prioridade 3 devem ser concluídas " assim que o tempo permitir".
• As tarefas de prioridade 4 devem ser concluídas " se o tempo permitir".

Continue lendo para obter mais detalhes sobre o tipo de tarefas em cada um desses 4 grupos ...

Descrições de tarefas

Prioridade 1 - Operar o suporte técnico

• Por especialistas que são facilmente acessíveis e sempre disponíveis.
• Via telefone, e-mail ou sistema de emissão de bilhetes durante o horário comercial.
• Compatível com SLAs predefinidos.
• Registro baseado em ITIL de todas as chamadas do suporte técnico com relatórios periódicos de todas as chamadas.
• Aplique personalizações de emergência (soluções alternativas) para problemas críticos.

Prioridade 2 - Serviços de serviço de vigilância

• Disponibilidade 24 horas por dia, 7 dias por semana.
• Compatível com SLAs predefinidos.
• Relatórios de todas as chamadas de serviço de vigilância.
• Escalada de gerenciamento onde necessário.

Prioridade 3 - Manutenção de rotina

• Administração.
• Embarque de aplicativo.
• Serviço de limpeza.
• Aprimoramentos de desempenho.
• Gerenciamento de espaço.
• Ajuste do consumo de recursos.
• Sugira aprimoramentos para personalizações para reduzir o número de chamadas para o suporte técnico e / ou assistir a intervenções de serviço.

Prioridade 4 - Correções e aprimoramentos

• Crie e mantenha a documentação do usuário.
• Teste de controle de qualidade de novas personalizações.
• Desenvolver e implementar solicitações de aprimoramento.
• Participe dos testes DRP.

Avaliação

Se você estiver usando uma abordagem conforme descrito acima, várias coisas podem (vão!) Começar a acontecer:

• Se a equipe tiver falta de pessoal, provavelmente a maior parte do tempo passará para as tarefas de prioridade 1 e 2, enquanto pode demorar um pouco para obter as tarefas de prioridade 3 ... e as tarefas de prioridade 4 podem sofrer fome (parece que nunca há tempo para essas tarefas).
• Quanto mais (se torna) tempo disponível para " investir " em tarefas de prioridade 4, mais tempo é necessário para as tarefas de prioridade 1 e 2 serão reduzidas, de modo que ainda mais tempo (do orçamento disponível de 2 ETI) possa ser "investido "nas tarefas de prioridade 4.
• Você ficará surpreso ao ver como, depois de um tempo, o número de tarefas de prioridade 1 e 2 diminuirá. E se você gerar relatórios adequados sobre essas tarefas, isso é algo que a gerência adora ouvir. No nosso caso, esse número caiu de cerca de 300 / mês para menos de 100 / mês ...
• Se, no entanto, os 2 ETIs parecem nunca (ou dificilmente) têm tempo para as tarefas de prioridade 4, então você tem uma explicação e uma prova perfeitas para sua gerência ... de que está com falta de pessoal.