As 10 melhores palestras que assisti na SRECon18 Americas

Publicado por Matheus Rossato no dia eventos

srecon18_abertura.png

Entre 27 a 29 de Março de 2018, participei pela 2a vez da organização do SRECon’18, um dos melhores eventos de operação de sistemas de larga escala, que aconteceu em Santa Clara, Califórnia. Nos próximos parágrafos irei descrever brevemente o que vi e ouvi durante a conferência.

O que é Site Reliability Engineer (SRE)

Se você trabalha em uma empresa de tecnologia, possui um produto ou serviço em operação e ainda não ouviu falar em Site Reliability Engineer; recomendo ler o livro que o Google publicou sobre como eles rodam os sistemas em produção.

Ben Treynor, VP de Operações 24/7 do Google, define SRE como sendo quando você pede para um engenheiro de software fazer a operação de um sistema, basicamente ele usa todo o seu conhecimento e habilidades para poder fazer automação e automatização das suas atividades operacionais com o objetivo de garantir a disponibilidade e confiança.

O que é a SRECon

Agora que você já sabe um pouco o que que é SRE, vou falar sobre a SRECon’18 Américas, conferência sobre SRE que ocorre anualmente nos Estados Unidos, mais especificamente no Vale do Silício, organizada por pessoas da área para pessoas da área. Um fato relevante é que a conferência adota a política de acesso aberto a conteúdo da USENIX, ou seja, vídeo e/ou slides das apresentações são disponibilizados online gratuitamente. A organização principal fica por conta de funcionários do Google e Linkedin, porém grandes nomes da indústria também compõem o comitê organizador como Microsoft, Facebook, Apple, Netflix, Bloomberg, Dropbox, Intercom, IBM, Dropbox e nós da Resultados Digitais.

Esse ano a SRECon’18 Américas retornou para Santa Clara, após a última edição em San Francisco, e contou com 700 participantes de 23 países. Um novidade que tivemos foi a inclusão de 1 dia com 8 workshops e 2 dias com 39 palestras. Também foi listada como uma das 10 principais conferências de DevOps para 2018 segundo o OpsGenie.

Torço que os pontos que irei apresentar abaixo te incentivem a participar da próxima SRECon, eu com certeza irei e espero te ver lá ;)

Os pontos que levei das apresentações e desses 3 dias de evento, foram:

TL;DR;

Quanto mais maduros os processos e os times de produto/engenharia, menor é o tempo de resposta, normalização e consequentemente do incidente, não necessariamente a quantidade de incidentes. Assim como serviços de emergência, times também precisam praticar resposta a incidentes. Estrutura da organização em tempos de paz (padrão) é e deve ser diferente da estrutura em tempos de guerra (emergência), afinal cada emergência tem detalhes específicos e requer uma estrutura adequada para resposta. - Brent Chapman, Great Circle Associates (ex-Google)

Métricas boas para se medir maturidade da engenharia de uma organização são:

  • Quanto tempo demoramos para enviar mudanças(delta do commit para prod);
  • Frequência que fazemos liberações;
  • Tempo para restaurar um serviço após um incidente;
  • Quanto precisamos voltar versão (rollout / rollback);

Esqueça métricas como:

  • Linhas de código = muitos sistemas são inchados, maior quantidade de linhas, maior a manutenção consequentemente maior o custo da mudança;
  • Velocidade do time = pontos entregues na sprint é uma medida relativa e não permite comparar times, fácil de burlar inflando a estimativa;
  • Utilização = bom até certo ponto, mas não permite espaço para trabalho não planejado, segundo teoria das Filas, aproximando 100% de utilização o Lead Time tende ao infinito (∞)

Jez Humble fala mais sobre métricas e maturidade das organizações em seu livro Accelerate

Estatística aplicada e aprendizado de máquina (Machine Learning) já são uma realidade sendo aplicadas pelas grandes empresas para identificar problemas em produção, reduzir o tempo de resposta a incidente e também no planejamento predição de capacidade. - Rick Boone, Uber e Lorenzo Saino, Fastly

Depois de Cloud ser o novo normal agora é a vez de containers com Docker. Praticamente todas as empresas estão usando docker em produção e muitas migraram ou estão estudando migrar para Kubernetes. - Bridget Kromhout, Microsoft e Rodrigo Menezes, Pinterest

Na RD temos vaga para SRE - Site Reliability Engineering, confira.

Long version;

Dia 1 Workshops

Incident Command for IT—What We’ve Learned from the Fire Department por Brent Chapman, Great Circle Associates, Inc. (Ex-Google SRE)

Começou definindo o que na visão dele é um Major Incident: Array de discos falhando é operação de rotina, só se torna um Major Incident se não for tratada corretamente e tirar o serviço do ar.

  • Entrou nos detalhes de como de fato ocorre a gestão de incidente no Google;
  • Explicou como gerir múltiplos incidentes ao mesmo tempo;
  • Ensinou como fazer handoff e trazer pessoas para ajudar no incidente;

Apresentou 3 papéis principais e suas respectivas responsabilidades:

  • Subject Matter Expert;
  • Tech Lead;
  • Incident Commander;

Emergência, declarar para informar à empresa que está operando sob regras específicas.
Objetivo é retornar para operação padrão o mais rápido possível, importante comunicar quando encerrado.
Peacetime Vs Wartime = mudança de estrutura organizacional para reagir a diferente tipo de situação.

Kubernetes 101 por Bridget Kromhout, Microsoft

Apresentação da Bridget é uma adaptação da original do Jerome Petazzoni um dos principais evangelistas do Docker, disponível em container.trainning.

Uma introdução mão na massa em container e kubernetes. Possível fazer em casa caso não tenha familiaridade ou queira entender um pouco mais, aliás, recomendo ;)

Dia 2 Abertura e apresentações

If You Don’t Know Where You’re Going, It Doesn’t Matter How Fast You Get There por Nicole Forsgren and Jez Humble, DevOps Research and Assessment (DORA)

Defenderam como a Direção é mais importante que o Destino, Time também é uma peça chave e referenciam o estudo do Google sobre times efetivos (Rework, Effective Teams)

Métricas fáceis não são as melhores, apontaram erros comum como medir Output vs Outcome:

  • Linhas de código = muitos sistemas são inchados, maior quantidade de linhas, maior a manutenção consequentemente maior o custo da mudança;
  • Velocidade do time = pontos entregues na sprint é uma medida relativa e não permite comparar times, fácil de burlar inflando a estimativa;
  • Utilização = bom até certo ponto, mas não permite espaço para trabalho não planejado, segundo teoria das Filas, aproximando 100% de utilização o Lead Time tende ao infinito (∞)

Segundo estudo deles, as métricas que apontam maturidade da organização são:

  • tempo que demoramos para enviar mudanças(delta do commit para prod);
  • frequência de liberações;
  • tempo para restaurar um serviço;
  • taxa de liberações / voltar versão (rollout / rollback);

As práticas de desenvolvimento e operação tem impacto mensurável na organização:

“Firms with high-performing IT organizations were twice as likely to exceed their profitability, market share and productivity goals.” http://bit.ly/2014-devops-report/, http://bit.ly/2017-devops-report/

Comparação entre níveis de maturidade das organizações:

srecon18_it_performance.png

SparkPost: The Day the DNS Died por Jeremy Blosser, SparkPost

Enviam 25-30% dos emails não-spam da internet, 15Bi/mês;

Falaram de um enorme incidente que durou 7 horas e como ao longo dos meses reescreveram o sistema de DNS deles uma dezena de vezes até ter total isolamento dos componentes.

Sobre o incidente, DNS falhou em várias escalas. Parou muitos serviços devido a dependências:

  • SSH;
  • LDAP;
  • VPN;
  • Admin panels;
  • Ferramentas de monitoração/alerta.

Causa raiz foi um limite de conexão não documentado da AWS:
Pessoal do suporte da AWS não acreditava que eles tinham 40mb/s de tráfego real de query DNS passando na infra.

Lição aprendida é que como toda empresa, provedores de cloud também tem coisa não documentada.

Stable and Accurate Health-Checking of Horizontally-Scaled Services por Lorenzo Saino, Fastly

Fastly é uma CDN com serviços agregados. Github, Newrelic, Vimeo e outras grandes usam eles.

Tem muitos PoPs (Point-of-Presence) pelo mundo:

  • Espaço e energia é muito caro em um PoP;
  • Se precisa de mais capacidade, precisa adicionar mais um servidor. Tem que comprar, mandar entregar, instalar, não conseguem em menos de 30 dias.

Coletam métricas de erro e tempo de resposta das instâncias no mundo e agregam em um processador de métricas para passar por um filtro de 3 estágios:

  • Denoising: removem ruídos, buscam mudanças persistentes e não picos;
  • Anomaly detection: comparam as instâncias e identificam os hosts se comportando de forma inesperada;
  • Hysteresis filter: previne troca de estado indesejado quando muda muito de estado ok / nok;

Usam bastante estatística aplicada e com essas informações conseguem decidir entre remover um host ou fazer redirecionamento de tráfego para outro PoP sem precisar adicionar um novo servidor.

How SREs Found More than $100 Million Using Failed Customer Interactions por Wes Hummel, PayPal

No Paypal processam mais de 16537 transações/segundos;

Precisaram mudar o método de medir disponibilidade (availability).

Definiram failed customer interactions (fcis) que são:

  • Ações que o cliente desejava executar e que não conseguiam;
  • Ganharam visões por dono(time) da função, região(global) onde está falhando o sistema, funcionalidade que está falhando.

O caminho foi dolorido, tiveram que consertar logs e consequentemente as interações que falhavam;

Reduziram fcis em 95% nos últimos 2 anos.

  • Aumentaram em ~1% a receita;
  • Economizaram em torno de $20M com custos de Call Center por não precisarem atender suporte de clientes/parceiros com problemas no processamento de transações.

Heatmap que mostra a redução dos erros, consequentemente aumento do faturamento.

srecon18_paypal_heatmap.png

Dia 3 Apresentações e encerramento

Containerization War Stories por Ruth Grace Wong and Rodrigo Menezes, Pinterest

Falou sobre a dor que eles tiveram nos últimos 3 anos tentando migrar de Masterful Puppet para Materless Puppet. Desistiram e foram para Docker :) Comentou dos problemas de migrar conf file para docker file. Estão testando Kubernetes ainda.

Resolving Outages Faster with Better Debugging Strategies por Liz Fong-Jones and Adam Mckaig, Google

Apresentaram algumas das ferramentas de debugging distribuído que usam no Google e como fazem para debugar os sistemas da empresa, bem legal :)

“Capacity Prediction” Instead of “Capacity Planning”: How Uber Uses ML to Accurately Forecast Resource Utilization por Rick Boone, Uber

Capacity Planning, é necessário para que um serviço seja:

  • Confiável: serviço não vai falhar ou degradar pela falta de recursos;
  • Eficiente: serviço não vai gerar desperdícios por alocar muitos recursos (e não usar);

Descreve como é difícil fazer planejamento de capacidade em escala, e argumenta que precisaram mudar de planning para prediction.

O que importa para eles são as viagens (Trips) e como isso afeta os sistemas (CPU). No gráfico abaixo Trips temos a relação entre Trips Ingress e CPU em azul, bem como a predição em vermelho. Esse modelo é ajustado para a predição superar a demanda, permitindo o processamento de todas as instruções.

srecon18_capacity_safe.png

Operational Excellence in April Fools’ Pranks: Being Funny Is Serious Work! por Thomas Limoncelli, Stack Overflow, Inc

Foram fazer uma brincadeira de 1o de Abril e acabou derrubando o StackOverflow ;)

Dicas para April Fool Prank ou qualquer outra situação de verdade:

  • Feature Flag = Melhor que deployar um binário e possivelmente introduzir um bug;
  • Load Testing = É o “passar fio dental” de TI, todo mundo diz que faz, mas só faz de fato 2 dias antes do dentista(auditor);
  • Dark Launch = Deu exemplo para caso que Milhões/Bilhões de usuários irão usar o sistema no dia 0. Facebook Messenger, rodavam javascript no Browser e mandava escondido mensagens na plataforma para já testar a plataforma antes do lançamento oficial;
  • Involve All Silos = Comunicar Marketing, PR, QA, PMs, Customer Services e Executivos, assim ninguém é pego de surpresa.

Project Retrospective = Fazer uma retrospectiva para entender e aprender o que deu certo, errado, aprendemos no processo. Melhoria contínua.

Conclusão

Espero ter trazido os principais pontos que demonstram por que esse evento é considerado um dos mais importante no assunto e as coisas interessantes sendo feita pelas empresas que muitos de nós usamos como referência.

Caso se interesse por Site Reliability Engineering, não deixe de se candidatar em nossa vaga. Essa foi minha 3a participação no evento e pretendo estar na próxima, e você achou interessante os tópicos e conteúdos? Deixe um comentário abaixo e nos vemos na próxima SRECon.

Matheus Rossato

Matheus Rossato

Team Leader

Comentários