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

Евгений Потапов

Евгений Потаповгенеральный директор компании ITSumma

Круглоcуточное удаленное администрирование серверов и техническая поддержка сайтов

100 миллионов уникальных посетителей в сутки

Штат – 50 человек

Более тысячи серверов на поддержке

На поддержке

Содержание• Мониторинг и его специфика

в высоконагруженном проекте• Организация резервирования

и резервного копирования• Организация обслуживания и

поддержки.

Цели мониторинга

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

решений

Мониторинг как система оповещения

• Оповещение о проблемах на сервере• Оповещение о проблемах, связанных с

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

бизнес-показателями

Мониторинг как система оповещения

Требования к системе оповещения:1. независимость от самого проекта (если

он упадет система должна продолжать работать)

2. максимально быстрое оповещение о достижении критических показателей

3. надежность оповещений о достижении критических показателей

Мониторинг как система оповещения

Три уровня оповещений:1. Проблемы на сервере (проблемы на

серверном железе/серверном ПО)2. Проблемы на уровне приложения

(производительность подсистем, число обращений к подсистемам)

3. Проблемы на уровне бизнес-логики (метрики бизнеса)

Оповещения о проблемах на сервереПроблемы на сервере

1. Статистика по нагрузке на CPU(Оповещения на рост Load Average>числа ядер, CPU idle ниже определенного порога)

2. Статистика по нагрузке на дисковую подсистему (увеличение времени avio, рост дисковых операций iops, рост «busy» диска)

3. Использование оперативной памяти/swap(снижение cached+buffers+free ниже порога, рост использования swap (swap in / swap out)

Оповещения о проблемах на сервере

4. Статистика по серверному софту(падение / всплески числа запросов на веб-сервер, статистика сервера БД, итд)

5. Внешний мониторинг ответа сервисов (время ответа страниц, код ответа страниц, размер ответа страниц, ошибки рендеринга в CasperJS, время рендеринга)

Оповещения о проблемах на сервереПроблемы на уровне приложения

1. Число ошибок уровня приложения (Рост числа ошибок больше заданного, рост/падение числа событий в целом)

2. Число обращений к подсистемам/ «узлам» приложения(Рост/падение таких обращение)

3. Время взаимодействия приложения с внешними сервисами(рост времени запроса к внешним сервисам, корректность ответов внешних сервисов на уровне приложения)

Оповещения о проблемах на сервереПроблемы на уровне бизнес-логики

1. Бизнес данные на «последней миле» технологического стека(Bablo per minute, время с последних действий пользователей, падение числа пользователей)

2. Эмуляция пользовательской логики приложения(оповещения не невозможность выполнить пользовательские действия, оповещения на увеличение времени ответа пользовательских действий)

Оповещения о проблемах на сервере

4. Статистика по серверному софту(падение / всплески числа запросов на веб-сервер, статистика сервера БД, итд)

5. Внешний мониторинг ответа сервисов (время ответа страниц, код ответа страниц, размер ответа страниц, ошибки рендеринга в CasperJS, время рендеринга)

Оповещения о проблемах на сервере

Устанавливать оповещения следует не на фатальные состояния (не осталось места на диске, CPU загружен на 95%), а на «контрольные точки» проекта.

1. На запуске – проект не загружен. После первоначального «шторма», рост будет плавный.

2. Ключевая метрика роста/проблем - достижение контрольных точек (исчерпали 25% ресурсов, исчерпали 50% ресурсов итд).

3. В сложных решениях нужно иметь запас времени для действий связанных с оптимизацией или масштабированием.

Мониторинг как система анализа

Цель – понять причину происходящих проблем

Требования:1. возможность хранить максимально

возможное количество данных в максимально возможной детализации

2. возможность быстро выбрать эти данные за нужный период

3. возможность быстро отобразить выбранные данные и детально их изучить

Мониторинг как система анализа

Необходимая функциональность:

1. Сравнение однотипных данных по разным серверам (на каком сервере происходят отклонения от нормы)

2. Сравнение текущих данных с историческими данными (день назад, неделя назад, месяц назад)(насколько текущие показатели отклоняются от нормы)

3. Быстрая выборка большого диапазона исторических данных (изменение данных в динамике)

Мониторинг как система анализа

Дополнительно:

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

Мониторинг как система принятия решенийОрганизационный подход:

1. Данные в мониторинге следует использовать не только для анализа причин текущих аварий, но и для понимания что делать дальше

2. Регулярный обзор всех ключевых метрик с целью анализа новых «контрольных точек» («через 6 месяцев мы съедим половину ресурсов»)

3. Данные в мониторинге, как средство избежать повторяющихся ошибок

Мониторинг

Доступные решения:

1. Новый проект на старте: SaaS (Serverdensity, NewRelic, DataDog)

2. Сложный сбор данных, развитие семейство Graphite

3. Извращение и много ресурсов: свои системы

Резервное копирование

Ключевые проблемы:

1. Процесс снятия резервной копии (нагрузка на сервер)

2. Регулярность снятия резервной копии (объем данных, время, необходимое на резервирование)

3. Время восстановления из резервной копии

Резервное копирование

Процесс снятия резервной копии:

1. Сам по себе процесс снятия резервной копии – тяжелая процедура

2. Резервные копии - создавать с резервных машин

3. Понимание того, что нужно резервировать: UGC – база легкая, а статика может весить гигабайты. База без картинок людям не нужна.

4. Бэкап без регулярной процедуры восстановления – не бэкап.

Резервное копированиеРезервные копии - БД:

1. Slave-сервер, как резервная копия на случай аварии (защита от аварий с железом но не от человеческого фактора)

2. Slave-сервер с искусственной задержкой, как резервная копия на случай человеческого фактора

3. Hot-backup-службы – для регулярного внешнего резервного копирования.

Резервное копированиеРезервные копии – БД – хранение:

1. Минимум одна копия – в пределах внутреннего канала площадки (оперативное восстановление при повреждении данных)

2. Минимум одна копия – на внешней площадке (восстановление при глобальной аварии).

Резервное копированиеРезервная копия - контент:

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

2. Дублирование статики на резервный сервер непосредственно сервером.

Резервное копированиеРезервная копия - конфигурация:

1. Конфиги надо бэкапить!

Резервное копированиеРезервные копии – процедуры

Регулярная регламентированная процедура восстановления проекта из резервной копииКлючевые показатели:

1. Оценка времени, занятого на восстановление из резервной копии

2. Оценка «отката во времени» на проекте, после восстановление из резервной копии

3. Оценка целостности восстановленной резервной копии

Резервирование

Ключевые вопросы:

1. Выбор площадки для резервирования2. Мощности для резервирования и

бюджеты3. Процедуры переключения на резерв

Резервирование

Выбор площадки для резервирования

1. Резервная площадка не должна быть связана с текущим датацентром (часто видим резервные сервера в той же стойке даже на крупных проектах)

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

Резервирование

Мощности для резервированияНа запуске проекта – простаивающие мощности – лишние затраты.

1. Проект можно разделить на два ДЦ, и переходить на один в случае аварии (тогда возможны тормоза)

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

Резервирование

Резервирование – процедуры

Регулярная регламентированная процедура переключения на резерв (все ненавидят)

1. Оценка времени, занятого на переключение2. Оценка целостности данных после

переключения на резерв3. Очень не любит бизнес – риск простоя (но

еще больший риск – если не делать)

Резервирование и резервное копирование

1. Slave – это не бэкап2. Бэкап в том же ДЦ – это не бэкап3. Резерв в том же ДЦ – это не резерв4. Бэкап, который не восстанавливали –

это не бэкап5. Бэкап без статики – это не бэкап6. Если не хватает места – это не отмазка7. Резерв без переключения – это почти не

резерв8. «Я решу про бэкап на днях» – первый

(из двух) шагов к потерянным данным.

Поддержка

Все это – не работает без команды

1. Понимание внутренностей продукта, способность локализовать проблему

2. Вовлеченность в команду (ночные алерты - это боль)

3. Стрессоустойчивость (ночные алерты – это боль)

4. Чаще всего – на старте – разработчики с задатками админа.

5. Должны быть экстраверты (по крайней мере – те кто будут объяснять бизнесу что случилось)

Поддержка

Все это – не работает без организации

1. Исправленная авария, шаги по исправлению которой не документированы - не исправлена

2. Любой инцидент без алертов может случится один раз. Это должен быть единственный раз.

3. Любые повторяющиеся процедуры, повторяющиеся алерты должны быть описаны

4. Минимум бюрократии на этапе борьбы с аварией, формализация – на этапе postmortem-а.

Поддержка

Режим работы

1. Старт – SMS-ки ключевым людям, телефонные звонки

2. Дежурства: двое через двое по 12 часов – отсутствует жизнь.

3. Категорически не должно быть одного человека на sms-ках. Минимум двое (лучше трое)

4. У каждого из людей on-call должно быть минимум 3 телефона критических людей для оповещения

Поддержка

Дополнительные метрики

1. Alerts per hour – для общего понимания увеличения беды.

2. Время проведенное на серверах (рост времени – рост проблем).

3. Запись SSH-сессий как способ просто восстановить сделанные во время аварий операции.

4. У каждого из людей on-call должно быть минимум 3 телефона критических людей для оповещения

Поддержка

Еще про работу

1. Bus factor – если несколько ключевых людей летят на одном рейсе – серверы обязательно упадут

2. On-call с SMS-ками – всегда минимум два способа связи при себе.

3. Идеально: редирект на другого on-call человека при недоступности мобильного телефона.

4. Жизнь on-call людей тяжела – любите и цените их

Вместо выводов

1. Просто сделать и запустить – не работает (человек тоже болеет)

2. Замониторить и больше никогда не упадет – не работает (диспансеризация – тот же мониторинг)

3. Зарезервировать и не проверять – не работает (каждый второй – не проверяет, 9 из 10 не проверяет полноценно)

4. Зарезервировать, замониторить но не организовать службу поддержки – не работает (программисты будут смотреть как «все упало» и не знать что делать)

Евгений Потапов

http://itsumma.rueapotapov@itsumma.ruhttp://facebook.com/eapotapov