Я наконец-то понял, как открытость может помешать — и отчёт об аварии
В прошлый понедельник у нас случилась очередная крайне идиотская авария. Идиоты тут мы, если что, и сейчас я расскажу детали.
Пострадало четыре сервера из всего ЦОДа — и все наши публичные коммуникации. Потому что владельцы виртуальных машин пришли под все посты и везде оставили комментарии.
Параллельно была ещё одна история — под статьёй про то, что случалось за год, написал человек, мол, чего у вас всё постоянно ломается. Я вот размещаюсь у регионального провайдера, и у него за 7 лет ни одной проблемы.
Так вот.
Разница в том, что мы про всё это рассказываем. Тот провайдер наверняка уже раз 10 падал, останавливался и оставался без сети, но грамотно заталкивал косяки под ковёр.
Это значит — никаких блогов на Хабре, никаких публичных коммуникаций с комментариями (типа канала в Телеграме), никаких объяснений кроме лицемерных ответов от службы поддержки и т.п. И тогда, внезапно, вас будут воспринимать более стабильным и надёжным.
Наверное.
Ну а я продолжаю рассказывать, что у нас происходило. Добро пожаловать в очередной RCA, где главное в поиске root cause было не выйти на самих себя. Но мы вышли!
Сбои случаются у всех, но не все про них рассказывают
До понедельника было другое событие.
Место действия — наш ЦОД в Королёве. Он находится на территории особо охраняемого завода. Завод, как и ЦОД, запитан от двух независимых подстанций + у нас есть ИБП, дизели и запас топлива + договор на поставки топлива и аренду дополнительного резервного дизеля.
Тестовые прогоны дизелей случаются регулярно как минимум на смене топлива с летнего на зимнее.
Подстанции в последние годы нестабильны. Там в 2023-м уже был ремонт, в результате которого электрики увидели летающие дверцы шкафа. Вот отчёт по этой истории. На этот раз случилось что-то новое, и обе подстанции вышли из строя. На этот раз нам не сообщали никаких деталей, то есть спектр причин мог быть очень широк: от банального человеческого фактора до диверсий.
Для нас важно то, что обе подстанции перестали подавать электричество в позапрошлый четверг.
ЦОД в Королёве переключился на дизель и почти 4 часа так работал с перерывами на попытки включения линий подстанций несколько раз. Подачу питания восстанавливали несколько раз, мы выжидали, переходили на городской ввод, и несколько раз происходило повторное отключение и снова переход на дизель.
Примерно через 4 часа подача питания от подстанций была восстановлена и оставалась стабильной. Авария закончилась.
Для абсолютного большинства клиентов ЦОДа все эти действия прошли незаметно. Сеть сохранялась, всё оборудование сохраняло работоспособность, так как каждый сервер имеет два блока питания, и они подключены к разным ИБП. Были некоторые проблемы с сетевым оборудованием в это время, которое потребовало перезагрузку коммутаторов по итогу, но в целом эту ситуацию отработали штатно.
В чём прикол с ИБП при «миганиях» света
Важно то, что дизели не стартуют мгновенно. Пока они заводятся, серверы и коммутаторы живут на
- ИБП — старых добрых батареях. Что произошло:
- При первом отключении батареи частично разрядились, ЦОД перешёл на дизель.
- Батареи начали заряжаться от дизеля.
- Они не успели полностью зарядиться, ЦОД перешёл на городской ввод.
- Ещё 10 минут они заряжались от города.
- Затем снова переход на дизели, то есть они разряжаются до примерно 20–30% остаточной ёмкости, потому что не успели зарядиться полностью прошлый раз.
Если свет моргнёт ещё раз, надо либо сутки стоять на дизеле и заряжать батареи, либо рисковать переключением с возможностью не переключиться обратно. Стандартная процедура — стоять на дизеле до безопасного заряда батарей.
Ещё несколько раз свет «мигал», когда питание прерывалось на несколько секунд, без переключения на дизели.
В прошлый понедельник ситуация повторилась
Питание с двух — напомню, независимых с независимыми маршрутами — подстанций пропало на 20 минут.
И вот в этот момент вылетело два ИБП.
Это вызвало отключение четырёх серверов, которые были одновременно подключены к вылетевшим батареям. Остальным серверам повезло больше, у каждого был как минимум один ИБП.
Почему всего четыре, а не полстойки? Потому что эта стойка неполная.
ИБП при такой нагрузке вылетать не должны.
Но!
Во-первых, мы планировали плановую замену батарей в ИБП как раз в начале декабря (напоминаю, авария — уже почти середина декабря). 2 декабря мы оплатили счета за них, и они должны были приехать 3–5 декабря.
Они действительно приехали к поставщику, но коробки оказались битые.
Поставщик отказался поставлять батареи, и был на 100% прав. Если логисты побили коробку — это всегда возврат и тщательная диагностика, возможно, списание.
То есть ровно неделю мы стояли с несколькими батареями за сроком плановой замены.
Срок плановой замены подбирается с запасом. Это не так, что ровно день в день батарея умирает.
Диагностика у нас постоянная, в помещении сверяется температура (она около 18–19 градусов Цельсия), плюс мы смотрим напряжение. У самих ИБП тоже есть собственные средства диагностики, и они зажигают лампочки, если нужна замена батарей.
Лампочки не горели. Температура была нормальная. Батареи давали нормальное напряжение.
Но часть из них почему-то решила взять и умереть при разряде в понедельник в этих двух ИБП.
Понедельник
В понедельник я оказался в странной ситуации:
- Мы не понимали, что случилось. Но поддержка уже ответила клиентам наиболее вероятной версией, что в результате некоторого испорченного телефона стоило нам сильного недопонимания клиентов. Очень упрощая, клиент спросил, есть ли резервирование ИБП. Админ ответил, что нет, ни один ЦОД так не делает. Админ имел в виду ЦОДы TIER-III (T4 так делает) и резервирование 2N по мощности. ИБП должны выдерживать 2 переключения на своих батареях, и общий пул батарей не дублируется практически никогда. Смысл в том, что это именно общий пул, суммарная ёмкость. Она уже содержит резерв. Но из-за непонимания, что каждый имел в виду, клиент решил, что резервирования питания в ЦОДе нет.
- Я в это время пытался разобраться с поставщиком и достать батареи быстрее.
- Через несколько часов мы решили, что вместо расследования причин проблем с батареями, сначала надо провести все плановые замены. Поставщик не успевал с повторной поставкой, поэтому мы поехали и купили батареи в магазине как физики.
- Дальше мы ковырялись с заменами и всё поменяли.
- Ещё позже приехали батареи от поставщика.
- До вечера мы разбирались с тем, что происходит.
- Затем начислили положенные по SLA компенсации за простой тем, кто пострадал.
- В итоге мы почти не трогали обсуждения, и в публичном поле творилось не самое хорошее.
Главный мой вопрос был — а что именно случилось с батареями? Они не должны были так деградировать. Плановая замена на то и плановая профилактическая, чтобы такого не было. Если бы горели лампы «замените батарею», можно было бы рассуждать про то, что мы не так обслужили ИБП, но смысл профилактической замены — сделать всё так, чтобы эти лампы никогда не загорались.
Первая наша гипотеза, которую поддержали инженеры, — батареи стали хуже. Тут я обосновать пока не могу.
Второй вариант — частые «мигания» питания могли повредить батареи. Но вообще-то они для этого и спроектированы.
Решения мы везде принимали правильные. Да, при аварии в четверг фактически был проведён стресс-тест системы, но мониторинг показывал, что все ИБП работают, ошибок нет. По этой причине не было никакого мотива каким-то образом там искать прямо в четверг эти батарейные блоки на замену, когда мы знали, что они едут. Принимать битые коробки мы точно не должны были.
Непохоже, что проигрывая эту ситуацию ещё раз, мы поступили бы иначе, имея тот же набор исходных данных для решения.
Почему пострадало относительно небольшое количество серверов. Мы применяем шахматную схему подключения, в которой серверы подключаются в таком порядке, чтобы минимизировать количество потенциально страдающих серверов при отключении более чем одного ИБП по любой причине. Ниже пример логики этой схемы. Если бы не она, отключились бы восемь серверов.
Возвращаюсь к вопросу открытости
Если бы мы ничего никому не сказали, ситуация для нас была бы гораздо легче. Время такое, что всё, что угодно, можно свалить на блокировки, санкции и т.п. И даже подсказывать не надо, это вроде как самоочевидная причина, люди сами очень быстро так подумают.
Если бы мы сказали позже на сутки, не было бы слухов и неправильного толкования того, что сказал саппорт. Они отвечали, ещё не до конца поняв, в чём проблема. Можно было не отвечать? Спокойно. Все так делают.
С другой стороны, пострадало 4 сервера в одном из 20 ЦОДов. Но ощущение из-за нашей публичности было такое, как будто авария крупная. И вот здесь главный минус открытости — складывается впечатление, что у нас такое происходит чаще, чем обычно. Так вот, нет. Ломается всё у всех, но если про это не говорить, это незаметно.
Я всё ещё считаю, что нужно держать в курсе всегда и по имеющимся на текущий момент данным. У нас открыты чаты и комментарии везде, есть сообщество клиентов в ТГ. Да, нас больно бьют за каждую проблему, и некоторые вещи эмоционально очень хочется не рассказывать. Это цена открытости.
ruvds.com/ru-rub
