Облако и дизайн инфраструктуры
Здесь эксплуатация перестаёт быть про один хост и становится проектированием системы, которая переживает отказы, поглощает непредсказуемую нагрузку и не разоряет бюджет. Облако выдаёт примитивы — регионы, зоны доступности, управляемые сервисы, автоскейлинг, тиры хранилища, — но не решает за вас; каждый дефолт это компромисс, который вы принимаете. Сквозная идея всей темы — считать, что машина умрёт: инстансы это скот, а не питомцы, поэтому доступность даёт распределение по независимым доменам отказа, а не покупка одного большого и более надёжного сервера.
Первый слой строит модель самого облака: лестницу IaaS/PaaS/SaaS и кто за что отвечает, почему регион — не зона доступности, почему multi-AZ это базовая единица высокой доступности, а multi-region — дорогое аварийное восстановление, и как эластичность, балансировка, тиры хранилища и модели цен превращаются в управляемый месячный счёт. Второй слой пускает эти примитивы в дело в цельных системных дизайнах — высокодоступные многослойные приложения, выкаты без простоя, observability и секреты в масштабе, disaster recovery, автоскейлинг под всплески и слоистое кеширование, — и каждый называет конкретный компромисс, который решает.
Карта темы
- Облачная архитектура — IaaS/PaaS/SaaS и разделённая ответственность, регионы против зон доступности, multi-AZ как база HA против multi-region DR, эластичность против масштабируемости, managed против self-host, балансировка L4/L7, тиры хранилища и цены spot/reserved/on-demand.
- Системный дизайн инфраструктуры — HA многослойная архитектура, выкаты и миграции схемы без простоя, observability и логирование в масштабе, архитектура секретов, disaster recovery (RPO против RTO), автоскейлинг под всплески, планирование ёмкости и слоистое кеширование.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Держать много инстансов в одной AZ и звать это HA | Авария одной зоны кладёт весь сервис |
| Считать multi-region дешёвым выбором по умолчанию | Платите за межрегиональную репликацию и egress, которые не нужны; ответ был multi-AZ |
| Путать эластичность с масштабируемостью | Провижн под пик 24/7 без сжатия обратно |
| Путать RPO с RTO | Купили быстрый failover, когда нужны были частые бэкапы, или наоборот |
| Катить разрушительное изменение схемы вместе с кодом | Старые инстансы ломаются в середине выката; простой вместо zero-downtime |
| Кешировать без инвалидации и защиты от stampede | Вечно устаревшие данные или thundering herd при протухании горячего ключа |
Значение для собеседований
Облако и дизайн инфраструктуры — территория senior-собеседований: интервьюер даёт размытый сценарий и смотрит, тянетесь ли вы к независимым доменам отказа, называете ли свои точки отказа и оцениваете ли компромисс, который принимаете. Сильный ответ звучит как «ставлю stateless-инстансы по трём AZ за L7-балансировщиком с health-проверками, держу БД в multi-AZ с failover и принимаю задержку между зонами» — каждое предложение это решение со своей ценой.
Что обычно проверяют:
- Регион против AZ и почему высокую доступность даёт multi-AZ, а не число инстансов.
- Разделённую ответственность в IaaS/PaaS/SaaS.
- RPO против RTO и механизмы, которые задаёт каждый.
- Expand/contract для миграции схемы без простоя.
- Где кеширование становится сложным: инвалидация, TTL и stampede.
Типичный неверный ответ: «высокая доступность — это просто больше серверов». Больше серверов в одной зоне — это резерв против смерти одного инстанса, а не зоны, региона или плохого выката. Доступность про то, где и насколько независимо эти серверы отказывают, а не про их число.