Вчерашний кейс с падением Amazon Web Services снова напомнил, как всё призрачно в нашем технологическом мире.
Когда падает крупнейший в мире облачный провайдер — падает всё: Slack тормозит, Gamma App перестаёт рендерить презентации, а половина интернета тихо рыдает в логах.
И вот в такие моменты остро ощущаешь, что нефункциональные требования — это не скучный раздел документации, а реальный инструмент выживания.
Что стоит помнить техническим продактам и аналитикам 👇
- Мониторинг — не «nice to have».
Мы обязаны постоянно отслеживать жизнеспособность наших сервисов и иметь быстрые индикаторы того, что что-то идёт не так. - Коммуникация важнее аптайма.
Если сервис недоступен, пользователи должны узнать об этом от вас, а не из Twitter.
Письмо, SMS, push, бот в Telegram — канал не важен, важно, чтобы он был альтернативным. - План “B” должен быть не только в головах.
Да, никто не держит полную копию инфраструктуры у второго провайдера —
но понимать, что именно рухнет, если упадёт AWS или Azure, и во сколько это обойдётся, нужно. - Компромисс — часть архитектуры.
100% доступности не бывает.
Наша задача — оцифровать этот компромисс и заранее знать,
что мы теряем при отказе и как это объяснить стейкхолдерам.
💡 Вывод:
Технический продакт, который не думает про нефункциональные требования,
— это как капитан, который не проверяет, есть ли шлюпки на корабле.
Стабильность стоит денег.
Но незнание, где вы уязвимы, — стоит дороже.
