Тестирование аварий / Андрей Губа (Одноклассники)

Докладчик представил себя как специалиста с пятнадцатилетним опытом работы в компании, начав путь с системного администратора до должности заместителя технического директора. В его зоне ответственности находятся системное администрирование, платформа API и команда, решающая сложные задачи в области разработки и информационной безопасности. Компания демонстрирует значительные цифры: начиная с 2010 года, достигнут показатель примерно в 45 миллионов уникальных пользователей в сутки, используется около 8 тысяч серверов, а пиковый трафик превышает один терабит в секунду, что подчеркивает критическую важность надежности инфраструктуры.

Для иллюстрации потенциальных рисков был рассмотрен гипотетический проект на 200 серверов, где последовательно происходят отказы: выход из ротации веб-сервера, невозможность перехода на реплику основной базы данных, отключение электричества на резервной площадке, потеря сети в основном дата-центре, а также нарушение коммуникации из-за отсутствия главного администратора в пятницу вечером. Эти сбои, которые по отдельности могут быть не фатальными, при совпадении в короткий промежуток времени и при наличии осложняющих факторов, таких как нарушенная связь или отсутствие ключевых сотрудников, могут привести к затягиванию устранения аварии.

Вообще все те аварийные случаи, которые сейчас рассказали по отдельности может быть и не фатальны, но когда они случаются за короткий период времени, когда появляются осложняющие обстоятельства, тогда решение аварии может затянуться.

В результате подобных каскадных отказов репутация компании может быть серьезно подорвана, а планы развития нарушены. Участники, имеющие опыт решения проблем на продакшене, подтвердили актуальность данной темы. Самая крупная зафиксированная авария произошла в апреле 2013 года, когда проект был частично недоступен на протяжении почти трех суток.

Несмотря на рост проекта, усложнение системы и увеличение количества сотрудников, наблюдается устойчивая тенденция к снижению числа инцидентов с эффектом для пользователей, уменьшившись практически в четыре раза с 2010 года. Важно отметить, что регистрируются абсолютно все инциденты, даже те, которые затронули небольшое число пользователей. Проблемы могут обнаруживаться как от пользователей или руководства, так и через системы оперативного мониторинга, который информирует о сбоях здесь и сейчас.

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

По мере роста проекта увеличивается количество сервисов и данных, что приводит к появлению десятков графиков, за которыми следит команда мониторинга. Первоначальные попытки решить проблему путем приоритезации графиков и создания удобного интерфейса не дали полного результата. Поэтому был автоматизирован процесс реакции на инциденты путем настройки триггеров, срабатывающих на превышение лимитов на графиках, что реализовано через механизм, названный «семафор».

Для решения проблемы анализа большого количества сложных графиков была запущена собственная система с названием Smart Monitoring. Эта система автоматически обнаруживает аномалии, показывает взаимосвязь между ними и решает проблему создания проблемных тикетов, добавляя начальную информацию об инциденте. Например, система может выявить, что замедление видеосервиса влияет на веб-серверы из-за торможения баз данных.

Существует отдельная система для мониторинга использования ресурсов, которая собирает порядка 3 миллионов метрик с производственного оборудования, включая использование дисков, памяти, трафика, а также метрики Java (heap и сборщик мусора). Кроме того, для предотвращения проблем с нехваткой места на дисках в больших кластерах, система «Смысл» дважды в сутки выкачивает информацию из системы графиков и раз в неделю запускает аналитический режим. Этот режим проверяет ресурсы на соответствие установленным правилам и прогнозирует, когда ресурс закончится при текущем темпе использования.

Резервирование, такое как дисковые массивы RAID, резервные каналы связи или репликация баз данных, является базовым требованием. Однако подход к резервированию эволюционировал. Изначально использовалось оборудование, взятое из небольшого проекта, но по мере роста объемов данных и сложности, этот подход перестал быть эффективным, приводя к длительным простоям для выполнения рутинных операций, таких как создание индексов.

Надежное железо тоже отказывает: если у вас один сервер, он может отказать раз в три года, но если у вас 2000 серверов, то может чаще, чем раз в день что-нибудь случается.

Это привело к выработке тезиса о необходимости обрабатывать аварийные сценарии на стороне приложений. Ключевые сценарии включают отказ связанных сервисов, замедление работы и старт несвязных сервисов. Если работа крупного кластера нарушена, и проблему нельзя решить быстро, необходимо реализовать управляемую деградацию сервиса, чтобы показать пользователю неполные или ограниченные данные, а не полный отказ.

Для проверки работы этих механизмов была разработана собственная система «Горилла», которая тестирует работу «рубильников» при полном отключении сервиса или недоступности реплики в одном из дата-центров. Также подчеркивается, что все данные должны иметь копии в разных дата-центрах, поскольку реальные аварии (пожары, ураганы, повреждение оптики) могут привести к потере целой площадки на несколько часов.

При устранении аварий рабочие инструменты должны функционировать в штатном режиме. Это касается, в первую очередь, аварийного доступа. Доступ должен быть проверен регулярно, поскольку изменения в инфраструктуре могут сделать его неработоспособным. Кроме того, системы централизованного управления, такие как Puppet или аналогичные панели, должны использоваться для устранения аварии, а не чиниться в процессе. Системы мониторинга также не должны показывать ложные срабатывания во время активного устранения инцидента, чтобы не создавать дополнительный шум.

Во время крупной аварии 2013 года возникла ситуация, когда невозможно было получить доступ по SSH к тысячам Linux-серверов, а централизованная система управления также перестала работать. Это вынудило вручную переконфигурировать серверы, что заняло много времени. Если бы все было сконцентрировано правильно, это время удалось бы сэкономить.

Существует приоритизированный чек-лист по установлению сервисов, включающий восстановление доступа и систем управления. После устранения проблемы обязательно проводится тестирование всего функционала. Дежурный разработчик, как правило, является одним из самых квалифицированных сотрудников и может эскалировать проблему нужным ресурсам, если не может решить ее самостоятельно.

Аварией, из которой сделаны выводы, считается та, которая была проанализирована. Все проблемы, включая время их возникновения, регистрируются. Фиксируется время оповещения команды мониторинга, эффект от аварии и полная хронология произошедшего. Результаты разбора аварии дополняют соответствующий тикет, после чего в нем появляются задачи на исправление с конкретными исполнителями и сроками. Тестирование планов проводится регулярно, в идеале — ежеквартально или чаще, с привлечением смежных команд, например, сетевого отдела и разработчиков.

Протестированная авария — это та, из которой сделаны выводы, а что если выводы неверны или они не могут быть сделаны в данный текущий момент времени?

Улучшение измеряется через статистику инцидентов различных типов (связанных с железом, софтом, внешними партнерами). Особое внимание уделяется инцидентам, имеющим эффект для пользователей, которые становятся предметом отдельного разбирательства. Хотя прямого показателя аптайма в процентах нет, анализ статистики инцидентов позволяет делать выводы о повышении надежности и скорости устранения сбоев.

Процесс расследования является бесконечным. Если эффект от аварии небольшой, но ресурсы на расследование уже потрачены в огромном объеме, расследование может быть остановлено. Однако, если эффект очень большой, работа по устранению корневой причины будет продолжаться до полного понимания ситуации. Взаимодействие между сервисами и логирование построены на стандартных подходах, что упрощает понимание схемы тысяч серверов для дежурных разработчиков.