Site Reliability Engineering (SRE) ou Engenharia de Confiabilidade em português, é o resultado da combinação de responsabilidades de operações de TI com desenvolvimento de software. Com o SRE, há uma expectativa inerente de responsabilidade para atender aos objetivos de nível de serviço (SLOs) definidos para o serviço que eles gerenciam e os acordos de nível de serviço (SLAs) que prometemos em nossos contratos.
Os SLOs definem metas de confiabilidade que são frequentemente chamadas de orçamentos de erro. Os dados são coletados enquanto o sistema está operando e compilados como indicadores de nível de serviço (SLIs) para ajudar a orientar a tomada de decisões pelos SREs sobre quais partes do sistema precisam ser priorizadas para aprimoramento. Para ajudar com isso, os engenheiros automatizam tudo o que podem, em vez de repetir tarefas. Essa automação gera mais tempo para o engenheiro, eliminando o trabalho árduo, tempo que pode ser gasto para tornar o software cada vez mais confiável.
O foco na confiabilidade é o principal fator que separa o DevOps e a engenharia de confiabilidade do site, não a automação.
Em uma equipe de SRE, os engenheiros aceitam a responsabilidade de que a pessoa que constrói o software também o envie e o gerencie na produção. Nesse sentido, o SRE às vezes é referido como o próximo estágio do DevOps.
Aplicar essa expectativa de automação às tarefas de operações deixa os desenvolvedores de software e administradores de sistema que estão se tornando engenheiros de confiabilidade de site com a tarefa de aprender como lidar com problemas complexos que podem estar fora de sua experiência anterior. Agora, espera-se que eles lidem com problemas como latência, desempenho, alta disponibilidade, sistemas de produção distribuídos complexos, monitoramento de sistema, resposta de emergência e recuperação de desastres e até mesmo gerenciamento de mudanças com apenas a quantidade de interação humana absolutamente necessária. Isso leva a uma eficiência cada vez maior.
Uma equipe SRE é o desenvolvimento de software, a administração de sistemas e as operações de TI, tudo mesclado. Qualquer membro pode ser mais forte como administrador de sistema, desenvolvedor ou DBA, mas nenhum membro faz apenas uma coisa. Todos eles trabalham juntos em direção a um objetivo comum sem as paredes tradicionais obstruindo a comunicação e a cadência.
Quais são os fundamentos e benefícios da engenharia de confiabilidade?
Os princípios básicos da Engenharia de Confiabilidade são fáceis de explicar, mas exigem algum trabalho para serem aplicados. Começamos com o entendimento básico de que os sistemas e plataformas de computador de hoje têm uma complexidade sem precedentes.
Nossos sistemas são complicados
O número de partes móveis e unidades funcionais discretas dentro de nossas arquiteturas é vasto e impossível para qualquer pessoa entender completamente em um determinado momento. Além disso, nossos sistemas estão em constante mudança. Novas capacidades estão sendo adicionadas. Sistemas de recuperação de falhas. Balanceamento de carga. Implantações canário. Os contêineres antigos que não são mais necessários são constantemente removidos.
Onde costumávamos projetar um sistema no papel, desenhando diagramas de sistema e arquiteturas de sistema, hoje nossos sistemas mudaram antes que a tinta seque com qualquer tentativa de fazê-lo. Eles podem, na melhor das hipóteses, ser considerados aproximações.
A automação nos ajuda a gerenciar a complexidade
Grande parte da administração de grandes sistemas hoje envolve tarefas sem graça e repetitivas. Nossa carga aumentou devido a um fluxo de compradores on-line acessando nosso site depois que o marketing enviou um e-mail de venda de oportunidade especial? Trazer mais capacidade? A carga diminuiu porque a temporada de impostos acabou e todos que preencheram a tempo terminaram e já receberam seus resultados? Remova os servidores de aplicativos redundantes desnecessários.
Nenhum engenheiro quer fazer a mesma coisa indefinidamente. A repetição rapidamente se torna enfadonha e leva à procura de emprego em busca de um novo e interessante desafio. Adoramos resolver problemas e apresentar soluções úteis. Adoramos ainda mais quando nos livra de tarefas que não gostamos e nos dá mais tempo para um trabalho divertido e benéfico.
Amamos ainda mais a automação quando ela é confiável e torna nossos sistemas mais resistentes a eventos de alto impacto. Todos nós apreciamos quando não precisamos apagar um incêndio metafórico que resultou de um número maior de usuários simultâneos do que o normal. Quando nossos sistemas monitoram, alertam e até mesmo reagem antes que isso se torne um problema, todos se beneficiam.
Quem se beneficia dos engenheiros de confiabilidade?
Qualquer empresa grande o suficiente para precisar de mais do que uma pequena equipe para gerenciar seus sistemas se beneficiará da engenharia de confiabilidade. Qualquer um de nós com sistemas grandes ou vitais o suficiente para exigir 99% de disponibilidade ou mais se beneficiará. Se o tempo de atividade for importante, o SRE bem implementado ajudará você a melhorá-lo.
O maior benefício vem para empresas com grande número de usuários, sejam eles internos à empresa ou clientes externos. Além disso, empresas que processam grandes quantidades de dados ou que têm cargas de trabalho que variam de recursos pesados a leves.
Nesses casos, muitas empresas estão transferindo grande parte de seu poder de processamento e computação para serviços baseados em nuvem. Alguns moveram tudo para a nuvem, enquanto outros têm um motivo para usar uma arquitetura híbrida que mantém dados confidenciais, como informações de identificação pessoal ou finanças da empresa internamente, enquanto move outros processamentos para a nuvem. Outros ainda têm um data center de propriedade interna usando virtualização ou uma nuvem interna.
O que os engenheiros de confiabilidade fazem diariamente?
Os engenheiros de confiabilidade começam examinando o sistema e, em seguida, pegam as tarefas mais fáceis e sem graça e as automatizam. Isso libera mais tempo para codificar novos recursos e se preparar para possíveis problemas.
Os Engenheiros de Confiabilidade tendem a ter experiência em desenvolvimento de software ou em sistemas ou operações. Todos nós gastamos tempo fazendo cada uma dessas tarefas: escrever código e gerenciar o sistema. É por isso que somos adequados tanto para saber o que seria útil automatizar quanto para escrever o código que faz a automação.
Mitigação de desastres
Enquanto as tarefas mais simples são tratadas, também examinamos esquemas de preparação e mitigação de desastres e escrevemos manuais, planos de como lidar com coisas ruins quando coisas ruins acontecem.
Para os SREs sênior e júnior vale a pena tentar automatizar o máximo possível das tarefas de mitigação descobertas: ativar servidores de banco de dados extras quando os tempos de resposta são lentos, redirecionar o tráfego em torno de servidores de aplicativos sobrecarregados quando o uso da CPU ou a capacidade de rede está ficando um pouco demais perto da capacidade, e assim por diante.
Configurar e usar o monitoramento para observabilidade
Tudo isso requer um bom monitoramento para obter observabilidade no sistema e se os componentes estão funcionando conforme o previsto. Adivinha quem está encarregado disso? Sim, SREs. O monitoramento requer um conhecimento do sistema e quais dados seriam significativos e úteis. Também requer boas ferramentas e tempo para aprender a usá-las bem.
Podemos monitorar “tudo”, mas o resultado de fazer isso é uma explosão de informações que é esmagadora e rapidamente é ignorada. Em vez disso, dedicamos nosso tempo para considerar cuidadosamente quais métricas nos informam o que precisamos saber sobre o sistema, de preferência muito antes de ocorrerem problemas que afetam o usuário e muito, muito antes do tempo de inatividade.
Não podemos pegar tudo, mas fazer isso cientificamente nos ajuda a pegar tanto quanto sabemos que precisamos pegar, evitando uma sobrecarga de barulho e distração.
Manutenção do site e do software
Para ser seguro e atualizado, um sistema deve ser mantido. Não é aceitável ter versões de software desatualizadas ou configurações antigas quando você busca qualidade, estabilidade e segurança.
Os SREs gastam parte de seu tempo certificando-se de que o software seja atualizado adequadamente em tempo hábil. Eles podem automatizar coisas como verificações de versão, datas de expiração para itens como certificados de segurança e necessidades de dependência.
Gestão de Incidentes e Reparação de Incidentes
Está bem ali no nome, “confiabilidade do site”. Uma das principais tarefas do SRE é manter um site em funcionamento e, quando ele parar de funcionar porque algo falhou, recuperá-lo e colocá-lo em funcionamento o mais rápido possível.
Um incidente acontece. Um alerta é enviado. O SRE de plantão para tudo o que está fazendo e começa a trabalhar para descobrir qual é o problema. Todos na equipe de plantão se reúnem, talvez pessoalmente ou usando uma chamada de conferência de áudio ou vídeo. As informações são coletadas e compartilhadas. Base de conhecimento de incidentes são usados para priorizar o que observar e tentar fazer as coisas funcionarem novamente. Se eles não ajudarem, o que às vezes acontece, as ideias e possíveis correções são discutidas. As responsabilidades são distribuídas entre os membros da equipe. Todos trabalham juntos para fazer qualquer pesquisa e tarefas necessárias para que o sistema volte a funcionar.
Existem várias métricas que são usadas para medir a velocidade e a eficiência da resposta a incidentes, como:
- Tempo médio de detecção (MTTD), que mede o tempo médio necessário para descobrir um problema;
- Tempo médio para resolver (MTTR), que mede quanto tempo leva para consertar um sistema com falha;
- Tempo médio para falha (MTTF), que é a quantidade média de tempo que um sistema defeituoso pode continuar funcionando antes de falhar; isso é semelhante ao tempo de atividade e ajuda as equipes a planejar a substituição futura dos componentes do sistema antes que eles parem de funcionar;
- Tempo médio entre falhas (MTBF), que mede o tempo médio que um sistema ou componente está funcionando corretamente.
Evitar perda de dados
O trabalho mais conhecido e aparentemente óbvio de um SRE é manter a disponibilidade do sistema. Talvez menos óbvio, mas ainda mais importante é preservar a integridade de nossos dados. Durabilidade. A prevenção da perda de dados.
Os dados são a coisa mais importante que temos em nossos sistemas. Cada componente existe para fazer algo com ou para dados. Dados de entrada, armazenamento de dados, dados de processo, dados de transformação, dados de uso, dados de saída, a lista continua.
Alguns dados são proprietários. Alguns são sensíveis. Muitos tipos de dados só podem ser tratados de acordo com padrões regulatórios rígidos.
Sem bons dados, nossos sistemas não têm valor. Se nossos dados não estiverem devidamente protegidos e forem roubados, podemos ser multados, processados ou até mesmo ir à falência, e nossos clientes que confiaram em nós tornam-se vulneráveis de maneiras que devemos trabalhar para prevenir.
Se nosso armazenamento de dados for corrompido ou um banco de dados travar, é melhor esperarmos ter bons sistemas de backup e redundância integrados. Os SREs também são responsáveis por isso, e esse é outro lugar onde boas ferramentas e saber como usá-las são importantes.
Prevenir a recorrência de problemas passados
Os SREs analisam eventos problemáticos do passado e tentam impedir que eles se repitam. É aqui que eventos como retrospectivas são incrivelmente valiosos. Falar sobre um problema questão por questão, anotando o que aconteceu e como, sem fazer de ninguém o bode expiatório, irá suscitar ideias úteis e participação para evitar que o problema volte a acontecer.
A parte divertida é quando conseguimos automatizar a mitigação e testá-la com um pouco de Engenharia do Caos para provar a nós mesmos que realmente evitamos desastres futuros.
Análise de Incidentes
Esses termos podem ser usados de duas maneiras. Podemos analisar um incidente enquanto ele está em andamento, procurando como repará-lo e recuperá-lo. Isso foi coberto pelo reparo de incidentes. Aqui estamos pensando em outro tipo de análise, aquela que acontece depois que um problema é resolvido e tudo volta a funcionar.
A cultura do SRE insiste que as retrospectivas sejam feitas de maneira irrepreensível. Não procuramos um bode expiatório, procuramos aprender. Não se trata de quem cometeu um erro (mesmo que o incidente seja causado por erro humano), porque muitas vezes o erro humano ocorre porque alguém fez algo que não deveria ter sido permitido pelas ferramentas ou software.
Todos os detalhes disponíveis sobre um incidente são reunidos, organizados em uma ordem lógica (frequentemente cronológica) e apresentados pela equipe. Partilhamos para aprender.
Às vezes, a retrospectiva é compartilhada por toda a empresa ou, pelo menos, pelas unidades de negócios afetadas. Às vezes, é até compartilhado publicamente. Nesses casos, também são incluídas informações sobre como o problema foi corrigido e também como será mitigado ou evitado que ele se repita.
Aprenda e compartilhe habilidades
Uma grande parte da Engenharia de Confiabilidade é a perspectiva. As equipes da SRE se comprometem a trabalhar em benefício mútuo; para compartilhar informações de forma que o maior número possível possa se beneficiar. Conseguir o emprego não é o fim do aprendizado. Compreender um sistema e gerenciá-lo bem como parte de uma equipe SRE madura e bem-sucedida não é o estágio final. Essa filosofia de respeito mútuo, compartilhamento, trabalho em equipe e foco na construção de um sistema futuro melhor em conjunto, em vez de se preocupar com “quem quebrou” da última vez, é fundamental.
Os SREs seniores dedicam tempo para ensinar os SREs juniores usando manuais de integração especialmente escritos que descrevem as principais tarefas que eles precisam aprender, orientando e comunicando ativamente as melhores práticas e o conhecimento institucional. Fazer bem a engenharia de confiabilidade requer absolutamente o desenvolvimento de uma comunidade dentro de cada equipe e entre as equipes. Uma falha aqui acabará por levar ao fracasso da prática.
Engenheiros com talento para apresentações geralmente encontram oportunidades para compartilhar seus conhecimentos em conferências e outros eventos, normalmente com a presença de outros profissionais de SREs e DevOps e aqueles que desejam aprender mais sobre as práticas. Isso oferece grandes oportunidades para aprender novas habilidades, conhecer novas tecnologias e masterizar práticas que funcionam em todas as empresas. Uma coisa que a maioria gosta de compartilhar são as histórias de interrupções. Há um poder em uma boa narrativa para que os SREs transmitam informações significativas de maneira envolvente.
Além disso, há muitas oportunidades de encontrar outros profissionais na web. Muitos escrevem postagens de blog para a empresa ou em seu site pessoal para compartilhar o que estão aprendendo. Encontramos nossos colegas SREs no Twitter , grupos Meetup , Reddit , alguns grupos comunitários do LinkedIn, este último disponível em português, e canais Slack tópicos especializados.
Como começou a engenharia de confiabilidade?
A história começa no início dos anos 2000 e é anterior ao termo mais comercializado, DevOps. O título “Engenheiro de confiabilidade” foi inventado por Ben Treynor, vice-presidente de engenharia do Google, responsável por milhares de engenheiros de software. Seu perfil no LinkedIn diz:
Se o Google parar de funcionar, a culpa é minha.
Outras empresas, como Amazon e Netflix, tiveram atividades semelhantes iniciadas em momentos próximos. Todos eles estavam procurando maneiras de tornar suas implantações já em grande escala mais confiáveis, eficientes e escaláveis. No entanto, foi uma equipe do Google que literalmente escreveu o livro sobre SRE com base nas práticas da empresa.
Além de combinar as funções de engenharia de software e operações, a grande mudança foi uma mudança de perspectiva. A mudança do combate a incêndios reativo quando surgem problemas para o reforço proativo da infraestrutura é um grande negócio. Requer uma atenção mais focada no início, mas, em última análise, economiza o tempo do funcionário da SRE e o dinheiro da empresa, evitando possíveis falhas.
É esse tipo de mudança de perspectiva que levou à criação da Engenharia do Caos como uma prática adotada por profissionais de SREs e DevOps. Quem quisesse provar que os esquemas de mitigação e as ações preventivas implementadas realmente funcionam de repente tinha ferramentas para fazê-lo.
Quais habilidades eu preciso para me tornar um engenheiro de confiabilidade?
Cobriremos esta questão com mais profundidade em outro artigo, mas resumindo:
Um candidato a Engenheiro de Confiabilidade de alto nível terá um processo natural de priorização. Ou seja, eles são capazes de filtrar as informações e discernir o que é importante e o que não é. Eles também terão excelentes habilidades de comunicação interpessoal.
Eles também terão um conjunto de habilidades, incluindo algum nível de familiaridade com:
- Git e hosts como GitHub e/ou GitLab;
- Vim (porque este editor está amplamente disponível em praticamente qualquer servidor que você provavelmente encontrará);
- Fundamentos do Linux, como gerenciamento de pacotes, gerenciamento de contas de usuário e permissões de diretório e arquivo;
- Gerenciamento básico de software de servidor, como Apache httpd ou Nginx;
- SSH;
- Shell scripting, como com Bash;
- Programação com linguagens como Python e talvez Go e até Rust;
- Automação;
- Rede;
- Monitoramento, geração de registros e observabilidade;
- Testes, incluindo a capacidade de escrever testes de unidade e testes para uso em CI;
- Bancos de dados, tanto relacionais como MySQL e Postgres, quanto pelo menos familiaridade com opções NoSQL/NewSQL mais recentes, como Cassandra, MongoDB e Neo4j.
Não se espera que aqueles que estão entrando no SRE em uma posição de nível júnior saibam tudo isso no início, mas que aprendam o que é necessário para trabalhar com sucesso nos sistemas que foram contratados para mantê-los funcionando com eficiência.
Quais ferramentas os SREs usam?
A Engenharia de Confiabilidade às vezes pode ser caótica. Está sempre e sempre mudando. Gerenciar o trabalho nesse ambiente requer planejamento. Padronizar um conjunto de ferramentas em uma equipe é sempre uma boa ideia.
Para começar, os SREs devem ser capazes de acompanhar o trabalho e o progresso para serem bem-sucedidos. Para isso, uma das primeiras ferramentas utilizadas por uma organização SRE é um bom rastreador de problemas como JIRA ou Pivotal Tracker .
Os SREs escrevem muitas de suas ferramentas junto com o software que gerenciam. Colocar esse código em um repositório como o Git é vital. Fazer com que todos usem o mesmo IDE, bibliotecas e processo de criação, como uma ferramenta de CI/CD como Jenkins ou Spinnaker , torna o trabalho em conjunto muito mais eficiente e tranquilo.
O processo de implantação dos serviços pertencentes a uma equipe SRE na arquitetura mais ampla de aplicativos em nuvem é importante. Muitas equipes usam contêineres como Docker ou Kubernetes para isso.
As equipes normalmente automatizam tudo o que podem, incluindo configurações. Ferramentas como Ansible e Terraform são úteis para isso.
Como a engenharia de confiabilidade do local se encaixa em uma organização de ecossistema mais amplo?
Em uma organização mais jovem que possui uma grande implantação de nuvem, as funções SRE podem ser modelo. Em organizações mais antigas que ainda possuem datacenters corporativos e equipes dedicadas de desenvolvimento versus operações, o SRE pode ser a nova e única função. A evolução só parece rápida ao contrário.
Durante um período de transição (que pode durar muitos anos em alguns casos), uma empresa pode ter uma equipe de desenvolvimento ainda fazendo o desenvolvimento do produto usando métodos em cascata e jogando o código por cima do muro para os operadores encarregados de fazer esse código funcionar na produção. Claro, isso ocorre apenas após várias revisões e aprovações por comitês de revisão de alterações, implantações em ambientes de teste e stage e assim por diante.
Essas mesmas empresas podem, ao mesmo tempo, ter novas equipes executando como projetos-piloto com permissão para usar métodos de desenvolvimento ágil, DevOps e/ou práticas de engenharia de confiabilidade e pipelines automatizados de CI/CD. Estes estão correndo ao lado das equipes mais tradicionais e às vezes podem ser vistos como concorrentes.
A melhor maneira de provar o valor da Engenharia de Confiabilidade como perspectiva é fazê-lo com excelência. Aprenda as perspectivas. Declare os valores centrais. Envie recursos estáveis e necessários em uma cadência mais rápida do que nunca e faça com que as mesmas pessoas que escrevem o código sejam responsáveis por mantê-lo funcionando bem na produção.
As equipes podem ser compostas por funções tradicionais de desenvolvedor/engenheiro, especialistas em operações, gurus de monitoramento e assim por diante, com apenas um punhado de membros da equipe com o título de “Engenheiro de Confiabilidade”. Isso não é incomum. Em locais como este, todo o time é dono do código e dos aspectos operacionais, e o SRE normalmente é quem mais sabe como gerenciar o código; construção, implantação, configuração e assim por diante. Um analista de banco de dados provavelmente ainda é aquele que se concentra na confiabilidade dos dados, mas o SRE ajuda com uma perspectiva mais ampla enquanto se beneficia de seu conhecimento.
No final, o SRE tem tudo a ver com colaboração e cooperação, reunindo pessoas com habilidades díspares com um objetivo comum e fazendo com que compartilhem conhecimentos e responsabilidades de forma eficiente para o benefício positivo de maior eficiência e tempo de atividade do sistema.
Como podemos criar nossa primeira equipe de engenharia de confiabilidade?
A melhor maneira de ser bem sucedido é primeiro saber o que estamos tentando realizar. Muitas vezes vemos projetos ou mudanças de paradigma começarem com muito pouco planejamento. Queremos flexibilidade em nossa implementação à medida que aprendemos e precisamos nos adaptar às mudanças nas circunstâncias, mas ainda precisamos seguir com um plano.
Começamos definindo nossa necessidade. O que queremos que uma equipe SRE faça? Gerenciar? Um bom lugar para começar é planejar que essa nova equipe assumirá a responsabilidade por um serviço ou sistema relativamente pequeno.
Por quê? Porque, neste ponto, a organização está aprendendo a cultura e o processo ao mesmo tempo e você deseja configurar sua primeira equipe para o sucesso, pois eles têm o dobro de aprendizado a fazer. Comece a preparar a organização para o que está por vir. Eles precisarão de tempo para se adaptar à ideia de uma equipe funcionando assim. Alguns podem recuar. Ouça-os, ensine e oriente gentilmente, mas não se desvie.
Em seguida, pense nas ferramentas que essa equipe precisará para ter sucesso. Não se apresse em comprá-los ainda, pois você pode contratar um conjunto de engenheiros experientes que conhecem maneiras e ferramentas melhores, mas pelo menos faça sua pesquisa sobre os custos típicos para poder definir uma expectativa de orçamento preliminar.
Quantas pessoas serão incluídas nesta equipe? Você precisa de 24 horas por dia, 7 dias por semana, 365 dias por ano ou esta é uma equipe que pode trabalhar em horário padrão junto com uma ou duas pessoas de plantão, conforme necessário? Recomendamos o último para sua primeira equipe, aprenda como implementar o SRE em algo de baixo risco e, em seguida, suba.
Defina a cultura que você deseja cultivar nesta equipe SRE. Anote-o para poder descrevê-lo nas listas de empregos que você criará a seguir.
Para continuar seu planejamento de pessoal, escreva descrições de cargo para cada um dos candidatos ideais que você deseja contratar para esta equipe. Lembre-se, nem todos virão de um histórico idêntico, e é isso que você deseja – múltiplas perspectivas! Seja claro sobre as responsabilidades e expectativas dos membros da equipe.
Decida se todos os membros da equipe serão intitulados “Engenheiro de confiabilidade” ou haverá uma mistura de SREs e funções e títulos tradicionais? Lembre-se de que os membros individuais da equipe podem ter especialidades, mas espera-se que todos contribuam em toda a equipe para todas as necessidades e funções, portanto, você precisa de pessoas flexíveis que estejam entusiasmadas para aprender juntas enquanto compartilham seus próprios conhecimentos.
Agora, defina seu orçamento salarial, seu orçamento de equipe e seu orçamento de ferramentas para o primeiro ano. Estimativa maior do que você acha que precisa.
Recomendamos a contratação de um bom conjunto de SREs experientes que amam seus empregos primeiro. Espere que esse conjunto inicial de 3-4 líderes comece aprendendo o que existe hoje, como funciona e pensando em como eles desejam assumir o controle. Considere uma combinação de contratações internas e externas para ajudar a tornar esse processo tranquilo institucionalmente, ao mesmo tempo em que fornece alguns novos insights e perspectivas.
Essas primeiras contratações precisarão de um pouco de tempo para conhecer as personalidades, pontos fortes e talentos uns dos outros, e talvez quaisquer lacunas que eles vejam na equipe como um todo. Confie em seus instintos quando eles lhe disserem o que precisam como equipe para ter sucesso. Pergunte a eles sobre quem contratar em seguida e inclua-os no processo de crescimento da equipe.
Deixe que a experiência e o conhecimento aprendido sobre o sistema que eles executarão guiem como as coisas progridem a partir daqui.
Como medimos o sucesso de nossa equipe de SRE?
Aqui estão alguns pensamentos. Se começarmos compilando uma lista de tempo de inatividade e falhas que causaram problemas, mesmo sem tempo de inatividade, e tivermos uma noção de quanto isso custou para a empresa, podemos usar isso como uma linha de base para medir.
Se implementarmos boas práticas de SRE e dermos aos nossos engenheiros as ferramentas e o número de funcionários de que nossas equipes precisam para ter sucesso, você verá uma diminuição em itens como tempo de inatividade, tanto no número de incidentes quanto na gravidade, ao mesmo tempo em que observa tempos de resposta mais rápidos e menores impactos no cliente e no negócio.
Grande parte da engenharia de confiabilidade trata de medir as coisas certas e usar esses dados para informar a priorização de trabalhos futuros. Quando erramos nas medições e métricas iniciais, mudamos assim que percebemos. É melhor mudar para uma nova instrumentação, métricas diferentes e políticas evoluídas do que manter o que temos apenas porque temos uma linha de base existente com a qual queremos medir.
Sabemos quando nosso tempo de atividade melhora. Sabemos quando nosso site é mais ou menos responsivo. Sabemos quando os clientes, tanto internos como externos, estão satisfeitos com o serviço que lhes é prestado. Meça o que você acha que é mais importante e concentre-se em melhorar isso. Quando estiver satisfeito com o sucesso dessa métrica, concentre-se em outra. O principal é escolher algo para melhorar e melhorar. Melhorias focadas, mesmo as pequenas , se somam.
A engenharia de confiabilidade é muito mais do que acelerar a recuperação de desastres. Trata-se de prevenir o tempo de inatividade, melhorar a capacidade de resposta do sistema a grandes cargas e tornar nossos sistemas tão eficientes e confiáveis quanto humanamente possível.
