Capítulo 32 - O Modelo de Envolvimento Evolutivo do SRE

Escrito por Acacio Cruz e Ashish Bhambhani

Editado por Betsy Beyer e Tim Harvey

Envolvimento do SRE: O quê, como, e por quê

Discutimos na maior parte do resto deste livro o que acontece quando o SRE já está encarregado de um serviço. Poucos serviços começam o seu ciclo de vida desfrutando de suporte SRE, portanto, é preciso haver um processo para avaliar um serviço, certificando-se de que ele merece suporte SRE, negociando como melhorar quaisquer déficits que impeçam o suporte SRE e, de fato, instituindo suporte SRE. Chamamos a este processo integração. Se estiver num ambiente em que esteja rodeado por muitos serviços existentes em vários estados de perfeição, a sua equipe SRE estará provavelmente executando uma fila prioritária de integrações durante algum tempo até que a equipe tenha terminado de assumir as metas de maior valor.

Embora isto seja muito comum, e uma forma completamente razoável de lidar com um ambiente de fato consumado, existem pelo menos duas formas melhores de trazer a sabedoria da produção, e o apoio do SRE, aos serviços antigos e novos.

No primeiro caso, tal como na engenharia de software – onde quanto mais cedo for encontrado o bug, mais barato será a correção -, quanto mais cedo acontece uma consulta à equipe SRE, melhor será o serviço e mais rapidamente sentirá o benefício. Quando o SRE é engajado durante os estágios iniciais do projeto, o tempo de integração é reduzido e o serviço é mais confiável “na largada”, geralmente porque não temos que passar o tempo desenrolando projeto ou implementação subótima.

Outra forma, talvez a melhor, é encurtar o processo através do qual sistemas especialmente criados com muitas variações individuais acabam “chegando” à porta do SRE. Forneça ao desenvolvimento de produtos uma plataforma de infraestruturas validadas pelo SRE, sobre a qual possam construir os seus sistemas. Esta plataforma terá a dupla vantagem de ser ao mesmo tempo confiável e escalável. Isto evita inteiramente certas classes de problemas de carga cognitiva, e ao abordar práticas comuns de infraestruturas, permite às equipes de desenvolvimento de produtos concentrarem-se na inovação na camada de aplicação, à qual ela pertence principalmente.

Nas seções seguintes, passaremos algum tempo analisando cada um destes modelos por sua vez, começando pelo “clássico”, o modelo orientado por PRR.

O modelo PRR

O passo inicial mais típico do envolvimento do SRE é a Revisão da Prontidão da Produção (PRR), um processo que identifica as necessidades de confiabilidade de um serviço com base nos seus detalhes específicos. Através de um PRR, os SREs procuram aplicar o que aprenderam e experimentaram para assegurar a confiabilidade de um serviço que opera na produção. Um PRR é considerado um pré-requisito para que uma equipe SRE aceite a responsabilidade de gerir os aspectos de produção de um serviço.

A figura 32-1 ilustra o ciclo de vida de um serviço típico. A Revisão de Prontidão da Produção pode ser iniciada em qualquer ponto do ciclo de vida do serviço, mas as fases em que o compromisso SRE é aplicado têm-se expandido ao longo do tempo. Este capítulo descreve o Modelo PRR Simples, depois discute como a sua modificação no Modelo de Engajamento Estendido e nas Estruturas e Plataforma SRE permitiram ao SRE escalar o seu processo de engajamento e impacto.

Figura 32-1. Um ciclo de vida de serviço típico

O Modelo de Engajamento SRE

O SRE procura a responsabilidade pela produção de serviços importantes para os quais pode dar contribuições concretas para a confiabilidade. O SRE preocupa-se com vários aspectos de um serviço, que são coletivamente referidos como produção. Estes aspectos incluem o seguinte:

Arquitectura do sistema e dependências inter-serviços
Instrumentação, métrica e monitoramento
Resposta de emergência
Planejamento de capacidade
Gestão de mudanças
Desempenho: disponibilidade, latência, e eficiência

Quando os SREs se envolvem num serviço, o nosso objetivo é melhorá-lo ao longo de todos estes eixos, o que torna mais fácil a gestão da produção para o serviço.

Apoio alternativo

Nem todos os serviços do Google recebem um envolvimento próximo do SRE. Alguns fatores estão aqui em jogo:

Muitos serviços não precisam de alta confiabilidade e disponibilidade, portanto, o apoio pode ser fornecido por outros meios.
Por projeto, o número de equipes de desenvolvimento que solicitam apoio SRE excede a largura de banda disponível das equipes SRE (ver Capítulo 1).

Quando o SRE não pode fornecer apoio completo, fornece outras opções para fazer melhorias na produção, tais como documentação e consulta.

Documentação

Estão disponíveis guias de desenvolvimento para tecnologias internas e clientes de sistemas amplamente utilizados. O Guia de Produção do Google documenta as melhores práticas de produção de serviços, tal como determinado pelas experiências do SRE e das equipes de desenvolvimento. Os desenvolvedores podem implementar as soluções e recomendações em tal documentação para melhorar os seus serviços.

Consulta

Os desenvolvedores podem também procurar consultoria do SRE para discutir serviços específicos ou áreas problemáticas. A equipe de Engenharia de Coordenação de Lançamento (LCE) (ver Capítulo 27) passa a maior parte do seu tempo consultando as equipes de desenvolvimento. As equipes SRE que não estão especificamente dedicadas ao lançamento de consultas também se envolvem em consultas com as equipes de desenvolvimento.

Quando um novo serviço ou uma nova funcionalidade é implementado, os desenvolvedores consultam normalmente o SRE para aconselhamento sobre a preparação para a fase de Lançamento. A consulta de lançamento envolve normalmente um ou dois SREs que passam algumas horas estudando o projeto e a implementação em alto nível. Os consultores do SRE reúnem-se então com a equipe de desenvolvimento para aconselhar sobre áreas de risco que necessitam de atenção e para discutir padrões ou soluções bem conhecidas que possam ser incorporadas para melhorar o serviço na produção. Alguns destes conselhos podem vir do Guia de Produção mencionado anteriormente.

As sessões de consulta são necessariamente amplas porque não é possível obter uma compreensão profunda de um determinado sistema no tempo limitado disponível. Para algumas equipes de desenvolvimento, a consulta não é suficiente:

Serviços que cresceram por ordens de magnitude desde o seu lançamento, que agora requerem mais tempo para compreender do que é viável através de documentação e consulta.
Serviços com os quais muitos outros serviços passaram a depender posteriormente, os quais recebem agora um tráfego significativamente maior de muitos clientes diferentes.

Estes tipos de serviços podem ter crescido ao ponto de começarem a encontrar dificuldades significativas na produção, ao mesmo tempo que se tornam importantes para os usuários. Nesses casos, torna-se necessário um envolvimento a longo prazo do SRE para assegurar que são devidamente mantidos na produção à medida que crescem.

Análises de prontidão da produção: Modelo PRR simples

Quando uma equipe de desenvolvimento solicita que o SRE assuma a gestão da produção de um serviço, o SRE avalia tanto a importância do serviço como a disponibilidade das equipes SRE. Se o serviço merecer o apoio do SRE, e a equipe SRE e a organização de desenvolvimento acordarem os níveis de pessoal para facilitar esse apoio, o SRE inicia uma Revisão de Prontidão para a Produção com a equipe de desenvolvimento.

Os objetivos da Revisão de Prontidão para a Produção são os seguintes:

Verificar se um serviço cumpre os padrões aceites de configuração de produção e prontidão operacional, e se os proprietários do serviço estão preparados para trabalhar com o SRE e aproveitar a experiência do SRE.
Melhorar a confiabilidade do serviço na produção, e minimizar o número e a gravidade dos incidentes que podem ser esperados. Um PRR visa todos os aspectos da produção com os quais o SRE se preocupa.

Após terem sido feitas melhorias suficientes e o serviço ser considerado pronto para o apoio do SRE, uma equipe do SRE assume as suas responsabilidades de produção.

Isto leva-nos ao próprio processo de Revisão de Prontidão de Produção. Existem três modelos de envolvimento diferentes, mas relacionados (Modelo PRR Simples, Modelo de Envolvimento Antecipado, e Estruturas e Plataforma SRE), que serão discutidos por sua vez.

Descreveremos em primeiro lugar o Modelo PRR Simples, que normalmente é direcionado a um serviço que já está lançado e que será assumido por uma equipe SRE. Um PRR segue várias fases, muito parecidas com um ciclo de vida de desenvolvimento, embora possa proceder de forma independente em paralelo com o ciclo de vida de desenvolvimento.

Envolvimento

A liderança do SRE decide primeiro qual a equipe do SRE que se adequa bem para assumir o serviço. Normalmente, um a três SREs são selecionados ou auto-nomeados para conduzir o processo de PRR. Este pequeno grupo inicia então a discussão com a equipe de desenvolvimento. A discussão abrange assuntos tais como:

Estabelecimento de um SLO/SLA para o serviço
Planejamento de alterações de projeto potencialmente disruptivas, necessárias para melhorar a confiabilidade
Planejamento e cronogramas de treinamento

O objetivo é chegar a um acordo comum sobre o processo, objetivos finais e resultados necessários para que a equipe do SRE se envolva com a equipe de desenvolvimento e o seu serviço.

Análise

A análise é o primeiro grande segmento de trabalho. Durante esta fase, os revisores do SRE tomam conhecimento do serviço e começam a analisá-lo para detectar falhas de produção. O seu objetivo é medir a maturidade do serviço ao longo dos vários eixos de preocupação do SRE. Examinam também o projeto e a implementação do serviço para verificar se este segue as melhores práticas de produção. Normalmente, a equipe do SRE estabelece e mantém uma lista de verificação de PRR explicitamente para a fase de Análise. A lista de verificação é específica ao serviço e é geralmente baseada em conhecimentos de domínio, experiência com sistemas relacionados ou semelhantes, e melhores práticas do Guia de Produção. A equipe SRE pode também consultar outras equipes que tenham mais experiência com determinados componentes ou dependências do serviço.

Alguns exemplos de itens da lista de controle incluem:

As atualizações do serviço têm impacto numa percentagem exageradamente elevada do sistema de uma só vez?
O serviço está ligado à instância de serviço apropriada das suas dependências? Por exemplo, os pedidos do usuário final a um serviço não devem depender de um sistema projetado para um caso de uso de processamento em lote.
O serviço solicita uma qualidade de serviço de rede suficientemente elevada ao conversar com um serviço remoto crítico?
O serviço reporta erros aos sistemas centrais de log para análise? Comunica todas as condições excepcionais que resultam em respostas degradadas ou falhas para os usuários finais?
Todas as falhas visíveis dos pedidos dos usuários são bem instrumentadas e monitorizadas, com um alerta adequado configurado?

A lista de verificação pode também incluir normas operacionais e melhores práticas seguidas por uma equipe específica do SRE. Por exemplo, uma configuração de serviço perfeitamente funcional que não siga o “padrão de ouro” de uma equipe SRE pode ser refatorada para funcionar melhor com as ferramentas SRE para uma gestão escalável das configurações. Os SREs também analisam os incidentes recentes e os postmortems para o serviço, bem como as tarefas de seguimento dos incidentes. Esta avaliação mede as exigências de resposta de emergência para o serviço e a disponibilidade de controles operacionais bem estabelecidos.

Melhoramentos e Refactoring

A fase de Análise leva à identificação das melhorias recomendadas para o serviço. Esta fase seguinte prossegue da seguinte forma:

As melhorias são priorizadas com base na importância para a confiabilidade do serviço.
As prioridades são discutidas e negociadas com a equipe de desenvolvimento, e é acordado um plano de execução.
Tanto o SRE como as equipes de desenvolvimento de produtos participam e assistem-se mutuamente na refatoração de partes do serviço ou na implementação de características adicionais.

Esta fase tipicamente varia mais em duração e quantidade de esforço. O tempo e esforço que esta fase implicará depende da disponibilidade de tempo de engenharia para o refactoring, da maturidade e complexidade do serviço no início da revisão, e de inúmeros outros fatores.

Treinamento

A responsabilidade pela gestão de um serviço na produção é geralmente assumida por toda uma equipe de SRE. Para assegurar a preparação da equipe, os revisores do SRE que lideraram o PRR se apropriam do treinamento da equipe, que inclui a documentação necessária para dar suporte ao serviço. Normalmente com a ajuda e participação da equipe de desenvolvimento, estes engenheiros organizam uma série de sessões de treinamento e exercícios. As instruções podem incluir:

Panorama geral do projeto
Aprofundamentos em vários fluxos de solicitação no sistema
Uma descrição da configuração da produção
Exercícios práticos para vários aspectos das operações do sistema

Ao final do treinamento, a equipe do SRE deve estar preparada para gerenciar o serviço.

Onboarding (Integração)

A fase de Treinamento desbloqueia a integração do serviço pela equipe SRE. Envolve uma transferência progressiva de responsabilidades e propriedade de vários aspectos de produção do serviço, incluindo partes das operações, o processo de gestão da mudança, direitos de acesso, etc. A equipe SRE continua a concentrar-se nas várias áreas de produção mencionadas anteriormente. Para completar a transição, a equipe de desenvolvimento deve estar disponível para apoiar e aconselhar a equipe SRE durante um período de tempo, à medida que esta se estabelece na gestão da produção para o serviço. Esta relação torna-se a base para o trabalho contínuo entre as equipes.

Melhoramento Contínuo

Os serviços ativos mudam continuamente em resposta a novas exigências e condições, incluindo pedidos de novas funcionalidades, dependências de sistema em evolução e atualizações tecnológicas, além de outros fatores. A equipe do SRE deve manter os padrões de confiabilidade dos serviços face a estas mudanças, conduzindo a uma melhoria contínua. A equipe SRE responsável aprende naturalmente mais sobre o serviço no decurso da operação do serviço, revendo novas alterações, respondendo a incidentes, e especialmente ao realizar análises post-mortem/causa raiz. Esta experiência é partilhada com a equipe de desenvolvimento como sugestões e propostas de alterações ao serviço sempre que novas características, componentes e dependências possam ser acrescentadas ao serviço. As lições da gestão do serviço também contribuem para as melhores práticas, que estão documentadas no Guia de Produção e em outros locais.

Engajamento com Shakespeare

Inicialmente, os desenvolvedores do serviço Shakespeare eram os responsáveis pelo produto, inclusive carregando o pager para atendimento de emergência. Contudo, com a crescente utilização do serviço e o crescimento das receitas provenientes do serviço, o apoio do SRE tornou-se desejável. O produto já tinha sido lançado, então o SRE realizou uma Revisão de Prontidão de Produção. Uma das coisas que descobriram foi que os painéis de bordo não cobriam completamente algumas das métricas definidas no SLO, então isso precisava ser corrigido. Depois que todos os problemas que tinham sido arquivados terem sido corrigidos, o SRE assumiu o pager para o serviço, embora dois programadores também estivessem em rotação de plantão. Os desenvolvedores estão participando da reunião semanal de plantão discutindo os problemas da semana passada e como lidar com as próximas manutenções em larga escala ou desligamentos de cluster. Além disso, planos futuros para o serviço agora são discutidos com os SREs para garantir que novos lançamentos ocorram perfeitamente (embora a lei de Murphy esteja sempre procurando oportunidades para estragar isso).

Evolução do Modelo PRR Simples: Envolvimento Antecipado

Até agora, discutimos a Revisão da Prontidão para a Produção, tal como é utilizada no Modelo PRR Simples, que se limita aos serviços que já entraram na fase de Lançamento. Existem várias limitações e custos associados a este modelo. Por exemplo:

A comunicação adicional entre equipes pode aumentar alguma sobrecarga do processo para a equipe de desenvolvimento, e a carga cognitiva para os revisores do SRE.
Os revisores certos do SRE devem estar disponíveis, e capazes de gerir o seu tempo e prioridades no que diz respeito aos seus compromissos existentes.
O trabalho realizado pelos SREs deve ser altamente visível e suficientemente revisado pela equipe de desenvolvimento para assegurar o compartilhamento efetivo do conhecimento. Os SREs devem trabalhar essencialmente como parte da equipe de desenvolvimento, e não como uma unidade externa.

No entanto, as principais limitações do Modelo PRR resultam do fato de que o serviço é lançado e servido em escala, e o envolvimento do SRE começa muito tarde no ciclo de vida do desenvolvimento. Se o PRR ocorresse mais cedo no ciclo de vida do serviço, a oportunidade do SRE de remediar potenciais problemas no serviço aumentaria consideravelmente. Como resultado, o sucesso do compromisso do SRE e o sucesso futuro do próprio serviço provavelmente melhoraria. As desvantagens resultantes podem representar um desafio significativo para o sucesso do envolvimento do SRE e o sucesso futuro do próprio serviço.

Candidatos a Envolvimento Antecipado

O Modelo de Envolvimento Antecipado introduz o SRE mais cedo no ciclo de vida do desenvolvimento, a fim de alcançar vantagens adicionais significativas. A aplicação do Modelo de Envolvimento Antecipado requer a identificação da importância e/ou valor comercial de um serviço no início do ciclo de vida do desenvolvimento, e a determinação se o serviço terá escala ou complexidade suficiente para se beneficiar da perícia do SRE. Os serviços aplicáveis têm frequentemente as seguintes características:

O serviço implementa novas funcionalidades significativas e fará parte de um sistema existente já gerido pelo SRE.
O serviço é uma reescrita significativa ou alternativa a um sistema existente, visando os mesmos casos de utilização.
A equipe de desenvolvimento procurou o conselho do SRE ou abordou o SRE para aquisição no lançamento.

O Modelo de Envolvimento Antecipado mergulha essencialmente os SREs no processo de desenvolvimento. O foco do SRE permanece o mesmo, embora os meios para alcançar um melhor serviço de produção sejam diferentes. O SRE participa no Design e fases posteriores, eventualmente assumindo o serviço a qualquer momento durante ou após a fase de Construção. Este modelo baseia-se na colaboração ativa entre as equipes de desenvolvimento e o SRE.

Benefícios do Modelo de Envolvimento Antecipado

Embora o Modelo de Envolvimento Antecipado implique certos riscos e desafios discutidos anteriormente, a perícia e colaboração adicionais do SRE durante todo o ciclo de vida do produto cria benefícios significativos em comparação com um envolvimento iniciado mais tarde no ciclo de vida do serviço.

Fase de design

A colaboração do SRE durante a fase de design pode evitar a ocorrência de uma variedade de problemas ou incidentes mais tarde na produção. Embora as decisões de design possam ser invertidas ou retificadas mais tarde no ciclo de vida do desenvolvimento, tais mudanças têm um custo elevado em termos de esforço e complexidade. Os melhores incidentes de produção são aqueles que nunca acontecem!

Ocasionalmente, as trocas difíceis conduzem à seleção de um design menos que ideal. A participação na fase de Design significa que os SREs estão cientes das contrapartidas e fazem parte da decisão de escolher uma opção menos do que ideal. O envolvimento precoce do SRE visa minimizar futuras disputas sobre escolhas de design, quando o serviço estiver em produção.

Construção e implementação

A fase de Construção aborda aspectos de produção tais como instrumentação e métrica, controles operacionais e de emergência, utilização de recursos, e eficiência. Durante esta fase, o SRE pode influenciar e melhorar a implementação, recomendando bibliotecas e componentes específicos existentes, ou ajudando a construir certos controles no sistema. A participação do SRE nesta fase ajuda a facilitar as operações no futuro e permite que o SRE ganhe experiência operacional antes do lançamento.

Lançamento

O SRE pode também ajudar a implementar padrões e controles de lançamento amplamente utilizados. Por exemplo, o SRE pode ajudar a implementar uma configuração de “lançamento escuro”, em que parte do tráfego dos usuários existentes é enviado para o novo serviço, além de ser enviado para o serviço de produção ao vivo. As respostas do novo serviço são “escuras”, uma vez que são jogadas fora e não são realmente mostradas aos usuários. Práticas como os lançamentos “escuros” permitem à equipe obter uma visão operacional, resolver problemas sem afetar os usuários existentes, e reduzir o risco de encontrar problemas após o lançamento. Um lançamento suave é imensamente útil para manter a carga operacional baixa e manter o ímpeto de desenvolvimento após o lançamento. As interrupções em torno do lançamento podem facilmente resultar em alterações de emergência do código fonte e da produção, e perturbar o trabalho da equipe de desenvolvimento em recursos futuros.

Pós-lançamento

Ter um sistema estável no momento do lançamento conduz geralmente a menos prioridades conflituosas para a equipe de desenvolvimento em termos de escolha entre melhorar a confiabilidade do serviço versus acrescentar novas funcionalidades. Em fases posteriores do serviço, as lições das fases anteriores podem informar melhor o refactoring ou o redesenho.

Com um envolvimento estendido, a equipe SRE pode estar pronta para assumir o novo serviço muito mais cedo do que é possível com o Modelo PRR Simples. O envolvimento mais longo e estreito entre o SRE e as equipes de desenvolvimento também cria uma relação de colaboração que pode ser sustentada a longo prazo. Uma relação positiva entre as equipes promove um sentimento mútuo de solidariedade, e ajuda o SRE a estabelecer a propriedade da responsabilidade de produção.

Desvinculação de um serviço

Por vezes, um serviço não garante um gerenciamento completo da equipe do SRE – esta determinação pode ser feita após o lançamento, ou o SRE pode comprometer-se com um serviço, mas nunca assumi-lo oficialmente. Este é um resultado positivo, porque o serviço foi projetado para ser confiável e de baixa manutenção, e pode portanto permanecer com a equipe de desenvolvimento.

Também é possível que o SRE se envolva cedo com um serviço que não atinja os níveis de utilização previstos. Nesses casos, o esforço gasto pelo SRE é simplesmente parte do risco empresarial geral que acompanha os novos projetos, e um pequeno custo relativo ao sucesso dos projetos que atingem a escala esperada. A equipe SRE pode ser realocada, e as lições aprendidas podem ser incorporadas no processo de engajamento.

Desenvolvimento de Serviços em Evolução: Estruturas e Plataforma SRE

O Modelo de Envolvimento Antecipado avançou na evolução do envolvimento do SRE para além do Modelo PRR Simples, que se aplicava apenas a serviços que já tinham sido lançados. No entanto, ainda havia progresso a ser feito no dimensionamento do envolvimento do SRE para o próximo nível, projetando para confiabilidade.

Lições aprendidas

Ao longo do tempo, o modelo de compromisso SRE descrito até agora produziu vários padrões distintos:

A integração de cada serviço exigia dois ou três SREs e normalmente duravam dois ou três trimestres. Os tempos de espera para um PRR eram relativamente altos (trimestres de distância). O nível de esforço requerido foi proporcional ao número de serviços em análise, e foi limitado pelo número insuficiente de SREs disponíveis para conduzir PRRs. Estas condições levaram a uma serialização das aquisições de serviços e a uma priorização rigorosa dos serviços.
Devido às diferentes práticas de software entre serviços, cada característica de produção foi implementada de forma diferente. Para cumprir as normas impulsionadas por PRR, as características tiveram geralmente de ser reimplementadas especificamente para cada serviço ou, na melhor das hipóteses, uma vez para cada pequeno subconjunto de código de compartilhamento de serviços. Estas reimplementações foram um desperdício de esforço de engenharia. Um exemplo canônico é a implementação de estruturas de log funcionalmente semelhantes repetidamente na mesma língua, porque serviços diferentes não implementaram a mesma estrutura de codificação.
Uma análise de questões e interrupções comuns de serviços revelou certos padrões, mas não havia forma de replicar facilmente as correções e melhorias entre serviços. Exemplos típicos incluem situações de sobrecarga de serviço e hot-spotting de dados.
As contribuições da engenharia de software do SRE foram frequentemente locais para o serviço. Assim, era difícil construir soluções genéricas para serem reutilizadas. Como consequência, não havia uma forma fácil de implementar novas lições aprendidas por equipes individuais do SRE e as melhores práticas em serviços que já tinham sido incorporados.

Fatores externos que afetam o SRE

Os fatores externos têm tradicionalmente pressionado a organização SRE e os seus recursos de várias maneiras.

O Google segue cada vez mais a tendência da indústria de avançar para os microserviços. Como resultado, tanto o número de solicitações de suporte SRE e a cardinalidade de serviços para suporte aumentaram. Como cada serviço tem um custo operacional fixo de base, mesmo os serviços simples exigem mais pessoal. Os microserviços também implicam uma expectativa de menor tempo de execução, o que não era possível com o modelo PRR anterior (que tinha um lead time de meses).

A contratação de SREs experientes e qualificados é difícil e dispendiosa. Apesar do enorme esforço da organização de recrutamento, nunca há SREs suficientes para apoiar todos os serviços que necessitam da sua perícia. Uma vez contratados os SREs, seu treinamento é também um processo mais longo do que é típico para engenheiros de desenvolvimento.

Finalmente, a organização SRE é responsável por servir as necessidades do grande e crescente número de equipes de desenvolvimento que ainda não se beneficiam de apoio direto do SRE. Este mandato exige a extensão do modelo de apoio SRE muito além do conceito original e do modelo de engajamento.

Rumo a uma solução estrutural: Estruturas

Para responder eficazmente a estas condições, tornou-se necessário desenvolver um modelo que permitisse os seguintes princípios:

Melhores práticas codificadas

A capacidade de comprometer o que funciona bem na produção a codificar, de modo que os serviços possam simplesmente utilizar este código e tornar-se “prontos para a produção” por padrão.

Soluções reutilizáveis

Implementações comuns e facilmente compartilháveis de técnicas utilizadas para mitigar os problemas de escalabilidade e confiabilidade.

Uma plataforma de produção comum com uma superfície de controle comum

Conjuntos uniformes de interfaces para instalações de produção, conjuntos uniformes de controles operacionais, e monitoramento, log e configuração uniformes para todos os serviços.

Automatização mais fácil e sistemas mais inteligentes

Uma superfície de controle comum que permite a automação e sistemas inteligentes em um nível que antes não era possível. Por exemplo, os SREs podem receber prontamente uma visão única da informação relevante para uma interrupção, em vez de coletar e analisar manualmente a maioria dos dados brutos de fontes diferentes (logs, dados de monitoramento, etc.).

Com base nestes princípios, foi criado um conjunto de plataformas e estruturas de serviços apoiados pelo SRE, um para cada ambiente que apoiamos (Java, C++, Go). Os serviços criados usando essas estruturas compartilham implementações projetadas para funcionar com a plataforma suportada pelo SRE e são mantidas pelo SRE e pelas equipes de desenvolvimento. A principal mudança trazida pelas estruturas foi permitir às equipes de desenvolvimento de produtos projetar aplicações utilizando a solução de estrutura que foi construída e abençoada pelo SRE, em vez de adaptar a aplicação às especificações SRE após o fator, ou adaptar mais SREs para dar suporte a um serviço que era marcadamente diferente de outros serviços Google.

Uma aplicação compreende tipicamente alguma lógica empresarial, que por sua vez depende de vários componentes de infraestrutura. As preocupações de produção do SRE estão amplamente focadas nas partes relacionadas à infraestrutura de um serviço. As estruturas de serviços implementam o código de infraestrutura de uma forma padronizada e abordam várias preocupações de produção. Cada preocupação é encapsulada em um ou mais módulos de estrutura, cada um dos quais fornece uma solução coesa para um domínio problemático ou dependência da infraestrutura. Os módulos de estrutura abordam as várias preocupações do SRE enumeradas anteriormente, como por exemplo:

Instrumentação e métricas
Solicitação de log
Sistemas de controle envolvendo gerenciamento de tráfego e carga

O SRE constrói módulos de estrutura para implementar soluções canônicas para a área de produção em questão. Como resultado, as equipes de desenvolvimento podem concentrar-se na lógica empresarial, porque a estrutura já se ocupa da utilização correta da infraestrutura.

Uma estrutura é essencialmente uma implementação prescritiva para a utilização de um conjunto de componentes de software e uma forma canônica de combinar estes componentes. A estrutura pode também expor características que controlam vários componentes de uma forma coesa. Por exemplo, uma estrutura pode fornecer o seguinte:

Lógica empresarial organizada como componentes semânticos bem definidos que podem ser referenciados usando termos padrão
Dimensões padrão para instrumentação de monitoramento
Um formato padrão para logs de depuração de solicitação
Um formato de configuração padrão para gerenciar o descarte de carga
Capacidade de um único servidor e determinação de “sobrecarga” que podem ambos utilizar uma medida semanticamente consistente para feedback a vários sistemas de controle

As estruturas fornecem vários ganhos iniciais em consistência e eficiência. Eles liberam os desenvolvedores da necessidade de colar e configurar componentes individuais de uma maneira específica de serviço ad hoc, de maneiras ligeiramente incompatíveis, que precisam ser revisadas manualmente pelos SREs. Conduzem a uma única solução reutilizável para problemas de produção em todos os serviços, o que significa que os usuários da estrutura acabam com a mesma implementação comum e diferenças mínimas de configuração.

O Google oferece suporte a várias linguagens importantes para o desenvolvimento de aplicações, e as estruturas são implementadas em todas estas línguas. Embora diferentes implementações da estrutura (digamos em C++ versus Java) não possam compartilhar código, o objetivo é expor a mesma API, comportamento, configuração, e controles para uma funcionalidade idêntica. Portanto, as equipes de desenvolvimento podem escolher a plataforma de linguagem que se adapta às suas necessidades e experiência, enquanto os SREs podem ainda esperar o mesmo comportamento familiar na produção e ferramentas padrão para gerir o serviço.

Novos benefícios de serviço e gestão

A abordagem estrutural, fundada em estruturas de serviços e numa plataforma de produção e superfície de controle comum, proporcionou uma série de novos benefícios.

Custos gerais operacionais significativamente mais baixos

Uma plataforma de produção construída em cima de estruturas com convenções mais fortes reduziu significativamente as despesas operacionais, pelas seguintes razões:

Suporta testes de conformidade fortes para estrutura de codificação, dependências, testes, guias de estilo de codificação e assim por diante. Esta funcionalidade também melhora a privacidade dos dados dos usuários, testes, e conformidade de segurança.
Inclui a implementação de serviços integrados, monitoramento e automação de serviços integrados para todos os serviços.
Facilita a gestão de grandes números de serviços, especialmente micro-serviços, que estão crescendo em número.
Permite uma implantação muito mais rápida: uma ideia pode se transformar em qualidade de produção de nível SRE totalmente implantada em questão de dias!

Apoio universal por padrão

O crescimento constante do número de serviços no Google significa que a maioria destes serviços não pode garantir o compromisso do SRE nem ser mantido pelos SREs. Independentemente disso, os serviços que não recebem apoio total do SRE podem ser construídos para utilizar características de produção que são desenvolvidas e mantidas pelos SREs. Esta prática rompe efetivamente a barreira do pessoal do SRE. Permitir normas e ferramentas de produção apoiadas por SRE para todas as equipes melhora a qualidade geral do serviço em todo o Google. Além disso, todos os serviços que são implementados com estruturas se beneficiam automaticamente das melhorias feitas ao longo do tempo nos módulos de estruturas.

Compromissos mais rápidos e de menor sobrecarga

A abordagem das estruturas resulta numa execução mais rápida de PRR porque podemos contar com:

Recursos de serviço integrados como parte da implementação da estrutura
Integração de serviço mais rápida (geralmente realizada por um único SRE durante um trimestre)
Menos carga cognitiva para as equipes SRE que gerenciam serviços criados usando estruturas

Essas propriedades permitem que as equipes de SRE reduzam o esforço de avaliação e qualificação para integração de serviços, mantendo um alto nível de qualidade de produção de serviços.

Um novo modelo de compromisso baseado na responsabilidade compartilhada

O modelo original de compromisso do SRE apresentava apenas duas opções: ou suporte total do SRE, ou aproximadamente nenhum envolvimento do SRE.

Uma plataforma de produção com uma estrutura de serviço comum, convenções e infraestrutura de software tornou possível a uma equipe SRE fornecer apoio à infraestrutura da “plataforma”, enquanto que as equipes de desenvolvimento fornecem suporte de plantão para questões funcionais com o serviço – ou seja, para bugs no código da aplicação. Sob este modelo, os SREs assumem a responsabilidade pelo desenvolvimento e manutenção de grandes partes da infraestrutura de software de serviço, particularmente sistemas de controle, tais como rejeição de carga, sobrecarga, automação, gestão de tráfego, log, e monitoramento.

Este modelo representa um desvio significativo da forma como a gestão de serviços foi originalmente concebida de duas formas principais: implica um novo modelo de relacionamento para a interação entre o SRE e as equipes de desenvolvimento, e um novo modelo de pessoal para a gestão de serviços apoiados pelo SRE.

Conclusão

A confiabilidade do serviço pode ser aprimorada por meio do engajamento do SRE, em um processo que inclui revisão sistemática e aprimoramento de seus aspectos de produção. A abordagem sistemática inicial do Google SRE, a Revisão Simples de Prontidão à Produção, fez progressos na padronização do modelo de compromisso SRE, mas só foi aplicável a serviços que já tinham entrado na fase de Lançamento.

Ao longo do tempo, o SRE ampliou e aprimorou esse modelo. O Modelo de Envolvimento Antecipado envolveu o SRE mais cedo no ciclo de vida do desenvolvimento, para “projetar para confiabilidade”. À medida que a demanda por experiência em SRE continuou a crescer, a necessidade de um modelo de engajamento mais escalável tornou-se cada vez mais evidente. Foram desenvolvidas estruturas para serviços de produção para satisfazer esta procura: padrões de código baseados nas melhores práticas de produção foram padronizados e encapsulados em estruturas, de modo que a utilização de estruturas se tornou uma forma recomendada, consistente e relativamente simples de construir serviços prontos para a produção.

Todos os três modelos de compromisso descritos continuam a ser praticados no Google. No entanto, a adoção de estruturas está se tornando uma influência proeminente na criação de serviços prontos para produção no Google, além de expandir profundamente a contribuição do SRE, reduzindo a sobrecarga de gerenciamento de serviços e melhorando a qualidade do serviço de linha de base em toda a organização.

Fonte: Google SRE Book