Embora as soluções PaaS (Platform as a Service) por si só não possam mudar a maneira como as interações individuais e em equipe ocorrem, muitas vezes elas atuam como um catalisador para mudanças organizacionais em resposta à maior flexibilidade das tecnologias de TI.
Na prática, o máximo retorno sobre o investimento em PaaS muitas vezes só é possível com a mudança dos papéis organizacionais, áreas de responsabilidade e esquemas de relacionamento. Felizmente, soluções PaaS, como a OpenShift Container Platform, possuem flexibilidade suficiente para que cada organização de TI possa determinar a velocidade e a escala das mudanças em relação às pessoas envolvidas e aos processos em andamento.
Na primeira fase da containerização empresarial, a prioridade principal é a implementação de uma plataforma de contêineres como um novo sistema de implantação de aplicativos. Nesse momento, as organizações vinculam tarefas conhecidas a papéis familiares para responder a solicitações padrão das equipes de desenvolvimento em questões como sistemas de armazenamento, ambientes de implantação e afins. Nas etapas subsequentes da containerização, a ênfase já está na automação ou na oferta de funcionalidades de autosserviço pelos desenvolvedores, com o objetivo de reduzir a carga sobre os administradores de sistema e elevar a autonomia e agilidade dos desenvolvedores. Assim, a organização começa a avançar em direção ao DevOps. Na fase final da containerização, a empresa chega a um modelo DevOps mais limpo e canônico, onde muitas das tarefas e trabalhos anteriores passam a ser controlados por equipes multifuncionais, que se agrupam não com base em plataformas ou tecnologias, mas sob a perspectiva de garantir o funcionamento de aplicativos ou serviços aplicacionais.
Neste post, apresentaremos um guia para realizar as mudanças organizacionais necessárias e explicaremos como os papéis tradicionais de TI mudam com a implementação de tecnologias de contêineres na empresa.
Vinculação de novas tarefas a papéis antigos
Na sua forma básica, o modelo organizacional PaaS é configurado para alocar recursos de TI para aplicações de forma mais flexível e ágil. Embora isso proporcione vantagens para os administradores de sistema, os desenvolvedores geralmente não recebem benefícios ou oportunidades significativas, pois nesta fase a empresa pode operar sem precisar iniciar a automação, implementar autoatendimento ou melhorar radicalmente o fluxo de implantação. Minimizar o impacto nos processos de desenvolvimento nesta fase, PaaS, no entanto, aumenta a dinamismo do sistema de TI, permitindo que os administradores atendam melhor às solicitações dos desenvolvedores. Por exemplo, se antes levar dias ou até semanas para criar um ambiente de desenvolvedor com várias máquinas virtuais e volumes de armazenamento, exigindo a participação de diversos administradores, no PaaS tudo é feito de forma muito mais rápida e com apenas um administrador. Em outras palavras, as equipes de desenvolvimento solicitam como antes, mas agora a execução dessas solicitações é realizada segundo um novo esquema.
Na jornada para uma organização DevOps
Ao implementar PaaS e transferir especialistas em operações de TI e desenvolvedores de aplicativos para ele, a organização pode continuar a adoção da metodologia DevOps, que entre outras coisas inclui os seguintes princípios fundamentais:
- Dividir o trabalho em etapas menores, para obter feedback nas fases iniciais, reduzir riscos e evitar a "paralisia analítica";
- Automatizar operações de forma adequada, para não criar obstáculos ou gargalos no processo de implantação da aplicação;
- O compartilhamento de conhecimento é a chave para construir confiança;
- Realmente pagar as dívidas técnicas, alocando tempo em cada ciclo de trabalho para melhorias sistemáticas.
Na segunda fase da implementação de tecnologias de contêineres, as equipes de desenvolvimento naturalmente começam a identificar oportunidades de melhorias, e a empresa tende a adotar um modelo DevOps mais canônico. O mecanismo tradicional de solicitação e execução de pedidos de manutenção é agora visto como um gargalo, portanto, a organização busca automatizar ações repetitivas e proporcionar aos desenvolvedores capacidades de autoatendimento. Além disso, essas capacidades dos desenvolvedores em cada solicitação são determinadas pelos esforços conjuntos dos profissionais de TI responsáveis pela operação das plataformas e aqueles encarregados da entrega de aplicativos. Em outras palavras, os administradores de sistemas que executavam ações a partir das solicitações dos desenvolvedores estão sendo substituídos pelas duas categorias mencionadas acima, que são responsáveis pela descrição e aplicação de políticas que regulam o que exatamente os desenvolvedores estão autorizados a fazer por conta própria. Os procedimentos automatizados ajudam a garantir que os requisitos especificados sejam cumpridos e a coordenar ações quando a situação ultrapassa as políticas em vigor.
A transição para um cronograma iterativo, onde o ambiente de TI e o modelo operacional passam por mudanças iterativas ao longo do tempo, é um marco crítico na formação de um sistema DevOps maduro dentro da empresa. O grau de adoção da metodologia DevOps depende da tolerância específica de cada organização a mudanças e de quais alterações proporcionam o maior benefício. Por exemplo, se a necessidade de criar novos ambientes ou aplicativos surgir com pouca frequência, a otimização das ações correspondentes será menos importante do que o fortalecimento do controle dos desenvolvedores sobre o ciclo de vida dos aplicativos.
Novas tarefas que surgem em organizações de TI ao migrar para OpenShift
Nesta seção, examinaremos os papéis e tarefas que as organizações que migraram para OpenShift geralmente aplicam para acelerar a automação e o autoatendimento utilizando tecnologias e PaaS.
A tabela abaixo lista as principais tarefas de alto nível que existem em qualquer organização que implementou o OpenShift, com exemplos de trabalhos e habilidades correspondentes. Esta lista de tarefas não deve ser confundida com um esquema de divisão de trabalho ou uma estrutura organizacional de equipes; é apenas um conjunto de tarefas que devem ser executadas por responsáveis pelo suporte ao ambiente de TI para uma implementação bem-sucedida da plataforma de containers. Na verdade, mostraremos que a implementação de tecnologias de containers cria as condições para a formação de uma estratégia DevOps mais madura na empresa, o que, por sua vez, aumenta o grau de multifuncionalidade das equipes e reduz os riscos de especialização excessiva tanto no nível de indivíduos quanto de equipes.
Tabela 1. Definições das tarefas OpenShift
Tarefas
Habilidades necessárias
Automação e preparação (provisionamento) de infraestruturas de TI
Trabalhos:
- Projetar e construir soluções de hardware
- Organizar e manter a automação da configuração inicial
- Projetar e automatizar a preparação de VMs e hosts
- Projetar e implementar data centers
- Administração de sistemas Linux
- Scripts de automação
- Conhecimento de sistemas de armazenamento
- Conhecimento em design e implementação de redes
- Segurança
Instalação e gerenciamento da plataforma OpenShift
Trabalhos:
- Realização da instalação do cluster
- Gerenciamento de serviços de infraestrutura
- Gerenciamento de escalabilidade da plataforma
- Verificação de autenticidade e autorização no nível da plataforma
- Administração de sistemas Linux
- Conhecimento em tecnologias de redes
- Scripts de automação (Ansible)
- Conhecimento de sistemas de armazenamento
- Conhecimento em tecnologias e arquiteturas de containers
- Conhecimento em arquiteturas Kubernetes e OpenShift
- Segurança das plataformas
- Integração de monitoramento
Gerenciamento de preparação de ambientes de clientes (provisionamento de inquilinos), isolamento com recursos de TI
Trabalhos:
- Criação de usuários e equipes na plataforma
- Projetar e gerenciar quotas
- Projetar e implementar RBAC
- Conhecimento em arquiteturas Kubernetes e OpenShift
- Conhecimento em tecnologias e arquiteturas de containers
- Scripts de automação
- Boas habilidades em projetos, quotas, vinculação de funções e trabalho com agendadores
Construir e gerenciar imagens base
Trabalhos:
- Desenvolver fluxo de trabalho para alteração de imagens
- Desenvolver imagens com base em padrões
- Administração de sistemas Linux
- Scripts de automação
- Configurar componentes de runtime de aplicações e middleware
- Conhecimento em arquiteturas de containers
- Frameworks de construção de aplicações
- Boas habilidades em imagens, imagestreams e templates
Design e gestão de pipelines de implantação
Trabalhos:
- Design e documentação de padrões de pipeline
- Desenvolvimento de guias e modelos resumidos
- Treinamento de desenvolvedores
- Gestão de código-fonte
- Design e implementação de aplicativos
- Scripts de automação
- Teste automatizado
- Teste de qualidade de código
- Conhecimento em arquiteturas de containers
- Conhecimento de infraestrutura imutável
- Segurança – gestão de acesso às etapas do pipeline, aprovação de fluxos de trabalho, etc.
- Bom conhecimento dos templates OpenShift, componentes buildconfigs, deploymentconfigs, services, routes, configmaps
Desenvolvimento de aplicativos e testes
Trabalhos:
- Codificação de aplicativos
- Desenvolvimento de testes automatizados
- Resposta a falhas de testes durante o pipeline de implantação
- Resposta a falhas de aplicativos
- Teste de aceitação do usuário
- Design e implementação de aplicativos
- Teste automatizado
- Gestão de código-fonte
- Monitoramento de aplicativos
- Conhecimento de arquiteturas de aplicativos nativos da nuvem (cloud native)
Monitoramento operacional e gestão de aplicativos
Trabalhos:
- Design de aplicativos no contexto de desempenho
- Monitoramento de aplicativos em tempo de execução
- Escalonamento de aplicativos (ou escalonamento automático)
- Gestão da disponibilidade de aplicativos
- Cotas de solicitações e limites de gestão de recursos
- Teste de desempenho e capacidade de TI
- Design e implementação de desempenho de aplicativos
- Monitoramento de desempenho de aplicativos
- Teste de desempenho e teste de carga
Teste de aceitação do usuário
Trabalhos:
- Teste de UI (design e interação com o usuário)
- Desenvolvimento de testes automatizados
- Design e verificação de interfaces do usuário
- Templates de testes automatizados
- Frameworks de Teste
- Templates de design de aplicativos
Novas funções que surgem na organização de TI durante a transição para OpenShift
À medida que as organizações adotam um modelo organizacional orientado a DevOps, tende-se a reduzir a especialização das funções, enquanto o número de equipes e funções multifuncionais cresce para maximizar a eficácia da colaboração. Aqui está, em nossa opinião, uma lista das principais funções em uma organização de TI que utiliza OpenShift:
- Engenheiro de operações de aplicativos (Application Operations Engineer) OU Engenheiro de confiabilidade do site (Site Reliability Engineer). Anteriormente, essa posição poderia ser chamada de 'Administrador de servidor de aplicativos'.
- Desenvolvedor de aplicativos/desenvolvedor de software/engenheiro de software.
- Administrador de cluster/plataforma de aplicativos. Anteriormente, esse papel poderia ser chamado de "Administrador de Sistemas" ou "Administrador de Plataformas Linux".
- Gerente de Lançamento de Software (Release Manager)/Engenheiro de Build (Build Engineer).
Matriz de papéis e responsabilidades RACI
Finalmente, chegamos à correspondência das posições e tarefas discutidas, para fornecer uma visão geral de como deve ser a estrutura organizacional que implementa DevOps na plataforma OpenShift. Inicialmente, os papéis abaixo indicados podem ser desempenhados por diferentes ramificações da antiga estrutura organizacional tradicional. Mas, com o tempo, ocorre a consolidação e surgem novas equipes organizadas em torno de aplicativos, que assumem a maioria ou até todas as tarefas indicadas abaixo.
Tarefas
Funções
Engenheiro de Operações de Aplicativos / Engenheiro de Confiabilidade do Site
Desenvolvedor de Aplicativos / Desenvolvedor de Software / Engenheiro de Programação
Administrador de cluster/plataforma de aplicativos
Gerente de Lançamento de Software / Engenheiro de Build
Automação e preparação (provisionamento) de infraestruturas de TI
I
I
R/A
C
Instalação e gerenciamento da plataforma OpenShift
C
I
R/A
C
Design e gestão de pipelines de implantação
C
C
I
R/A
Gerenciamento da preparação do ambiente do cliente (tenant provisioning), isolamento e recursos de TI
C
I
R/A
I
Construir e gerenciar imagens base
R
C
R/A
C
Desenvolvimento de aplicativos e testes
C
R/A
I
I
Monitoramento operacional e gestão de aplicativos
R/A
C
C
I
Teste de aceitação do usuário
C
R
I
I
Símbolos na matriz RACI
Fonte:
- Responsável – Executor – aquele que realiza o necessário para concluir a tarefa.
- Responsável – Responsável – funcionário que é, em última instância, responsável pela correta e atenta execução da tarefa ou alcance do resultado; e também o único que pode delegar o trabalho aos executores.
- Consultado – Consultores – geralmente, são especialistas na área em questão, cujo conselho é solicitado; mantém-se uma comunicação bilateral com eles.
- Informado – Informados – pessoas que são mantidas a par dos acontecimentos (e, às vezes, apenas no final da tarefa ou do resultado alcançado); recebem informações de forma unilateral.
Como funciona a colaboração das equipes em uma organização DevOps
O esquema tradicional de obtenção de recursos geralmente é um ciclo de solicitações de alocação de recursos, que são então atendidas por várias equipes. No final, todos os recursos necessários são alocados e confirmados pela parte solicitante. Muitas vezes, esses processos são parcialmente, se não totalmente, realizados manualmente e exigem frequentes e numerosas interações entre as equipes para o processamento bem-sucedido de cada solicitação.
Figura 1. Organização de TI tradicional
O diagrama acima ilustra as relações típicas entre as equipes em uma organização de TI tradicional. Dentro deste esquema, algumas equipes se comunicam com outras para solicitar a execução do trabalho necessário, utilizando meios de comunicação mais ou menos formalizados, como sistemas de tickets ou e-mail. Esses pedidos são então colocados em uma fila e aguardam sua vez, onde a longa espera muitas vezes leva ao pioramento, ou até mesmo ao agravamento das relações entre as equipes. A tensão é exacerbada pelo fato de que os membros de diferentes equipes raramente se encontram pessoalmente e, em geral, compartilham apenas as informações mínimas necessárias.
Figura 2. Organização de TI DevOps
Neste diagrama, está ilustrado como a colaboração é estruturada em uma organização DevOps. Aqui, as mesmas equipes do diagrama anterior abandonaram as comunicações ineficazes que exacerbavam a desconexão e as substituíram por contatos pessoais, criando assim canais permanentes de interação entre as equipes. Esses canais ajudam a formar um conjunto híbrido de habilidades que permite aos colaboradores entenderem melhor e representarem as necessidades, problemas e oportunidades das equipes que representam. As equipes possibilitam que os colegas realizem o trabalho necessário através de portais de autoatendimento automatizados, em vez de processar manualmente os pedidos de mudanças dos outros, como faziam antes. E, devido à presença desses canais de interação, esses sistemas de autoatendimento conseguem se adaptar rapidamente às necessidades das equipes para as quais foram criados. Para alcançar ainda mais entendimento e troca de conhecimento dentro da organização, os membros das equipes periodicamente realizam rotação de papéis para ganhar experiência de interação com diversas equipes e entender melhor o todo dos sistemas de TI que apoiam, assim elevando seu nível de interfuncionalidade e utilidade.
Resumindo
Neste post, discutimos como a implementação de soluções PaaS pode estimular uma organização a adotar a metodologia DevOps, onde durante esse processo as funções e responsabilidades tradicionais são adaptadas. Por isso, listamos as principais tarefas de TI que surgem em uma organização ao migrar para o OpenShift, além das habilidades necessárias para sua execução. Também apresentamos um conjunto básico de funções organizacionais que emergem na formação de equipes multifuncionais de DevOps e uma matriz RACI que conecta novos papéis com novas tarefas. Por fim, explicamos como a plataforma OpenShift e a metodologia DevOps associada podem transformar a estrutura organizacional de uma empresa ao passar de uma hierarquia tradicional e sistemas de gerenciamento de solicitações para equipes multifuncionais com um maior nível de comunicação pessoal.
Fonte: habr.com
