Поддержка высоконагруженного проекта Евгений Потапов Евгений Потапов

Поддержка высоконагруженного проекта Евгений Потапов

Евгений Потапов генеральный директор компании ITSumma Круглоcуточное удаленное администрирование серверов и техническая поддержка сайтов 100 миллионов уникальных посетителей в сутки Штат – 50 человек Более тысячи серверов на поддержке

На поддержке

Содержание • • • Мониторинг и его специфика в высоконагруженном проекте Организация резервирования и резервного копирования Организация обслуживания и поддержки.

Цели мониторинга • • • Мониторинг как система оповещения Мониторинг как средство анализа Мониторинг как система принятия решений

Мониторинг как система оповещения • • • Оповещение о проблемах на сервере Оповещение о проблемах, связанных с логикой приложения Оповещение о проблемах, связанных с бизнес-показателями

Мониторинг как система оповещения 1. 2. 3. Требования к системе оповещения: независимость от самого проекта (если он упадет система должна продолжать работать) максимально быстрое оповещение о достижении критических показателей надежность оповещений о достижении критических показателей

Мониторинг как система оповещения 1. 2. 3. Три уровня оповещений: Проблемы на сервере (проблемы на серверном железе/серверном ПО) Проблемы на уровне приложения (производительность подсистем, число обращений к подсистемам) Проблемы на уровне бизнес-логики (метрики бизнеса)

Оповещения о проблемах на сервере Проблемы на сервере 1. 2. 3. Статистика по нагрузке на CPU (Оповещения на рост Load Average>числа ядер, CPU idle ниже определенного порога) Статистика по нагрузке на дисковую подсистему (увеличение времени avio, рост дисковых операций iops, рост «busy» диска) Использование оперативной памяти/swap (снижение cached+buffers+free ниже порога, рост использования swap (swap in / swap out)

Оповещения о проблемах на сервере 4. 5. Статистика по серверному софту (падение / всплески числа запросов на веб-сервер, статистика сервера БД, итд) Внешний мониторинг ответа сервисов (время ответа страниц, код ответа страниц, размер ответа страниц, ошибки рендеринга в Casper. JS, время рендеринга)

Оповещения о проблемах на сервере 1. 2. 3. Проблемы на уровне приложения Число ошибок уровня приложения (Рост числа ошибок больше заданного, рост/падение числа событий в целом) Число обращений к подсистемам/ «узлам» приложения (Рост/падение таких обращение) Время взаимодействия приложения с внешними сервисами (рост времени запроса к внешним сервисам, корректность ответов внешних сервисов на уровне приложения)

Оповещения о проблемах на сервере 1. 2. Проблемы на уровне бизнес-логики Бизнес данные на «последней миле» технологического стека (Bablo per minute, время с последних действий пользователей, падение числа пользователей) Эмуляция пользовательской логики приложения (оповещения не невозможность выполнить пользовательские действия, оповещения на увеличение времени ответа пользовательских действий)

Оповещения о проблемах на сервере 4. 5. Статистика по серверному софту (падение / всплески числа запросов на веб-сервер, статистика сервера БД, итд) Внешний мониторинг ответа сервисов (время ответа страниц, код ответа страниц, размер ответа страниц, ошибки рендеринга в Casper. JS, время рендеринга)

Оповещения о проблемах на сервере Устанавливать оповещения следует не на фатальные состояния (не осталось места на диске, CPU загружен на 95%), а на «контрольные точки» проекта. 1. 2. 3. На запуске – проект не загружен. После первоначального «шторма» , рост будет плавный. Ключевая метрика роста/проблем - достижение контрольных точек (исчерпали 25% ресурсов, исчерпали 50% ресурсов итд). В сложных решениях нужно иметь запас времени для действий связанных с оптимизацией или масштабированием.

Мониторинг как система анализа Цель – понять причину происходящих проблем 1. 2. 3. Требования: возможность хранить максимально возможное количество данных в максимально возможной детализации возможность быстро выбрать эти данные за нужный период возможность быстро отобразить выбранные данные и детально их изучить

Мониторинг как система анализа Необходимая функциональность: 1. 2. 3. Сравнение однотипных данных по разным серверам (на каком сервере происходят отклонения от нормы) Сравнение текущих данных с историческими данными (день назад, неделя назад, месяц назад) (насколько текущие показатели отклоняются от нормы) Быстрая выборка большого диапазона исторических данных (изменение данных в динамике)

Мониторинг как система анализа Дополнительно: Сложная агрегация метрик (скользящая средняя, перцентиль, группировка по минимуму, максимум итд).

Мониторинг как система принятия решений Организационный подход: 1. 2. 3. Данные в мониторинге следует использовать не только для анализа причин текущих аварий, но и для понимания что делать дальше Регулярный обзор всех ключевых метрик с целью анализа новых «контрольных точек» ( «через 6 месяцев мы съедим половину ресурсов» ) Данные в мониторинге, как средство избежать повторяющихся ошибок

Мониторинг Доступные решения: 1. 2. 3. Новый проект на старте: Saa. S (Serverdensity, New. Relic, Data. Dog) Сложный сбор данных, развитие семейство Graphite Извращение и много ресурсов: свои системы

Резервное копирование Ключевые проблемы: 1. 2. 3. Процесс снятия резервной копии (нагрузка на сервер) Регулярность снятия резервной копии (объем данных, время, необходимое на резервирование) Время восстановления из резервной копии

Резервное копирование Процесс снятия резервной копии: 1. 2. 3. 4. Сам по себе процесс снятия резервной копии – тяжелая процедура Резервные копии - создавать с резервных машин Понимание того, что нужно резервировать: UGC – база легкая, а статика может весить гигабайты. База без картинок людям не нужна. Бэкап без регулярной процедуры восстановления – не бэкап.

Резервное копирование Резервные копии - БД: 1. 2. 3. Slave-сервер, как резервная копия на случай аварии (защита от аварий с железом но не от человеческого фактора) Slave-сервер с искусственной задержкой, как резервная копия на случай человеческого фактора Hot-backup-службы – для регулярного внешнего резервного копирования.

Резервное копирование Резервные копии – БД – хранение: 1. 2. Минимум одна копия – в пределах внутреннего канала площадки (оперативное восстановление при повреждении данных) Минимум одна копия – на внешней площадке (восстановление при глобальной аварии).

Резервное копирование Резервная копия - контент: 1. 2. Снэпшоты/Rsync (при небольшом количестве изменяемых данных в пределах интервала резервного копирования). Дублирование статики на резервный сервер непосредственно сервером.

Резервное копирование Резервная копия - конфигурация: 1. Конфиги надо бэкапить!

Резервное копирование Резервные копии – процедуры Регулярная регламентированная процедура восстановления проекта из резервной копии Ключевые показатели: 1. 2. 3. Оценка времени, занятого на восстановление из резервной копии Оценка «отката во времени» на проекте, после восстановление из резервной копии Оценка целостности восстановленной резервной копии

Резервирование Ключевые вопросы: 1. 2. 3. Выбор площадки для резервирования Мощности для резервирования и бюджеты Процедуры переключения на резерв

Резервирование Выбор площадки для резервирования 1. Резервная площадка не должна быть связана с текущим датацентром (часто видим резервные сервера в той же стойке даже на крупных проектах) 2. Существует риск того, что резервная площадка после переключения останется основной надолго – она не должна быть слишком плохой по качеству или слишком дорогой по стоимости.

Резервирование Мощности для резервирования На запуске проекта – простаивающие мощности – лишние затраты. 1. Проект можно разделить на два ДЦ, и переходить на один в случае аварии (тогда возможны тормоза) 2. Гибридное облако – резерв находится в минимальной конфигурации в облаках, достаточной только для того чтобы принимать репликацию. В случае аварии – масштабирование и переключение.

Резервирование – процедуры Регулярная регламентированная процедура переключения на резерв (все ненавидят) 1. 2. 3. Оценка времени, занятого на переключение Оценка целостности данных после переключения на резерв Очень не любит бизнес – риск простоя (но еще больший риск – если не делать)

Резервирование и резервное копирование 1. 2. 3. 4. 5. 6. 7. 8. Slave – это не бэкап Бэкап в том же ДЦ – это не бэкап Резерв в том же ДЦ – это не резерв Бэкап, который не восстанавливали – это не бэкап Бэкап без статики – это не бэкап Если не хватает места – это не отмазка Резерв без переключения – это почти не резерв «Я решу про бэкап на днях» – первый (из двух) шагов к потерянным данным.

Поддержка Все это – не работает без команды 1. 2. 3. 4. 5. Понимание внутренностей продукта, способность локализовать проблему Вовлеченность в команду (ночные алерты - это боль) Стрессоустойчивость (ночные алерты – это боль) Чаще всего – на старте – разработчики с задатками админа. Должны быть экстраверты (по крайней мере – те кто будут объяснять бизнесу что случилось)

Поддержка Все это – не работает без организации 1. 2. 3. 4. Исправленная авария, шаги по исправлению которой не документированы - не исправлена Любой инцидент без алертов может случится один раз. Это должен быть единственный раз. Любые повторяющиеся процедуры, повторяющиеся алерты должны быть описаны Минимум бюрократии на этапе борьбы с аварией, формализация – на этапе postmortem-а.

Поддержка Режим работы 1. 2. 3. 4. Старт – SMS-ки ключевым людям, телефонные звонки Дежурства: двое через двое по 12 часов – отсутствует жизнь. Категорически не должно быть одного человека на sms-ках. Минимум двое (лучше трое) У каждого из людей on-call должно быть минимум 3 телефона критических людей для оповещения

Поддержка Дополнительные метрики 1. 2. 3. 4. Alerts per hour – для общего понимания увеличения беды. Время проведенное на серверах (рост времени – рост проблем). Запись SSH-сессий как способ просто восстановить сделанные во время аварий операции. У каждого из людей on-call должно быть минимум 3 телефона критических людей для оповещения

Поддержка Еще про работу 1. 2. 3. 4. Bus factor – если несколько ключевых людей летят на одном рейсе – серверы обязательно упадут On-call с SMS-ками – всегда минимум два способа связи при себе. Идеально: редирект на другого on-call человека при недоступности мобильного телефона. Жизнь on-call людей тяжела – любите и цените их

Вместо выводов 1. 2. 3. 4. Просто сделать и запустить – не работает (человек тоже болеет) Замониторить и больше никогда не упадет – не работает (диспансеризация – тот же мониторинг) Зарезервировать и не проверять – не работает (каждый второй – не проверяет, 9 из 10 не проверяет полноценно) Зарезервировать, замониторить но не организовать службу поддержки – не работает (программисты будут смотреть как «все упало» и не знать что делать)

Евгений Потапов http: //itsumma. ru eapotapov@itsumma. ru http: //facebook. com/eapotapov