SLA 99,99 - RubyConf 2022

Poucos livros ensinam como transitar de uma simples aplicação para uma aplicação robusta que atende milhares de requisições por minuto. Aqui vamos falar algumas estratégias utilizadas para garantir velocidade de desenvolvimento e disponibilidade do serviço: migrations em 3 etapas, feature flags, e infraestrutura 100% redundante. Ainda assim, as coisas podem dar errado, tentar se recuperar o mais rápido possível, gerenciar a expectativa dos clientes e reduzir estresse da equipe são fundamentos essenciais para um bom SLA.

Transcript

1. | na RubyConf 2022 Por Daniel Libanori
2. Desafios e estratégias para um SLA 99,99: Codificação, deploy e infraestrutura.
3. Daniel Libanori ♦ Trabalho com Ruby desde 2006 🎓 Formação: UFSCar e USP 󰞦 Passei por agências, startups e trabalhei autônomo Em 2010 junto com Marcelo Kramer e Michael Bernstein fundei a Clicksign
4. Startup de assinatura digital Pioneira no Brasil Full remoto pré-pandemia Mais de 300 colaboradores Mais de 70 cidades Nas 5 regiões do Brasil Portugal, EUA e outros
5. 🔐 | Trust 👥 | Empatia 🚀 | Proatividade 🎨 | Capricho 󰟑 | Ritmo 🧐 | Visão Crítica Cultura e Valores
6. Travessia Ubatuba - Cape Town Fevereiro de 2022 Atlântico Sul Veleiro de ~10m 5 tripulantes: 2 homens e 3 mulheres 35 dias seguidos de mar 6.200 km Ondas de 7 a 9 metros Ventos de +115 km/h
7. O que a vela me ensinou sobre SLA Nervosismo não ajuda Trabalho em equipe “Quem tem um não tem nenhum” A direção é mais importante que a velocidade Planejar, fazer, checar e ajustar
8. Expectativa
9. Realidade
10. SLA Service level Agreement
11. SLA (Service level Agreement) Definição dos resultados a serem obtidos Tempo de execução da atividade a ser desenvolvida Definir os responsáveis pelas atividades e o envolvimento que terão Definir as ferramentas que serão utilizadas Detalhar qual será a qualidade do trabalho que deverá ser entregue;
12. Aqui SLA é… Aplicação de funcionando Sem bugs graves Sem lentidões
13. Calculando esforços de SLA Preâmbulo
14. SLA 99,99999999… Todo mundo quer, mas todo mundo precisa?
15. "Otimização prematura é a raiz de todo mal" Donald Knuth cientista computacional
16. O verdadeiro problema é otimizar antes de saber o que nós precisamos
17. Qual o SLA que seu negócio demanda?
18. O que você deve SEMPRE fazer Ser transparente Avaliar medidas corretivas Avaliar medidas preventivas
19. O que funcionou para nós Essa talk é sobre…
20. Cenário “Não pode cair!” Clientes de grande porte Bilhões de registros Risco: contratos de R$ 1,00 até R$ 10.000.000,00 Operação “normal”: +30k reqs/min Não existe meia-noite Time distribuído geograficamente Alta expansão nos últimos anos
21. Estratégias Minimize o tempo de deploy Dê atenção às migrations Deixe o trabalho duro para depois Tenha em mente a possibilidade de rollback Desligue parcialmente sua aplicação Tenha no mínimo dois Timeout pra tudo
22. Minimize o tempo de deploy Construa tudo antes: imagens, assets etc Mude o comportamento por feature flags invés de imagens Controle o comportamento “por conta”
23. As migrations podem ser um problema… Na verdade, as migrations são um problema!
24. Roda e reza!
25. Migrations problemáticas Se houver manipulação de dados pode demorar Banco sendo alterado com a aplicação funcionando pode dar ruim Rollback pode levar a inconsistências Rollback pode demorar tanto quanto a migration
26. Safe Migrations: DDL & DML DDL • Deploy • Metainformações • O mais rápido possível DML • Runtime • Informações • O mais seguro possível
27. Quem pode te ajudar safe-pg-migrations strong_migrations
28. safe-pg-migrations Lock timeout statement timeout no dll transaction safe: add_column, add_index, remove_index, add_foreign_key retries verbose
29. Leia a documentação
30. Leia TODA a documentação É rápido! Porém…
31. Migrations durante o deploy Migration Versão N-1 Versão N
32. Migrations durante o deploy Só Deus sabe o que acontece aqui…
36. Migrations durante o deploy Atualização de registros (DML) Alteração nas tabelas (DDL)
37. Migrations durante o deploy Atualização de registros (DML) Alteração nas tabelas (DDL)
38. Migrations durante o deploy Quanto menor, melhor
39. Deixe o trabalho duro para runtime
40. “Mas eu já faço isso com rake tasks…” Alguém na platéia
41. Mas a gente não faz com rake task… cada conta tem um número aleatório entre 0 e 1: feature level migramos os clientes por fatia de feature level contas mais propensas à risco possuem feature level mais baixo contas menos propensas à risco possuem feature level mais alto cada migração pode ser encapsulado numa transação nossas regras de negócio permitem este approach
42. Do que você ta falando cara?
43. Feature flags • Pete Hodgson em martinfowler.com • Categorias: ◦ Release toggles ◦ Ops toggles ◦ Permission toggles ◦ Experiment toggles • Dinamismo • Duração • Vale uma talk!
44. Feature flags
45. Um exemplo simples
46. Na prática nunca é tão simples Antes Depois
47. Garanta o rollback
48. Garanta o rollback
49. Minimize o tempo de rollback
50. Geralmente uma escrita no banco é muito mais rápida que um deploy
51. No all-in!
52. Desligue parcialmente sua aplicação
53. Ops Toggles Desligam parte da aplicação Sem prazo para serem retiradas Dinâmicas Podem ser globais ou per conta Reduzem a turbulência ou Ao menos permitem um “pouso seguro”
54. Exemplos Estamos com problemas de indexação em contas grandes. Podemos desabilitar a barra de busca para apenas algumas contas.
55. Princípio do mal menor: melhor uma funcionalidade a menos que a aplicação inteira parada
56. Tenha no mínimo dois
57. Timeout onde for possível
58. Desafios Estratégias de migrations (DDL) em multi-tenant Gerenciamento de feature toggles Instalações locais e multi cloud Expansão da equipe
59. Estamos contratando! https://clicksign.gupy.io/
60. "Clicksign vagas" no Google
61. Dúvidas?