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

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