всем привет. эта маленькая записка о том как нельзя быть техно-гиганом страны и не уважать своих клиентов полностью и бесповоротно. Возможно этот текст, разбудит кого-то в недрах яндекса и сподвигнет более тесно контактировать с клиентами, раз уж вы решили их заводить.
не буду тут цитировать новостные порталы, все и так всё знают. Да это всё про яндекс клауд.
в зону central1-b прилетает БПЛА, понятное дело что он что-то рушит
Зона Б это часть бетонного ангара в старом советском заводе, ныне именуемым "Саста" . Какую информацию получают клиенты облака? да в общем-то никакую (сбой электропитания). До сих пор не известно сохранились ли данные на стораджах хранимых в зоне Б. Однако по сарафанным данным данные из зоны Б некоторые особо привилегерованые клиенты смогли получить. Саппорт, когда их портал не лежит, отписывается базовыми отписками и ничем помочь, клиентам, кто доверился яндексу, не может. Клиентские акаунт менеджеры, говорят не чуть больше.
конечно во всяческих публиках бурлит обсуждение ситуации, люди находят что янедкс замазал свой цод во Владимире на янедкс-картах, хотя конечно же всё доступно для просмотра на Гугл картах, из фоток которого делается вывод что зона А у Владимира это здание похожие на овощебазу или пятерочку из сэнвич-панелей, с совершенно открыто стоящей подстанцией электропитания за несерьезной решеточкой, которую можно развалить из рогатки без всяких БПЛА.
Что же ждут и на что надеется действующие клиенты облака? Конечно что эта зона А не будет атакована. Что же делает Яндекс? конечно, привлекают армию для обороны оставшейся зоны А, в которой каждый клиент разместил что-то из своих ресурсов, просто исторически по алфавиту и даты создания зоны. К сожалению армейцы не справились с обороной и зона А тоже получает повреждения о масштабе которых нам до сих пор не сообщают.
1. Мультизональность — это не катастрофоустойчивость. Нам годами объясняли, что раскидай ресурсы по зонам A, B и D, и будет тебе счастье и девять девяток. На деле три зоны одного провайдера в одной стране и в одной зоне досягаемости — это не три независимых площадки, а три яйца в одной корзине, просто корзина чуть шире. Зоны проектировались на случай отказа ДГУ или экскаватора, перерубившего оптику, а не на случай, когда по ним прицельно прилетает. Модель угроз устарела, а маркетинг остался прежним.
2. «Сбой электропитания» — это не коммуникация, это издевательство. Клиенту не нужны подробности про БПЛА и ПВО. Клиенту нужны ответы на три вопроса:
живы ли мои диски, снапшоты и бакеты в зоне B (да / нет / неизвестно);
когда будет ясность (хотя бы ориентировочно);
что мне делать прямо сейчас: ждать или поднимать всё с нуля из своих бэкапов.
Когда на статус-странице висит «сбой электропитания», а поддержка неделю отвечает шаблонами, клиент не может принять ни одного решения. Ждать бессмысленно, восстанавливаться страшно, потому что вдруг завтра всё вернётся, а ты уже потратил ресурсы и деньги на миграцию. Это худший вариант из возможных: неопределённость, которую создаёт сам провайдер.
3. Равенство клиентов закончилось на первом серьёзном инциденте. Если правда, что часть клиентов свои данные из зоны B получила, а остальным говорят «ничего не известно», значит, данные физически доступны и вопрос только в том, кто ты для Яндекса. Тогда честно напишите в тарифах: «восстановление данных после катастрофы — опция для стратегических клиентов». Мы хотя бы будем знать, за что платим и за что нет.
4. SLA — это бумажка на компенсацию гранта, а не гарантия. Максимум, что вы получите по SLA, — процент от месячного счёта в виде бонусов на тот же самый облачный аккаунт. Ваш простой, потерянная выручка, сорванные контракты и выгоревшие инженеры в SLA не входят и никогда не входили. Читайте договор до того, как заливаете туда прод.
5. Managed-сервисы — это золотая клетка. Managed PostgreSQL, Managed Kafka, Managed Kubernetes удобны ровно до того момента, пока провайдер жив. Когда он лежит, у вас нет ни WAL, ни доступа к нодам, ни дампа — ничего, кроме тикета в саппорт, который тоже лежит.
Что делать тем, кто ещё там (и тем, кто где угодно ещё):
Бэкапы — вне провайдера. Не в соседнюю зону, не в Object Storage того же облака, а к другому провайдеру или на своё железо. Правило 3-2-1 никто не отменял. restic, kopia, velero, pgBackRest,
clickhouse-backup— всё это работает с любым S3.Для БД — живая реплика на стороне. Логическая репликация из managed-кластера наружу или переезд на самостоятельно управляемый Postgres, где вы контролируете WAL-архив.
Вся инфраструктура в коде. Terraform/OpenTofu + Ansible/Helm, причём модули должны подниматься не только в Yandex Cloud. Если ваш IaC завязан на
yandex_*-ресурсы на 100%, у вас не IaC, а vendor lock-in в формате HCL.DNS не у того же провайдера и с вменяемым TTL, чтобы переключение заняло минуты, а не сутки.
DR-учения по-настоящему. Не «у нас есть бэкапы», а «мы в прошлом квартале подняли прод из бэкапов на другой площадке за N часов». Кто не проверял восстановление, у того нет бэкапов.
Посчитайте RTO/RPO честно и покажите бизнесу. Пусть бизнес сам решит, сколько он готов платить за второй провайдер, а сколько готов потерять, если повторится.
И пара слов Яндексу. Отказы инфраструктуры случаются у всех, включая AWS и Google. Клиенты прощают падения. Не прощают молчание. Вы решили стать облаком, то есть взяли на себя ответственность за чужой бизнес. Значит, при инциденте нужны: честная статус-страница, регулярные апдейты с конкретикой, единая позиция для всех клиентов, а не «кому-то отдали, кому-то нет», и постмортем после. Пока этого нет, единственный правильный вывод для клиента — относиться к Yandex Cloud как к одной из площадок, а не как к фундаменту, на котором стоит весь бизнес.
Свои данные никто не будет беречь так, как вы сами. Это было верно и до прилёта, просто теперь это стоит дороже.