В 2013 году случилась самая большая авария в истории Одноклассников: в течение трёх дней проект был целиком, а потом частично, неработоспособен. После того, как мы устранили последствия аварии, к нам пришел бизнес со следующим вопросом: какие проблемы видит технический отдел компании и какие варианты защиты может предложить. Сходу мы выделили три основных — взлом хакерами, DDoS-атаки и аварии. Взломы — не в плоскости конференции Highload, про DDoS-атаки — наоборот, рассказывают довольно часто. Поэтому в этом докладе мы поговорим именно про аварии. Отказ диска или сервера мы давно не считаем аварией — у нас несколько тысяч серверов, и подобные сбои происходят по нескольку раз в день. Среди выделенных нами серьезных отказов — отказ канала связи до дата-центра, сбои электричества, перегрузка какой-то из подсистем, вызванная ростом какой-то активности (в т.ч. эксперименты), ошибка программиста/инженера и другие. По каждому из перечисленных направлений мы проанализировали риски и провели ряд работ на портале, позволивший нашей системе успешно функционировать в условиях перечисленных выше проблем. Как и в программировании, мы решили, что тестирование — это отличный способ выявлять проблемы на ранних стадиях и ликвидировать их минимальными средствами. В презентации мы расскажем о том, как мы защищаемся от каждой из перечисленных выше угроз и сфокусируемся на техниках эмуляции аварийных ситуаций.

1. Тестирование
аварий
Андрей Губа

2. О себе
• В IT 15 лет
• В Одноклассниках с 2008 года
• Системный администратор
– Руководитель отдела
– Deputy CTO
• Системное Администрирование
API, Платформа
Информационная безопасность

3. Одноклассники в цифрах
0
10
20
30
40
50
2010
2011
2012
2013
2014
2015
Уники, млн/сут

4. Одноклассники в цифрах
0
1000
2000
3000
4000
5000
6000
7000
8000
2010
2011
2012
2013
2014
2015
Серверов

5. Одноклассники в цифрах
0
200
400
600
800
1000
1200
2010
2011
2012
2013
2014
2015
Трафик, Гбит/cек

6. Авария в WEB проекте
Умер web сервер
Отказала «главная база»
Пропало электричество во втором ДЦ
Пропала сеть в основном ДЦ
jabber сервера с нами больше нет
Главный админ вне досягаемости
Пятница, вечер

8. Авария 04.04.2013
h p://habrahabr.ru/p/268413/

9. Инциденты с эффектом для
пользователей
2010
2011
2012
2013
2014
2015
Инциденты/месяц
Уники/день
45
млн
13
млн
16
84

10. Оперативный мониторинг
Железо и инфраструктура
Приложения
Активность пользователей

11. Оперативный мониторинг.
Проблемы
Новое оборудование
Новая операционная система

12. Много информации!
Сложно!

13. Оперативный мониторинг
Решение
Семафоры

15. Smart Monitoring
Обнаруживает аномалии на графиках
Показывает причинно-следственную
связь между найденными аномалиями
Создает и оформляет тикеты

17. Графики использования
ресурсов
Всё продакшн оборудование
Автоматически
Диски, память, трафик …
Java heap, GC …
2.7 млн метрик

18. ПОПП — Проверка операционных
показателей и прогнозирование

19. Резервирование
Диски в райд массиве
Резервный интернет канал
Реплика базы данных
Множество серверов одного типа в
кластере.

20. Резервирование
MS SQL, HP
Быстро реагируем –> Не всегда помогает

21. Резервирование
Надежное железо тоже отказывает
1 сервер = раз в 3 года
200 серверов = раз в неделю
2000 серверов > раз в день

22. Приложения должны обрабатывать
аварийные ситуации:
Отказ
Замедление
Возвращение в работу
Старт без связанных сервисов
Резервирование

23. Управляемая деградация

24. Отключение сервиса

25. Горилла и Годзилла
Тестирование аварийных сценариев в
приложениях, сервисах … ДЦ

26. Резервирование
Все данные должны иметь копии в
разных дата-центрах

27. Все данные должны иметь копии в
разных дата-центрах

28. Все данные должны иметь копии в
разных дата-центрах

29. Все данные должны иметь копии в
разных дата-центрах

30. Проект должен работать в случае
отказа любого дата-центра!

31. Резервирование. Сложности
Приложения не готовы.
Нужно переписать код.
Приложений много!
Нет готовых технических решений.
Нужно внедрять!
Не хватает людей

32. Рабочие инструменты
Доступ

33. Рабочие инструменты
Аварийный доступ

35. Рабочие инструменты
Системы управления
Надежность
Системы мониторинга
Надежность
Точность

36. Документация
Описание сервиса
Схема
Настройка
Решение типичных проблем
Achtung!

37. План действий при аварии
Чеклист для команды мониторинга:
Оповещение дежурного
Сообщение в рабочие чаты
Создание аварийного чата
Способы оповещения
Мобилизация нужных команд
Оповещение:
руководителей, менеджеров,
партнеров

38. План действий при аварии
Распределение ролей и ответственности:
Оценка масштаба
Координатор
Составление оперативного плана
Предоставление доступов
Координация работ в отдельном ДЦ
Перенятие ролей
Разбор аварии

39. План действий при аварии
Чеклист по восстановлению сервисов:
Приоритезированный список
Ссылки на инструкции и инструменты
Как проверять
Что делать, если что-то пошло не так
Тестирование

40. План действий при аварии
Отдельная инструкция для человека,
выполняющего роль координатора:
Распределять задачи
Контролировать
Делегировать
Обновлять оперативный план
Информировать

41. План действий при аварии
Отдельная инструкция на случай падения
дата-центра:
Вывод трафика
Ввод трафика
Контроль

42. План действий при аварии
Регламент взаимодействия с партнёрами:
Список контактов
Способы коммуникации
Уровни взаимодействия:
Информационный
Мобилизационный
Рабочая группа
Распределение ролей

43. Тестирование плана
Раз в квартал
Разный координатор
Сценарий
Коллеги из других команд
Фиксирование проблем
Задачи на исправление

45. Сами аварии – это тоже
тестирование!
Регистрируем
Время (начало, завершение)
Скорость оповещения
Эффект
Хронология
Суть проблемы
Обновляем в процессе
Результаты разбора
Задачи на исправление

47. Коротко о главном
Мониторинг
Резервирование
Рабочие инструменты
План действий при аварии
Тестирование аварий

48. Спасибо за внимание!
h p://habrahabr.ru/company/odnoklassniki/blog/
andrey.guba@ok.ru