Confiabilidade é tudo
Para quê serve um site, produto ou serviço em que seus clientes não podem confiar? Quantos erros eles ainda tolerarão até te trocarem pela concorrência?
Pois é. Já passou da hora de falarmos sobre SRE.
Mas antes, uma aula de história
Desde há muito tempo, equipes de desenvolvimento vêm desenvolvendo diversos tipos de sistemas multiusuário para atender às necessidades de seus clientes, internos ou externos. E durante todo esse tempo, a operação da infraestrutura necessária para rodar esses sistemas ficava a cargo de um outro time - o de Infraestrutura - que conhecia pouco ou nada do processo de desenvolvimento de sistemas.
De um lado tínhamos uma equipe cobrada pr entregar mais e mais funcionalidades para atender a um negócio em eterno estado de mudança, enquanto de outro lado estavam aqueles por garantir a estabilidade do ambiente. E não há nada mais danoso à estabilidade que a mudança. Conflitos quase sempre eram inevitáveis.
Inevitavelmente, alguma coisa precisaria mudar. Afinal, os departamentos de TI nas grandes empresas estavam virando enormes gargalos e impedindo o negócio de crescer. Além disso, o (pouco) trabalho entregue estava sempre com problemas de qualidade que minavam a confiança naquilo que estava sendo entregue.
Primeira tentativa: Agilidade
Como forma de melhorar a qualidade e consistência do trabalho produzido por equipes de desenvolvimento, o primeiro passo era melhorar a maneira como se escrevia software - e também a forma de gerenciar esses projetos de software. O movimento de Agilidade, marcado pelo Manifesto Ágil, visava justamente a definir melhores maneiras de de conduzir projetos de software.
Extreme Programming (XP), Lean/Kanban, Scrum… Não importa seu “sabor” preferido de Agile, com certeza sua forma de escrever software só tinha a ganhar com a adoção de um modelo de trabalho ágil.
Mas restava um “problema” - a equipe de infraestrutura. Ou, melhor dizendo, o modelo de trabalho da infraestrutura. Isso porque de um lado as equipes de desenvolvimento estavam se tornando ágeis mas as de infraestrutura não estavam acompanhando a transformação. Ao otimizar o trabalho de Desenvolvimento, sem se preocupar com a parte de Operações, nós estávamos apenas empurrando o problema para a frente.
É fácil imaginar o que acontece quando fazemos uma analogia com uma linha de produção: se aceleramos a capacidade produtiva de um determinado estágio em nossa liha, sem se preocupar com a vazão do estágio seguinte, os produtos começarão a se acumular no meio da linha de produção, gerando estoque de partes inacabadas. Era preciso otimizar também as práticas de infraestrutura, senão todas as melhorias nas equipes de Desenvolvimento teriam sido em vão.
Era hora de tentar algo novo.
Segunda tentativa: DevOps
Sam Guckenheimer, Product Owner do Azure DevOps na Microsoft, não por acaso definiu DevOps como “a segunda década da Agilidade”. Isso porque muitos viam DevOps como uma forma de completar o “pedaço” que a Agilidade não tinha tido a oportunidade de transformar - o trabalho das equipes de Infraestrutura.
Com o advento de DevOps, passou-se a pensar mais em como garantir melhores processos de infraestrutura que permitissem às equipes de desenvolvimento entregar código com mais frequência e consistência. Práticas de automação e técnicas de coleta de telemetria permitiram o “encurtamento” dos laços de feedback - ou seja, as equipes ficavam sabendo mais rápido qual o resultado da liberação que haviam acabdo de fazer e podiam reagir de maneira mais rápida e certeira.
Entretanto, a verdade é que em muitos lugares não foi assim que as coisas aconteceram. DevOps não foi usado como uma oportunidade de melhorar o trabalho de Operações, mas sim uma chance de eliminar a participação da área de Infraestrutura no processo de implantação e operação de sistemas. Equipes de desenvolvimento passaram a assumir uma autonomia maior, tendo acesso direto aos ambientes de produção, cuidando “do seu quadrado”.
Arquiteturas de software que favorecem a modularização, como a de Microsserviços, permitiram uma autonomia até então impensada. Junte-se a isso o modelo self-service da nuvem e temos o nirvana das equipes de desenvolvimento: Com cada equipe responsável por seu componente, cuidando do seu ciclo de vida de ponta-a-ponta - incluindo a implantação em produção - parecia que finalmente estávamos chegando na Era do NoOps - onde não haveria mais a necessidade de se ter uma equipe de Infraestrutura.
Mas como acontece com quase tudo na vida, a verdade está no meio.
Por mais que se desse autonomia às equipes de desenvolvimento, isso nunca eliminou a necessidade de haver alguém responsável por olhar a infraestrutura como um todo. E, mais do que isso, com essa modularização excessiva dos sistemas, quem deteria a visão do todo?
Outro aspecto frequentemente negligenciado era a estabilidade dos serviços. Com o aumento da complexidade - e com todas essas equipes contribuindo com pequenos pedaços de um grande sistema - garantir que tudo isso operasse da melhor maneira possível continuava sendo um grande desafio.
E com isso voltamos à estaca zero. Continua havendo a necessidade de termos uma equipe de infraestrutura mantendo a operação funcionando, mas ainda amparada em práticas e ferramentas arcaicas. DevOps ajudou bastante, mas ainda não resolveu.
E agora?
Engenharia de Confiabilidade
Site Reliability Engineering (SRE) é uma disciplina ligada à Engenharia de Software, documentada por funcionários do Google pela primeira vez em 2003. Ou seja, não é exatamente uma novidade; pelo contrário, visto que surgiu antes mesmo daquilo que hoje chamamos DevOps.
Benjamin Treynor Sloss, VP de engenharia do Google, projetou e gerenciou uma equipe de operações para garantir a estabilidade de alguns dos serviços do Google.
A grande “novidade” na sua abordagem foi orientar sua equipe - que tipicamente usaria práticas e processos comuns em times de Infraestrutura - a trabalhar como se eles fossem, na verdade, uma equipe de engenharia (desenvolvimento) de software. Nas palavras dele:
SRE é o que acontece quando você pede a um engenheiro de software para projetar uma equipe de operações. Quando entrei para o Google em 2003 e fui incumbido de dirigir uma “Equipe de Produção” de sete engenheiros, toda a minha vida até então tinha sido na engenharia de software. Então eu projetei e gerenciei o grupo do jeito que eu gostaria que funcionasse se eu mesmo trabalhasse como SRE. Desde então, esse grupo amadureceu para se tornar a atual equipe de SRE do Google, que permanece fiel às suas origens, como imaginado por alguém que foi engenheiro de software a vida inteira.
Perceba, portanto, que SRE se propõe a resolver muitos dos problemas e situações que DevOps busca endereçar. Não por acaso, há quem diga que SRE é uma “implementação de DevOps” - ainda que tenha surgido antes do próprio DevOps :-).
SRE, enquanto disciplina, é muito mais prescritiva (e pragmática) que DevOps. Se de um lado DevOps se preocupa muito com “o que” precisa ser feito, sem necessariamente se preocupar com o “como”, SRE tende a ser muito mais prático e objetivo.
Isso significa que Engenheiros de SRE do local precisam de uma compreensão holística dos sistemas e das conexões entre esses sistemas. Os SREs devem ver o sistema como um todo e dar tanta atenção às interconexões entre sistemas quantos aos próprios componentes dos tais sistemas.
Além da compreensão dos sistemas, os engenheiros de SRE também são responsáveis por tarefas e resultados específicos. Estes são descritos nos sete princípios básicos da SRE, descritos pelos autores do The Site Reliability Workbook
-
As operações são um problema de software: “O princípio básico da SRE é que fazer bem as operações é um problema de software. A SRE deve, portanto, usar abordagens de engenharia de software para resolver esse problema.”
-
Gerenciar por SLOs (Service Level Objectives, objetivos de nível de serviço): Manter 100% de disponibilidade não é a meta do SRE. “Em vez disso, a equipe de produto e a equipe da SRE selecionam uma meta de disponibilidade apropriada para o serviço e sua base de usuários, e o serviço é gerenciado para essa SLO. Decidir sobre esse objetivo requer uma forte colaboração do negócio.”
-
Trabalhe para minimizar a labuta: “Labuta” é trabalho árduo, tedioso e manual. A SRE não aceita a labuta como padrão. “Acreditamos que se uma máquina pode realizar uma operação desejada, então a máquina muitas vezes deve fazê-lo. Essa é uma distinção (e um valor) não frequentemente vistos em outras organizações, onde a labuta é o trabalho, e é isso que você está pagando uma pessoa para fazer.”
-
Automatize o trabalho do ano inteiro: A automação anda lado a lado com a redução da labuta, “determinando o que automatizar, sob quais condições e como fazê-lo”.
-
Mova-se mais rápido reduzindo o custo da falha: Quanto mais tarde um problema for descoberto, mais difícil é corrigí-lo. A SRE aborda esse problema. “Os SREs são especificamente encarregados de melhorar a descoberta de problemas indesejáveis, gerando benefícios para a empresa como um todo.”
-
Compartilhe a responsabilidade com os desenvolvedores: SRE visa a reduzir as fronteiras e os silos que isolam as equipes. “Idealmente, tanto as equipes de desenvolvimento de produtos quanto as equipes de SRE devem ter uma visão holística da pilha — frontend, backend, bibliotecas, armazenamento, kernels e máquina física — e nenhuma equipe deve, de forma ciumenta, ser a única ‘dona’ de um componente.”
-
Use a mesma ferramenta, independentemente da função ou do cargo: No SRE, você não pode ter equipes diferentes usando diferentes conjuntos de ferramentas. “Não há uma boa maneira de gerenciar um serviço que tenha uma ferramenta para os SREs e outra para os desenvolvedores de produtos, com comportamentos diferentes (e potencialmente catastróficos) em diferentes situações. Quanto mais divergência você tiver, menos sua empresa se beneficia de cada esforço para melhorar cada ferramenta individual.”
Então SRE é a resposta para meus problemas?
Com acontece com quase tudo na vida, aqui também a resposta é um enorme “depende”.
Primeiramente, a implementação da SRE requer planejamento e consenso.
Por exemplo, uma empresa que deseja implementar o SRE precisa estar preparada para fazer algumas personalizações que levem em consideração as especificidades de seu negócio.
A coisa mais importante que uma organização deve considerar antes de se adotar a SRE é definir o que a SRE significa para a empresa e como ela funcionará, com uma declaração de apoio da liderança que permita sua adoção de maneira ampla e que vá muito além da equipe de SRE. Por conta das abordagens por vezes pouco ortodoxas da equipe de SRE, o “buy-in” da empresa é imprescindível.
Conclusão
Como você deve ter percebido, a adoção da SRE não pode ser algo apenas da boca para fora. É algo que precisa de planejamento, muito estudo, comprometimento da empresa e um esforço constante para se obter sucesso.
Pronto para aprender mais sobre SRE? Eis aqui alguns materiais de refeência para continuar seus estudos:
- Site Reliability Engineering
- Site Reliability Workbook
- Building Secure & Reliable Systems
- Seeking SRE
Ah, e não se esqueça: Se precisar de ajuda na sua empresa para adotar práticas de SRE e DevOps, não deixe de nos procurar. Teremos o maior prazer em compartilhar com sua empresa toda a nossa experiência!
Um abraço,
Igor
13/04/2020 | Por Igor Abade V. Leite | Em Negócios | Tempo de leitura: 10 mins.
