Dez anos depois da primeira conferência DevOpsDays em Ghent, a evolução do DevOps e organizações que tentam adotá-lo, estavam no DevOpsDays em Portugal. No segundo dia, uma mistura de palestrantes locais e internacionais abordou tópicos de como aprender com incidentes sem procurar culpados, como gamificar em plantões, entrega contínua moderna e muito mais.
A palestra de Pranjal Deo sobre post-mortem sem culpados deu o tom do dia. Deo compartilhou as experiências aprendendo com incidentes sem culpados, tanto profissionalmente no Google como em sua vida pessoal, por exemplo, quando enfrentava sinais de esgotamento. Um dos principais argumentos foi que perder a chance de aprender com um incidente sério torna as coisas mais custosas. Para evitar isso, Deo recomenda ter critérios mensuráveis pré-definidos para disparar post-mortems, como um certo número de usuários afetados, quantidade de receita perdida, ou até mesmo um canary release mostrando uma regressão significativa. Além de executar consistentemente post-mortems, outros fatores críticos para uma cultura de transparência incluem deixar de lado o discurso de procura de culpados, celebrar a descoberta de vulnerabilidades, estabelecer segurança psicológica, todas as pessoas poderem falar, e uma abordagem de melhoria contínua para o trabalho, no qual as falhas são vistas como oportunidades de aprendizagem. Por fim, Deo advertiu que ter todos os itens mencionados, mas não fornecer tempo suficiente para concluir as ações de acompanhamento, poderia inviabilizar todo o processo.
Pedro Torres falou no Talkdesk sobre os desafios de escalar plantões, desde as pessoas, até mesmo o CEO, que estão de plantão para todos os sistemas nos primeiros dias, algumas quase esgotadas entrando em burnout, até ter engenheiros de plantão trabalhando fora da sprint para aumentar a resiliência e reduzir o trabalho em torno dos sistemas, seguindo o modelo SRE do Google. Hoje há uma compensação de taxa fixa mais alguns dias de folga quando se trabalha fora do expediente (contra nenhuma compensação anterior a isso). Além disso, as avaliações de desempenho não estão vinculadas à participação do plantão. As cartilhas para procedimentos de plantão agora são testadas com exercícios semanais de incêndio, onde os incidentes que resultaram em post-mortem são reproduzidos para verificar se o manual fornece orientação suficiente para um engenheiro consertá-lo. O ingrediente final até agora foi a introdução da gamificação, com "prêmios" como canecas personalizadas, adesivos e cadernos, com o MTTR melhorando em 12% em comparação com a pré-gamificação, que já havia melhorado substancialmente desde os primeiros dias.
A apresentação de Ken Mugrage sobre a Entrega Contínua (Continuous Delivery, CD) moderna começou com uma recapitulação da história do CD a partir do ponto de vista da Thoughtworks, resultando nos livros "Entrega Contínua", "Construindo Microservices" e "Infraestrutura como Código", cada um com co-autoria de um membro atual ou ex-Thoughtworker. Mugrage, mencionou como as imagens de containers tornaram-se o novo artefato onipresente nos pipelines modernos e o Kubernetes está, de fato, se tornando uma plataforma para o gerenciamento de ambientes, tanto para produção quanto para teste. Outras peças críticas para a entrega moderna de software, de acordo com Mugrage, incluem alternância de recursos, desenvolvimento nas branches principais, além de suporte a várias estratégias de implantação, de canary release a implementações por meio do modelo azul-verde e atualizações contínuas, dependendo do contexto da aplicação e do propósito das mudanças implementadas. Por fim, liberar as alterações do banco de dados separadamente das alterações do código do aplicativo, mas pelo mesmo pipeline, usar ambientes dinâmicos, também chamados de ambientes efêmeros, verificação de vulnerabilidades e gerenciamento de segredos também é importante para uma abordagem de Entrega Contínua moderna.
Falando de estratégias de implantação, Pierre Vincent enfatizou que há uma diferença entre o tempo de inatividade real e o tempo de inatividade percebido durante as atualizações do aplicativo, e dos banco de dados. Vincent estava falando sobre como a Poppulo decidiu optar por uma estratégia de tempo de inatividade zero, à medida que o software de comunicação que os funcionários estavam criando, era usado em todo o mundo e as janelas de manutenção se tornavam impraticáveis para os clientes. Vincent disse que mesmo os sistemas legados com bancos de dados tradicionais, podem se beneficiar de padrões como expansão ou contrato de bancos de dados para reduzir o tempo de inatividade, mas o tempo de inatividade real zero é quase impossível de ser alcançado. No entanto, "tempo de inatividade zero é uma percepção do usuário" não significa que todo serviço precisa estar ativo durante uma migração, mas sim que os usuários finais não notem qualquer tipo de inatividade, de acordo com Vincent.
Outras palestras neste dia focaram nos desafios para a adoção do Kubernetes em produção por João Vale e André Ferreira, além de uma visita aos microservices "legados" do Financial Times e como usaram bancos de dados gráficos (neo4J com GraphQL) para criar um modelo compartilhado de os serviços e propriedade correspondente, por Rhys Evans.
Os vídeos para a maioria das palestras serão publicados no canal do Youtube da conferência. Segundo os organizadores, a próxima edição da conferência será na cidade de Porto, em 2020.