Характеристики ЦОДов ФНС по данным самой ФНС То, что они называют "цодом" в самой Москве — это, конечно, не ЦОД. Это "серверная комната" — всего сотня стоек. И обратите внимание, как там все импортозамещено: Cisco, Oracle, IBM Power и вот это все. ЦОДы в Городце и Дубне — это точные копии друг друга. Типа, если один ЦОД сгорит, в другом все останется. Так вот — один, в Городце — сгорел. Второй остался. Это почти никак не повлияет на сдачу налоговой отчетности и работоспособность налоговой системы РФ. Но вот если ударят по Дубне... Вот это уже будет катастрофа. Заменить или куда-то перебросить все эти информсистемы невозможно. Ну, в обозримом временном промежутке. Мне очень интересно как теперь все эти эффективные менеджеры будут изворачиваться

Как в MWS Cloud построили сетевой балансировщик с минимальными потерями производительности На первый взгляд у балансировщика довольно простая работа: принять трафик, распределить его между виртуалками и следить, чтобы запросы не уходили на упавшие серверы. Всё выглядит прекрасно, пока дело не доходит до реальных пакетов, маршрутизации и отказоустойчивости. В MWS Cloud построили собственный NLB и получили разницу всего в 1-2% между прямым обменом виртуальных машин и обменом через балансировщик. Правда, ради этого пришлось пойти на архитектурные компромиссы. Первую схему проверки доступности серверов выбрали за простоту, хотя заранее понимали, что она плохо масштабируется. Следующая избавила от одних проблем, зато принесла другие. Узнаем, как инженеры выстраивали маршруты пакетов, выбирали между производительностью и гибкостью и почему даже удачные решения приходится пересматривать.

#рецепт Что общего у ЦОДов Яндекса, концерта Канье и Cloudflare? У катастроф в IT есть своя специфика. Давай размберем пальцах: пять зависимостей, о которых проджекту стоит спросить Вендор-лок - не абстрактная архитектурная проблема. Если основной поставщик исчезнет, сможем ли мы принимать платежи, общаться с пользователями и поднять сервис? 1. Домен, DNS, сертификаты У кого доступ к регистратору, DNS и ключам? Есть ли независимый DNS и путь перевыпустить сертификат, если панель основного CDN лежит? 2. Платежи Есть ли второй банк или эквайер с договором и проверенной интеграцией? Если нет, кто уведомит клиентов и как сверять зависшие платежи, повторы, возвраты? 3. Связь Где сообщать статус, если приложение, почта и основной мессенджер недоступны? Нужны независимый канал и ответственный за проверенные обновления 4. Серверы Есть ли мощность на другой площадке и доступны ли вне основного облака образы, конфигурация, секреты и доступы? Два ЦОДа одной компании с общим управлением могут отказать вместе 5. Данные и БД. Копии лежат у другого провайдера? Рестор проверен? Дамп не течет, не избыточен, и мы можем поднять за адекватные сроки его?Правило 3-2-1 про три копии, два типа носителей, одна вне площадки появилось не просто так. Но бэкап своим существованием не доказывает, что БД восстановится до нужной точки и операции не задвоятся 6. Кто и где получает апдейты от поставщиков и контрагентов? Это должен быть не 1 человек и желательно дублирующийся канал. Компания должна сразу узнать например о блокировке Google Developer Console, а не обнаружить спустя пару дней из хейта в треадс, что у них перестали скачиваться сборки и смочь моментально среагировать Проджекту не нужно проектировать всё самому. Нужные ответы часто за пределами его зоны ответственности: что реально работает, а что только нарисовано. Например RTO и RPO, за сколько вернём сервис и сколько данных допустимо потерять. Ну и понимать что арифметку: 99,9% - примерно 43 минуты простоя за 30 дней, без обещания починить одну аварию за 43 минуты Если вы C-lvl связанный с техничкой или фаундер. Хотя бы раз в год устройте учения: разверните критичный путь с нуля из доступных извне копий, лучше у другого провайдера; проверьте платежи, запись в БД, переключение и откат хотя бы на стейдже. Фактическое время и потери важнее красивой схемы. AWS прямо рекомендует проверять восстановление практикой Очень важна развилка: резерв с ценой и сроком в план на год или сознательно принимаем такой-то простой. Запишите цену часа простоя, владельца решения и дату пересмотра. "Все в курсе почему так исторически сложилось" не решение

Всего должно быть два Кому-то это может показаться странным, но для меня давно очевидна одна вещь: в работе всего должно быть два. — Всегда должно быть проработано две гипотезы – основная и запасная. — KPI должен быть всегда по двум показателям, а не по одному. — Должны быть два дашборда, которые ты смотришь каждый день. — Лучше иметь два рекламных аккаунта в ФБ и Гугле, а не один. — Еще лучше иметь два билда в сторе – основной и зеркало. — Должны быть сдублированы критичные вещи, типа телефона, компа, юрлица и аккаунта в банке. — Крайне желательно работать сразу с двумя ассистентами – личным и продуктовым И Т Д Только жена может быть одна. В нашей работе регулярно приключается какое-то дерьмо. Например, отлетела платежка, или забанили рекламный аккаунт, или блокнули банковский счет, или что-то ещё. Часто это разруливается месяцами, и очень тупо, когда из-за этого встаёт вся работа. Так что дублируй, пока не поздно. Ну и ставь двойную реакцию.

Как в MWS Cloud тестировали отказоустойчивость платформы и при чём тут швейцарский сыр Облако проектировали так, чтобы оно пережило потерю целого дата-центра: диски и сетевые карты отваливаются только в путь, площадки склонны отмирать, а над двумя линиями оптики в десяти километрах друг от друга идут две независимые стройки, где операторы экскаваторов начинают рабочий день в одно и то же время. Всё это заложено в архитектуру. И прежде чем сказать рынку «у нас теперь тоже облако», решили проверить честно — погасить зону доступности прямо на проде. Неделя подготовки, сорок инженеров в чате, отдельный логотип для координации. День X: гасят внешние линки одной зоны. По ощущениям — легло всё. Консоль недоступна целиком, объектное хранилище тоже. В системе, которую с фундамента строили ровно под этот сценарий. А дальше — чуть больше двух недель разбора, как в такой конструкции дырки на всех слоях защиты умудрились выстроиться в одну линию.

Один сбой Redis остановил систему кредитного скоринга на полчаса. Допустимый лимит простоя за месяц закончился за один инцидент. Тогда команда решила перейти на Hazelcast. Тут данные хранятся сразу в нескольких копиях, а при отказе одного сервера система продолжает работать. Следующая поломка оборудования уже прошла незаметно для пользователей. Но у новой системы нашлись свои проблемы. Сохранение данных после перезапуска пришлось настраивать самостоятельно, некоторые библиотеки нельзя было нормально подключить, а часть нужных функций оказалась платной. Автор разбирает переход с Redis на Hazelcast, настройки системы и проблемы, которые обнаружились уже во время работы. Несмотря на удачный результат, теперь команда рассматривает еще одну замену.