O fusca é um exemplo de robustez. Passava por atoleiro, por água, e continuava funcionando. Tenho um amigo no Rio que tinha um fusca nos anos 90. Em uma enchente o fusca dele foi engolido pelas águas. No dia seguinte, após as águas baixarem, ele foi ver seu carro e, ao girar a chave, o carro ligou e saiu andando normalmente.
O artigo do James Hamilton ("On Designing and Deploying Internet-Scale Services") analisa as preocupações que um projetista de soluções deve ter quando se elabora as operações de um serviço amigável de TI. Dois dos pontos que ele elabora eu considero que contribuem para a robustez de uma solução:
- Design for Failure. Os sistemas vão falhar. Prepare a sua infra para sobreviver durante falhas. Teste previamente contra falhas. Se você não fizer o teste, ou se a sua equipe tem medo de fazer esse teste, então you will be in big trouble when system crashes!
- Redundancy and Fault recovery. A infraestrutura deve estar preparada para manter o SLA, mesmo com indisponibilidade parcial. Temos por hábito achar que uma operação de negócio tem que se contentar em operar sem SLA caso a infra principal sofra um crash. Isso não é verdade! Quando isso acontecer os usuários vão criar um "carnaval" inesquecível para qualquer gestor de TI.
O usuário que percebe a robustez de uma infra ou aplicação, mesmo quando ocorrem situações não previstas em tempo de projeto, sabe que tem uma ferramenta poderosa em suas mãos. E isso não tem preço para um arquiteto que elabora a solução!
Tenho certeza de que robustez não é um conceito novo, mas ter uma infra de TI robusta é, sim, SER INOVADOR!
Hasta luego!
Alexandre (Gula) Goularte
