9% de tempo de atividade garantido. Seu fornecedor está dizendo a verdade?

Uma afirmação de 99% de tempo de atividade parece tranquilizadora, mas o número por si só não me diz como será o desempenho de um serviço quando eu precisar dele. Um sistema pode atingir 99% de tempo de atividade e ainda assim ficar indisponível por mais de sete horas em um mês de 30 dias. Para um site comercial, plataforma de reservas ou loja online, esse tempo de inatividade pode afetar a confiança do cliente, o fluxo de trabalho da equipe e a receita. Não trato “99% de tempo de atividade” como prova. Eu trato isso como um ponto de partida para perguntas. O que realmente significa 99% de tempo de atividade? O tempo de atividade mede quanto tempo um serviço permanece disponível durante um período definido. Com um mês de 30 dias: - 99% de tempo de atividade permite cerca de 7 horas e 12 minutos de tempo de inatividade - 99,9% de tempo de atividade permite cerca de 43 minutos e 12 segundos de tempo de inatividade - 99,99% de tempo de atividade permite cerca de 4 minutos e 19 segundos de tempo de inatividade Esses números podem parecer pequenos em uma página de vendas. Nas operações diárias, várias horas sem acesso podem criar um problema sério. Um provedor de serviços pode calcular o tempo de atividade durante um ano inteiro, um mês civil ou um período de faturamento. O resultado muda com base na janela de medição. Manutenção planejada, falhas de terceiros, problemas de rede e problemas no nível da conta podem receber tratamento diferente de acordo com a política do provedor. É por isso que a percentagem precisa de contexto. A promessa precisa de uma definição clara Quando analiso uma declaração de tempo de atividade, procuro o escopo do serviço. A porcentagem cobre: ​​- O site principal - O painel do cliente - A API - Login e autenticação - Uploads de arquivos - Recursos de pagamento - Acesso a dados - Uma região específica ou todas as regiões Um provedor pode informar que sua plataforma principal está online enquanto uma API chave permanece indisponível. Os clientes ainda enfrentam interrupções, mesmo que o número principal permaneça inalterado. O acordo de nível de serviço deve explicar como o tempo de atividade é medido e o que acontece quando a meta não é atingida. Um crédito de serviço pode estar disponível, mas não pode cobrir vendas perdidas, prazos perdidos ou tempo gasto pela equipe no tratamento do incidente. O monitoramento pode mostrar a experiência dos clientes O monitoramento interno de um provedor é útil, mas prefiro verificar se o serviço é testado fora de sua própria rede. O monitoramento externo pode verificar: - Carregamento da página - Acesso de login - Resposta da API - Resolução de DNS - Tempo de resposta do servidor - Disponibilidade regional Um ping básico do servidor não prova que os clientes podem concluir uma tarefa. Um site pode responder a uma solicitação de rede enquanto sua página de checkout, ferramenta de pesquisa ou processo de login falha. O monitoramento sintético oferece uma visão mais prática. Ele pode executar testes como abrir uma página, inserir dados de amostra e verificar se o resultado esperado aparece. Esse tipo de teste não substitui os dados do provedor, mas pode revelar problemas que um simples selo de tempo de atividade deixa passar. Uma página de status pública fornece evidências úteis Uma página de status pública pode mostrar incidentes passados, a integridade atual do sistema e registros de manutenção. Procuro detalhes como: - Horários de início e término - Serviços afetados - Regiões afetadas - Atualizações de incidentes - Informações sobre a causa raiz - Etapas tomadas para reduzir falhas repetidas Uma página de status não garante desempenho estável. Mostra quão abertamente o provedor se comunica quando algo dá errado. A qualidade das atualizações é importante. “Estamos investigando” pode ser uma mensagem inicial razoável. Várias horas de atualizações vagas sem um impacto claro no serviço podem dificultar o planejamento dos clientes. Interrupções reais mostram por que os detalhes são importantes Em junho de 2022, a Cloudflare passou por uma interrupção generalizada associada a uma alteração na configuração da rede. Muitos serviços online que dependiam da Cloudflare tornaram-se difíceis ou impossíveis de acessar por um período de tempo. O evento mostrou um ponto prático: uma empresa pode ter um servidor de aplicativos íntegro e ainda assim perder acesso aos clientes quando um importante provedor de rede falha. Um provedor de hospedagem pode publicar uma forte porcentagem de tempo de atividade, enquanto a jornada completa do cliente depende de outros serviços, como DNS, processamento de pagamentos, entrega de e-mail, redes de entrega de conteúdo e bancos de dados externos. Julgo a disponibilidade em toda essa cadeia, não em um número. Perguntas que faço antes de confiar em uma declaração de tempo de atividade Pergunto ao provedor: 1. Como o tempo de atividade é calculado? 2. O que conta como tempo de inatividade? 3. Os períodos de manutenção planeados estão excluídos? 4. As falhas parciais de serviço estão incluídas? 5. O cálculo abrange minha região? 6. Com que rapidez o provedor detecta um incidente? 7. Com que frequência os clientes são atualizados? 8. Existe compensação quando a meta não é atingida? 9. Posso revisar incidentes históricos? 10. Quais planos de backup e recuperação estão em vigor? As respostas devem ser escritas em linguagem simples. Se a política for difícil de compreender, a percentagem publicada poderá não me ajudar a tomar uma decisão prática. O tempo de atividade é apenas uma parte da confiabilidade do serviço A disponibilidade é importante, mas não descreve todo o serviço. Também verifico: - Objetivo de tempo de recuperação, ou a rapidez com que o serviço deve retornar - Objetivo de ponto de recuperação, ou quantos dados recentes podem ser perdidos - Frequência de backup - Testes de restauração de backup - Tempos de resposta de suporte - Capacidade durante tráfego intenso - Comunicação de incidentes de segurança - Opções de exportação de dados Uma plataforma que permanece on-line, mas perde dados do cliente, ainda cria um grande risco comercial. Um serviço que se recupera rapidamente, mas não consegue restaurar backups precisos, pode não atender às necessidades de uma empresa em crescimento. Minha visão é simples: o tempo de atividade me diz com que frequência um serviço está acessível. O planejamento de recuperação me diz como o provedor responde quando a disponibilidade falha. Como testar você mesmo a reivindicação Eu uso um breve processo de revisão antes de escolher um fornecedor. Verifico o acordo de nível de serviço e marco todas as exclusões. Comparo a meta de tempo de atividade com o número de horas que ela permite. Reviso o histórico do status público e procuro incidentes repetidos. Testo as principais ações do cliente em mais de um local. Faço perguntas de suporte antes de me inscrever e observo a clareza com que a equipe responde. Para uma plataforma crítica para os negócios, executo um pequeno piloto. O teste inclui tráfego normal, acesso de usuário, relatórios, integrações e uma solicitação de restauração de backup quando o provedor permitir. Um piloto curto não pode prever todas as interrupções, mas pode expor limites pouco claros e um suporte fraco. Eu registro os resultados em vez de confiar em um crachá ou extrato de vendas. Uma reivindicação de tempo de atividade de 99% pode ser precisa de acordo com o método declarado do provedor. Ainda pode ser uma opção inadequada para uma empresa que precisa de acesso quase contínuo. A questão útil não é se o número parece bom. A questão útil é se o plano de medição, exclusões, monitoramento e recuperação corresponde ao serviço que preciso executar. Uma promessa torna-se evidência quando o fornecedor explica como é medida, publica o seu histórico e oferece aos clientes uma forma prática de verificar o desempenho.

Um fornecedor pode escrever “99% de tempo de atividade” em uma proposta em poucos segundos. A questão mais difícil é o que esse número cobre, como é medido e o que acontece quando o serviço fica offline. Já vi compradores compararem os números do tempo de atividade como se fossem iguais. Eles não são. Um fornecedor pode contar apenas sua plataforma principal, enquanto seu contrato depende de armazenamento, acesso à rede, sistemas de suporte, ferramentas de terceiros e manutenção programada. Um elo fraco pode afetar o seu negócio mesmo quando o fornecedor reporta um resultado mensal saudável. Antes de assinar, verifico os detalhes por trás da porcentagem. ### O que significa 99% de tempo de atividade? Uma meta de tempo de atividade de 99% permite cerca de: - 7 horas e 26 minutos de tempo de inatividade em um mês de 30 dias - 3 dias e 15 horas de tempo de inatividade em um ano de 365 dias Isso pode parecer aceitável para uma ferramenta interna de baixo risco. Pode criar sérios problemas para uma loja online, serviço de pagamento, plataforma de reservas ou portal do cliente. Um fornecedor que promete 99,9% permite cerca de 43 minutos de inatividade em um mês de 30 dias. A diferença entre 99% e 99,9% é grande, embora o número pareça pequeno. Não julgo a oferta apenas pela porcentagem. Pergunto como o fornecedor calcula isso. ### Pergunte o que significa “disponível” Um serviço pode ser marcado como disponível quando a página de login é carregada, mesmo que os usuários não consigam concluir um pagamento ou fazer upload de um arquivo. Peço ao fornecedor que defina: - Quais funções estão incluídas - Quais regiões são cobertas - Se as respostas lentas contam como tempo de inatividade - Se as falhas parciais de serviço contam - Como as solicitações com falha são medidas - Qual sistema de monitoramento fornece os dados - Como os clientes podem revisar os registros Uma definição útil de tempo de atividade deve refletir o trabalho que meus usuários precisam realizar. Se os clientes conseguem abrir uma página, mas não conseguem fazer um pedido, o serviço não está funcionando do ponto de vista deles. ### Revise as exclusões Muitas promessas de tempo de atividade excluem eventos como: - Manutenção planejada - Manutenção de emergência - Erros de configuração do cliente - Falhas no provedor de Internet - Interrupções de serviços de terceiros - Incidentes de segurança cibernética - Eventos de força maior - Problemas causados ​​por software não suportado Algumas exclusões podem ser razoáveis. Uma lista longa pode tornar o número de tempo de atividade menos útil. Leio cada exclusão e peço um exemplo prático. Se o fornecedor excluir “eventos de rede”, pergunto se isso inclui uma falha dentro do seu próprio data center. Se a manutenção for excluída, pergunto quanto aviso receberei e quanto tempo o trabalho poderá durar. A resposta deve constar no contrato, não apenas em uma ligação de vendas. ### Verifique os créditos de serviço Um acordo de nível de serviço pode oferecer créditos quando o tempo de atividade ficar abaixo da meta declarada. Isso parece útil, mas o crédito pode ser pequeno comparado ao custo de uma interrupção. Eu verifico: - O valor do crédito - O prazo da reclamação - As provas exigidas - Se os créditos são automáticos - O crédito mensal máximo - Se o crédito é a única solução - O que acontece após falhas repetidas Um fornecedor pode exigir que o cliente apresente uma reclamação no prazo de dez dias. Se o processo não estiver claro, o cliente pode perder o prazo ao lidar com a interrupção em si. Os créditos de serviço também não reparam vendas perdidas, compromissos perdidos, tempo de inatividade da equipe ou danos à confiança do cliente. Eu os trato como parte do contrato e não como um substituto da confiabilidade do serviço. ### Solicitar evidências do passado Um fornecedor deve ser capaz de explicar seu histórico de serviços sem se esconder atrás de uma única porcentagem. Peço para ver: - Registros públicos de status - Relatórios de incidentes - Histórico de manutenção - Dados de tempo de recuperação - Relatórios de causa raiz - Referências recentes de clientes - Detalhes de qualquer interrupção grave Uma página de status pode mostrar padrões que um documento de vendas não mostra. Interrupções curtas repetidas podem apontar para um risco diferente de uma interrupção longa. Ambos são importantes, dependendo de como sua empresa opera. A interrupção do serviço da Cloudflare em 2020 é um lembrete útil de que um problema num componente interno pode afetar muitos produtos ao mesmo tempo. Uma empresa pode ter sistemas robustos em funcionamento e ainda assim enfrentar um incidente grave. A questão prática é a rapidez com que detecta o problema, comunica com os clientes, restaura o serviço e evita repetições. ### Teste o plano de recuperação do fornecedor O tempo de atividade é apenas uma parte da confiabilidade. Também pergunto o que acontece depois de uma falha. O fornecedor deve explicar: - Com que frequência os backups são criados - Onde os backups são armazenados - Como a restauração é testada - A meta de tempo de recuperação - A meta do ponto de recuperação - Quem lidera a resposta - Como os clientes recebem atualizações - Como o fornecedor lida com a perda de dados Um fornecedor pode alegar que existem backups, mas nunca testar uma restauração completa. Isso deixa uma lacuna importante entre a política e o desempenho. Prefiro respostas claras como “Restauramos um backup trimestralmente e registramos o resultado”, em vez de declarações amplas sobre proteção forte. ### Separe o tempo de atividade do fornecedor da sua própria configuração Mesmo um fornecedor confiável não pode controlar todas as partes do seu ambiente. Seu serviço ainda pode falhar devido a: - Configurações de DNS ruins - Registro de domínio expirado - Regras de firewall incorretas - Acesso fraco à Internet - Integrações quebradas - Alterações não planejadas de software - Falta de contatos de backup Mapeio o caminho completo do serviço antes de tomar uma decisão. Isso inclui o dispositivo do usuário, conexão com a Internet, domínio, plataforma de hospedagem, software, provedor de pagamento e processo de suporte. O valor de 99% do fornecedor pode cobrir apenas uma seção desse caminho. ### Use uma tabela de comparação simples Quando comparo fornecedores, registro as respostas em um só lugar. | Pergunta | Fornecedor A | Fornecedor B | |---|---|---| | Meta de tempo de atividade | 99% | 99,9% | | Método de medição | Resposta do servidor | Transação concluída | | Manutenção planeada excluída | Sim | Limitado | | Histórico de incidentes públicos | Disponível | Não disponível | | Crédito de serviço | 5% | 10% | | Meta de tempo de recuperação | 12 horas | 4 horas | | Período de aviso ao cliente | 24 horas | 72 horas | A tabela revela frequentemente que um preço mais baixo acarreta exclusões mais amplas, relatórios mais fracos ou um período de recuperação mais longo. ### Faça perguntas diretas antes de assinar Eu enviaria estas perguntas ao fornecedor: 1. Quanto tempo de inatividade os clientes enfrentaram durante os últimos 12 meses? 2. A meta de tempo de atividade abrange as funções que meus clientes usam? 3. Quais eventos estão excluídos? 4. Como é medido o tempo de inatividade? 5. Posso visualizar os registros de monitoramento? 6. Como você me notificará durante um incidente? 7. Qual é a meta de tempo de recuperação? 8. Com que frequência você testa backups? 9. Que compensação se aplica após uma meta não cumprida? 10. Posso rescindir o contrato após repetidas falhas no serviço? O estilo de resposta do fornecedor também fornece informações úteis. Respostas claras mostram que a equipe pensou no serviço. Respostas vagas podem sinalizar que o número constante da proposta tem pouco valor prático. Uma reivindicação de tempo de atividade de 99% pode ser razoável para uma empresa e fraca demais para outra. Examino a porcentagem, calculo o tempo de inatividade permitido, reviso as exclusões, verifico o desempenho passado e testo o plano de recuperação. O fornecedor certo não é aquele com o maior número na página. É aquele que define claramente a promessa e pode mostrar como apoia essa promessa quando os usuários não conseguem acessar o serviço.

Um número de tempo de atividade elevado pode parecer tranquilizador, mas o número por si só não me diz o desempenho de um serviço quando os clientes mais precisam dele. Um provedor pode anunciar um tempo de atividade de 99,9%. Isso parece forte até eu convertê-lo em tempo de inatividade. Em um mês de 30 dias, 0,1% permite cerca de 43 minutos de interrupção do serviço. O valor também pode excluir manutenções programadas, problemas de rede fora do controle do provedor ou incidentes que afetam apenas parte da plataforma. Quando comparo serviços de hospedagem, nuvem, SaaS ou pagamento, procuro os dados por trás da reivindicação. ### Verifique como o tempo de atividade é medido Um provedor deve explicar: - Quais sistemas estão incluídos - Com que frequência a disponibilidade é verificada - Se o teste usa um monitor externo - O que conta como tempo de inatividade - Como as interrupções parciais são registradas - Se a manutenção é excluída Uma página inicial pode permanecer on-line enquanto o login, o checkout, o upload de arquivos ou as chamadas de API falham. Uma verificação básica do servidor ainda pode relatar o serviço como disponível. Meus clientes experimentam a função com falha, e não o status mostrado por um simples script de monitoramento. Um relatório útil de tempo de atividade deve refletir as partes do serviço das quais os usuários realmente dependem. ### Solicitar uma página de status pública Uma página de status pública me dá uma maneira de revisar incidentes passados. Posso verificar: - Datas dos incidentes - Horários de início e término - Serviços afetados - Regiões de serviço - Atualizações durante o evento - A explicação do provedor após a recuperação Empresas como Cloudflare e GitHub publicam informações de status de serviço por meio de páginas de status públicas. Essas páginas não eliminam o risco de tempo de inatividade, mas fornecem aos compradores mais contexto do que apenas uma afirmação de marketing. Presto atenção ao padrão. Uma pequena interrupção pode ter pouco efeito em meus negócios. Incidentes repetidos que afetem o mesmo produto ou região podem demonstrar uma preocupação mais profunda com a confiabilidade. ### Leia o contrato de serviço O contrato de nível de serviço geralmente contém os detalhes que faltam em uma página de vendas. Procuro a meta exata de tempo de atividade, o período de medição, as soluções disponíveis e as exclusões. Alguns acordos oferecem créditos de serviço em vez de reembolso. Um crédito não pode cobrir vendas perdidas, atrasos no trabalho, custos de suporte ao cliente ou danos à reputação. Também verifico se o contrato cobre o recurso que utilizo. Um provedor pode publicar uma meta de tempo de atividade para sua plataforma principal, enquanto APIs, ferramentas de armazenamento ou serviços de suporte separados seguem termos diferentes. O texto é mais importante do que a grande porcentagem exibida em um anúncio. ### Compare dados de monitoramento externo Prefiro testar um serviço fora da rede do próprio provedor. Ferramentas como Pingdom, UptimeRobot, Better Stack e Statuspage podem ajudar a rastrear a disponibilidade em diferentes locais. Meu plano de monitoramento geralmente inclui: 1. Uma verificação da página inicial ou do endpoint principal 2. Um teste de login 3. Um teste de transação, como adicionar um item a um carrinho 4. Uma solicitação de API se meu negócio depender de uma API 5. Alertas enviados para mais de um membro da equipe Uma verificação da página inicial por si só pode criar uma falsa sensação de segurança. Para uma loja online, preciso saber se os clientes podem pesquisar, pagar e receber a confirmação do pedido. Também registro o tempo de resposta. Uma página que carrega após 30 segundos pode ser tecnicamente acessível, mas muitos visitantes sairão antes que ela seja aberta. ### Revise o histórico de incidentes do provedor Incidentes passados ​​podem mostrar como um provedor responde sob pressão. Eu observo a qualidade e o momento das atualizações de status. O provedor explicou o que aconteceu? Mostrou quais regiões foram afetadas? A equipe forneceu uma atualização de recuperação e um relatório de acompanhamento? Uma mensagem vaga como “o problema foi resolvido” me dá poucas informações úteis. Registros claros de incidentes me ajudam a avaliar o processo de comunicação e manutenção do fornecedor. Também pergunto como a empresa lida com proteção de dados, backups, failover e recuperação de desastres. Um número de tempo de atividade não mostra se meus dados podem ser restaurados após uma falha grave. ### Teste o suporte antes de escolher Entro em contato com o suporte com perguntas técnicas específicas antes de me inscrever. A resposta pode revelar como o fornecedor lida com os detalhes. Posso perguntar: - Como é calculado o tempo de atividade? - O que aconteceu durante a última grande interrupção? - Quais serviços são cobertos pela garantia de uptime? - Como são contabilizadas as falhas regionais? - O que acontece durante a manutenção planejada? - Como os clientes podem solicitar créditos de serviço? Uma resposta clara gera mais confiança do que uma grande porcentagem impressa em uma página de preços. Por exemplo, uma pequena loja online com a qual trabalhei selecionou uma plataforma com base em uma reivindicação de 99,99%. Depois que um problema de pagamento afetou os clientes, a loja descobriu que o processamento de pagamentos estava coberto por um termo de serviço separado. O site principal permaneceu disponível, então o relatório de tempo de atividade do provedor apresentou um forte resultado. Do ponto de vista do dono da loja, os clientes ainda não conseguiam concluir os pedidos. A lição é simples: o tempo de atividade deve ser medido em relação à ação comercial que importa. Não rejeito um provedor porque ele sofreu interrupções. Todo serviço complexo pode enfrentar problemas técnicos. Analiso as provas, o âmbito da garantia, o método de monitorização e a resposta após um incidente. Uma declaração confiável de tempo de atividade deve vir acompanhada de registros, definições e acesso a dados de suporte. Quando faltam esses detalhes, trato a porcentagem como uma demonstração de vendas, em vez de um quadro completo da confiabilidade do serviço.

Quando um fornecedor promete 99,9% de tempo de atividade, não trato o número como prova de serviço confiável. Uma porcentagem pode parecer alta enquanto o contrato deixa de fora manutenção planejada, falhas de rede, atrasos no suporte ou repetidas interrupções curtas. Já vi compradores compararem os valores do tempo de atividade durante a seleção do fornecedor e ignorarem os detalhes que definem como o valor é medido. Isso pode criar problemas após a implantação. O serviço pode atender às reivindicações públicas do fornecedor, mas não atende às necessidades da empresa que o utiliza. A verdadeira questão é simples: o fornecedor pode mostrar como a promessa de tempo de atividade é medida, relatada e tratada quando o serviço fica abaixo do nível acordado? ## Leia a definição de tempo de atividade O tempo de atividade pode se referir à plataforma completa, a um único recurso ou apenas ao data center principal do fornecedor. Esses significados não são iguais. Procuro respostas claras para perguntas como: - Que serviço ou sistema o valor do tempo de atividade cobre? - A medição inclui portal do cliente, API, armazenamento e serviço de login? - O tempo de atividade é calculado mensalmente, trimestralmente ou anualmente? - Uma pequena interrupção conta? - As falhas regionais estão incluídas? - O valor é baseado no sistema de monitoramento do próprio fornecedor? Um fornecedor pode relatar um forte tempo de atividade da plataforma, enquanto uma API usada pelos clientes tem um registro diferente. Uma definição escrita ajuda a evitar essa lacuna. ## Verifique as exclusões de interrupções A maioria dos contratos de serviço lista eventos que não contam como tempo de inatividade. Algumas exclusões podem ser razoáveis, como alterações de configuração causadas pelo cliente ou manutenção aprovada. A redação ainda merece uma revisão cuidadosa. Presto atenção aos termos que abrangem: - Manutenção programada - Manutenção de emergência - Provedores de rede terceirizados - Falhas na infraestrutura de nuvem - Incidentes de segurança cibernética - Equipamentos do cliente ou acesso à Internet - Eventos de força maior - Suspensão de conta ou problemas de cobrança Uma exclusão ampla pode reduzir o valor prático de uma garantia de tempo de atividade. Se a manutenção de emergência não tiver limite de tempo, interrupções repetidas do serviço poderão ficar fora do cálculo do fornecedor. Peça ao fornecedor para explicar cada exclusão com um exemplo simples. Uma resposta clara é mais útil do que uma cláusula contratual longa que poucos usuários conseguem interpretar. ## Converta a porcentagem em tempo de inatividade A porcentagem fica mais fácil de entender quando eu a converto em horas e minutos. Para um mês de 30 dias: - 99% de tempo de atividade permite cerca de 7 horas e 12 minutos de inatividade - 99,5% permite cerca de 3 horas e 36 minutos - 99,9% permite cerca de 43 minutos - 99,99% permite cerca de 4 minutos e 19 segundos Esses números mostram por que o nível de serviço deve corresponder à necessidade do negócio. Uma empresa que processa pedidos ao longo do dia pode considerar 43 minutos uma interrupção grave. Um sistema utilizado para relatórios internos pode aceitar um nível diferente. O cálculo também deve corresponder ao período de medição do fornecedor. Um número anual pode esconder vários meses difíceis. ## Revise os créditos de serviço Uma garantia geralmente vem com créditos de serviço em vez de compensação direta. O crédito pode ser aplicado a uma fatura futura e o cliente pode precisar enviar uma reclamação dentro de um curto período. Eu verifico: - Como o crédito é calculado - Se o crédito cobre o serviço afetado - O crédito máximo permitido - O prazo de reclamação - As provas exigidas - Se o crédito é automático - Se o contrato oferece outras soluções ao cliente Um crédito não restaura vendas perdidas, trabalho perdido ou confiança do cliente. Oferece uma solução contratual, não uma medida completa do impacto nos negócios. ## Solicite evidências de monitoramento Um fornecedor confiável deve explicar como o tempo de atividade é monitorado. Evidências úteis podem incluir páginas de status, relatórios mensais, registros de incidentes, avisos de manutenção e reuniões de revisão de serviço. Eu pediria para ver um exemplo de relatório que mostrasse: - O método de medição - Tempo total de interrupção - Horários de início e término - Serviços afetados - Eventos excluídos - Causa raiz - Ação corretiva O relatório não precisa revelar dados confidenciais do cliente. Deve mostrar detalhes suficientes para que o comprador entenda se o número reflete o desempenho real do serviço. Um exemplo comum de compra envolve um fornecedor de software que anunciava 99,9% de tempo de atividade. Depois que um cliente passou por diversas falhas de login, a análise mostrou que o fornecedor mediu apenas o aplicativo principal. O serviço de identidade utilizado para login foi excluído da figura pública. O contrato também excluía pequenas interrupções inferiores a cinco minutos. A percentagem declarada não era necessariamente falsa, mas não descrevia a experiência completa do cliente. ## Teste o processo de suporte O tempo de atividade e a resposta do suporte estão conectados. Um serviço pode se recuperar rapidamente quando o fornecedor detecta um incidente, enquanto um processo de suporte lento pode ampliar o impacto sobre os usuários. Pergunto sobre: ​​- Horário de suporte - Níveis de gravidade - Metas de resposta - Contatos de escalonamento - Atualizações de status - Relatórios de incidentes - Comunicação durante interrupções regionais Uma meta de resposta é diferente de uma meta de resolução. “Resposta dentro de uma hora” não significa que o problema será resolvido dentro de uma hora. O contrato deve deixar essa distinção clara. ## Coloque os termos corretos no contrato Uma apresentação de vendas não substitui a linguagem do contrato. O acordo deve identificar o serviço coberto, método de medição, exclusões, processo de relatório, deveres de suporte e solução. Também comparo a promessa de tempo de atividade com minhas próprias necessidades. Se um fornecedor oferece um nível de serviço geral para cada cliente, verifico se ele se adapta aos sistemas mais importantes para o meu negócio. Uma revisão prática pode seguir esta ordem: 1. Definir os serviços que requerem proteção de tempo de atividade. 2. Converta a percentagem indicada em tempo de inatividade permitido. 3. Liste todas as exclusões. 4. Rever os métodos de monitorização e elaboração de relatórios. 5. Verifique as tarefas de suporte e escalonamento. 6. Confirme o processo de crédito do serviço. 7. Registre os termos acordados no contrato. 8. Revise o desempenho após a implantação. Uma garantia de tempo de atividade pode ser útil quando o texto corresponde ao serviço do qual as pessoas dependem. A percentagem por si só me diz muito pouco. Preciso das regras de medição, das exclusões, das evidências e do plano de resposta. Quando avalio um fornecedor, olho além do número do título e pergunto o que os usuários vivenciarão durante uma interrupção. Essa abordagem leva mais tempo durante a aquisição, mas dá à empresa uma base mais clara para comparar fornecedores e planear interrupções de serviço.

Uma promessa de tempo de atividade de 99% pode parecer reconfortante até que eu a converta em horas. Um serviço com 99% de tempo de atividade pode ficar indisponível por cerca de 87 horas e 36 minutos por ano. São mais de três dias e meio. Uma meta de 99,9% permite cerca de 8 horas e 46 minutos de inatividade. Uma meta de 99,99% permite cerca de 52 minutos. O número por si só não me diz o quão confiável será um serviço. Quando comparo provedores de hospedagem, plataformas em nuvem ou software empresarial, examino a porcentagem. Li a definição de tempo de atividade, o período de medição, as exclusões e as regras de crédito de serviço. Esses detalhes geralmente moldam a experiência real do cliente. Um provedor pode calcular o tempo de atividade ao longo de um mês. Outro pode usar uma média anual. Uma interrupção curta pode ter um efeito maior em um relatório mensal, enquanto um incidente longo pode parecer menor em um valor anual. O cálculo também depende do que o fornecedor mede. Um sistema de monitoramento pode verificar se um site responde a uma solicitação básica. Essa verificação pode ser aprovada enquanto os clientes não conseguem fazer login, concluir a compra, fazer upload de arquivos ou chegar a uma região importante. Uma página inicial carregada nem sempre significa que o serviço completo está funcionando. Já vi esse problema em lojas online. As páginas do produto abriram normalmente, mas o gateway de pagamento falhou. A partir de uma simples verificação de tempo de atividade, o site parecia disponível. Do ponto de vista do cliente, a principal função comercial havia parado. Uma garantia de tempo de atividade útil deve responder a diversas perguntas. O que significa “disponível”? Procure uma definição de serviço clara. Pode referir-se a: - Uma resposta bem-sucedida do servidor - Uma solicitação de API em funcionamento - Acesso a um recurso específico - Disponibilidade em regiões selecionadas - Uma porcentagem de solicitações bem-sucedidas Uma definição vaga não ajuda muito quando uma interrupção afeta apenas um recurso ou local. Como o tempo de inatividade é medido? Verifique o método de monitoramento e os locais de teste. Um provedor pode monitorar a partir de um data center enquanto usuários se conectam de vários países. Problemas de rede, falhas regionais, erros de DNS e problemas de roteamento podem afetar os clientes sem aparecer em um teste de local único. Também verifico se o provedor mede o desempenho médio ou solicitações individuais. Um serviço que responde lentamente por dez minutos ainda pode passar em um teste básico de tempo de atividade, mesmo que os usuários tenham dificuldade para concluir as tarefas. Quais exclusões se aplicam? As políticas de tempo de atividade geralmente excluem eventos como: - Manutenção planejada - Erros de configuração do cliente - Problemas causados ​​por redes externas - Falhas de software de terceiros - Tráfego além dos limites acordados - Incidentes de segurança - Eventos de força maior Algumas exclusões podem ser razoáveis. A preocupação é uma formulação pouco clara. Se muitos tipos de falhas comuns forem removidos do cálculo, a porcentagem publicada poderá não refletir o serviço do qual dependo. A manutenção planejada merece atenção especial. Um provedor pode anunciar a manutenção com antecedência e excluí-la do tempo de inatividade. Preciso saber com que frequência isso acontece, quanto tempo normalmente dura e se recursos críticos permanecem disponíveis durante o trabalho. Qual período a garantia cobre? Uma garantia mensal pode produzir resultados diferentes de uma garantia anual. Um serviço que passa por 40 minutos de inatividade em um mês pode ficar abaixo da meta mensal de 99,9%. Os mesmos 40 minutos distribuídos ao longo de um ano permanecem dentro da meta anual de 99,99%. A porcentagem só tem significado quando conheço a janela de tempo por trás dela. O que acontece depois de uma meta perdida? Muitos contratos de tempo de atividade oferecem créditos de serviço em vez de compensação direta por vendas perdidas, prazos perdidos ou reclamações de clientes. O crédito pode exigir uma reclamação formal dentro de um determinado número de dias. Também pode ser limitado a parte da taxa mensal de serviço. Isso não torna a garantia inútil. Simplesmente mostra o que a garantia foi projetada para fazer. Pode criar um compromisso de serviço, mas pode não cobrir o impacto comercial de uma interrupção. Trato o processo de crédito como parte do produto. Um processo de reclamação claro, relatórios públicos de incidentes e registros de suporte úteis me dizem mais do que uma grande porcentagem mostrada em uma página de vendas. Também pergunto como o provedor lida com interrupções parciais. Uma falha completa da plataforma é fácil de identificar. Um banco de dados pode funcionar enquanto o upload de arquivos falha. Um painel pode ser aberto enquanto os trabalhos em segundo plano permanecem travados. Uma região pode estar íntegra enquanto outra região apresenta erros repetidos. Para meus próprios projetos, acompanho as funções mais importantes: - Os usuários podem fazer login? - Eles podem fazer um pedido? - A API pode aceitar solicitações? - A equipe pode acessar o sistema administrativo? - Os trabalhos agendados podem terminar? - Os dados podem ser copiados e restaurados? Essas verificações me dão uma visão melhor do que um único resultado “para cima ou para baixo”. Eu uso um processo de revisão simples antes de escolher um fornecedor: 1. Leia o acordo de nível de serviço, não apenas a página de marketing. 2. Converta a porcentagem de tempo de atividade em tempo de inatividade permitido. 3. Verifique o período de medição. 4. Revise as exclusões e regras de manutenção. 5. Confirme as regiões abrangidas pelo monitoramento. 6. Leia relatórios de incidentes recentes. 7. Teste a resposta do suporte antes que ocorra um problema sério. 8. Crie um monitor independente para as principais ações do cliente. 9. Mantenha backups e um plano de recuperação. 10. Compare o custo de uma resiliência mais forte com o custo do tempo de inatividade. A última etapa é importante porque cada empresa tem uma tolerância diferente para interrupções de serviço. Um blog pessoal pode suportar várias horas de inatividade. Uma plataforma de reservas, sistema de folha de pagamento ou loja online pode precisar de outro design, como múltiplas regiões, sistemas de backup, testes de failover e um plano de recuperação claro. Um número de tempo de atividade mais alto não elimina o risco operacional. Pode reduzir uma parte desse risco quando o fornecedor o define e mede cuidadosamente. Minha opinião é simples: trate “99% de tempo de atividade” como ponto de partida, não como uma promessa completa. Pergunte o que foi medido, onde foi medido, quais funções foram incluídas e qual suporte está disponível quando o serviço falha. A garantia útil não é aquela com maior número. É aquele que posso entender, testar e conectar às partes do meu negócio que os clientes realmente usam. Para qualquer dúvida sobre o conteúdo deste artigo, entre em contato com Jerry: sales@cnisbm.com/WhatsApp +8618967898611.

Referências Equipe do Google SRE, 2016, Site Reliability Engineering: How Google Runs Production Systems Cloudflare, 21 de junho de 2022, Cloudflare Outage em 21 de junho de 2022 Amazon Web Services, 2024, Amazon EC2 Service Level Agreement Microsoft, 2024, Azure Service Level Agreements Google Cloud, 2024, Google Cloud Service Level Agreements Uptime Institute, 2023, Annual Outage Analysis 2023