1. Мониторинг высоконагруженного проекта. 1.1. Специфика мониторинга высоконагруженного проекта: гранулярность мониторинга, надежность системы мониторинга, система оповещений. 1.2. Мониторинг и контроль распределенных систем. 1.3. Специфика организации оповещений в высоконагруженном проекте. Превентивный мониторинг. 2. Резервирование и резервное копирование в высоконагруженном проекте. 2.1. Резервирование и резервное копирование - разные вещи. 2.2. Резервирование: на уровне сервера, дата-центра, географически распределенных площадок. 2.1. Организация резервного копирования. Сохранность часто обновляемых данных. 3. Обслуживание высоконагруженного проекта. 3.1. Организация поддержки высоконагруженного проекта: опыт, специфика работы. 3.2. Организация дежурств, эскалация оповещений. 3.3. Аварии в высоконагруженных проектах: примеры из жизни.

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

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

3. На поддержке

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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