Por que a documentação do SRE é importante. Parte 2

Boa noite a todos!

Portanto, não resta nada (isto é, um dia) antes do início do fluxo do curso DevOps Practices and Tools , o que significa que precisamos ter tempo para concluir o restante do artigo "Por que a documentação do SRE é importante" durante esse período.

Nós continuamos.

Documentos para integrar novo serviço

Os SREs conduzem uma PRR (revisão de prontidão de produção) para verificar se o serviço atende aos padrões de prontidão operacional e para garantir que os proprietários do serviço entendam como usar o conhecimento de SRE para gerenciar grandes sistemas.

O serviço precisa passar por esse teste antes de ser lançado na produção. (Antes do lançamento, ele não é suportado pelo SRE, mas pela própria equipe de desenvolvimento.) O objetivo do PRR nesta fase é garantir que o serviço atenda aos padrões mínimos de confiabilidade no momento do lançamento.



A próxima PRR ocorre antes da transferência do serviço SRE, ou seja, muito tempo pode passar após o lançamento. E quando a equipe do SRE decide contratar um novo serviço, é realizada uma análise completa do estado da produção e das práticas de serviço utilizadas. O objetivo é simplificar o processo de transferência de serviços em termos de confiabilidade e estabilidade operacional, além de ajudar a SRE a lidar melhor com isso.

Ao conduzir PRRs antes de entregar o serviço, os SREs podem fazer mais perguntas e definir padrões mais altos de confiabilidade e facilidade de uso do que ao realizar PRRs antes do lançamento. A PRR antes do lançamento pode ser "leve" para não desacelerar a equipe de desenvolvimento.

Na história de Zoe, a equipe não tinha um processo padronizado ou lista de verificação de PRR, o que significa que eles poderiam perder problemas muito importantes ao transferir o serviço. Portanto, existe o risco de uma colisão com um grande número de problemas que podem ser facilmente antecipados e resolvidos antes de assumir a responsabilidade pelo gerenciamento do serviço.

A transferência de PRR / serviço requer a criação de modelos de PRR e documentação do processo (documentação do processo) que descreve como as equipes do SRE trabalharão com o novo serviço e usarão modelos de PRR. Os padrões usados ​​no processo de transferência podem ser mais abrangentes que os usados ​​durante a inicialização.

O modelo de PRR abrange várias áreas e é necessário verificar respostas para perguntas críticas. A Tabela 1 mostra algumas das áreas e questões relacionadas que o modelo cobre.

Area	Perguntas
Arquitetura e Dependências	Qual é o caminho da solicitação do cliente para o front-end e o back-end? Existem diferentes tipos de solicitações com diferentes requisitos de latência?
Planejamento de capacidade	Quais são as expectativas para volumes de tráfego e taxas de crescimento durante e após o lançamento? Você tem o poder de computação necessário para suportar esse tráfego?
Tipos de falhas	Existem pontos únicos de falha na sua arquitetura? Como você elimina a indisponibilidade de dependência?
Processos e Automação	Existem processos manuais necessários para dar suporte ao serviço?
Dependências externas	Quais dados, códigos, serviços ou eventos de terceiros dependem do serviço e do lançamento? Algum de seus parceiros depende do serviço? Em caso afirmativo, eles precisam ser notificados sobre o lançamento?

Tabela 1. Áreas de exemplo de um modelo de PRR

A documentação do processo também deve indicar os documentos que o SRE deve solicitar à equipe de desenvolvimento do produto como pré-requisitos para a transferência. Por exemplo, eles podem solicitar à equipe de desenvolvimento que crie um manual para problemas comuns.

Além disso, a organização do SRE precisará criar um documento de revisão que explique brevemente à equipe de desenvolvimento o papel e as áreas de responsabilidade do SRE. Isso é necessário para formar expectativas realistas. O primeiro documento deve explicar o que é SRE, cobrir todos os tópicos discutidos na parte anterior e no início deste artigo, incluindo as principais funções, ciclo de vida de serviço, responsabilidades de suporte / manutenção. O principal objetivo deste documento é garantir que os desenvolvedores não confundam SRE com a equipe do OPS e não considerem as respostas do pager como o único dever do SRE. Como mostrado na história descrita anteriormente, se no momento da transferência do serviço os desenvolvedores não entendessem completamente o que o SRE estava fazendo, isso levaria a problemas de comunicação e mal-entendidos.

Além disso, é necessário criar um documento de modelo de engajamento para esclarecer as expectativas e explicar o processo de interação entre a equipe do SRE e a equipe de desenvolvimento do produto durante e após a transferência do serviço. Os tópicos abordados na documentação podem incluir o seguinte:

• Critérios de transferência de serviço e processo de PRR.
• O processo de discutir relatórios de objetivos de nível de serviço (brevemente SLO) e cálculo de erros.
• Novos critérios de inicialização e política de congelamento (se possível).
• O conteúdo e a frequência dos relatórios de status do serviço da equipe do SRE.
• Requisitos de pessoal SRE.
• O processo de planejar um roteiro de novas funcionalidades e a prioridade de uma funcionalidade que aumenta a confiabilidade (exigida pelo SRE) em relação à nova funcionalidade do produto.

Documentação de operação de serviço

Para dar suporte ao serviço, as equipes de SRE contam principalmente com a documentação operacional principal: descrição geral (entrevista) do serviço, manuais e procedimentos, post mortem, diretrizes e SLA. (Nota: esta seção estava presente no capítulo "Do Docs Better" em Como buscar o SRE.)

Entrevista de Serviço

Uma descrição geral do serviço é fundamental para entender o SRE, que tipo de serviço ele oferece suporte. O SRE precisa conhecer a arquitetura do sistema, seus componentes e dependências, os contatos do serviço e seus proprietários. A descrição geral do serviço é o resultado do trabalho conjunto da equipe de desenvolvimento e da equipe de SRE, criada para orientar e priorizar as tarefas de SRE e identificar áreas para estudos adicionais. Essas entrevistas geralmente são obtidas como resultado da PRR e devem ser atualizadas conforme o serviço muda (por exemplo, se novas dependências aparecerem).

Uma entrevista simples fornece à SRE informações suficientes para explorar ainda mais o serviço. Uma entrevista completa fornece uma descrição completa do serviço e como ele interage com o mundo ao seu redor, além de links para painéis, métricas, todas as informações que o SRE precisa para solucionar problemas imprevistos.

Playbook

Às vezes, também chamado de runbook, é um documento fundamental que permite que os engenheiros respondam às notificações de um sistema de monitoramento de serviço durante um turno. Por exemplo, se a equipe de Zoey tivesse um manual explicando o significado do alerta "Job Ragnarok se recostou" e o que precisa ser feito na situação em que foi recebido, o incidente seria resolvido em questão de minutos. Os Playbooks reduzem o tempo de recuperação de incidentes e fornecem links úteis para consoles e procedimentos.

Os manuais contêm instruções para verificar, eliminar e escalar qualquer notificação gerada dos processos de monitoramento de rede. Os nomes das notificações nos playbooks geralmente coincidem com o que o sistema gera. Eles contêm comandos e etapas que precisam ser testados quanto à precisão. Eles precisam ser atualizados regularmente quando novos métodos de solução de problemas são descobertos, bem como quando novos tipos de falha são identificados e dependências são adicionadas.

Playbooks não são criados exclusivamente para notificações. Eles também podem conter procedimentos de produção para liberar liberações, monitoramento e solução de problemas. Outros exemplos de procedimentos de produção incluem ligar / desligar um serviço, manutenção de um serviço e um acidente / escalação.

Post mortem

Os SREs trabalham com sistemas distribuídos complexos e de larga escala e também melhoram os serviços com a ajuda de novas funcionalidades e a adição de novos sistemas. Portanto, dada a escala e a velocidade das mudanças, incidentes e interrupções são inevitáveis. Post-mortem é uma ferramenta importante de SRE, formalizando o processo de aprendizado com nossos erros. Na história hipotética de Zoe, a equipe não tinha um procedimento post-mortem formal; portanto, não havia um processo formal para registrar as descobertas de um incidente que impediriam sua recorrência. Portanto, a equipe está fadada a repetir os mesmos erros repetidamente.

As equipes do SRE precisam criar um modelo post-mortem padronizado com seções que capturam informações importantes sobre a falha. Idealmente, o modelo deve ser estruturado para que possa ser facilmente analisado por uma ferramenta de análise de dados. Ele envia relatórios de dinâmica de falhas usando post-mortem como fonte de dados. Cada post mortem criado usando este modelo descreve uma falha de produção, incluindo as seguintes informações (no mínimo):

• Cronologia dos eventos (linha do tempo).
• Descrição do impacto no usuário.
• Causa raiz
• Pontos de Ação / Lições Aprendidas.

Postmortem é escrito por um membro da equipe que encontra uma falha, idealmente para aqueles que participaram da remoção e podem assumir a responsabilidade pelas melhorias. Post mortem deve ser escrito de maneira inocente. Ele deve conter as informações necessárias para entender o que aconteceu, bem como uma lista de decisões que precisam ser tomadas para reduzir a probabilidade de recorrência, reduzir as consequências e / ou simplificar a recuperação.

Diretivas

Na documentação da política, são indicadas regras e diretrizes técnicas e não técnicas específicas de produção. As regras técnicas podem se aplicar, por exemplo, ao registro de alterações na produção, manutenção de registros, nomeação de serviços internos (regras de nomeação que os engenheiros devem seguir ao implementar serviços) e uso e disponibilidade de dados de identificação de emergência.

As diretivas também podem ser direcionadas aos processos. As regras de escalonamento ajudam os engenheiros a classificar as falhas como emergenciais e não emergenciais e a entender quais ações devem ser tomadas em uma determinada situação; as diretrizes de expectativas de mudança descrevem a estrutura da equipe e a área de responsabilidade de cada um de seus membros.

Contrato de Nível de Serviço

Contrato de Nível de Serviço (Contrato de Nível de Serviço, em resumo - SLA) - um contrato oficial com o cliente sobre o serviço prestado e as ações tomadas em caso de inadimplência. As equipes do SRE documentam a disponibilidade e a latência do serviço e monitoram o desempenho do serviço associado aos SLAs.

A documentação e publicação de SLAs, bem como uma análise completa da experiência do usuário e sua comparação com os SLAs, permitem que as equipes de SRE inovem mais rapidamente sem perder a qualidade do UX. SREs que oferecem suporte a serviços com um aviso claro de SLA falham mais rapidamente e, portanto, os corrigem mais rapidamente. O SLA também reduz a quantidade de atrito entre as equipes SRE e SWE (desenvolvedores de software), permitindo que as equipes discutam objetivamente metas e resultados, evitando julgamentos subjetivos sobre o risco.

Vale ressaltar que a existência de um contrato externo válido legalmente pode não se aplicar à maioria das equipes de SRE. Nesses casos, as equipes de SRE podem estar limitadas aos objetivos de nível de serviço (SLO, abreviado). SLO - Determine o nível de serviço desejado para uma métrica específica, por exemplo, disponibilidade ou atraso.

Documentação do produto

As equipes do SRE se esforçam para gastar 50% do tempo trabalhando em um projeto, desenvolvendo software para automatizar o trabalho manual ou melhorar a confiabilidade do serviço. Esta seção descreve documentos relacionados ao produto e ferramentas que o SRE desenvolve.

Esses documentos são importantes porque permitem que os usuários entendam se este produto é adequado para eles, como começar a trabalhar com ele e como obter suporte. Eles também fornecem a experiência correta ao usuário e facilitam a adoção do produto.

Página Sobre o Produto

A página de descrição ajuda os engenheiros de desenvolvimento de produtos e SRE a entender o que é um produto ou ferramenta, o que faz e como usá-lo.

Manual de conceitos

Um guia ou glossário de conceitos define todos os conceitos exclusivos do produto. A definição de conceitos permite manter a consistência na documentação e nos elementos das interfaces de usuário, APIs e CLIs (interfaces de linha de comando).

Guia de Introdução

O objetivo do guia de introdução é atualizar rapidamente os engenheiros com um mínimo de atrasos. Isso é útil para novos usuários que desejam experimentar o produto.

Codelab

Os engenheiros podem usar esses tutoriais, combinando explicação teórica, exemplos de código e exercícios, para conhecer rapidamente o produto. O Codelabs também fornece scripts detalhados que levam os engenheiros passo a passo por uma série de tarefas. Esses tutoriais geralmente são mais longos do que os guias de introdução. Eles podem cobrir mais de um produto ou ferramenta se estiverem relacionados a alguma coisa.

Guia prático

Essa orientação é necessária para usuários que desejam resolver um problema específico. Esses guias geralmente são um guia passo a passo que você deve seguir.
Perguntas frequentes

Na página de Perguntas frequentes, o usuário pode obter respostas para as perguntas mais populares, descobrir as dificuldades e limitações que podem ser encontradas, encontrar links para documentos e outras páginas para obter informações mais detalhadas.

Suporte

Na página de suporte, os engenheiros podem aprender como resolver o problema que estão enfrentando. Você também pode encontrar um plano de escalação, informações sobre solução de problemas, links de grupos, painéis e SLOs, além de informações sobre turnos.

Descrição da API

Este guia descreve funções, classes e métodos, geralmente com o mínimo de texto que o acompanha. Essa documentação geralmente é criada com base em comentários no código e, às vezes, é escrita por escritores técnicos.

Guia do desenvolvedor

Neste guia, os desenvolvedores podem aprender a programar com a API do produto. Esses guias geralmente são necessários se o SRE criar produtos que fornecem APIs para desenvolvedores, o que permite criar ferramentas mistas que invocam as APIs umas das outras para executar tarefas mais complexas.

Documentos para relatar o status do serviço

Esta seção descreve os documentos que a equipe do SRE cria para descrever o status dos serviços suportados.

Revisão trimestral do serviço

As informações sobre o status do serviço são apresentadas em dois formatos: um relatório trimestral acordado pelo líder do SRE, que é distribuído por toda a organização do SRE, e apresentações para o líder no desenvolvimento de produtos e a equipe.

Os líderes de SRE estão interessados ​​em relatórios trimestrais, pois fornecem informações sobre os seguintes itens:

• Problemas de suporte (turnos, tickets, post-mortem). Os líderes da SRE sabem que, se os problemas de suporte começarem a ocupar mais de 50% dos recursos da equipe da SRE, será necessário responder e alterar as prioridades. O objetivo é identificar o problema já nos estágios iniciais.
• Execução de SLA. Os líderes da SRE querem saber se está tudo bem com o SLA, se existem componentes prejudiciais no ecossistema que representam uma ameaça.
• Riscos Os líderes de SLA querem saber sobre os riscos conhecidos pelo SRE que podem interferir nos objetivos do produto e dos negócios.

Os relatórios trimestrais dão à equipe do SRE a oportunidade de:

• Enfatize os benefícios do SRE para a equipe de desenvolvimento de produtos, bem como o próprio trabalho da equipe de SRE.
• Solicite prioridade para resolver problemas que interfiram no comando SRE (resiliência).
• Solicite feedback sobre as prioridades da equipe do SRE.
• Enfatize a contribuição mais ampla da equipe.

Visão geral das técnicas de sucesso

Essa revisão ajuda a adotar técnicas bem-sucedidas e chega a um estado estável no qual as operações exigem um tempo mínimo. Para preparar esses relatórios, as equipes de SRE fornecem um site e um estatuto da equipe, detalhes de status de turnos, projetos vs. interrupções, planejamento de capacidade etc.

Uma revisão de técnicas bem-sucedidas ajuda a equipe do SRE a se comparar com o restante da organização do SRE e a melhorar o desempenho em áreas-chave: status da mudança, projetos versus interrupções, SLOs e planejamento de capacidade.

O fim da segunda parte.

Leia a próxima parte.

Estamos aguardando suas perguntas e comentários, como de costume.