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

Заглянуть «по ту сторону» аналитики и мониторинга нам помог Сергей Шарапов – системный аналитик Mail.ru. У него богатый опыт работы в Одноклассниках, начиная с настройки серверного и сетевого оборудования, вплоть до выстраивания бизнес-процессов для HR.

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

— Сергей, расскажите про размер команды мониторинга, ее структуру и точки взаимодействия с разработчиками. Кто и за что отвечает в этой схеме?

Сергей Шарапов: Команда мониторинга состоит из восьми человек: пять человек работают в дневные смены, которых у нас три (с 7:00 до 16:00, с 10:00 до 19:00 и с 14:00 до 23:00), и три человека работают в ночную смену. Днем, когда на портале повышенная пользовательская активность и запускается много экспериментов, работают два человека в смене. Ночью и в выходные работает один человек в смене. Дневная команда занимается более глубоким анализом и расследованием возникших аномалий. В помощь команде мониторинга выделяется системный администратор, они дежурят по 24 часа и привлекаются только тогда, когда от них действительно что-то требуется. Поэтому даже во время дежурства админы могут заниматься своими задачами. Во время дежурства дневная команда мониторинга напрямую взаимодействует с разработчиками и инженерами в ЦОД. Ночная команда, в основном, контактирует только с дежурным системным администратором, она будит админа только если есть даунтайм или вероятность его возникновения. Все ночные инциденты обычно разбираются утром.

— Какие KPI у команды мониторинга, как оценивается ее эффективность? Кто форсирует изменения?

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

— Каким образом работает система оповещений и с технической, и с человеческой точки зрения?

Сергей Шарапов: Весь оперативный мониторинг находится в одной системе — SmartMonitoring (вся необходимая информация находится на одном экране), в которой видны проблемы с бизнес-метриками и проблемы в работе приложений. Там же появляются нотификации по новым автоинцидентам, которые у нас работают в связке Jira+Zabbix. Zabbix обнаруживает проблему и автоматически создается инцидент в Jira. Все общение команды мониторинга с админами, разработчиками и инженерами происходит в нашем мессенджере TamTam. На каждый более-менее серьезный инцидент создается отдельный чат, в котором происходит его решение. При создании инцидентов приходят автоматические уведомления в основной чат, где есть все сотрудники, там же пишут о всех экспериментах и работах, которые могут на что-то повлиять, кроме того, все это дублируется и в отдельный чат мониторинга, где есть только технические специалисты. Автоинциденты не попадают в эти чаты, т.к. эти инциденты не влияют на пользователей, а если происходит что-то серьезное, то создается общий инцидент, к которому прилинковываются автоинциденты. Самое главное, что чат «читаем», в нем нет спама, и все сообщения несут смысл.

— Расскажите про самые интересные случаи влияния человеческого фактора, кто-нибудь удалял базу данных?

Сергей Шарапов: Конечно, такие случаи встречаются… Мы постоянно придумываем что-то, чтобы минимизировать человеческий фактор. Самый серьезный инцидент произошел 4 апреля 2013 года. Про него многое было рассказано, и есть отдельная статья на Хабре. Мы между собой так и называем этот инцидент — 404. Восемь лет назад и я отличился, «убил» оборудования на несколько десятков тысяч долларов… Я только начинал работать в Одноклассниках, и меня обучали обновлять прошивки на наших стореджах Promise. Мой наставник кинул по скайпу новую прошивку, показал на моем компьютере, как обновлять. Но ждать, когда массив выйдет из ребута, долго, да и что там может произойти?! Я повторил это на 15 устройствах. Оказалось, что прошивка была не от этого оборудования, а откатить возможности нет. Но история кончилась благополучно для нас. Поскольку оборудование только готовилось к продакшну, вендор пошел нам навстречу и бесплатно заменил все «убитые» устройства.

В другой раз один из разработчиков удалил 4 ТБ данных с нашей статистикой. Причиной послужила ошибка в команде на удаление — не экранирован ‘$’ в начале имени каталога, что привело к удалению родителя. Но и эта история закончилась хорошо, был бэкап.

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

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

Если вы хотите больше узнать технических деталей из практики Одноклассников, приходите послушать доклад Сергея «SmartMonitoring — мониторинг бизнес-логики в Одноклассниках» на октябрьскую конференцию DevOops 2017 Piter. Разумеется, он там будет не один. Наверняка вам будут интересны и другие доклады, среди которых:

Ансамбль солёных поваров-кукловодов: сравниваем Ansible, SaltStack, Chef и Puppet (Андрей Филатов, Epam Systems)
Расширяем k8s (Николай Рыжиков, Health Samurai)
DevOps в масштабе: греческая трагедия в трех актах (Барух Садогурский, JFrog и Леонид Игольник, CA Technologies)
Troubleshooting & debugging production applications in Kubernetes (a.k.a. The Failing Demo Talk) (Ray Тsang, Google и Барух Садогурский, JFrog)

Как у других: Monitoring&Tracing Tools в «Одноклассниках»