Get best of the week

Como o OpenShift está mudando a estrutura organizacional de uma organização de TI. A evolução dos modelos organizacionais ao mudar para PaaS

Embora as soluções de PaaS (plataforma como serviço) sozinhas não sejam capazes de mudar os modos de interação individual e de equipe, elas costumam servir como catalisador da mudança organizacional em resposta à maior flexibilidade das tecnologias de TI.



De fato, o retorno máximo do investimento em PaaS geralmente é possível apenas se as funções organizacionais, as áreas de responsabilidade (tarefas) e os relacionamentos forem alterados. Felizmente, as soluções PaaS, como a OpenShift Container Platform, são flexíveis o suficiente para que cada organização de TI possa determinar independentemente a velocidade e a extensão da mudança em relação às pessoas envolvidas e aos processos que estão ocorrendo.

No primeiro estágio da conteinerização corporativa, a principal prioridade é a implementação da plataforma de contêiner como um novo sistema de implantação de aplicativos. Nesse ponto, as organizações vinculam tarefas familiares a funções familiares para responder às solicitações padrão das equipes de desenvolvimento em questões como sistemas de armazenamento, ambientes de implantação e muito mais. Nos estágios subsequentes da conteinerização, já estamos falando sobre automação ou fornecendo aos desenvolvedores recursos de autoatendimento, a fim de reduzir a carga sobre os administradores de sistema e trazer a autonomia e a eficiência dos desenvolvedores para um nível superior. É assim que a organização começa a avançar para o DevOps. No estágio final da conteinerização da empresa, trata-se de um modelo DevOps mais limpo e canônico,na estrutura em que muitas das tarefas e trabalhos anteriores ficam sob o controle de equipes multifuncionais, agrupadas não com base em plataformas ou tecnologias, mas do ponto de vista de garantir a operação de aplicativos ou serviços de aplicativos.

Nesta publicação, forneceremos orientações sobre as mudanças organizacionais necessárias e descreveremos como as funções tradicionais de TI estão mudando com a introdução da tecnologia de contêineres na empresa.

Vinculando novos trabalhos a funções antigas


Na sua forma básica inicial, o modelo organizacional PaaS é formado para alocar de maneira mais flexível e eficiente os recursos de TI para aplicativos como um ambiente de tempo de execução. E, embora isso dê certas vantagens aos administradores de sistema, os desenvolvedores aqui, em regra, não recebem benefícios significativos e novas oportunidades, pois nesse estágio a empresa pode muito bem sem iniciar a automação, introduzir autoatendimento ou melhorar radicalmente o pipeline de implantação. Afetando minimamente os processos de desenvolvimento nesse estágio, o PaaS aumenta o dinamismo do sistema de TI, o que permite aos administradores atender melhor às solicitações dos desenvolvedores. Por exemplo, se mais cedo poderia levar dias ou até semanas para criar um ambiente de desenvolvimento a partir de várias máquinas virtuais e volumes de armazenamento,e exigiu a participação de vários administradores diferentes; em PaaS, tudo é feito muito mais rapidamente e com a ajuda de apenas um administrador. Em outras palavras, as equipes de desenvolvimento enviam aplicativos como antes, mas o trabalho de implementação desses aplicativos já está sendo realizado de acordo com o novo esquema.

Rumo a uma organização DevOps


Ao iniciar o PaaS e transferir especialistas em operação de sistemas de TI e desenvolvedores de aplicativos, a organização pode continuar implementando a metodologia DevOps, que, entre outros, inclui os seguintes princípios básicos:

  • Divida o trabalho em pequenos estágios para obter feedback nos estágios iniciais, reduzir riscos e evitar "paralisia analítica";
  • Automatize as operações o suficiente para não criar obstáculos ou gargalos no processo de implantação do aplicativo;
  • Compartilhar conhecimento é a chave para criar confiança;
  • Pague regularmente dívidas técnicas , alocando uma certa quantidade de tempo em cada ciclo de trabalho para melhorias sistemáticas.

No segundo estágio da implementação de tecnologias de contêiner, as equipes de desenvolvimento naturalmente começam a ver oportunidades de melhoria, e a empresa está se inclinando para um modelo DevOps mais canônico. O mecanismo tradicional de envio e execução de solicitações de serviço agora é percebido como um gargalo, portanto a organização procura automatizar ações repetitivas e fornecer aos desenvolvedores recursos de autoatendimento. Além disso, esses recursos dos desenvolvedores na estrutura de um aplicativo específico são determinados pelos esforços conjuntos de especialistas em TI na operação de plataformas e dos responsáveis ​​pelo fornecimento de aplicativos. Em outras palavras, os administradores de sistema que executam ações a pedido dos desenvolvedores estão sendo substituídos pelas duas categorias de funcionários acima, responsáveis ​​pela descrição e aplicação das políticas que regemo que exatamente os desenvolvedores têm permissão para fazer por conta própria. Os procedimentos automatizados ajudam a garantir a conformidade com esses requisitos e coordenam as ações nos casos em que a situação vai além do escopo das políticas existentes.

Mudar para uma linha do tempo iterativa na qual o ambiente de TI e o modelo operacional passam por mudanças iterativas ao longo do tempo é um marco crítico em termos de construção de um sistema DevOps maduro na empresa. O grau de adoção da metodologia DevOps depende da tolerância de cada organização em particular a mudar e de quais mudanças são mais benéficas. Por exemplo, se a necessidade de criar novos ambientes ou aplicativos surgir com pouca frequência, otimizar as ações apropriadas será menos importante do que fortalecer o controle dos desenvolvedores durante o ciclo de vida do aplicativo.

Novos desafios que as organizações de TI enfrentam ao migrar para o OpenShift


Nesta seção, examinaremos as funções e tarefas que as organizações que mudaram para o OpenShift normalmente usam para acelerar a automação e o autoatendimento usando a tecnologia e o PaaS.

A tabela abaixo lista as principais tarefas de nível superior existentes em qualquer organização que implementou o OpenShift, com exemplos de trabalho e habilidades relevantes. Essa lista de tarefas não deve ser confundida com o esquema de compartilhamento de trabalho ou a estrutura organizacional das equipes; este é apenas um conjunto de tarefas que devem ser encerradas pelos responsáveis ​​pelo suporte ao (s) ambiente (s) de TI para a implementação bem-sucedida da plataforma de contêiner. De fato, mostraremos ainda que a implementação de tecnologias de contêiner cria os pré-requisitos para a formação de uma estratégia de DevOps mais madura na empresa, o que, por sua vez, aumenta o grau de funcionalidade cruzada das equipes e reduz os riscos de uma especialização restrita no nível de funcionários e equipes individuais.

Tabela 1. Definições da tarefa OpenShift
TarefasHabilidades necessárias
(provisioning) -

:

  • -
  • Linux

OpenShift

:

  • Linux
  • (Ansible)
  • Kubernetes OpenShift

(tenant provisioning), -

:
  • RBAC

  • Kubernetes OpenShift
  • , ,



:

  • Linux
  • runtime- middleware
  • (application build frameworks)
  • , imagestream



:

  • immutable
  • – , . .
  • OpenShift, buildconfigs, deploymentconfigs, services, routes, configmaps



:

  • (cloud native)



:
  • ( )
  • -




:
  • UI ( )

  • Estruturas de teste
  • Modelos de Design de Aplicativo


Novas funções que surgem nas organizações de TI ao migrar para o OpenShift


À medida que você passa para um modelo organizacional baseado em DevOps, o número de especializações de função tende a diminuir e o número de equipes e funções multifuncionais, por sua vez, aumenta para maximizar a eficiência da colaboração. Aqui, em nossa opinião, está a lista de posições-chave em uma organização de TI usando o OpenShift:

  • Engenheiro de operações de aplicativos OU Engenheiro de confiabilidade do local. Anteriormente, essa posição poderia ser chamada de "Administrador do servidor de aplicativos".
  • Desenvolvedor de aplicativos / Desenvolvedor de software / Engenheiro de software.
  • Administrador de Cluster / Application Platform. Anteriormente, essa função poderia ser chamada de "Administrador do sistema" ou "Administrador da plataforma Linux".
  • Gerente de Liberação de Software (Engenheiro de Construção).

Função RACI e matriz de tarefas


Finalmente, passamos a comparar as posições e tarefas discutidas acima para fornecer uma idéia geral de como deve ser a estrutura de uma organização que implementa o DevOps na plataforma OpenShift. Inicialmente, as seguintes funções podem ser desempenhadas por diferentes ramos da estrutura organizacional tradicional e antiga. Porém, com o tempo, consolidações e novas equipes, criadas em torno de aplicativos, surgem e fecham quase todas ou até todas as tarefas abaixo.

TarefasFunções
Engenheiro de Operações de Aplicação / Engenheiro de Confiabilidade do SiteDesenvolvedor de aplicativos / Desenvolvedor de software / Engenheiro de softwareAdministrador de cluster / plataforma de aplicativosGerente de liberação de software / engenheiro de montagem
Automação e provisionamento de infra-estruturas de TIEuEuR / aC
Instalando e gerenciando a plataforma OpenShiftCEuR / aC
Projetar e gerenciar pipelines de implantaçãoCCEuR / a
Gerenciar provisionamento, isolamento e recursos de TI do inquilinoCEuR / aEu
Construa e gerencie imagens básicasRCR / aC
Desenvolvimento de aplicativos e testesCR / aEuEu
Monitoramento operacional e gerenciamento de aplicativosR / aCCEu
Teste de aceitação personalizadaCREuEu

Convenções na matriz RACI
Fonte: Wikipedia

  • Responsável - Um executor é aquele que faz o necessário para concluir uma tarefa.
  • Accountable – – , ; , .
  • Consulted – – , , ; .
  • Informed – – , (, ); .

DevOps-


O esquema tradicional para obter recursos, como regra, é uma série de solicitações de alocação de recursos, que são executadas por vários comandos. Por fim, todos os recursos necessários são alocados e confirmados pelo solicitante. Freqüentemente, esses processos são realizados parcial ou totalmente por meio manual e requerem interações frequentes e numerosas entre as equipes para processar com êxito cada solicitação.

Figura 1. Organização de TI tradicional



O diagrama acima ilustra os relacionamentos típicos entre equipes em uma organização tradicional de TI. Como parte desse esquema, algumas equipes recorrem a outras equipes com uma solicitação para executar o trabalho necessário usando meios de comunicação mais ou menos formalizados, como um sistema de ticket ou email. Então, esses pedidos caem na fila e esperam nos bastidores, e uma longa espera muitas vezes leva à deterioração e até ao agravamento das relações entre as equipes. A tensão é exacerbada pelo fato de que membros de equipes diferentes raramente se encontram pessoalmente e, em regra, compartilham apenas as informações mínimas necessárias.

Figura 2. Organização de TI do DevOps



Este diagrama mostra como a colaboração funciona em uma organização do DevOps. Aqui, as mesmas equipes do diagrama anterior abandonaram as comunicações ineficientes, o que aumentou a desunião e as substituíram por contatos pessoais, criando assim canais permanentes de interação entre as equipes. Esses canais ajudam a criar um conjunto de habilidades híbrido que ajuda os funcionários a entender e representar melhor as necessidades, os desafios e os recursos das equipes que representam. As equipes dão uma à outra a oportunidade de realizar o trabalho necessário através de portais de autoatendimento automatizados, em vez de processar manualmente as solicitações de mudança de outra pessoa, como antes. E devido à presença de canais de interação, esses sistemas de autoatendimento podem se adaptar rapidamente às necessidades das equipes,para o qual eles são criados. Para alcançar um entendimento mútuo ainda maior e o compartilhamento de conhecimento dentro da organização, os membros da equipe alternam periodicamente funções para ganhar experiência na interação com várias equipes e entender melhor a imagem geral dos sistemas de TI que eles servem, aumentando assim seu nível de funcionalidade e utilidade cruzada.

Resumindo


Neste post, falamos sobre como a implementação de soluções PaaS pode incentivar a organização a implementar a metodologia DevOps, e as funções e tarefas tradicionais estão sujeitas a alterações como parte desse processo. Portanto, listamos as principais tarefas de TI que surgem na organização com a transição para o OpenShift, bem como as habilidades necessárias para sua implementação. Também apresentamos o principal conjunto de funções organizacionais que ocorre ao criar equipes multifuncionais de DevOps e a matriz RACI vinculando novas funções a novas tarefas. Por fim, conversamos sobre como a plataforma OpenShift e sua metodologia DevOps associada podem alterar a estrutura organizacional de uma organização ao passar de uma hierarquia tradicional e sistemas de processamento de aplicativos para equipes multifuncionais com um nível mais alto de comunicação pessoal.

More articles:


All Articles