Всем привет! Меня зовут Александр Афенов, я работаю в Lamoda. Ээта статья основана на моем отчете с HighLoad 2019, запись которого находится здесь .
Раньше я был руководителем группы и отвечал за несколько критически важных служб.
А если в них что-то шло не так, это останавливало реальные бизнес-процессы.
Например, заказы больше не шли на сборку на складе.
Недавно я стал руководителем направления и теперь отвечаю за три команды вместо одной.
Каждый из них управляет ИТ-системой.
Я хочу понять, что происходит в каждой системе и что может сломаться.
В этой статье я расскажу о
- что мы отслеживаем
- как мы контролируем
- и самое главное: что нам делать с результатами этих наблюдений.
У Lamoda много систем.
Их всех выпускают, что-то в них меняется, что-то происходит с техникой.
И хотелось бы иметь хотя бы иллюзию, что мы легко можем локализовать поломку.
Меня постоянно засыпают уведомлениями, в которых я пытаюсь разобраться.
Чтобы отойти от абстракций и перейти к конкретике, расскажу первый пример.
То и дело что-то взрывается: хроника пожара Одним теплым летним утром, без объявления войны, как это обычно бывает, наш мониторинг сработал.
Мы используем Icinga для оповещения.
Алерт сообщил, что у нас на сервере СУБД осталось 50 ГБ жесткого диска.
Скорее всего, 50 гигабайт — это капля в море, и она очень быстро закончится.
Мы решили посмотреть, сколько именно свободного места осталось.
Нужно понимать, что это не виртуальные машины, а аппаратные серверы, и база данных испытывает большую нагрузку.
Есть SSD на 1,5 терабайта.
Скоро этой памяти скоро придет конец: она продлится 20-30 дней.
Это очень мало; проблему нужно решить быстро.
Затем мы дополнительно проверяли, сколько памяти реально было использовано за 1-2 дня.
Получается, что 50 гигабайт хватит примерно на 5-7 дней.
После чего служба, работающая с этой базой данных, предсказуемо завершится.
Мы начинаем задумываться о последствиях: что срочно архивируем, какие данные удаляем.
В отделе анализа данных есть все резервные копии, поэтому вы можете смело удалять все, что старше 2015 года.
Пробуем его удалить и помним, что MySQL с полпинка так работать не будет. Удаленные данные — это здорово, но размер файла, выделенного для таблицы и БД, не меняется.
MySQL затем использует это местоположение.
То есть проблема не решилась, места больше не было.
Давайте попробуем другой подход: переведем планшеты с быстрых, заканчивающих SSD, на более медленные.
Для этого мы подбираем таблички, которые весят много, но при небольшой нагрузке, и используем мониторинг Percona. Мы перенесли столы и уже думаем о переносе самих серверов.
После второго переезда серверы занимают не 1,5, а 4 терабайта SSD. Мы потушили этот пожар: организовали переезд и, конечно, наладили мониторинг.
Теперь предупреждение будет срабатывать не на 50 гигабайтах, а на полтерабайта, а критическое значение мониторинга будет срабатывать на 50 гигабайтах.
Но на самом деле это просто прикрытие спины одеялом.
На какое-то время этого будет достаточно.
Но если мы позволим ситуации повториться, не разделив базу данных на части и не подумав о шардинге, все кончится плохо.
Предположим, что мы в следующий раз меняем серверы.
На каком-то этапе пришлось перезапустить мастер.
Вероятно, в этом случае будут ошибки.
В нашем случае время простоя составило около 30 секунд. Но запросы приходят, писать некуда, начали сыпаться ошибки, мониторинг заработал.
Используем систему мониторинга «Прометей» — и видим в ней, что подскочила метрика в 500 ошибок или количество ошибок при создании заказа.
Но мы не знаем подробностей: какой орден не был создан и тому подобное.
Далее я расскажу, как мы работаем с мониторингом, чтобы не попадать в подобные ситуации.
Обзор мониторинга и четкое описание службы поддержки У нас есть несколько направлений и показателей, которые мы отслеживаем.
В офисе повсюду телевизоры, на которых много разных технических и бизнес-лейблов, за которыми помимо разработчиков следит служба поддержки.
В этой статье я рассказываю о том, как у нас это есть и добавляю, чего мы хотим достичь.
Это касается и мониторинга отзывов.
Если бы мы регулярно проводили инвентаризацию своего «имущества», мы могли бы обновлять все, что устарело, и исправлять это, не допуская повторения факапа.
Для этого нужен четкий список.
У нас есть конфиги с алертами в репозитории, который на данный момент содержит 4678 строк.
Из этого списка сложно понять, о чем говорит каждый конкретный мониторинг.
Допустим, наша метрика называется db_disc_space_left. Служба поддержки не сразу поймет, о чем речь.
Что-то насчет свободного места, отлично.
Мы хотим копнуть глубже.
Смотрим конфиг этого мониторинга и понимаем откуда он.
У этой метрики есть имя, свои ограничения, когда включать мониторинг предупреждений и оповещение о критической ситуации.pm_host: "{{ prometheus_server }}" pm_query: ”mysql_ssd_space_left" pm_warning: 50 pm_critical: 10 pm_nanok: 1
Мы используем соглашение об именовании метрик.
В начале каждой метрики указано название системы.
Благодаря этому становится ясна зона ответственности.
Если метрику создает тот, кто отвечает за систему, сразу понятно, к кому идти.
Оповещения заливаются в Telegram или Slack. Служба поддержки отвечает на них первой в режиме 24/7. Ребята смотрят, что именно взорвалось и нормальная ли это ситуация.
У них есть инструкции:
- те, которые даны на замену
- и инструкции, которые записываются в слиянии на постоянной основе.
По названию взорванного мониторинга можно узнать, что оно означает. Для самых критичных описано, что сломано, какие последствия и кого нужно поднимать.
В каждой команде есть кто-то, кто всегда доступен.
Если что-то случится, они его заберут. При срабатывании оповещения команде поддержки необходимо быстро узнать всю ключевую информацию.
Было бы здорово, если бы в сообщении об ошибке была ссылка на описание мониторинга.
Например, чтобы иметь следующую информацию:
- описание этого мониторинга в ясных и относительно простых терминах;
- адрес, где он находится;
- объяснение, что это за метрика;
- последствия: чем все закончится, если мы не исправим ошибку;
- Иногда наши системы мониторинга сгорают, и вы можете игнорировать их, и ничего не произойдет. Возможно, это мониторинг, сделанный напрасно.
Здесь нужна четкая точка действия, что делать.
Хотелось бы сделать такие описания для каждого мониторинга.
Они помогут вам организовать обзоры и внести коррективы.
Мы реализуем такую практику: в конфиге айсинга уже есть ссылка на слияние с этой информацией.
Я работаю над одной системой уже почти 4 года, и таких описаний по ней в принципе нет. Поэтому теперь я собираю знания вместе.
Описания также решают проблему невежества команды.
Для большинства оповещений у нас есть инструкции, в которых указано, что приведет к конкретному воздействию на бизнес.
Именно поэтому мы должны быстро разобраться в ситуации.
Критичность возможных инцидентов определяется службой поддержки совместно с бизнесом.
Приведу пример: если срабатывает мониторинг потребления оперативной памяти на сервере RabbitMQ службы обработки заказов, это означает, что служба организации очередей может выйти из строя через несколько часов или даже минут. А это, в свою очередь, остановит многие бизнес-процессы.
В результате клиенты будут безуспешно ждать обработки заказов, SMS/push-уведомлений, изменения статуса и многого другого.
Разговоры о мониторинге с бизнесом часто возникают после серьезных инцидентов.
Если что-то ломается, мы собираем комиссию из представителей того направления, которое пострадало от нашего выброса или инцидента.
На встрече мы анализируем причины инцидента, как сделать так, чтобы оно никогда не повторилось, какой ущерб мы понесли, сколько денег потеряли и почему.
Бывает, что нужно привлечь бизнес к решению проблем, созданных для клиентов.
Там мы обсуждаем превентивные действия: какой мониторинг установить, чтобы подобное не повторилось.
Служба поддержки отслеживает значения метрик с помощью телеграм-бота.
При появлении нового мониторинга сотруднику поддержки нужен простой инструмент, который позволит ему узнать, где что сломалось и что с этим делать.
Ссылка на описание в оповещении решает эту проблему.
Вижу факап как в реальности: используем Sentry для разбора полетов Недостаточно просто знать об ошибке; вы хотите увидеть детали.
Наш стандартный сценарий использования таков: мы выкатили релиз и получили оповещения от стека K8S. Благодаря мониторингу мы смотрим на состояние подов: какие версии приложения выкатились, как завершился развертывание и все ли в порядке.
Далее смотрим на РММ, что у нас с базой и нагрузкой на нее.
Для Grafana и плат мы смотрим на количество подключений к Rabbit. Он классный, но умеет сливать, когда память кончается.
Мы следим за этими вещами, а затем проверяем Sentry. Он позволяет посмотреть онлайн, как разворачивается очередное фиаско со всеми подробностями.
В этом случае пострелизный мониторинг сообщает, что именно сломалось и как.
В PHP-проектах мы используем клиент Raven и дополнительно обогащаем его данными.
Sentry прекрасно объединяет все это.
И видим динамику по каждому факапу, как часто это происходит. Мы также рассмотрим примеры, чтобы увидеть, какие запросы не удалось выполнить, а какие возникли исключения.
Примерно так это выглядит. Вижу, что в следующем релизе ошибок кардинально больше, чем обычно.
Мы проверим, что именно сломалось.
А затем, если необходимо, мы на основе контекста извлечем неудавшиеся заказы и исправим их.
У нас есть классная штука — привязка к Jira. Это тикет-трекер: я нажал кнопку, и в Jira создалась задача об ошибке со ссылкой на Sentry и трассировкой стека этой ошибки.
Задача помечается определенными ярлыками.
Один из разработчиков выступил с разумной инициативой — «Чистый проект, чистый страж».
Во время планирования мы каждый раз закидываем в спринт минимум 1-2 задачи, созданные из Sentry. Если в системе постоянно что-то ломается, то Sentry завален миллионами мелких глупых ошибок.
Мы их регулярно чистим, чтобы случайно не пропустить действительно серьезные.
Вспыхивает по любому поводу: избавляемся от мониторинга, которым все пренебрегают
- Привыкаем к ошибкам
Служба поддержки может ошибаться, думая, что ситуация адекватная.
А когда что-то серьезное сломается, это будет проигнорировано.
Как в басне о мальчике, который кричал: «Волки, волки!» Классический случай — наш проект, отвечающий за обработку заказов.
Он работает с системой автоматизации склада и передает туда данные.
Эту систему обычно отпускают в 7 утра, после чего загорается наш мониторинг.
Все к этому привыкли и забивают, что не очень хорошо.
Было бы разумно настроить этот мониторинг.
Например, подключение релиза конкретной системы и некоторых оповещений через Прометей просто не включает ненужную сигнализацию.
- Мониторинг не учитывает бизнес-показатели
Никто из них не выстрелил, и вроде бы все в порядке.
Счетчик показывает, что данные теряются.
В этом случае используется мыло.
На самом деле счетчик может выглядеть так: зеленая часть — входящие обмены, желтая — исходящие.
У нас был случай, когда данные действительно работали, но были криво.
Заказы не были оплачены, но были помечены как оплаченные.
То есть покупатель сможет забрать их бесплатно.
Кажется, это страшно.
Но веселее наоборот: человек приходит забрать оплаченный заказ, а его просят оплатить еще раз из-за ошибки в системе.
Чтобы избежать подобной ситуации, мы отслеживаем не только технологические, но и бизнес-показатели.
У нас есть специальный мониторинг, который отслеживает количество заказов, требующих оплаты при получении.
Любые значительные скачки этого показателя будут указывать на то, что что-то пошло не так.
Мониторинг бизнес-показателей — вещь очевидная, но о ней часто забывают при выпуске новых сервисов, в том числе и у нас.
Все снабжают новые сервисы чисто техническими показателями, связанными с дисками, процессорами и т. д. У нас как интернет-магазина есть критически важная вещь — количество создаваемых заказов.
Мы знаем, сколько люди обычно покупают, с учетом маркетинговых акций.
Поэтому мы следим за этим показателем во время релизов.
Еще один важный момент: когда клиент повторно заказывает доставку на один и тот же адрес, мы не утомляем его общением с колл-центром, а автоматически подтверждаем заказ.
Сбой системы сильно влияет на качество обслуживания клиентов.
Мы также следим за этой метрикой, поскольку релизы разных систем могут сильно на нее влиять.
Мы наблюдаем за реальным миром: заботимся о здоровом спринте и нашей производительности.
Чтобы помочь предприятиям отслеживать различные показатели, мы создали небольшую систему мониторинга в реальном времени.
Изначально его создавали для другой цели.
У бизнеса есть план, сколько заказов мы хотим продать в определенный день следующего месяца.
Эта система показывает соответствие между планами и тем, что было фактически сделано.
Для графа он берет данные из производственной базы данных и считывает их на лету.
Однажды наша реплика развалилась.
Мониторинга там не было, поэтому мы не успели об этом узнать.
Но бизнес увидел, что мы не выполняем план по 10 условным единицам заказов, и прибежал с замечаниями.
Мы начали понимать причины.
Оказалось, что из сломанной реплики считывались нерелевантные данные.
Это тот случай, когда бизнес наблюдает интересные показатели, и мы помогаем друг другу, когда возникают проблемы.
Расскажу про еще один реальный мониторинг, который уже давно находится в разработке и постоянно дорабатывается каждой командой.
У нас есть Jira Viewer — он позволяет следить за процессом разработки.
Система предельно проста: PHP-фреймворк Symfony, который заходит в Jira Api и берет оттуда данные о задачах, спринтах и так далее, в зависимости от того, что было дано на входе.
Jira Viewer регулярно записывает в Prometeus метрики, связанные с командами и их проектами.
Там они отслеживаются, оповещаются и отображаются в Grafana. Благодаря этой системе мы отслеживаем ход работ.
- Мы отслеживаем, как долго выполняется задача с момента ее выполнения и до момента ее выкатывания в производство.
Если число слишком велико, теоретически это указывает на проблему с процессами, командой, описанием задач и т. д. Продолжительность жизни задачи — важный показатель, но одного его недостаточно.
- Вы также можете посмотреть на здоровье спринта.
Допустим, оно заканчивается, и осталось слишком много невыполненных задач.
Или есть проблемы с протоколированием времени, если у вас принято его протоколировать.
- Недостаток релизов — слишком много задач в статусе готовности к релизу, но они никуда не делись.
Этот случай произошел с нами из-за заморозки кода перед большой акцией, такой как Черная пятница.
- Мы следим за просадкой в тестировании: когда куча задач ожидает тестирования, никто за этим пристально не следит. Эта метрика исключает ручную работу со стороны менеджера или руководителя группы.
- Статус невыполненных работ также можно отслеживать.
Недавно мы взяли техническое портфолио проекта и сократили его с 400 задач до 150. Мы просто поняли, что многие вещи не будут выполнены, поэтому отменили их.
- В своей команде я отслеживал количество пул-реквестов от разработчиков в нерабочее время.
Особенно после 8 вечера.
А когда метрика взлетает – это тревожный знак: человек либо не успевает что-то сделать, либо прикладывает слишком много усилий и рано или поздно просто перегорит.
На снимке экрана показано, как Jira Viewer генерирует данные.
Это страница, где есть сводная информация о статусе задач из спринта, сколько весит каждая и тому подобное.
Такие вещи тоже собираются и летят к Прометею.
Не только технические метрики: что мы уже отслеживаем, что можем отслеживать и зачем все это нужно Чтобы объединить все это, я предлагаю совместно отслеживать как технологии, так и показатели, связанные с процессами, разработкой и бизнесом.
Одних только технических показателей недостаточно.
- Мы взяли за правило, что когда мы внедряем новую систему или новый бизнес-процесс, мы заранее создаем новую доску Grafana. На этой доске отображаются все критические показатели этой системы.
Оповещения, уведомления и т. д. также настраиваются заранее, чтобы мы могли предвидеть проблемы на старте.
- Мы следим за тенденциями: делаем мониторинг, который отслеживает ситуацию в долгосрочной перспективе.
Однажды мы увидели, как постепенно растёт количество подключений к нашей базе данных, поэтому разобрались в проблеме с crontab и перешли в супервизор.
Так что практика просмотра долгосрочных изменений чисел в «Прометее» привела к спасению системы.
Правда, тем самым мы породили еще один серьезный инцидент, но такое случается.
- Мониторинг-обзор – это вещь, которая позволяет навести порядок в подобных историях и устранить древнее зло, запустившееся без видимых причин.
- Предлагаю исключить ложные срабатывания: чтобы не было ситуаций, когда что-то горит, хотя на самом деле этого быть не должно.
Очень важно, чтобы у людей не замыливались глаза.
- В целом стоит убедиться, что оповещения действительно отражают состояние данных в системе.
Моя проблема за последний год в том, что в Sentry накопилось несколько страниц ошибок.
Некоторые из них случаются миллионы раз, и я хочу это удалить.
Я хочу увидеть действительно важные вещи, которые необходимо решить.
А еще чтобы у Sentry не было нормального поведения, и чтобы там не было старых ошибок.
- Документируйте показатели и объясняйте их важность.
Очень плохо, когда никто, кроме автора метрики, не понимает, почему это важно и что нужно исправить.
- Решайте проблемы, а не прикрывайте тыл одеялом.
Важно не просто настраивать мониторинг, повышая пороговые значения, потому что что-то в системе постепенно разваливается.
Предлагаю действительно устранить первопричину оповещений и не допустить повторения уже произошедших сбоев.
-
Монитор Dell Ultrasharp 2709 Вт
19 Oct, 24 -
Список
19 Oct, 24 -
Циско. Первое Издание. Соединяем Две Сети.
19 Oct, 24
