Um artigo recente de Jackie Kahle, da CA Technologies, lança um olhar sobre como DevOps está avançando em várias indústrias para aumentar a velocidade na forma como publicamos nossas soluções em ambientes de desenvolvimento ágil.

O mais surpreendente foi que em Telecom a adoção de DevOps é muito maior do que se imagina e parece mais disposta a ampliar suas metodologias ágeis existentes. Segundo Jackie Kahle:

Conteúdo relacionado de patrocinadores

A nítida liderança aqui é telecom. Eles tem quase duas vezes mais probabilidade de adotar práticas DevOps (68%) do que o restante (39%). Na verdade, um total de 88% das empresas de telecomunicações ou a utilizam ou pretendem utilizá-la, contra um total de 66% das outras indústrias. É claro que a indústria de telecomunicações é uma das mais competitivas e as pressões para entregar continuamente novos produtos e serviços são enormes. Os benefícios de DevOps principalmente em relação a acelerar o ritmo das entregas fornece uma razão muito atraente para a indústria de telecomunicações avançarem agressivamente com DevOps.

Desafio distinto para fornecedores e operadoras

Isso parece correto para provedores de Internet e operadoras móveis que anos atrás implantaram métodos ágeis e agora seguem para WebRTC, web services e HTTP/REST em sua batalha para manter os lucros em serviços de valor agregado ( Value-Added-Services - VAS). Seu campo de atuação torna-se mais algo como TI com serviços sendo executados no navegador ou facilmente virtualizados em um contêiner OpenStack.

DevOps vem de TI (assim como Agile). Por isso, é lógico que as indústrias tendem a convergir com as plataformas de Internet e portais web e usem tanto as ferramentas, quanto a mentalidade DevOps.

Mas essa pilha de TI pura, encontrada em quase todas as operadoras e provedores de Internet é apenas um subconjunto de "telecom" e não reflete a maior participação do que a indústria de telecomunicações "realmente é": notadamente, fornecedores de equipamentos de rede que constroem o equipamento e a infraestrutura.

Além dos 4 maiores fornecedores como a NSN, Ericsson, Alcatel-Lucent e Huawei, existem milhares de empresas de médio porte escrevendo e implantando software segundo princípios ágeis. Elas migraram anos atrás do desenvolvimento waterfall-interativo para Agile, e apesar de serem grandes, em comparação com as equipes de TI, elas não são alheias à Integração Contínua, e, até certo ponto, até à entrega contínua.

Mas diferentemente de TI e de plataformas de Internet, eles não criam um serviço virtual a ser implantado em algum lugar na nuvem, que também não pode ser "continuamente" corrigido de forma ágil. Eles entregam hardware que podem custar milhões para serem colocados em funcionamento e são mantidos durante anos com SLAs rigorosos. Portanto no plano técnico, usar OpenStack, Puppet, Chef, Salt ou outras tecnologias DevOps não vai agregar valor aos profissionais de Telecom.

Quando em 2012 eu perguntei aos meus antigos colegas do período que trabalhei com SaaS, o que realmente era DevOps, a resposta confusa dada pelos entusiastas foi:

Para entender DevOps é preciso lembrar que não se trata de um framework, mas de um mindset.

Isso me deixou curioso, porque mesmo em TI ninguém conseguia dar uma definição mais adequada do que:

Isso vai torná-lo mais rápido através da melhoria da comunicação entre o desenvolvimento e os departamentos de integração/implantação.

Seja na indústria de telecomunicações, na automotiva ou em outra indústria com uso intensivo de hardware, será pouco provável que alguém forçado a tomar uma rota conservadora abrace o DevOps by-the-book, mesmo que já existam processos ágeis em vigor.

Aqueles mais familiarizados com algumas das imagens engraçadas em devopsreactions, podem dar uma boa risada com a idéia de "DevOps em uma usina nuclear", ou o deploy de "live updates em Equipamentos Médicos Cirurgicos".

Por mais divertido que seja, é o mesmo em Telecomunicações: a estação rádio-base de celular ou eNodeB ou qualquer outro nó prestando um serviço para milhares de assinantes, tem que funcionar sem falhas. Se o seu novo e reluzente celular LTE/4G constantemente perde as chamadas de voz - um serviço que funciona desde 1948 (0G/MTS) ou serviços de emergência como o 911 são interrompidos então as penalidades para o fornecedor são graves (milhões a cada hora).

Enviar um engenheiro ao local para coletar logs vai demorar um dia. Mais alguns dias para analisar, em seguida, entregar e lançar a correção, que pode funcionar ou não. E até isso ser resolvido as penalidades são muitas vezes superiores às receitas obtidas com o negócio. Portanto, encontrar falhas o mais cedo possível usando "Modo de Falhas e Análise de Efeitos para Design" (Design Failure Mode and Effect Analysis, ou DFMEA) é o aspecto mais importante para saber se você continua a ser rentável.

Mas ainda não descarte DevOps em indústrias conservadores. A "mentalidade" DevOps ainda pode torná-lo mais rápido do que seus competidores. Antes de irmos para o lado filosófico, vejamos como essas grandes empresas que não são de TI geralmente desenvolvem/implantam seus produtos.

Caso de Uso: ACME Corp

O exemplo abaixo utiliza a ACME, um fornecedor de equipamentos de telecomunicações, para ilustrar um cenário típico, mas pode ser facilmente aplicado a qualquer outra empresa que constrói sistemas complexos e muito caros, cujo produto não é apenas um SaaS, mas entregue com milhares de peças móveis. ACME poderia igualmente ser um fabricante de automóveis OEM, uma empresa aeroespacial, uma usina de energia fornecendo soluções de smart grid ou uma empresa ofertando Automação Industrial.

ACME é um negócio de bilhões de dólares e desenvolve componentes de rede para operadoras de telefonia móvel. Um de seus projetos de P/D atualmente mantém mais de 1.000 engenheiros ocupados desenvolvendo para fazer deste mundo um lugar melhor. Nos últimos 10 anos a ACME migrou com sucesso do desenvolvimento "interativo" (Waterfall) para o Ágil. Seus engenheiros agora se organizam como micro-equipes multifuncionais que são agrupados/desagrupados de forma ad-hoc trabalhando em vários pedaços do produto. Nem todo mundo toca tudo dentro do repositório de código, mas eles olham para o código e propriedade no âmbito de seus recursos e impactos sobre o sistema.

As competências são espalhadas por diferentes locais geográficos com uma boa mistura e equilíbrio. Algumas equipes estão mais próximas do hardware enquanto outras trabalham mais alto na pilha de tecnologia. Diretrizes rigorosas de qualidade garantem que sempre que submeterem uma mudança para o repositório de software, um feedback automático imediatamente é dado pelo seu sistema de integração contínua (CI) para informar quando os desenvolvedores quebraram a funcionalidade existente. Neste primeiro exemplo, o CI executa principalmente testes unitários, mas também testes mais elaborados sistema-componente que validam o binário final com cenários mais complexos e até mesmo simulando as mensagens que o binário viria a tratar com o hardware real. Quando as falhas são levantadas pelo CI elas ou implantam uma correção imediata ou fazem o rollback do que foi mudado. Desta forma, o conteúdo geral sempre tem uma versão funcional, recente e testável do produto ou dos seus subcomponentes.

Uma vez que as mudanças ou novas funcionalidades foram entregues, e desde que nada quebre, seu código é automaticamente "promovido" e liberado para avançar para as fases de integração e de teste.

Os responsáveis nos departamentos subsequentes então pegam (cherry-pick) uma versão recente do CI anterior, mas também alinham e coordenam as entregas de outros departamentos que têm a sua própria estrutura de CI e contribuem para o produto final. Eles, então, aprofundam a integração dessas versões à plataforma de hardware real que também varia de acordo com aplicações (MCU, DSP, etc ...). Por exemplo alguns departamentos entregariam a camada de kernel e a camada de abstração para o sistema operacional, enquanto outros entregariam o Layer-1 (camada Mac e camada física) ou Layer-2 (camada de enlace) no modelo OSI e depois há aquelas equipes que oferecem a funcionalidade real para manipulação de mensagens de rádio ou de core interfaces de rede: User-Plane, Control-Plane, OAM. Essa equipe subsequente tem seu próprio sistema de CI e um repositório para versionar e armazenar os seus casos de teste, e então, por sua vez, "promovem" e liberam o que veio das equipes anteriores, após os seus próprios testes passarem, para as próximas equipes. Isto também é feito, na maior parte, de modo automatizado e a intervenção humana só é necessária para analisar quando o pipeline para.

Você pode encontrar 4 ou mais desses casos de teste / integração, todos organizados por suas próprias camadas de gestão. Eventualmente, o código inicial e pacote binário final chega ao verdadeiro hardware onde os testes de sistema fim-a-fim e testes de interoperabilidade (IOT) podem ser conduzidos antes de seguir para testes de campo e, eventualmente, seguir para implementações em clientes.

Todos ficam felizes! Quer dizer, até que uma falha venha de cima pra baixo, e a análise irá consumir todos os recursos dos já sobrecarregados desenvolvedores.

• Qual versão do pacote de software apresenta a falha?
• Nesse meio tempo, quantos branches foram criados com as mesmas falhas?
• Onde devemos fazer o merge com as correções?
• Quem mais virá de outro departamento reportar o mesmo erro?
• Mas se já existe uma correção no controle de versão então por que essa versão já não foi usada nas etapas subsequentes?
• Como podemos pedir para os desenvolvedores lidar com essa sobrecarga quando eles precisam trabalhar com um prazo apertado para produzir as próximas funcionalidades do sprint?

Quem irá lidar com estas questões, se não podemos direcionar toda falha diretamente ao desenvolvedor?

Gerente de Falhas ao Resgate!

Agora temos uma apresentação para um cliente (pra falar a verdade, sempre temos uma dessas) o que significa que temos várias dessas falhas-super-mega-críticas-que-não-podem-esperar-e-precisam-ser-consertadas-imediatamente. E precisamos de desenvolvedores para corrigi-la imediatamente. Mesmo que nós não saibamos quem seja o culpado que cometeu esse crime hediondo. E já que nossos gerentes de falha estejam sobrecarregados, nós não temos tempo de analisar nada disso.

Se ao menos tivéssemos pessoas dedicadas que possam olhar os logs e identificar quais desenvolvedores possam fazer a correção!

Pré-Análise ao Resgate!

E de uma hora pra outra, nosso herói conseguiu analisar os 10 GB de logs e identificou os suspeitos de sempre, confirmou que não era um bug nos testes reais, e encaminhou a falha à equipe certa, que em seguida entregou a correção necessária.

Contudo, este claramente não é o final da história! Uma vez que agora a falha já se propagou em produtos que haviam sido congelados e, portanto, NÃO DEVE ser corrigida a menos que haja um pedido oficial por parte do cliente.

Tendo em conta que a entrega oficial do código defeituoso foi feito há 3 semanas, esta questão vai mostrar sua cara feia mais algumas vezes nos próximos meses, e cada vez em um branch diferente aparecendo como um novo bug na ferramenta de relatório de bug com um conjunto diferente de arquivos de log.

Portanto, nossos heróis estarão mais ocupados do que Batman e Robin pelos próximos anos!

O que aconteceu? O Ágil não havia tornado o ACME mais rápido?

Tendo abolido a propriedade individual do código e implementado o Ágil internamente dentro de sua equipe, o ACME Corp ganhou enorme velocidade ante seus concorrentes, produzindo mudanças bem testadas e novas funcionalidades a cada poucas horas e entregando várias vezes por dia em vez de uma vez por semana. Falhar rapidamente é o novo mantra.

Mas ao fazê-lo outro gargalo surgiu: a empresa havia internamente se comprometido com os métodos ágeis, mas cada departamento ainda trabalhava à sua maneira, mantendo seu status quo e tratando outros departamentos como colaboradores externos.

De volta ao seu workflow: se você olhar de perto como a cadeia de entrega do produto "cascateia", muitas vezes ao longo de cinco ou mais departamentos de integração e testes, você ainda verá uma "waterfall"! E essa "waterfall" é um pesadelo administrativo caro e devorador de recursos, que rapidamente corrói o tempo dos desenvolvedores, pois eles têm que constantemente oferecer esclarecimentos aos coordenadores dedicados, cuja principal tarefa consiste em direcionar a comunicação sobre as falhas dentro dos canais apropriados. Frustrante.

E é assim que o Ágil para e DevOps pode te ajudar a romper os silos remanescentes.

O que o DevOps pode trazer à mesa em indústrias que estão "perto do metal", ou seja longe do mainstream de TI, não é uma nova ferramenta para resolver todos os seus problemas. E tão pouco o Ágil!

Pensar "de maneira DevOps" significa integrar seus ambientes de teste/operações posteriores e aproximá-los dos desenvolvedores.

De fato, da perspectiva dos departamentos subsequentes pouca coisa mudou. Essencialmente porque a integração para eles não é tecnicamente tão fácil devido à falta de virtualização e a operação mais próxima ao hardware (usando as lentas e pouco confiáveis interfaces JTAG/USB, ou depurando comunicações em SRIO, ePCI ou lidando com interfaces altamente especializadas e específicas de telecom, tais como OBSAI/CPRI) frequentemente exigindo reinicializações manuais de PCs de teste que usam drivers específicos, etc. Portanto, eles ainda obtêm um baseline em intervalos regulares que é carregado manualmente para o ambiente de teste e, em seguida, eles fornecem um feedback as outras equipes. Para tornar mais claro, as equipes que realizam a integração tem um conjunto de habilidades totalmente diferentes, que estão longe de serem as atividades que um desenvolvedor normalmente faz. Aqui, o foco está mais próximo de compreender de ponta-a-ponta o fluxo de mensagens das especificações 3GPP, em vez de produzir pedaços de código C/C++. Quando Integração fala sobre uma "funcionalidade" esta geralmente inclui várias (ou todas as) equipes envolvidas.

Quanto mais você se move adiante na cadeia de produção mais você encontrará uma falta de conhecimento sobre scripting, que existe naturalmente nas outras equipes. Integração pode selecionar de forma aleatória apenas alguns desses baselines ou escolher o que parecer mais promissor.

Portanto, mesmo que nossos desenvolvedores nas diferentes linhas de produção produzam funcionalidades a todo vapor, "os próximos" continuam a viver isoladamente do resto dos outros departamentos.

E isso só piora a medida que você se distancia dos desenvolvedores nas linha de produção subsequentes:

• Cada departamento inventando seus próprios testes por causa das suas necessidades únicas (algumas justificáveis, algumas não);
• Muitos escrevendo casos de teste que se sobrepõem e retestando o que já foi validado. Não que fazer uma nova checagem seja algo ruim, mas é um desperdício escrever/manter várias vezes o mesmo código de testes. Existe uma sobreposição maciça e engenheiros criando e resolvendo problemas similares em cada departamento.

Quais são os passos que levam até o DevOps?

Uma "mentalidade" DevOps irá ajudá-lo a reduzir as barreiras técnicas entre esses departamentos em cascata, para que as implantações automatizadas se tornem possíveis. Adicione APIs que tornam toda a cadeia de entrega transparente do ponto de vista técnico - do princípio até o hardware alvo.

A boa notícia é que você não tem que começar a fazer tudo de uma vez, como fez há 10 anos atrás quando você começou a migrar para o Agile! Em vez disso, comece com um gap-analysis conduzido por um arquiteto interno - vamos chamar essa pessoa de engenheiro de consolidação - e verifique cada um dos seus departamentos de testes/integração para identificar sobreposições e formas de automatizar suas APIs/Interfaces de deploy.

Assim que tiver uma imagem clara, descubra como você pode quebrar seus silos internos e melhorar a comunicação intra-departamento. Como você faria isso? Simples: você já fez isso uma quando introduziu Agile em suas equipes de desenvolvimento! (e sim naquela época algumas pessoas provavelmente resistiram - algumas até se demitiram - e não será mais fácil desta vez).

• Agora, dê o próximo passo e faça com que alguns de seus desenvolvedores passem um ou dois dias por semana, no que foi até agora o próximo departamento posterior. E faça com que alguns desses caras do próximo departamento passem alguns dias por semana no desenvolvimento.
• Você pode querer pensar em incentivos para fazê-lo e recompensar pessoas dispostas a trabalhar através destas fronteiras. Considere-os como embaixadores em sua empresa que rompem seus silos. Antes que você perceba, as fronteiras terão se tornado tênues e aquele silo estará rachando! E a natural polinização cruzada de ideias vai começar a acontecer.
• Os desenvolvedores agora percebem os efeitos das suas mudanças de código dentro de algumas poucas horas e no hardware real. Isso os torna uma parte mais relevante na sua "grande máquina organizacional", e também os ajuda a se identificar mais com o produto vendido.
• Confie na sua cobertura de testes! No caso de algo falhar nos outros departamentos você precisará se comunicar com eles para tentar entender o porquê sua cobertura de testes não detectou logo o problema. Todo erro que conseguir chegar até um departamento subsequente deverá ser coberto em todos os testes futuros em todos os branches. Limitar o número de branches reduz "trocas de contexto" para os desenvolvedores e a complexidade do seu sistema. Se a sua cobertura de teste é tão ruim que a sua única forma de garantir a qualidade é isolar e congelar o branch então comece por aqui o seu processo de melhoria. A decisão que um novo branch deve ser criado geralmente vem de cima para baixo (gerentes de controle de qualidade), mas geralmente ignora o fato de que esta é a opção mais cara e ela nunca escala.

Será que isto tornará obsoletos os papeis de "Gestão de Falhas" e "Pré-Análise"?

Gostaria de imaginar essas posições como um "gerente provisório" que chega durante tempos de mudança e apoia com habilidades especiais para fazer a ponte entre os mundos de P/D e Operações. Grandes empresas que fazem o Agile sem DevOps serão incapazes de entregar serviços sem eles. Mas quando seus silos racharem essas tarefas precisarão serem redefinidas

Quanto tempo leva pra chegar lá?

Você precisa dar suporte de baixo para cima e de cima para baixo, porque quebrar silos e fazer DevOps afeta todos os elos da cadeia de distribuição. Da minha experiência pessoal durante a migração de Waterfall para Agile e também de muitas entrevistas técnicas que realizei como recrutador de Telecom, o tempo exigido para se deslocar de Waterfall para Agile é de 1-3 anos. Eu prevejo mais 1-3 anos para DevOps. O maior desafio em grandes organizações não é a tecnologia, mas a política e as pessoas, ou como disse a famosa citação de Gerald M. Weinberg:

Não importa o quão técnico pareça ser a primeira vista, sempre é um problema com pessoas.

Conclusão

• Fazer DevOps em indústrias fora do modelo XaaS e Web não é assim tão diferente. Lidamos com mais stakeholders e com estruturas mais complexas e conservadoras.
• Vai levar mais tempo para trazer todos a bordo. Mas se você generalizar e focar nas interfaces (por exemplo, a forma como estes silos se comunicam) então "um silo é um silo" e não há diferença para TI. É só uma escala maior.
• Estas empresas já adotaram de TI a ideia do Agile e a dimensionou às suas necessidades - na maior parte com sucesso. Silos individuais já estão operando com a máxima velocidade e eficiência e pouco pode ser melhorado internamente (a maioria deles funcionam como panelas de pressão). DevOps é o elo perdido e próximo passo lógico, uma vez que irá reduzir o crescente atrito entre estes silos.
• Uma vez que você mudar para DevOps ele irá aumentar habilidades multifuncionais e levar a uma melhor compreensão dos problemas que outras partes interessadas estão enfrentando.
• Finalmente ele permite soluções como colocar mais confiança em sua suite de testes ao invés de utilizar caras empresas de Q/A ou regularmente intercambiar profissionais de equipes anteriores/posteriores. Soluções que sempre pareceram corretas, mas que até então eram politicamente impossíveis de se implementar.

Sobre o Autor

Joachim Bauernberger é um engenheiro ágil focado em Pesquisa, Consultoria e Recrutamento para a Future-Network Technologies e pesquisa e desenvolvimento de otimização de processos nesses domínios.