Я люблю аварии. Серьезно. Прилетают аллерты в Телеге, SMS, количество чеков падает, база недоступна. И я чувствую азарт, адреналин. Все лишние мысли исчезают, и голова становится ясной. Есть только одна задача – разобраться и поднять систему.
Но так было не всегда. Три года назад я чувствовала совсем другое: страх, ступор, холодный пот, мысли разбегаются. Что делать? Кому звонить? Я ведь ничего не знаю, и, конечно, не справлюсь.
Та авария длилась почти полтора часа. Последняя – семь минут. И это были интересные семь минут.
В этой статье я расскажу о том, как паника превращается в азарт, а страх – в ясность мысли. И как авария может стать не катастрофой, а интересной задачей.
Контекст: Масштаб системы и ставки
Для начала немного контекста, чтобы всем были понятны ставки в этой игре.
Наша система – это один из самых высоконагруженных проектов на платформе 1С. На нее завязана работа всей розничной сети «Билайна». Это больше 5 000 пользователей в единой базе. Объем данных у нас превышает 15 ТБ. Кластер приложения – это восемь виртуальных машин. Под СУБД выделено три физических хоста.
В соответствии с уровнем критичности системы максимальное время на восстановление – два часа. Потеря данных недопустима в принципе.
SLA – 99,98%. Это всего полтора часа простоя в год. Не в месяц, не в квартал – в год. Это весь наш бюджет на все аварии, ошибки и какие-то косяки.
Я тимлид команды эксплуатации платформы 1С и три года назад понятия не имела, как со всем этим справляться.
Авария №1
Первая серьезная авария застала меня недели через три после начала работы в техкоманде. Я была тогда в отпуске в Крыму. Было отличное утро, пока в мессенджерах не начали сыпаться сообщения о том, что пользователи не могут подключиться к базе. Они получают ошибки при входе, и база, в принципе, уже стала недоступна. Заявлен инцидент первого приоритета.
Я подключаюсь на аварийную конференцию, и там уже человек пятнадцать: моя команда, техподдержка, менеджер АВР, коллеги из инфраструктуры.
Звучит вопрос: что происходит? Что делать? И тишина. Каждый смотрит в свой экран и надеется, что ответит кто-то другой. И я в том числе.
Единственное, что было тогда известно, – невозможно подключиться по RDP к одному из центральных серверов. Что с ним произошло – непонятно. И что с этим делать – тоже непонятно.
Я сижу и думаю: «Пожалуйста, пусть кто-то возьмет это на себя. Только не я. Я ведь даже не знаю, с чего начать».
В результате сервер мы просто перезагрузили физически, и система поднялась. А потом стали разбираться. И вот что выяснили.
У нас ведь был отказоустойчивый кластер. Это архитектура, которая должна работать при выходе из строя абсолютно любого узла. Но все клиентские лицензии тогда лежали на одном сервере. Именно на том, который и завис.
И вот два вывода, которые мы сделали в результате этой аварии:
-
Мы запустили проект по настройке отказоустойчивого сервера лицензирования, чтобы больше никогда выход из строя одного узла не приводил к полной недоступности системы.
-
Мы настроили мониторинг утилизации процессора по процессам. Потому что единственное, что мы увидели на тот момент перед аварией, – это загрузка процессора до 100%. Но нам не хватило данных, чтобы понять, кто именно был виноват. И этот мониторинг нам потом еще не раз помогал в расследованиях.
Авария №2
И вот прошло где-то три месяца. Я уже не новичок, аварию видела. Я думала, что много чего понимаю, как что работает. Или мне так казалось.
Был рабочий день, полдень, и система у нас начала подвисать. Еще не авария, но уже серьезная деградация. Увеличилась длительность серверных вызовов, соответственно, увеличилась длительность выполнения бизнес-операций, и пользователи начали заводить инциденты.
Я смотрю в техжурнал и вижу, что проседают операции с дисками. Это работа с временными файлами, с сеансовыми данными. Похоже, что проблема в дисковой подсистеме. И знаете, на каком сервере? Именно на том, который у нас зависал три месяца назад.
Но перезагрузить его сейчас – это снова уронить всю систему на полчаса. Потому что проект с сервером лицензирования у нас тогда еще не был завершен, и отказоустойчивого решения, к сожалению, не было.
И тут у меня возникает идея, как мне тогда казалось, просто гениальная. А что, если нам просто убрать всю нагрузку с проблемного сервера, переключить роль центрального сервера на другой хост в кластере, а на проблемном оставить только сервис лицензирования? Таким образом доживем до техокна и там его спокойно перезагрузим. Логично же? Вроде логично.
Я решаю сделать это на проде в рабочее время, прямо сейчас. Применяю настройки, жду и вижу, как начинают отваливаться сеансы. Сто. Пятьсот. Тысяча. Все пять тысяч.
В итоге база легла полностью. На восстановление тогда ушло почти полтора часа. И это три миллиона рублей убытков для компании.
Можно, конечно, сказать, что причина аварии была в деградации дисковой подсистемы. И в протоколе аварии мы так и написали. Но, признаться честно, причина была в моей самоуверенности.
Я думала, что хорошо знаю, как работает кластер. Но на самом деле понимала это не до конца. Я не знала, что произойдет, когда мы переключим роль центрального сервера. Что будет с сеансами и пользователями, если изменить конфигурацию требований назначения функциональности таким образом, под такой нагрузкой.
Я, конечно, читала теорию и много документации на тему того, как работает кластер. Но, к сожалению, не пробовала тогда ничего делать руками.
И в тот вечер я села воспроизводить все, что происходило днем, на нашем нагрузочном стенде. Там, где у нас есть полная копия продуктива. Ломала, восстанавливала, смотрела, что происходит с сеансами, за что вообще отвечают какие сервисы в кластере, как работают требования назначения функциональности.
В общем, к утру я понимала работу кластера так, как ни после каких курсов.
И вот главный вывод этой аварии. Теория – это, конечно, хорошо. Курсы, экзамены, сертификат эксперта – все здорово. Но этого мало. Нужно пощупать руками, сломать систему и попробовать восстановить ее, увидеть, как это происходит вживую. И делать это, конечно, лучше не на проде.
Классификация аварий: Три основных типа
Итак, две аварии за три месяца. Понятно было, что это только начало. Аварии всегда будут. И вопрос тут не «если», а «когда» и «какая».
Со временем мы увидели, что все аварии, в принципе, укладываются в три основных типа. А когда ты понимаешь тип аварии, тебе уже не так страшно, потому что у тебя есть алгоритм действий в голове, и ты знаешь, где искать причину.
Какие это типы?
-
Проблемы с инфраструктурой.
-
Платформа и СУБД.
-
Человеческий фактор.
Тип 1: Инфраструктура
Итак, первое – инфраструктура.
Что здесь может быть? Проблемы с СХД, с сетью, с гипервизором, если у вас используется виртуализация. Возможно, какое-то неожиданное проявление антивируса после, например, установки патчей.
К сожалению, это все зоны вне нашего контроля, и мы не можем это никак предотвратить. Но можем быстро понять, что проблема именно здесь.
Например, у себя за последний год мы довольно часто сталкивались с проблемами из-за СХД Ceph. Выглядит это довольно странно. Сервер пингуется, но при этом по RDP к нему подключиться нельзя, и кластер при этом зависает.
В первый раз мы смотрели и не понимали, что происходит. Сервер вроде бы живой, но почему все виснет? Пинг вроде бы идет. Кажется, что проблемы с сетью, но никаких аварий на сети в тот момент не было.
И главный вопрос: у нас ведь отказоустойчивый кластер. Все проблемные серверы – в одном модуле ЦОДа. Почему же платформа не понимает этого и не переключает всю нагрузку на вторую половину серверов, с которыми все хорошо?
А причина вот в чем. Для платформы сервер считается живым, если он пингуется. Пинг идет – окей, сервер работает, на него идет нагрузка. Затем платформа замечает, что процессы на нем не отвечают, и пытается завершить их. Но завершить она их тоже не может, потому что любая операция с диском приводит к зависанию. В итоге мы получаем полную недоступность приложения.
Сейчас мы понимаем, что проблема именно в Ceph по наличию ошибок viostor в логах операционной системы. Это драйвер виртуального устройства ввода-вывода. Но ошибки мы увидим только после того, как сервер оживет.
Поэтому первое, что мы сделали после такой аварии – настроили мониторинг дисковой подсистемы. Алгоритм довольно простой: берем контрольный файлик и копируем на каждый рабочий сервер. Файлик не обновился за 30 секунд – мы получаем алерт и уже знаем, что у нас есть проблема.
И второе – мы подготовили алгоритм отключения всех серверов из одной зоны доступности. Для того чтобы кластер понимал, что серверы в принципе недоступны, и перераспределял нагрузку. Сделали мы это с помощью API платформы виртуализации, потому что интерактивно ничего сделать с этими серверами нельзя.
Если на устранение первой такой аварии у нас ушло 30 минут, то на последнюю – 6. Разница в том, что теперь мы знаем симптомы и у нас есть четкий алгоритм действий.
Как еще можно понять, что проблема именно в инфраструктуре?
Здесь могут помочь алерты. У себя мы в основном пользуемся алертами на основе Zabbix. Это контроль основных железных метрик: процессор, диски, память, те же самые пинги.
Для визуализации используем Grafana: собираем метрики Prometheus и используем стандартный дашборд для Windows Exporter.
Тип 2: Платформа и СУБД
Если честно, чаще всего мы все-таки такие проблемы определяем методом исключения, после локализации основных проблем с платформой и с СУБД (это вообще первое, на что мы смотрим при аварии).
Здесь часть проблем связана с ошибками в сборках платформы. Все-таки мы участвуем в проекте бета-тестирования. А другая часть – с ошибками уже нашей эксплуатации.
Если падает рабочий процесс, это, в принципе, не страшно, потому что соединения перекидываются на любые доступные рабочие процессы, и пользователи этого даже не замечают.
Гораздо хуже, когда падает менеджер кластера. Здесь даже при отказоустойчивой конфигурации кластера платформе требуется несколько минут на то, чтобы процесс перезапустить. Во время одной из последних таких аварий платформа не могла запустить процесс менеджера в течение девяти минут.
Что здесь можно сделать? Можно, конечно, полностью перезагрузить кластер. Тогда мы гарантированно в течение пяти минут поднимемся. Но, к сожалению, пользователи потеряют все свои данные. Либо можно подождать, пока платформа сама восстановит свою работу. Но тут, к сожалению, время может быть непредсказуемым.
Такие баги мы, конечно, отправляем вендору на расследование. А пока они не исправлены, пытаемся как-то с этим жить и ищем обходные пути.
Авария №3
А теперь история про одну из самых дорогих аварий прошлого года.
Весной мы у себя после тщательного тестирования поставили новую сборку платформы – 8.3.27. И там появилась новая фича. Она появилась еще в 8.3.25, но у нас до этого была только 8.3.23. Новая фича – это мониторинг производительности кластера в формате Prometheus. Использует этот мониторинг службу RAS.
Вывели у себя в Grafana, у нас куча красивых графиков, все удобно, радуемся. И вот буквально спустя несколько дней у нас возникла нештатная ситуация. Потребовалось подключить критичное расширение, и, чтобы оно применилось у всех пользователей, пришлось этих пользователей из базы выгнать.
Согласовали с бизнесом, снесли все сеансы. И тут у нас начинается нечто странное. Начинает расти нагрузка на процессор до 70–80% на всех рабочих серверах. Сыпятся алерты. У нас падает количество чеков, начинается сильнейшая деградация. Ничего непонятно, потому что мы же просто пользователей выгнали и больше, в принципе, вообще ничего не делали.
Кое-как подключаемся к серверам, смотрим, что там происходит. И видим в топе огромное количество процессов RAS. Основную нагрузку дают тоже процессы кластера. И тут пазл сложился.
У нас новая сборка платформы. В ней фича с мониторингом, который мы включили, и этот мониторинг использует процессы RAS. И здесь мы видим просто аномальное количество процессов RAS, которых раньше просто никогда не было. Понятно, что проблема в сборке и в мониторинге. Отключаем мониторинг, сносим все лишние процессы, выдыхаем.
Проходит минут пять-семь, и у нас та же самая картина. Опять растет нагрузка на процессор. Ну теперь-то что? Мы вроде мониторинг уже выключили. Остается, конечно, только проблема в платформе. Что еще может предположить админ 1С?
Мы уже согласовываем откат платформы. Последний шанс – идем смотреть в техжурнал. А в техжурнале мы видим нечто совсем неожиданное. Там видно, что весь ресурс процессора уходит на наш же функционал, который мы выпустили буквально в предыдущем релизе. Это контроль входа кассиров.
Как он работает? Когда кассир открывает новый сеанс, проверяется наличие уже запущенного сеанса. И если уже есть открытый, система предлагает завершить старый сеанс и продолжить работу в новом. А старый сеанс она завершала с помощью службы RAS.
И вот что произошло. Мы пользователей выгнали, но старые сеансы еще остались жить на их компьютерах. И когда они повторно входили в базу, все получили предупреждение о том, что нужно завершить старый сеанс, и сделали это массово. Тысячи пользователей одновременно.
К сожалению, эта схема просто не была рассчитана на такую нагрузку. Итог – полтора миллиона рублей убытков.
И вот какой вывод из этой аварии мы вынесли. Очевидное решение - не всегда правильное. Не стоит слепо доверять своей интуиции. Важно собрать как можно больше данных и проанализировать их.
И в таком типе аварий основной источник данных – это, конечно, технологический журнал. И важно иметь удобный инструмент для его анализа.
У себя мы используем OpenSearch. У нас настроено несколько индексов, которые покрывают основную часть проблем и могут помочь в расследовании. Это ошибки, долгие вызовы, не только call, еще события на СУБД и блокировки.
Важно правильно настроить типизацию полей, чтобы можно было пользоваться сортировками и группировками.
Какие тут еще могут быть источники данных? Конечно, алерты. Основной список я привела на рисунке. Это то, что может дать дополнительную информацию и помочь составить какую-то общую картину.
Тип 3: Человеческий фактор
И мы подошли к последнему, самому непредсказуемому типу аварий, который тоже у нас периодически случается. Это: кто-то накосячил.
Каждый в нашей команде хотя бы раз ронял прод. Кто-то и не раз. Но не ошибается тот, кто ничего не делает. Ошибки, к сожалению, всегда будут. Здесь главное – играть за одну команду и сразу во всем признаться, чтобы как можно быстрее устранить последствия.
Из того, что у нас было, например, – архивация логов технологического журнала, которую мы запускали на всех рабочих серверах. Она нагружала процессор до 100%, и, естественно, кластер в это время зависал.
Как-то забыли построить индексы после установки релиза. К девяти утра у нас сервер СУБД просто прилег от колоссальной нагрузки на чтение.
Включали полные логи техжурнала и благополучно забывали об этом. К утру диски у нас полностью забивались логами.
Была случайная перезагрузка серверов, когда ставили патчи на операционную систему.
И недавно админы удалили виртуалку с продовой базой. К счастью, не с Retail.
Процесс АВР
Перейдем к организационной части. Как у нас выстроен процесс аварийно-восстановительных работ?
Как мы узнаем об аварии? В 99% случаев, если не больше, это данные мониторинга. У нас есть не очень большой список самых критичных алертов, которые свидетельствуют о том, что у нас началась авария.
Первое – это контроль по чекам. Это основная наша бизнес-метрика. Для него рассчитывается пороговое значение по данным за предыдущий месяц: по количеству пробитых чеков именно в эту минуту. И если текущее значение меньше порогового, мы тут же получаем алерт, и это уже считается недоступностью для нашего SLA.
Второе – это healthcheck базы. Тут стандартный веб-сервис из БСП, мы ничего своего не придумывали.
В течение первых двух-трех минут мы стараемся собрать основную картину и понять, какой у нас тип аварии. Для этого смотрим на наш основной дашборд. Проверяем наличие алертов, смотрим, о чем нам говорит мониторинг. Проверяем доступность серверов, наличие дампов. В общем, проводим базовый скрининг системы.
Дальше, в течение пяти минут, собирается моя команда, и мы пытаемся совместно найти решение, узнать причину. У нас на это есть 10 минут. Если мы собственными силами не успеваем за 10 минут справиться, то есть найти причину и устранить ее, об аварии узнает уже вся компания и автоматически заводится инцидент первого приоритета.
Тут начинается стандартный процесс АВР: подключаются менеджеры, начинается сбор информации об аварии, проверка гипотез. Если есть подозрение, что проблема в какой-то части инфраструктуры, сразу приглашаются дежурные: сетевики, DBA, безопасники – в общем, все, кто может помочь с решением.
И никто не расходится до того момента, пока, во-первых, не будет устранено влияние на пользователей. И, во-вторых, пока не будет найдена и устранена корневая причина аварии, чтобы не допустить ее повторения в ближайшее время.
Последний, итоговый этап – это проведение дебрифа. По итогам каждой аварии спустя некоторое время у нас проводится дебриф, в ходе которого выясняется, достаточно ли было мониторинга, не было ли нарушений по времени в процессе аварийно-восстановительных работ. Также планируются мероприятия по недопущению повторения таких аварий в будущем.
И, как вы понимаете, самое дорогое во время аварии – это, конечно, время. Если в это время приходится задавать себе вопросы: «А где у нас тот или иной график? Что у нас там с сетью происходит?» – ты проигрываешь SLA.
Поэтому во время аварии мы не ищем информацию. Информация сама приходит к нам и складывается в общую картину. Эту картину дают, как правило, алерты и дашборды.
Дашборд. Каждый график – следствие аварии
Хочу показать наш основной дашборд, которым мы пользуемся для определения типов аварий. Каждый график на нем появился не просто так. Это следствие какой-то аварии.
Не буду подробно рассказывать про каждый. Из основного – это контексты, сгруппированные по максимальному времени серверного вызова и по длительности выполнения запросов. Это те куски кода, которые оказывают максимальное влияние на наше железо.
Дальше идет раздел с управляемыми блокировками. Там мы видим область, на которой происходит конфликт, и соединение, которое дольше всего эту блокировку удерживает.
А дальше – график с конфликтом блокировок на стороне СУБД. Вообще платформа официально гарантирует, что таких ошибок быть не должно, если вы используете управляемые блокировки. Но это при условии, что на вашу базу нет никакого воздействия извне.
В нашем же случае существует еще регламент обслуживания базы данных, который периодически обновляет статистику. Работает он с 12 ночи до 8 утра. И вот в период где-то с 6 до 8 утра мы периодически ловили ошибки при проведении чеков, если у нас обновлялась статистика, например, на какой-то основной таблице: по номенклатуре или по чекам. И этот график нам теперь показывает, где у нас проблема. Плюс он покажет проблемы, если есть какие-то ошибки при репликации и транзакция не может закоммититься на основной ноде.
Дальше вторая часть. Здесь нагрузка на процессор отдельно на серверах приложений, отдельно - на СУБД. Очередь заданий на стороне MS SQL Server. Если график растет уже до 500, то очевидно: какая-то проблема у нас есть. Нужно идти и смотреть, какие запросы и на каком ресурсе конфликтуют.
Количество потоков на серверах приложений – этот график может показать проблемы на стыке инфраструктуры и платформы. То есть, если процессы кластера не получают какой-то ресурс вовремя: диск, процессор, память, – они начинают активно генерировать потоки. На графике это будет видно резким скачком. И приложение в это время, скорее всего, зависнет.
Количество активных сеансов в базе – с этим понятно.
Скорость запуска приложения. Здесь у нас специальный робот заходит в базу и открывает ее. Если база открывается дольше 30 секунд, мы получаем алерт, и на графике это тоже будет видно. В норме приложение обычно открывается в течение пяти-семи секунд.
И ниже уже раздел с бизнес-метриками. Это оценка работы системы с точки зрения пользователя.
Немного практики
Мы поговорили про процесс, про типы аварий. Теперь немного практики: то, что можно будет забрать с собой и использовать у себя.
Первое – это приложенный к статье чек-лист с настройками. В нем мы собрали те настройки, которые у нас используются на кластере приложения, на кластере СУБД, то, что актуально для высоконагруженной базы. Там же список с базовыми алертами, которые могут помочь при авариях. И шаблон для сбора техжурнала, который мы используем у себя на проде.
Как правило, такого техжурнала хватает для расследования практически любой аварии. Не стоит, конечно, воспринимать это как истину в последней инстанции. Это просто то, с чего можно начать, если вы только выстраиваете у себя какую-то систему мониторинга.
Второе – это ссылка на статью нашего инженера на «Инфостарте», который занимается мониторингом //infostart.ru/1c/articles/2629997. Там примеры с алертами в Телеге: на основе прямых запросов, на основе данных Elasticsearch и данных службы администрирования сервера.
Сразу отмечу такой нюанс: алертов не должно быть много. Если вы добавили алерт и никак на него не реагируете, лучше уберите его сразу. Иначе получится так, что ваш канал с уведомлениями превратится в бесконечную простыню сообщений. Вы потом перестанете их читать, отключите звук в этом канале и в один прекрасный день пропустите аварию. Мы, к сожалению, с этим тоже сталкивались.
Последний инструмент – это бот для управления кластером, тоже для Телеги https://github.com/d-naumenko/cluster_1c_operation_bot. Делали мы его для того, чтобы оперативно реагировать в нерабочее время, если у нас что-то случается. Сейчас пользуемся всегда, потому что это очень удобно: избавляет от рутины и минимизирует ошибки из-за того же человеческого фактора.
Что он умеет? Какие-то базовые вещи: перезапуск служб, может завершить процесс, перезагрузить сервер либо полностью рестартовать кластер с очисткой сеансовых данных.
На GitHub есть небольшая инструкция, как его использовать. Можете забрать себе, может быть, будет полезен.
Заключение
Итак, зачем же все это? Алерты, дашборды, боты. А нужно все это для того, чтобы в момент аварии не думать о рутине. Не вспоминать, какие команды нужны, где какой график, кто что должен делать. Все это нужно для того, чтобы освободить голову для главного – для принятия решений.
Вернемся к началу. Три года назад авария – это был страх и ступор. Сейчас – азарт и четкость действий. Что же изменилось?
Изменилось то, что я поняла: быстро не должно означать рискованно. Но и осторожно не должно означать медленно. Весь фокус в том, чтобы убрать панику во время аварии. А панику убирают пять вещей.
Первое – наличие опыта. Не книжного, а настоящего. Ломайте систему на тестовом стенде, смотрите, что с ней происходит, как ее восстановить. Когда ты уже видел проблему, тебе не так страшно.
Второе – наличие лидера. Не все вместе думают и что-то делают, а один принимает решение, остальные выполняют. Хаос без лидера может стоить гораздо дороже, чем ошибка лидера.
Третье – наличие информации: алерты, логи, дашборды. И при этом ничего лишнего.
Четвертое – типы аварий. Когда ты знаешь паттерн аварии, ты знаешь, где искать причину.
И пятое – ретроспектива. Вообще авария – это не катастрофа. Это возможность сделать вашу систему надежнее. Каждая авария у нас заканчивается вопросами: что случилось? Почему мы это пропустили? Что сделать, чтобы это не повторилось вновь? Если же вы просто боретесь с симптомами, то рано или поздно симптомы победят вас.
Сейчас, когда прилетает алерт о недоступности базы, я знаю: мы справимся. Конечно, бывают ошибки в диагностике, бывают неправильные гипотезы. Бывает так, что и первое решение не работает. Но за три года не было такой проблемы, которую мы не смогли бы решить или для которой не смогли бы найти обходной путь.
Самая дорогая авария – та самая из начала статьи, про переключение центрального сервера. Три миллиона рублей убытков и урок на всю жизнь. Но именно она дала мне максимальный рост как эксперту.
Сейчас решение аварии редко занимает больше пяти или десяти минут. Последняя – семь.
И да, я действительно люблю аварии. За то, что каждая из них делает нашу систему надежнее.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт