O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
O problema da linguagem de SLA com a qual ninguém consegue fazer nada
Um SLA que promete 99.99 por cento de disponibilidade parece preciso e tranquilizador até você ler o que acontece quando a meta não é cumprida. Muitas vezes, a compensação é um pequeno crédito de serviço, calculado como uma fração de uma fração da sua fatura mensal, disponível apenas se você mesmo perceber a falha, documentá-la com precisão e abrir uma reclamação dentro de um prazo curto, por meio de um processo que custa mais tempo da equipe do que o valor do crédito. A porcentagem na página de vendas e a proteção real por trás dela são duas coisas muito diferentes.
Isso não tem a ver com números de disponibilidade desonestos. A maioria dos provedores que publicam 99.9 ou 99.99 por cento provavelmente está descrevendo um desempenho histórico real. O problema é que uma porcentagem de disponibilidade, sozinha, descreve o histórico do provedor, não o que acontece especificamente com você quando esse histórico tem um dia ruim. Um cliente que lê um SLA quer saber que recurso ele tem durante uma falha, não só em que porcentagem do ano o serviço deve funcionar.
Preferimos que um compromisso de status seja julgado pelo que o cliente consegue realmente fazer com ele, e não por como o número de destaque fica em uma página de vendas. Isso começa com uma visibilidade que você não precisa pedir: cabeçalhos de cota em cada resposta, para que você saiba sua situação em tempo real, e documentação clara e publicada de limites de taxa e códigos de erro, em vez de um documento que você só lê depois que algo já quebrou.
Um SLA viável, se um provedor for oferecer um, precisa especificar uma compensação proporcional e fácil de solicitar, e não um detalhe técnico que desencoraja qualquer pessoa de realmente pedi-la. Se o crédito por uma meta de disponibilidade não cumprida é realmente pequeno demais para fazer diferença e o processo de reclamação é realmente lento demais para valer a pena, o SLA está funcionando como uma peça de marketing, não como uma promessa operacional. Ele existe para ser impresso, não para ser usado.
Achamos que o mais honesto que um provedor pode fazer é ser claro sobre o que realmente acontece durante uma degradação do serviço ou uma falha: o que é comunicado, quando e por qual canal, em vez de começar com uma porcentagem que sugere uma garantia que ele não consegue sustentar com uma compensação viável. Uma página de status que diz a verdade rapidamente vale mais para uma integração do que um número contratual que só paga em teoria.
Nada disso significa que compromissos de disponibilidade não valem nada. Um provedor disposto a publicar um número real e a sustentar uma compensação real e utilizável está fazendo algo bem diferente de um que publica uma porcentagem impressionante e um processo pensado para nunca ser acionado. A diferença não está na quantidade de noves. Está em saber se a promessa por trás do número é algo que você realmente conseguiria cobrar, em uma semana ruim, sem que isso custe mais esforço do que a própria falha.