Status
Todos os sistemas operacionais.
Uma página de status só vale alguma coisa se estiver disposta a dizer algo ruim. Esta aqui é atualizada durante o incidente, não depois, o que significa que às vezes você vai ver a palavra investigando do lado de um componente enquanto a gente ainda não sabe por quê.
Componentes
| Componente | Estado | Meta | Agora |
|---|---|---|---|
| API | Operacional | 99,9 por cento de disponibilidade | Nenhum erro acima da linha de base nas últimas 24 horas |
| Provisionamento | Operacional | 99,5 por cento dos pedidos pagos chegam a um perfil funcionando | A hora móvel está acima da meta, instalação mediana de 41 segundos |
| Pagamentos | Operacional | Autorização e reembolso automático em menos de 60 segundos | O processador reporta normalidade e os reembolsos estão saindo no prazo |
| Dados de cobertura | Operacional | Números publicados atualizados todo dia, com o piso de 25 amostras mantido | A última atualização terminou e nenhum país está oculto por dado velho |
| Suporte | Operacional | Primeira resposta em menos de 60 segundos, 24 horas por dia | A fila está dentro da meta em todos os idiomas atendidos |
Operacional quer dizer que o componente está cumprindo a meta na hora móvel. Não é uma promessa sobre a próxima hora.
99,5%
meta de sucesso no provisionamento
60 s
reembolso automático quando o provisionamento falha
30 min
duração de incidente que obriga a um post mortem público
72 h
prazo para publicar esse post mortem
O que significa cada estado
| Estado | O que significa | O que fazemos |
|---|---|---|
| Operacional | O componente está cumprindo a meta na hora móvel | Nada. É o estado normal e não é uma promessa sobre o futuro |
| Desempenho degradado | Funcionando, mas mais lento ou menos confiável que a meta | Citado nesta página, clientes afetados avisados, créditos aplicados sem ninguém pedir |
| Interrupção parcial | Falhando para um grupo identificável, como uma operadora ou uma região | O grupo é citado, as compras são bloqueadas onde falhariam, os reembolsos disparam sozinhos |
| Interrupção total | Falhando de forma ampla | Um comandante do incidente é nomeado e as atualizações saem pelo menos a cada 30 minutos até resolver |
| Manutenção | Trabalho planejado com janela conhecida | Anunciada com pelo menos 72 horas de antecedência e agendada na hora de menor tráfego |
Não existe um estado que signifique bem, provavelmente. Ou o componente está cumprindo a meta, ou ele está citado nesta página.
A política de incidentes
Dois compromissos seguram tudo isso, e os dois são incômodos de propósito. O primeiro é que a gente avisa os clientes afetados antes de eles perceberem. O segundo é que tudo que passa de 30 minutos ganha um post mortem escrito e publicado em até 72 horas.
O post mortem cita sistemas e decisões, não funcionários específicos, e quem escreve é quem estava de plantão, não um gestor descrevendo outra pessoa.
Se a gente for furar o prazo de 72 horas, publica o atraso e o motivo dentro dessas 72 horas, porque um prazo furado e anunciado tarde são duas falhas.
- A detecção é automática, a partir das taxas de sucesso no provisionamento e de autorização de pagamento, então um incidente começa quando os números se mexem e não quando alguém reclama
- O estado do componente nesta página muda em até cinco minutos depois da declaração, antes de a causa ser conhecida
- Um comandante do incidente conduz a resposta e outra pessoa cuida da comunicação, para que nenhuma das duas funções sufoque a outra
- Os clientes afetados são identificados e avisados, com o crédito já aplicado onde o serviço ficou degradado, em vez de oferecido só a quem pedir
- As compras são bloqueadas em qualquer caminho em que sabemos que falhariam, porque pegar um dinheiro que vamos ter que devolver é pior que perder a venda
- Durante uma interrupção total sai uma atualização pelo menos a cada 30 minutos, mesmo quando a atualização é que ainda não sabemos
- Em até 72 horas depois da resolução sai um post mortem com a linha do tempo, o impacto em clientes em números, a causa, e cada correção com responsável e data
Por que a meta não é cem por cento
Porque tem uma rede no meio e cem por cento seria mentira. Uma meta de 99,5 por cento no provisionamento diz em voz alta que cerca de cinco pedidos em mil vão falhar em algum ponto entre o pagamento e o perfil funcionando.
O que importa é que o caminho desses cinco esteja desenhado. O reembolso dispara em menos de 60 segundos sem abrir chamado, a mensagem explica o que aconteceu e o que tentar no lugar, e ninguém precisa decidir se o cliente merece.
A mesma lógica vale para a cobertura. Quando uma rede parceira está congestionada num território em que temos mais de uma operadora, a gente troca a sua rede em vez de registrar um incidente, e a nota diz qual troca foi feita.
Quando só existe uma rede e ela está num dia ruim, a gente diz isso na página do país. Nossas páginas de cobertura publicam a mediana, o décimo mais lento e o número de amostras exatamente por causa disso.
Histórico de incidentes
Nenhum incidente acima de 30 minutos foi declarado no período coberto por este relatório.
Essa frase vale exatamente o quanto valer a nossa disposição de mudá-la, e é por isso que a política acima está escrita com esse tanto de detalhe. Todo post mortem antigo continua publicado para sempre, em vez de sumir depois de noventa dias.