Gerenciamento e identificação de riscos de APIs de terceiros

Introdução

A explosão de serviços de terceiros para ajudar os desenvolvedores é fantástica! Isso reduz a necessidade de fazermos coisas como configurar servidores de e-mail quando podemos usar coisas como SendGrid ou MailGun . Não precisamos ter um servidor para hospedar nosso WebApp, podemos apenas implantá-lo no Heroku ou AppEngine.

O risco

Embora isso seja ótimo porque nos permite gastar um tempo mínimo na criação de infraestrutura e apenas começar a escrever nosso software, ele apresenta vários riscos, incluindo nos deixar vulneráveis ​​à interrupção ou desligamento do serviço API .

Enquanto escrevo isso, o Yahoo! desliguei mais uma vez outro serviço com uma janela muito pequena de aviso: a próxima API será desligada com 11 dias de antecedência !

Gerenciamento de riscos

Vou me concentrar aqui no que é chamado de risco residual . Embora este não seja um posto de gerenciamento de risco abrangente, ele lhe dará uma ideia para ajudar a se proteger.

Registro de riscos

A primeira coisa que precisamos fazer é identificar todos os nossos riscos usando algo como uma matriz de risco de cinco caixas . Essencialmente, isso pesa a probabilidade de ocorrência de um risco e a consequência que resulta na ocorrência do risco. Isso nos dá uma ideia muito melhor de onde enfocar nossos planos e em quais detalhes.

Aqui estou falando sobre os riscos de APIs de terceiros, então você pode considerar que a interrupção de um serviço de e-mail tem uma consequência menor (receber mais chamadas de suporte) do que a interrupção de um serviço de gateway de pagamento (perda de receita). Você pode dividir ainda mais seus riscos para incluir:

  • Interrupções
  • Desligamento (olá Yahoo!)
  • Falência
  • Aquisição

Planejamento – Mitigação e Resposta

A segunda coisa para cada risco que você identifica é criar dois planos:

  • O Plano de Mitigação
  • O Plano de Resposta

Plano de Mitigação

O plano de mitigação é como você pretende reduzir o risco de ocorrência. É importante observar que este não é um plano para impedir a ocorrência do risco, mas para reduzir a probabilidade de ocorrência do risco.

Seu plano de mitigação pode fazer com que seu aplicativo use SendGrid ou MailGun, dependendo de uma variável de ambiente.

Plano de Resposta

O plano de resposta é como você lidará com o risco quando ele ocorrer. O objetivo do gerenciamento de riscos não é tentar impedir que aconteçam coisas que estão fora de seu controle, mas o que você fará quando isso acontecer.

Seu plano de resposta pode detalhar como mudar seu aplicativo do SendGrid para o MailGun no caso de uma interrupção.

Conclusão

Embora certamente não seja uma descrição detalhada do gerenciamento de riscos, espero que este post dê uma ideia sobre o que pode dar errado e como se proteger quando isso acontecer. Ser capaz de simplesmente apertar um botão quando um provedor está fora do ar vai mostrar ao seu chefe que você certamente planejou um desastre!

Sinta-se à vontade para deixar um comentário ou entrar em contato se tiver alguma dúvida ou se quiser discutir qualquer coisa.