Contigência
3.7.1 Introdução
O assunto “contingência” não é novo, mas apesar disto, até os dias de hoje ainda há uma grande confusão em torno do mesmo.
Não é raro encontrar aqueles que pensam em contingência como uma “simples” duplicação de todos os sistemas em outro local. Também há opiniões de que seria suficiente apenas aplicar redundância nos sistemas. Em situações extremas, também há quem se sinta tranquilo somente com uma boa quantidade de sobressalentes.
De fato, todas essas visões possuem fundamentações válidas. Entretanto, em geral todas elas pecam por definir contingência apenas com uma visão parcial do que deve ser considerado.
Para dirimir as dúvidas e chegar a uma visão convergente e consistente, será explicado o termo “contingência” com a utilização da ferramenta 5W1H:
3.7.1.1 O que é (What)?
Os termos “redundância” e “backup” têm sido utilizados erroneamente na definição de “contingência”. O correto é que ambos representam estratégias que podem ser utilizadas para alcançar melhores níveis de contingência.
Ao invés disso, “contingência” é um estado que está intimamente relacionada à produção. No contexto de Portos: quando um Terminal está produzindo a todo vapor, não há qualquer contingência. Por outro lado, qualquer coisa que acarrete perda de produção leva o Terminal a um estado de contingência.
Logo, um Terminal em contingência significa estar operando com produção degradada. A dimensão da contingência (ou da degradação na produção) pode variar bastante: há contingências de site, de sistema, externa (custeio limitado, quantidade de energia elétrica limitada, embarque limitado, etc.).
3.7.1.2 Quando ocorre (When)?
Geralmente, contingências ocorrem aleatoriamente ou de maneira difícil de predizer temporalmente. São exemplos: incêndios e alagamentos em um site, quedas de energia elétrica, falhas em discos rígidos, etc.
Eventos de manutenção (programados ou não) também podem provocar um estado de contingência, se não forem bem