DevOps deixou de ser um diferencial para se tornar um requisito para o sucesso de uma organização. Mas você já pensou em como deve ser a organização de uma empresa que quer se tornar devops? Nós separamos para você os 11 processos que uma organização precisa ter para se tornar DevOps!
Para criar processos de fluxo contínuo, o JKK é o método mais eficaz para orientar o comportamento da equipe do DevOps.
JKK é uma maneira de trabalhar com qualidade, que significa:
- compreensão clara dos objetivos,
- compreensão da maneira correta de trabalhar,
- início do trabalho ideal para a conclusão de 100%
- mantimento da qualidade requerida, sem inspeções.
OS 11 PROCESSOS DEVOPS
DevOps
1- Estratégia e Planejamento de Negócios:
O serviço de TI precisa ter uma estreita relação com a estratégia de negócios e planejamento. O Service Master deve participar de sessões de planejamento de negócios e fazer recomendações sobre como obter vantagens comerciais de serviços de TI.
2- Marketing e vendas:
O Service Master deve discutir com o marketing como obter vantagens de serviços de TI. O Service Master identifica os clientes de serviços de TI, reúne os requisitos com valor comercial e concorda com um prazo.
3- Administração:
O Process Master concorda em como visualizar todo o processo. Um método é usar Obeya que pode ser configurado para todo o processo.
Obeya é uma sala de guerra que serve a dois propósitos – gerenciamento de informações e tomada de decisão no local. Existem muitas ferramentas de gerenciamento visual nele.
Os membros da equipe podem rapidamente ver onde estão em todos os aspectos do programa. Quando a equipe multifuncional trabalha em conjunto, o sistema Obeya permite uma tomada de decisões rápida e precisa, melhora a comunicação, mantém o alinhamento, acelera a coleta de informações e cria um senso importante de integração da equipe.
4- Planejamento de projetos:
O Service Master organiza o Escritório de Gerenciamento de Serviços (SMO) e define regras básicas para a equipe.
O Service Master cria a visão, meta e valor do projeto e, em seguida, reúne os membros da equipe DevOps. A infraestrutura de tempo de execução é definida nesta etapa. Um mapa de fluxo de valor de todo o processo é projetado.
5- Requisitos e Design:
- O Service Master define atrasos e prioridades do produto.
A equipe de DevOps usa os backlogs do produto para definir histórias (História do usuário, de Teste e da operação). A equipe também fica responsável por criar acordos de nível de serviço e de nível operacional.
O Engenheiro DevOps e a equipe de operações definem a infraestrutura de transição, teste e desenvolvimento. A equipe de Desenvolvimento também cria planos de liberação e iteração. O Gatekeeper estuda conformidade e requisitos regulatórios para os serviços de TI. E por fim, o Engenheiro de Confiabilidade define a metodologia de teste e casos de teste.
6- Desenvolvimento:
Scrum é a metodologia mais aplicável nesta fase. A equipe de desenvolvimento deve se comprometer a liberar planos e, em seguida, trabalhar usando a abordagem ágil disciplinado. O período de cada iteração (sprint) é acordado de acordo com a necessidade do negócio. Do ponto de vista da qualidade, as práticas de XP (Programação Extrema), como programação de pares, TDD, Refatoração, são eficazes.
7- Implantação:
Depois de completar a integração contínua, o processo automatizado começa para o teste de aceitação, teste de desempenho e implantação. O engenheiro DevOps deve construir o único pipeline de implantação automatizada como um fluxo de peça única.
O engenheiro de confiabilidade e o engenheiro do DevOps colaboram para melhorar o processo de teste. O gatekeeper monitora o progresso em todo o processo e faz a decisão go / no go sobre como entrar em ação. E a equipe de operações estuda como manter a continuidade dos negócios.
8 -Operação:
A equipe de operações é responsável por monitorar o status dos serviços de TI durante a operação usando o processo ITSM leve. Manter serviços vitais operacionais em caso de desastre é fundamental. A equipe deve envolver o engenheiro de confiabilidade e prestar atenção a dois parâmetros-chave, objetivo de ponto de recuperação e objetivo de tempo de recuperação.
9 - Manutenção:
O Service Master e o Engenheiro de confiabilidade decidem se devem ou não aprovar as atividades de manutenção. Se aprovado, eles são adicionados ao backlog do produto como solicitações de alteração.
10 - Serviço ao cliente:
O Service Master e Engenheiro de Confiabilidade são responsáveis pela coleta de feedback do cliente, tais como, problemas operacionais, incluindo a experiência do usuário e problemas de qualidade. Se aprovado, esses itens são adicionados ao backlog do produto como solicitações de alteração.
11 - Fim da vida:
O Service Master decide o fim da vida útil do serviço de TI, incluindo condições para quando e como isso acontecerá.
Os processos da sua empresa já são desenhados para a organização ser devops? Nós temos um outro artigo aqui “os 24 passos para a implantação devops” que pode te ajudar! Além disso somos experts no assunto, já fornecemos consultoria para grandes empresas se tornarem DevOps. Se desejar tornar a sua também, entre em contato e converse conosco!
Newsletter HNZ
Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!
Artigos relacionados:
