June 2026 DevOps Meetup

Conversa 1
**Título: A plataforma são as pessoas: SLAs, DORA e confiança em bilhões de solicitações por mês**
Por: Harry Bouras
Função / LinkedIn: Líder de IA e engenharia de nuvem, anteriormente liderando a organização de API de uma empresa líder, extremamente global e multicultural. LinkedIn: https://www.linkedin.com/in/harry-bouras/

Resumo:
A maioria das palestras sobre “plataforma” são sobre ferramentas. Este não é. Liderar a organização de API de uma empresa líder, extremamente global e multicultural, interconectando décadas de sistemas legados enquanto atende bilhões de solicitações por mês e escalonando no Azure e no Google Cloud, me ensinou uma lição contrária da maneira mais difícil: nesse volume, as plataformas não falham em tecnologia e as contas da nuvem não explodem por causa do Terraform ruim. Eles falham, ou têm sucesso, na forma como a organização está configurada para possuir, entregar e fazer crescer o produto. O organograma é a arquitetura real.

Examinarei as alavancas que realmente moviam a agulha, cada uma ancorada em momentos reais dessa escala. Como os SLAs, enquadrados como clareza e não como punição, mudam o comportamento dos engenheiros mais do que qualquer painel. Por que estender a confiança e o tempo a uma equipe desde o início - a coisa mais desconfortável que um líder pode fazer é precisamente o que aumenta a qualidade da construção e reduz o retrabalho que você não pode pagar em bilhões de solicitações. O que realmente mudou quando arrastamos uma organização em forma de cascata para uma entrega iterativa baseada em Scrum, e por que isso se tratava de encurtar os ciclos de feedback, e não de adicionar cerimônias. E como as métricas DORA se tornaram nossa resposta objetiva a uma pergunta sobre a qual todas as equipes discutem: o que realmente torna um engenheiro de software sênior bem-sucedido e o que é um engenheiro de DevOps?

Depois, o núcleo humano, contado honestamente, o que significa contado como comédia. O que faz um bom gestor neste mundo é narrado através de coisas que eu tinha certeza e sobre as quais estava completamente errado. A piada corrente também é o verdadeiro ponto: quase todos os instintos que me tornaram um bom engenheiro me tornaram um gerente medíocre, até que eu os desaprendi.

Finalmente, vamos dar uma olhada no que estamos prestes a errar juntos: a IA está forçando o DevOps a se transformar em DevSecOps - e as equipes que lidarem bem com isso serão aquelas que já possuem a cultura de propriedade, confiança e crescimento sobre a qual esta palestra realmente trata.

Conversa 2
**Cultura pós-morte: transformando falhas em aprendizado, não em culpa**
Por: Dani Yelovitch
A maioria das equipes de engenharia trata os incidentes como constrangimentos a serem enterrados – uma solução rápida, uma mensagem vaga do Slack e todos seguem em frente. Esta palestra defende uma abordagem diferente: tratar cada fracasso como uma dádiva.
A ideia central são análises post-mortem sem culpa – uma prática pioneira no Google e na Netflix onde o objetivo não é encontrar um bode expiatório, mas entender como o sistema (pessoas, ferramentas, processos) permitiu que uma falha acontecesse em primeiro lugar. Se um ser humano cometeu um erro, a verdadeira questão é: por que o sistema tornou esse erro fácil de cometer?
A palestra cobriria:
Qual é a aparência de uma boa postmortem (e as maneiras comuns pelas quais elas dão errado)
Como realizar uma revisão sem culpa sem que ela se torne uma sessão de culpa por comitê
Transformando itens de ação em mudanças reais, não em um documento de cemitério que ninguém lê
Construir segurança psicológica para que os engenheiros relatem os problemas antecipadamente, em vez de ocultá-los
A principal conclusão: as equipes que aprendem com as falhas mais rapidamente do que seus concorrentes fornecem software melhor com menos incidentes catastróficos — não porque tenham engenheiros melhores, mas porque construíram melhores ciclos de feedback.

**Discussão 3:**
Título: Da organização de serviços ao autoatendimento: engenharia de plataforma em ação
Por Pavel Bureš da Sky

As organizações de engenharia modernas acumulam silos de plataforma mais rápido do que conseguem pagá-los – cada equipe escolhe sua própria maneira de provisionar cargas de trabalho, bancos de dados, filas e caches, cada um com perfis de segurança, observabilidade e custos sutilmente diferentes. Nesta palestra, compartilhamos como estamos lidando com esse problema em escala por meio de uma prática de engenharia de plataforma baseada no princípio de uma interface unificada e abstrata para configuração centrada em aplicativos — uma abordagem que muda as equipes de plataforma do "encanamento orientado por tickets" para o pensamento de produto: contratos estáveis, caminhos dourados e autoatendimento por padrão.

Na segunda metade, nos concentramos em PEaaS (Engenharia de Persistência como Serviço), nossa implementação concreta desses princípios para cargas de trabalho com estado. Examinaremos a arquitetura - funções de composição Crossplane 2.0 no EKS, declarações Kubernetes (XRs) centradas em aplicativos e um modelo de integração de locatário que automatiza IAM, endpoints VPC, provisionamento OIDC e S3 - e como ele abstrai back-ends heterogêneos (Keyspaces, Aurora DSQL, Redis Cloud e Kafka no EKS) por trás de uma interface consistente.

Os participantes sairão com: Um padrão prático para projetar plataformas de engenharia em suas próprias organizações.
Uma arquitetura de referência para persistência como serviço no Crossplane.
Lições honestas sobre padronização, integração de locatários e adoção de plataforma.