Os desenvolvedores realmente são diferentes. Desde suas funções e responsabilidades até sua posição na estrutura organizacional, eles costumam ser o "grupo que destoa". Nem sempre é possível incluí-los no termo "TI", pois as equipes de desenvolvimento oscilam entre fazer parte da TI e fazer parte das áreas de negócio.
Mesmo com o DevOps começando a se consolidar como uma mudança cultural, a maioria das organizações continua estruturada funcionalmente nos chamados — e nada estimados — silos de TI. Em nossa pesquisa State of Application Services 2019, constatamos que quase metade dos entrevistados (46%) ainda estava organizada em "equipes de função única", como "Rede", "Servidores", "Armazenamento" e "Segurança". Mais de um terço (37%) trabalhava em equipes de operações integradas, mais preparadas para adotar e aplicar os princípios e as abordagens de DevOps à entrega e à implantação de aplicações. Apenas 15% trabalhavam em pequenas equipes multifuncionais estruturadas por unidades de negócios ou produtos da empresa.
A estrutura é importante, pois define, em parte, seu propósito e suas prioridades. Isso, por sua vez, determina as métricas usadas para medir o sucesso. Organizações isoladas em silos implicam métricas igualmente isoladas. Podemos observar isso em nossa pesquisa sobre NetOps e DevOps realizada no último verão. Identificamos diferenças significativas na forma como as equipes eram avaliadas de acordo com sua estrutura. Por exemplo, as métricas mais comuns entre todos os tipos de equipe e funções foram:
- Disponibilidade da rede (60%)
- Disponibilidade da aplicação (56%)
- Otimização de processos (40%)
- Tempo médio para resolução (39%)
Mas, quando analisamos isso em detalhes e observamos as métricas com base nos tipos de equipe, vemos que, quanto mais colaborativa — ou seja, semelhante ao DevOps — for a estrutura de uma equipe, mais as prioridades mudam.
| Função única | Operações combinadas | Multifuncional |
Disponibilidade da rede | 67% | 54% | 50% |
Disponibilidade da aplicação | 53% | 58% | 61% |
Otimização de processos | 34% | 45% | 45% |
Tempo médio de resolução (MTTR) | 43% | 30% | 44% |
Agora, qual é a relação entre as métricas usadas para avaliar seu desempenho e os serviços de aplicações? Na verdade, elas estão bastante relacionadas.
Se o seu foco principal for o tempo de atividade da rede, você trabalhará para aumentá-lo e implantará serviços que contribuam para esse objetivo. O mesmo vale para o tempo de atividade das aplicações. Se essa for a sua prioridade, você levará os serviços de disponibilidade muito mais a sério do que as pessoas avaliadas pela frequência de implantação.
Podemos observar o impacto de uma base de respondentes composta, em grande parte, por "equipes de função única" nos planos de implantação de serviços de aplicações analisados em nossa pesquisa. Isso fica mais evidente quando categorizamos esses serviços de acordo com o que oferecem às aplicações: segurança, desempenho, identidade/acesso, disponibilidade e mobilidade.
Esses resultados refletem o impacto das métricas de equipes com uma única função. Os desenvolvedores se preocupam principalmente com a disponibilidade — que muitas vezes inclui metas específicas de desempenho — e planejam implantar os serviços de aplicação que oferecem suporte tanto à disponibilidade quanto ao desempenho. Da mesma forma, as equipes de operações de rede se concentram nos serviços de aplicação que garantem a disponibilidade da rede por meio da otimização, do dimensionamento e da proteção dos protocolos de rede dos quais as aplicações dependem.
A estrutura da equipe é importante. Não apenas pela necessidade de promover uma cultura mais colaborativa, mas também pela forma como ela afeta as decisões — inclusive as escolhas tecnológicas. Objetivos distintos geram atritos e frustração. Esse é um dos motivos pelos quais vemos serviços de aplicação, como o balanceamento de carga, tradicionalmente implantados e operados por equipes de NetOps, serem assumidos por equipes de DevOps e implantados como parte da aplicação. Isso ocorre porque, em organizações com estruturas de equipes de função única, a disponibilidade das aplicações é uma prioridade para os desenvolvedores, mas não para as equipes de NetOps.
Para aproveitar de fato todo o potencial do DevOps, as estruturas das equipes — e as métricas usadas para avaliá-las — precisam migrar para modelos mais colaborativos e se afastar das equipes tradicionais de função única.
Porque silos são para fazendas, não para a TI.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...