Do código à Cloud: criando resiliência em todo o pipeline de DevOps

O DevOps gerencia código, pipelines, automação e metadados. Quando esses recursos ficam indisponíveis, os pipelines de entrega ficam paralisadose à medida que as operações comerciais são afetadas. 

Exclusões acidentais, ações de funcionários, configurações incorretas, limites de API, ransomware e interrupções nos serviços em nuvem afetam até mesmo organizações maduras. 

Muitas vezes, carecem de retenção de longo prazo, proteção de metadados, restaurações entre plataformas e controles de segurança de nível empresarial. 

Ao ajudar a oferecer proteção unificada e nativa da nuvem, com Recovery granular, restaurações entre nuvens, RBAC, capacidade de auditoria e armazenamento escalável. 

Como as interrupções atrasam os lançamentos, prejudicam a produtividade, aumentam o risco de não conformidade e mancham a reputação — tornando a resiliência do DevOps essencial. 

Assista ao vídeoaquipara ver a transcrição com marcação de tempo

…

Olá a todos, sejam bem-vindos à nossa sessão “Do código à nuvem: criando resiliência em todo o
“pipeline de DevOps”.

Meu nome é Aashray Agur, gerente sênior de produtos da Commvault.

Este é meu terceiro ano na Commvault.

Trabalho em Bangalore, na Índia.

Em termos de função, trabalho com a equipe de aplicativos SaaS, sendo diretamente responsável pelas soluções do Salesforce e
de DevOps.

Em termos simples, sou responsável por entender as necessidades do cliente e
desenvolver soluções de software relevantes nessa área.

Hoje, nosso palestrante e convidado é Anilkumar, da Oikocredit.

Antes de passar a palavra a ele, gostaria de falar um pouco sobre a Oikocredit.

A Oikocredit é uma das maiores investidoras em impacto social e cooperativas do mundo.

Eles promovem o desenvolvimento sustentável por meio de investimentos em inclusão financeira,
agricultura e energia renovável.

A sede fica na Holanda.

E Anil é engenheiro de nuvem na

Oikocredit.

Olá, Anil.

Seria ótimo se você pudesse falar um pouco sobre sua função e onde você trabalha. Sim,
Claro.

Sim, antes de mais nada, hum… sou o Anil.

Trabalho como engenheiro de nuvem na Oikocredit, então estou na Holanda.

Meu foco é, hum, implementar, auxiliar no projeto e manter a infraestrutura baseada
na nuvem.

A parte mais divertida é o processo de automação, para que as coisas aconteçam mais rápido.

Resumindo, garanto que nosso ambiente em nuvem funcione de maneira tranquila, segura e eficiente.

Aqui está a ordem do dia da sessão.

Começaremos falando sobre o risco crescente no ambiente DevOps; depois, abordaremos um pouco
a importância da resiliência e quais são as limitações de algumas das soluções existentes.

Em seguida, passaremos à demonstração.

Nos últimos dois anos, mais ou menos, vimos algumas das marcas mais confiáveis do setor de
tecnologia

enfrentando problemas inesperados em seus ambientes de DevOps.

Por exemplo, uma plataforma líder em colaboração perdeu mais de 100 repositórios do GitHub.

Um provedor global de nuvem sofreu um erro de configuração que causou uma interrupção nas operações de DevOps
em toda a região.

Da mesma forma, uma empresa líder do setor automotivo viu seus principais projetos em andamento serem excluídos.

Esses não foram casos isolados nem falhas de segurança.

Eles ocorrem mesmo em organizações com recursos abundantes e altamente maduras.

O ponto principal é que essa lista não é, de forma alguma, exaustiva.

Se você analisar essas situações, verá que elas poderiam ter ocorrido em qualquer organização.

Portanto, o que precisamos reconhecer é que os riscos estão aumentando em nossas ferramentas de DevOps.

Por que não perguntamos a alguém que trabalha nessa área, Anil? Você já gerencia ambientes de DevOps?
há bastante tempo.

Quando você vê incidentes como esses em todo o setor, como você os interpreta?

E você está percebendo que as organizações estão se tornando mais conscientes em relação à proteção de seus ambientes de DevOps?
?

Sim, essa é uma ótima pergunta.

Há alguns anos, o DevOps era visto principalmente como um fluxo de trabalho dos desenvolvedores.

Mas hoje, isso evoluiu para algo muito além disso.

É considerado parte da infraestrutura crítica dos negócios.

Portanto, embora todos estejam focados principalmente em manter os sistemas de produção em funcionamento, os sistemas que
desenvolvem e entregam essas aplicações — o ambiente de DevOps — também são essenciais.

Por isso, há uma crescente conscientização em todo o mundo

de proteger essa camada, não apenas contra ameaças externas, mas também contra alterações acidentais,
ações de funcionários ou até mesmo interrupções na plataforma.

É ótimo ver que a resiliência está começando a ser incorporada ao DevOps desde o início,
em vez de ser algo acrescentado posteriormente.

Essa é uma excelente observação.

Vamos nos deter um pouco em

porque, na verdade, a resiliência é importante.

Antes mesmo de falarmos sobre resiliência, vamos dar um passo atrás e esclarecer o que é o DevOps
o que isso realmente significa.

Como você disse antes, no início do DevOps, o desenvolvimento de software envolvia apenas duas equipes
: uma escrevia o código e a segunda, cuja principal função era

garantir que esses sistemas funcionassem.

Hoje, o DevOps

mudou de fato a forma como o desenvolvimento de software ocorre.

Não são mais duas equipes.

Hoje, tudo acontece em um ciclo contínuo.

Por exemplo, primeiro você começa com um plano.

Na fase de planejamento, você pensa em quais funcionalidades serão criadas, quais novas soluções precisam ser
desenvolvidas, etc.

Você pode usar uma ferramenta como o Jira, por exemplo, para isso.

Depois de planejar, você escreve o código.

Você armazena esse código em um repositório e o guarda em um local como

GitHub ou GitLab.

Depois de escrever o código, você o empacota e lança uma compilação, como um artefato.

Depois disso, você verifica se tudo está funcionando corretamente, implementa sua solução e, então, monitora.

Depois de monitorar, surgem novos requisitos.

Então, mais uma vez, você começa a planejar.

Veja bem, isso é como um ciclo sem fim.

Converse com qualquer pessoa que já tenha trabalhado na área de desenvolvimento de software.

Todos concordariam que isso continuaria indefinidamente.

Então, Anil, por que você acha que o DevOps se tornou tão essencial para a forma como as organizações modernas operam?
hoje, especialmente quando se trata de agilidade e inovação?

Sim, acredito que não se trata tanto de uma organização específica, mas sim de como a entrega de software mudou
de maneira geral.

Hoje em dia, todo mundo está focado na velocidade e na colaboração.

O DevOps realmente une as operações de desenvolvimento e até mesmo

segurança, para que as ideias possam passar do conceito à produção de forma rápida e confiável.

Portanto, não se trata mais apenas de eficiência.

O ambiente de DevOps agora abriga os elementos mais críticos, como código-fonte, pipeline e
lógicas de negócios — que são, basicamente, a propriedade intelectual da organização e seu

.

Portanto, o DevOps tornou-se mais estratégico.

Atualmente, as empresas precisam inovar, manter a resiliência e também preservar sua vantagem competitiva.

Exatamente.

A capacidade de agir rapidamente, automatizar e colaborar entre equipes tornou-se, sem dúvida alguma, uma vantagem competitiva
.

Mas também acho que, devido a essa interconectividade — tanta interconectividade —, um
um problema em um ponto terá

efeitos em cascata ao longo de toda a cadeia.

Por exemplo, se você perder seu código, tudo o que estiver relacionado a ele será afetado.

Sabe, esses são os riscos.

Agora, vamos entender quais são os riscos existentes atualmente.

Já vimos alguns exemplos em nosso primeiro slide sobre o que algumas empresas
Já passaram, né?

Estou apenas tentando dar um nome a eles.

Portanto, se ocorrer um ataque de ransomware, é provável que seus repositórios sejam criptografados.

No caso de funcionários mal-intencionados, um agente mal-intencionado poderia simplesmente excluir suas configurações.

No caso de erro humano, pode ser algo como… bem, você e nossos desenvolvedores de software integram várias
ferramentas de terceiros.

Se a integração der errado, todo o seu sistema fica corrompido.

Portanto, os riscos existem e estão sob nosso controle.

Então, Anil, na sua opinião, o que acontece se esses pipelines de DevOps forem interrompidos, mesmo
em que sentido, “brevemente”?

Hum… Essa é uma pergunta interessante.

Nosso pipeline de DevOps é, basicamente, o sistema que garante que as Features e as atualizações para
nossos aplicativos internos sejam entregues de forma tranquila e segura, de acordo com nossas

.

Portanto, não se trata apenas de enviar código.

É isso que mantém tudo avançando: testar, integrar e lançar alterações
sem atrasos.

Portanto, se o processo for interrompido, mesmo que por algo insignificante, isso atrasaria nossas
várias equipes ao mesmo tempo.

Hum… E o impacto não é apenas técnico.

Os membros da nossa equipe precisam ter certeza de que tudo está funcionando conforme o esperado até o momento.

Hum… O foco é, principalmente, resolver o problema e colocar tudo em funcionamento.

Então, o projeto…

Não perca o ritmo.

Entendi.

Entendi.

Tentei identificar, hum, os riscos imediatos.

Por exemplo, como você disse, se você perder alguma coisa, vai haver atrasos na implantação.

Se você usar um teste de exemplo, a qualidade do produto será baixa.

E hoje, o código protege sua propriedade intelectual.

Hoje, o código é como o coração dos seus dados.

Se você usar isso, estará se expondo a riscos relacionados à sua propriedade intelectual.

hum

Além do aspecto técnico, que tipo de impacto nos negócios você observaria se os dados
E se o DevOps ficasse indisponível no contexto, por exemplo, dos dados corporativos?

Sim, nesse caso, hum, se os dados do DevOps ficassem indisponíveis, mesmo que por horas ou dias, o
O maior, hum, impacto seria no andamento do trabalho.

Portanto, quando o sistema que dá suporte à entrega de software fica inoperante, ele atrasa as atualizações e
melhorias das quais a equipe depende.

É por isso que resiliência e Recovery não são opcionais.

Elas estão envolvidas no processo desde o início.

Trata-se, acima de tudo, de garantir que a continuidade faça parte do projeto.

Assim, mesmo que algo dê errado, podemos nos recuperar rapidamente e continuar avançando.

Quero dizer, eu não poderia ter dito melhor, só para complementar o que você falou.

… Não se trata apenas da…

taxa de perda de dados, você estaria enfrentando uma perda de produtividade.

Potencialmente, você estaria correndo o risco de prejudicar sua reputação.

Se você atua em setores regulamentados, estaria enfrentando inúmeras falhas de conformidade.

É por isso que a resiliência precisa ser incorporada ao DevOps desde o início, e concordo com a afirmação:
isso nunca é demais, só isso.

Ok, já deixamos claro que precisamos de resiliência no DevOps.

Agora, vamos falar um pouco sobre quais soluções existem no mercado hoje e quais são algumas delas
as limitações dessas ferramentas.

Bem, no que diz respeito às soluções disponíveis no mercado, o que tenho observado como gerente de produto
É que algumas dependem de ferramentas nativas, a chamada “lixeira”.

Algumas tentariam usar scripts, alguns personalizados para, digamos, fazer os backups, e depois há
como soluções pontuais.

Mas,

essas apresentam algumas limitações sérias.

Antes de falar na qualidade de gerente de produto, gostaria de perguntar a você, como cliente: por que você acha que
Algumas equipes ainda dependem desses recursos nativos ou scripts?

Por que essas soluções não estão em nosso produto?

Essa é uma ótima pergunta.

Sim, posso falar com base na minha experiência.

Então, começamos usando o que já vinha integrado à plataforma e outras ferramentas disponíveis no
mercado.

E essas opções não, hum, abrangem, hum, as opções abrangentes que estamos procurando.

Elas cobrem o básico e exigem muita manutenção.

Mas, quando você analisa mais de perto, elas costumam ter, hum, períodos de retenção mais curtos e não capturam
tudo o que é importante, como pipelines, painéis e metadados.

Entendi.

Na verdade, essa tem sido a minha experiência ao entrevistar várias pessoas.

Já que as lixeiras não abrangem necessariamente tudo.

Mesmo os scripts não abrangem totalmente algo como metadados.

Um dos maiores sinais de alerta que você percebe — digamos que você use seus scripts — seria
a segurança.

Seus backups também ficam no mesmo ambiente.

E isso é um sério sinal de alerta.

Se a produção cair, seu backup também fica inoperante.

Portanto, você não pode ter um backup

No mesmo ambiente.

E aí entra a questão da auditabilidade.

Quando você usa scripts, não consegue ver o que está sendo copiado e o que está sendo restaurado.

Por fim, hum, a escala empresarial.

Embora existam scripts e soluções pontuais que ofereçam os três itens acima,
eles enfrentam dificuldades em termos de escala.

Provavelmente, elas conseguem lidar com centenas de repositórios, mas quando você passa para milhares de repositórios
ou terabytes de dados,

elas enfrentam dificuldades e entram em colapso devido às limitações das APIs.

E é por isso que tanto os scripts quanto as soluções pontuais não
conseguem atender aos requisitos de nível empresarial.

E é exatamente essa lacuna que justifica a existência da Commvault: para preencher essas lacunas.

Agora, antes de falar sobre minha própria solução e explicar por que ela é boa, quero ouvir o Anil, como

Nosso cliente, qual foi o principal motivo que o
O que levou a empresa a adotar a solução da Commvault?

Sim, eu diria que o principal fator motivador foi a simplicidade e a consistência.

Antes, a gente se virava com várias ferramentas e políticas diferentes para cada ambiente, o que
Isso tornava a proteção complexa e mais difícil de gerenciar.

Com o backup da Commvault para DevOps,

Agora temos uma abordagem unificada, um único local para visualizar, proteger e recuperar dados em todo o DevOps.

E sim, essa consistência também fortaleceu nosso aspecto de segurança.

Hum, sim, o controle de acesso e as políticas de retenção são aplicados da mesma forma em todos os lugares, o que
também reduz o risco e nos ajuda a manter a conformidade sem acarretar nenhuma sobrecarga adicional.

Ótimo, concordo.

Na verdade, uma das primeiras coisas que ouço dos nossos clientes é sobre o painel único
, um único local onde você pode proteger todas as suas cargas de trabalho.

Além dos pontos que você destacou, gostaria de abordar rapidamente dois
pontos muito importantes, já que estão relacionados ao meu slide anterior.

Falamos sobre a escalabilidade, sobre como muitas soluções disponíveis no mercado não conseguem lidar com grandes implantações.

Isso se deve aos limites de taxa das APIs.

Cada uma dessas plataformas — Azure DevOps, GitHub, GitHub —, você sabe, limita a
frequência dos backups; ou seja, com que frequência ou quantas APIs você pode usar?

Quando você atinge esses limites, suas tarefas ficam lentas ou apresentam falhas.

E contornamos isso por meio da rotação automática de tokens.

Assim, os backups são executados em paralelo sem nunca atingir os limites de taxa.

Podemos usar vários tokens e alterná-los continuamente.

Também distribuímos nossas cargas de trabalho de maneira inteligente para que ambientes de grande escala continuem funcionando
sem problemas, sem qualquer intervenção.

E o próximo ponto que eu gostaria de abordar é a restauração entre plataformas.

Como discutimos anteriormente, podem ocorrer interrupções no serviço.

Até mesmo os principais provedores podem ficar fora do ar.

Quando isso acontecer, para resolver a situação, você pode migrar seus relatórios do Azure
DevOps do GitHub para o GitLab e em qualquer combinação desse tipo;

você será verdadeiramente resiliente, e seu trabalho não para.

Além disso, contamos com todos esses recursos padrão, como registros de auditoria detalhados
, controle de acesso baseado em regras, etc.

E, neste momento, gostaria de aproveitar essa oportunidade para anunciar também que, em
Em breve, começaremos a oferecer suporte ao Jira.

Iniciaremos nosso programa de acesso antecipado a partir de dezembro.

Com o Jira, entramos em nossa próxima fase de desenvolvimento no âmbito do DevOps, e estamos super
entusiasmados com o suporte ao Jira.

Vamos passar para a próxima parte da nossa apresentação: a demonstração do produto.

Este é o nosso Commvault Cloud Console.

Este é o único painel pelo qual você pode proteger praticamente todas as suas
cargas de trabalho.

Esta é a página inicial da nossa ferramenta de DevOps.

Vou dividir minha demonstração em duas partes.

No primeiro segmento, falarei sobre a página de visão geral e como integrar seu aplicativo.

Na segunda parte, vou me concentrar na restauração.

A página de visão geral oferece uma

visão geral dos aplicativos que você possui e dos tamanhos deles.

Por exemplo, ainda não configuramos o Jira, então você não vê o Jira aqui.

Mas, independentemente da configuração, você verá o tamanho do backup e quantos repositórios foram protegidos.

Isso dá uma ideia de quantos backups já foram realizados e de quantas instâncias ainda não tiveram seus
backups concluídos.

Portanto, isso funciona como uma verificação de integridade.

Agora, vamos dar uma olhada rápida em como integrar um aplicativo.

Esses são todos os aplicativos que configuramos.

O resumo disso é o que você viu nesta página de visão geral.

Agora, vamos integrar um aplicativo.

Clique em “Adicionar aplicativo DevOps”.

Hum… Esses são os quatro aplicativos para os quais oferecemos suporte.

O processo de integração é bastante semelhante para todas essas plataformas.

Clique em “Próximo”.

O nome do aplicativo pode ser, hum, qualquer coisa que

permita identificá-lo facilmente; pode ser um nome do seu Azure DevOps ou qualquer outro que seja adequado para você.

Existem duas maneiras de realizar a integração.

Se você usar a configuração expressa, a Commvault fornece o aplicativo.

Você pode usar sua própria configuração personalizada.

Isso significa que você pode usar seu próprio aplicativo e utilizá-lo também com a configuração expressa.

Leva menos de um minuto para adicioná-lo.

Vamos ver como isso funciona.

Pronto.

Estabelecemos contato com essa organização.

Agora vamos para o Access Node.

Basicamente, você precisa escolher sua região de armazenamento.

Estamos presentes praticamente em todos os lugares.

Digamos que, se você estiver nos EUA, verá a região de armazenamento dos EUA; da mesma forma na Europa e
na Ásia.

Isso aparecerá automaticamente.

Configurar uma região.

E, em seguida, escolha o plano.

Na seção “Plano”, basicamente você pode

escolher, hum, com que frequência você deseja fazer o backup.

Já oferecemos armazenamento em pacotes, e você também pode definir o período de retenção.

Portanto, oferecemos retenção ilimitada.

Você pode fazer o backup no mínimo uma vez por dia.

E, por fim, o conteúdo.

Esses são todos os serviços que protegemos.

Se você não quiser que nenhum serviço seja protegido, pode desmarcar a opção.

Em relação aos projetos, quando você seleciona “todos os projetos”, o que acontece é que qualquer novo
Todo projeto ou repositório criado no dia a dia é verificado e tem seu backup feito.

Se, por exemplo, você quiser proteger ou desmarcar apenas determinadas cargas de trabalho, pode escolher
essa opção.

Como o armazenamento está incluído na licença, a prática recomendada é selecionar todos os projetos.

Clique em “Enviar”.

Pronto.

Sua instância foi criada.

Agora, bem, eu gostaria de abordar um dos pontos que venho repetindo na minha apresentação:
a escalabilidade.

Por que muitas soluções disponíveis no mercado não lidam com a escalabilidade?

Isso se refere ao suporte a vários tokens.

Hoje, já adicionamos um aplicativo

que fornece um token.

Agora, vamos adicionar mais.

Essa é uma credencial que eu já criei.

Se quiser saber mais, clique aqui.

Funciona assim: digamos que você atinja os limites de taxa da API com um; nós mudamos
automaticamente para o segundo e, em seguida, para o terceiro.

Dessa forma, você pode adicionar o máximo de aplicativos possível.

Então, sempre que você atingir os limites de cota da API, a gente muda e aí fica assim.

É assim que lidamos com a escalabilidade.

Com isso, concluímos a parte de integração da demonstração.

Agora vamos ver a parte da restauração.

Vamos voltar à organização.

Esses são todos os backups que foram feitos.

Você verá este carimbo de data e hora.

Você pode selecionar qualquer data e clicar em “Restaurar”.

Esta é a organização.

Você pode clicar na organização.

Esses são todos os projetos.

Portanto, a hierarquia é: organização, projetos e repositórios.

Você pode ver que ela tem centenas de projetos.

Você pode acessar qualquer um dos projetos e verificar quais repositórios existem.

Esses são todos os repositórios existentes.

Agora, se você, digamos, quiser restaurar.

Clique no botão “Restaurar”.

Certo.

Agora, oferecemos ainda mais detalhamento.

Digamos, por exemplo, que você queira restaurar apenas os artefatos.

É só desmarcar.

Ou talvez você queira restaurar apenas os repositórios.

Você pode cancelar outros serviços.

É assim que lidamos com a granularidade.

E, da mesma forma, a restauração no local é evidente.

Mas oferecemos restauração fora do local e até mesmo em disco.

Isso é para sua Readiness para desastres.

Agora, vamos dar uma olhada na restauração fora do local.

Eu também falei sobre um fator importante, certo?

Digamos que suas plataformas também possam sofrer interrupções.

Quando isso acontecer, talvez você queira migrar seus relatórios para outras plataformas.

Por exemplo, o Azure DevOps ou o GitHub.

E nós oferecemos suporte para isso.

Por exemplo, você pode escolher qualquer um dos aplicativos configurados durante a instalação.

E esse é o fluxo.

Veja bem, você clica em “Enviar”.

Hum… Esses relatórios seriam restaurados sem problemas no seu aplicativo.

GitHub e, com isso dito, isso encerra o… ah.

Para encerrar toda a discussão, o que vimos?

Vamos encarar a realidade: os incidentes cibernéticos não são meras hipóteses.

Vemos empresas passando por isso quase todos os dias. Portanto, os riscos são muito claros: a
A lacuna entre as ferramentas nativas e os scripts do tipo “faça você mesmo” apresenta limitações, e as soluções pontuais

não conseguem lidar com a magnitude.

Portanto, confiar nelas prejudicará sua resiliência cibernética.

E também discutimos os riscos.

Você já percebeu a perda de produtividade, os danos à reputação, a quebra da confiança dos clientes e
outros possíveis riscos?

Uma solução é contar com uma solução de nível empresarial, como a Commvault, para lidar com esses
riscos e estar preparado.

Então, gostaria de concluir, dirigindo-me a essas organizações

que estão apenas começando a pensar em proteger seus ambientes de DevOps: que conselho
você daria a elas?

Sim, eu começaria tratando os dados de DevOps como qualquer outro dado crítico para os negócios.

Outro equívoco comum é achar que as ferramentas nativas ou scripts rápidos são suficientes, mas
eles podem abranger apenas a Recovery básica.

Elas não foram projetadas para garantir segurança a longo prazo, escalabilidade ou mesmo conformidade.

Então, o segundo ponto que quero mencionar é: busque a simplicidade.

Quanto mais fragmentada for a estratégia de proteção, mais difícil se torna manter
a consistência e a segurança.

Hum… Portanto, devemos adotar uma abordagem unificada que inclua visibilidade, automação e até mesmo controles de acesso robustos
.

Isso faz uma enorme diferença nas operações diárias de TI.

Excelente conselho.

Agradeço muito pela sua contribuição.

Antes de encerrarmos, use esses códigos QR para baixar nosso Resumo da Solução DevOps e se inscrever
No nosso Workshop de Resiliência Cibernética, faça a avaliação de Readiness cibernética e saiba mais

sobre nossos programas de acesso antecipado.

Obrigado.