HighLoad++ 2017 Зал «Пекин + Шанхай», 8 ноября, 12:00 Тезисы: http://www.highload.ru/2017/abstracts/3025.html Технологические команды разного размера рано или поздно сталкиваются с тем, что возникающие проблемы становится сложнее контролировать. Какие-то события возникают сами по себе, какие-то – "благодаря" человеческому вмешательству, – или что-то идёт не так после заранее запланированных работ. ...

1. Инцидент-
менеджмент в Badoo
Илья Аблеев

2. О чём доклад?
✓Плановые работы
✓Инциденты
✓Информирование/оповещение
✓Постмортемы

3. Плановые работы
события или изменения, которые могут повлиять на что-то
или на кого-то

4. На случай важных переговоров
✓Можно сделать быстро, никто не заметит!
✓А заметит — я тут не в игрушки играю!
✓Не совершает ошибок тот, кто ничего не делает!

5. Плановые работы
✓Без них никак — нужно делать прод лучше
✓Плановые работы должны быть запланированы
✓Планировать время (дольше — лучше)
✓Если затянулось — предупредить

6. Зачем вообще сообщать?
✓Люди будут знать, что сервис может не работать
✓Можно предотвратить негатив (как технически, так и…)
✓Ответственнее подойдёте к процессу

7. ИНЦИДЕНТ
Незапланированные плановые работы — это

8. Инциденты
события, которые точно несут негативный эффект

9. На случай важных переговоров
✓Быстро починю, никто и не заметит!
✓Ну ладно вам, всего час не работало, зато до этого
год всё было окей!
✓Быстро поднятый сервер не считается упавшим!

10. Инциденты
✓Без них никак (обычно)
✓Портят жизнь и нервы коллегам
✓Могут портить жизнь пользователям – что-то не работает
✓Несут убытки бизнесу

11. Зачем о них-то сообщать?
✓Сгладить негатив
✓Признать вину: +100500 к доверию
✓Держать в курсе событий: ещё +100500
✓Вести учёт факапов — анализ в будущем
✓Уменьшать даунтайм похожих проблем

12. Уведомления

13. На случай важных переговоров
✓Бюрократы!
✓Есть вопросы? Пусть меня спросят, я им всё объясню!
✓Никогда такого не было, и вот опять…
✓Не волнуйтесь, такого больше не повторится.

14. Способы уведомлений
✓Письма — у всех есть корпоративная почта
✓Веб-интерфейс/API
✓SMS/мессенджеры
✓Календарь
✓Почтовые голуби? 🐦

15. Как уведомлять?
✓Чем раньше сообщить, тем лучше
✓Примерное время восстановления
✓ Публично — это обещание
✓ Приватно — это прогноз
✓Не успеваете починить – сообщите заранее

16. Да кто их читает?
✓Сначала — никто
✓Надо приучать людей читать
✓Приучать к тому, где им больше нравится видеть
информацию
✓Собирать фидбек — повышать качество оповещений

17. Уведомления – не отписка
✓Должно быть понятно
✓Технари должны объяснить нетехнарям
✓Нетехнари должны понять технарей
✓Можно описать технические детали

18. Уведомления – не отписка
✓Должно быть понятно? Карта сервисов
Сервис Функциональность Уровень критичности
Authorizer Процесс авторизации на сайте Высокий
UDB Самая главная база данных о
пользователях, недоступна –
не работает регистрация,
логин и тд
Высочайший
Queue processor Фоновый обработчик
очередей, напрямую на
пользователей не влияет, но
при длительной пролёжке у
пользователей могут
перестать обновляться важные
данные
Низкий

19. Как было у нас?
✓Простые письма в почту
✓Прикрутили календарь
✓Из календаря — SMS оповещения (точечно)
✓Устали писать руками: интерфейс на коленке

20. Как сейчас?
✓Интерфейс + API
✓Заводим инциденты автоматически из мониторинга
✓Разделяем несколько уровней деградации
✓Подсвечиваем все работы и проблемы на графиках

21. Постмортемы
работа над ошибками, описание и разбор случившихся
инцидентов

22. Как выглядит?
✓Пример: GitLab Postmortem of database outage Jan 31
✓Нафакапили, “сознались”, указали последствия,
разобрали технические детали

23. Цели постмортема?
✓публичное порицание ни в коем случае :)
✓Найти критичные проблемы и устранить их
✓Не повторять аналогичных ошибок в будущем
✓Повысить уровень ответственности среди сотрудников

24. Что до публикации?
✓Оценить негативные последствия или убытки
✓Восстановить таймлайн событий
✓Найти источник проблемы
✓Разобраться в технических деталях (от и до)
✓Подвести итоги: lessons learned

25. Залог успешного постмортема
✓Не доводить до абсурда (не писать на любой чих)
✓Таймлайн
✓Не винить конкретных людей / отделы
✓Сухие факты, меньше эмоций
✓Начинать писать сразу, пока свежи воспоминания
✓Писать должен непосредственный участник

26. Как постмортем выглядит у нас?
✓Что было, как выглядело для юзера?
✓Когда и в течение какого времени?
✓Как много пользователей затронуло?
✓Причины, техническое описание
✓Что делать, чтобы больше не повторилось?

27. Что было, как выглядело для юзера?
✓Простым и понятным языком
✓TODO: примеры

29. Когда и в течение какого времени?
✓Время всегда в единой таймзоне — UTC
✓И в едином формате: 2017-11-08 12:00
✓Нужно указать время начала и исправления
✓Можно — время полного восстановления

31. Как много пользователей затронуло?
✓Метрика, по которой оцениваем инциденты
✓Должна быть возможность быстро посчитать
✓Зачастую — очень размытая оценка
✓Либо что-то ломается совсем
✓Либо что-то деградирует частично

33. Причины, техническое описание
✓Организационные причины сюда же
✓Писать так, чтобы другие технари тоже поняли
✓Не лить воду
✓Нет “я”, есть “мы”, или "оно само" — обезличиваем
✓Коллеги и заинтересованные проверяют и дополняют

34. Таймлайн
✓Поймём, на что больше всего тратили времени
✓Как это время можно сократить?
✓Долгое оповещение или ресёрч — тоже часть
проблемы

36. Что делать, чтобы больше не повторилось?
✓Думать головой :)
✓Больше конкретики — список задач + дедлайны
✓Документация — это хорошо, но техническая
“защита от дурака” — лучше

38. Ещё немного успеха
✓Визуализация: графики или сломанный интерфейс
✓Вовлечь людей после публикации
✓Время публикации — важно (дедлайн 2 дня)
✓Коллаборация! (у нас Google Docs)
✓Ревью, публикация — Postmortem Manager

40. Нормально делай — нормально будет
✓Уведомляйте о плановых работах
✓Сообщайте об инцидентах
✓Не забывайте о качестве информирования
✓Пишите постмортемы

41. Вопросы?
ableev
[Telegram, Twitter, GitHub, Facebook]
Badoo Tech
https://badootech.badoo.com/
Badoo на Хабре
https://habrahabr.ru/company/badoo/