⚙️ Нефункциональные требования и реальность: когда падает даже AWS

Вчерашний кейс с падением Amazon Web Services снова напомнил, как всё призрачно в нашем технологическом мире.
Когда падает крупнейший в мире облачный провайдер — падает всё: Slack тормозит, Gamma App перестаёт рендерить презентации, а половина интернета тихо рыдает в логах.

И вот в такие моменты остро ощущаешь, что нефункциональные требования — это не скучный раздел документации, а реальный инструмент выживания.

⸻

Что стоит помнить техническим продактам и аналитикам 👇

1️⃣ Мониторинг — не «nice to have».
Мы обязаны постоянно отслеживать жизнеспособность наших сервисов и иметь быстрые индикаторы того, что что-то идёт не так.

2️⃣ Коммуникация важнее аптайма.
Если сервис недоступен, пользователи должны узнать об этом от вас, а не из Twitter.
Письмо, SMS, push, бот в Telegram — канал не важен, важно, чтобы он был альтернативным.

3️⃣ План “B” должен быть не только в головах.
Да, никто не держит полную копию инфраструктуры у второго провайдера —
но понимать, что именно рухнет, если упадёт AWS или Azure, и во сколько это обойдётся, нужно.

4️⃣ Компромисс — часть архитектуры.
100% доступности не бывает.
Наша задача — оцифровать этот компромисс и заранее знать,
что мы теряем при отказе и как это объяснить стейкхолдерам.

⸻

💡 Вывод:
Технический продакт, который не думает про нефункциональные требования,
— это как капитан, который не проверяет, есть ли шлюпки на корабле.

Стабильность стоит денег.
Но незнание, где вы уязвимы, — стоит дороже.