Евгений Потапов / ITSumma — Менеджмент инцидентов и исследование жизненного цикла аварии

1. Евгений Потапов / ITSumma
Новое не значит лучшее.
Преждевеременное
внедрение технологий

2. 350+ компаний на поддержке
75 сотрудников, офисы в
Иркутске, Москве, Санкт-
Петербурге и Сан-Франциско
6000+ серверов на поддержке
SLA 15 минут
О компании

6. Главные причины аварий
• Аварии, связанные с новыми версиями
приложения
• Проблемы, связанные с ростом нагрузки и
масштабированием
• Человеческий фактор

7. Закон Луссера
надёжность ракеты равна произведению надёжности
всех компонентов,
а не надёжности самого ненадёжного элемента

8. Структура анализа ошибки
• Что случилось?
• В чем была ошибка?
• Как сделать так, чтобы такого больше никогда не
было?

9. «Поиск виновных»
• Один раз может ошибиться любой человек
• Частые ошибки – возможная
профнепригодность, но не вина
• Наказание – за целенаправленное нарушение
процессов

10. Основные причины
• Отсутствие процесса
• Ошибки в процессе
• Ошибки взаимодействия

11. Отсутствие процесса
31 марта 2016 года

12. 31 марта 2016 года - проблема
• Клиент пришел на поддержку без бэкапов баз
данных

13. 31 марта 2016 года - проблема
• Клиент пришел на поддержку без бэкапов баз
данных
• Размер БД (MySQL) – 2ТБ, около 300гб на
таблицу

14. 31 марта 2016 года - проблема
• Клиент пришел на поддержку без бэкапов баз
данных
• Размер БД (MySQL) – 2ТБ, около 300гб на
таблицу
• Нет слейва, работу останавливать нельзя

15. 31 марта 2016 года - проблема
• Клиент пришел на поддержку без бэкапов баз
данных
• Размер БД (MySQL) – 2ТБ, около 300гб на
таблицу
• Нет слейва, работу останавливать нельзя
• 300гб MyISAM (лок xtrabackup)

16. 31 марта 2016 года - план
• Запуск xtrabackup, вручную, без MyISAM части
• Перенос данных на слейв, поднятие слейва со
слейва
• Последующие бэкапы – остановка второго
слейва

17. 31 марта 2016 года - жизнь
• 31 марта, 02:00 – запуск xtrabackup

18. 31 марта 2016 года - жизнь
• 31 марта, 02:00 – запуск xtrabackup
• 31 марта, 02:00 – 1 апреля, 16:00 – рост (deleted)
redo-log-а

19. 31 марта 2016 года - жизнь
• 31 марта, 02:00 – запуск xtrabackup
• 31 марта, 02:00 – 1 апреля, 16:00 – рост (deleted)
redo-log-а
• 1 апреля, 16:00 – алерт «мало места на диске»

20. 31 марта 2016 года - жизнь
• 31 марта, 02:00 – запуск xtrabackup
• 31 марта, 02:00 – 1 апреля, 16:00 – рост (deleted)
redo-log-а
• 1 апреля, 16:00 – алерт «мало места на диске»
• 1 апреля, 17:00 – ответственный администратор
не знает о redo-log-е, решает чистить (deleted)
xtrabackup, создает скрипт для зануления file-
handler-а с (deleted)

21. 31 марта 2016 года - жизнь
• 31 марта, 02:00 – запуск xtrabackup
• 31 марта, 02:00 – 1 апреля, 16:00 – рост (deleted)
redo-log-а
• 1 апреля, 16:00 – алерт «мало места на диске»
• 1 апреля, 17:00 – ответственный администратор
не знает о redo-log-е, решает чистить (deleted)
xtrabackup, создает скрипт для зануления file-
handler-а с (deleted)
• 1 апреля, 18:00 – ответственный администратор
запускает скрипт

22. 31 марта 2016 года - жизнь
• 31 марта, 02:00 – запуск xtrabackup
• 31 марта, 02:00 – 1 апреля, 16:00 – рост (deleted)
redo-log-а
• 1 апреля, 16:00 – алерт «мало места на диске»
• 1 апреля, 17:00 – ответственный администратор не
знает о redo-log-е, решает чистить (deleted)
xtrabackup, создает скрипт для зануления file-
handler-а с (deleted)
• 1 апреля, 18:00 – ответственный администратор
запускает скрипт
• 1 апреля, 18:00 – сайт недоступен

23. 1-2 апреля 2016 года - спасение
• 1 апреля, 18:00-18:30 – mysql упал и не
запускается

24. 1-2 апреля 2016 года - спасение
• 1 апреля, 18:00-18:30 – mysql упал и не
запускается
• 1 апреля, 18:30 – зануленный file handler был
ibdata процесса mysql

25. 1-2 апреля 2016 года - спасение
• 1 апреля, 18:00-18:30 – mysql упал и не
запускается
• 1 апреля, 18:30 – зануленный file handler был
ibdata процесса mysql
• 1 апреля, 19:00 – остался скопированный
нагорячую ibdata в куске xtrabackup дампа

26. 1-2 апреля 2016 года - спасение
• 1 апреля, 18:00-18:30 – mysql упал и не
запускается
• 1 апреля, 18:30 – зануленный file handler был
ibdata процесса mysql
• 1 апреля, 19:00 – остался скопированный
нагорячую ibdata в куске xtrabackup дампа
• 1 апреля, 20:00 – компания data recovery mysql
отказывается работать в такой ситуации

27. 1-2 апреля 2016 года - спасение
• 1 апреля, 18:00-18:30 – mysql упал и не
запускается
• 1 апреля, 18:30 – зануленный file handler был
ibdata процесса mysql
• 1 апреля, 19:00 – остался скопированный
нагорячую ibdata в куске xtrabackup дампа
• 1 апреля, 20:00 – компания data recovery mysql
отказывается работать в такой ситуации
• 1 апреля, 21:00 – блогпост о восстановлении
через gdb

28. 1-2 апреля 2016 года - спасение
• 1 апреля, 18:00-18:30 – mysql упал и не запускается
• 1 апреля, 18:30 – зануленный file handler был ibdata
процесса mysql
• 1 апреля, 19:00 – остался скопированный нагорячую
ibdata в куске xtrabackup дампа
• 1 апреля, 20:00 – компания data recovery mysql
отказывается работать в такой ситуации
• 1 апреля, 21:00 – блогпост о восстановлении через
gdb
• 1 апреля, 21:00 - 2 апреля, 03:00 – попытки запуска,
успешный запуск в recovery mode

29. 1-2 апреля 2016 года - спасение
• 1 апреля, 18:00-18:30 – mysql упал и не запускается
• 1 апреля, 18:30 – зануленный file handler был ibdata
процесса mysql
• 1 апреля, 19:00 – остался скопированный нагорячую
ibdata в куске xtrabackup дампа
• 1 апреля, 20:00 – компания data recovery mysql
отказывается работать в такой ситуации
• 1 апреля, 21:00 – блогпост о восстановлении через
gdb
• 1 апреля, 21:00 - 2 апреля, 03:00 – попытки запуска,
успешный запуск в recovery mode
• 2 апреля, 03:00 – 3 апреля, 06:00 - mysqldump

30. Что случилось?
• Ответственный администратор, добавляя
системе свободного места, путем
зануления(deleted) file-handler-а удалил ibdata
mysql

31. В чем причина?
• Недостаточная информированность о работе
xtrabackup
• Отсутствие чеклиста и дополнительного
контроля
• Нестандартная операция, о которой не были
проинформированы сотрудники

32. Как сделать так, чтобы такого
никогда не было?
• Избегать нестандартных операций
• Если они происходят – работа одной группой
• Непонятная проблема – доложить менеджеру
• Рискованная операция – двойной контроль

33. Ошибки в процессе
Январь 2017

34. Январь 2017 - жизнь
• Для подготовки к кибервторнику утром и днем
на production-серверах проводится нагрузочное
тестирование на разладку.

35. Январь 2017 - жизнь
• Для подготовки к кибервторнику утром и днем
на production-серверах проводится нагрузочное
тестирование на разладку.
• Дежурный администратор отмечает в заметках
«проблемы с открытием страниц на проекте ABC
- ОК»

36. Январь 2017 - жизнь
• Для подготовки к кибервторнику утром и днем
на production-серверах проводится нагрузочное
тестирование на разладку.
• Дежурный администратор отмечает в заметках
«проблемы с открытием страниц на проекте ABC
- ОК»
• В момент рассылки кэш страницы акции
отключен, сайт периодически недоступен весь
вечер и ночь

37. Что случилось?
• Дежурный администратор, выйдя на смену,
прочитал сообщение и получил подтверждение
от предыдущего дежурного о легитимности
алертов на время открытия страницы и не
реагировал на проблемы

38. В чем причина?
• Отсутствие процесса валидации сообщений в
системе мониторинга при пересмене

39. Как сделать так, чтобы такого
никогда не было?
• Дежурный менеджер присутствует при
пересмене
• Любые критические оповещения – получить
подтверждения у дежурного менеджера
• Дежурный менеджер валидирует текущие
сообщения в системе мониторинга

40. Ошибки взаимодействия
5 октября 2017 года

41. 5 октября - жизнь
• Сотрудник отдела разработки мониторинга
попросил дежурного администратора
выключить модуль на production-сервере
клиента. Продажи в мобильном приложении не
шли 6 часов.

42. Что случилось?
• Сотрудник отдела разработки мониторинга
попросил дежурного администратора
выключить модуль на production-сервере
клиента. Продажи в мобильном приложении не
шли 6 часов.

43. В чем причина?
• Дежурный администратор ожидал, что
отключение согласовал разработчик, а
разработчик ожидал, что отключение согласует
дежурный администратор

44. Как сделать так, чтобы такого
никогда не было?
• Любое ожидаемое действие должно быть
подтверждено.

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