Мониторинг и SLA в проектах с постоянным деплоем
Александр Горник, Mindbox (Москва) Начал карьеру программистом в 2004м, а с 2007го года строю собственную компанию - Mindbox. В числе реализованных проектов: социальные сервисы mtv.com, потребительские CRM системы для Балтики, Danone и JTI. Решаю проблемы роста компании и перехода к продуктовой разработке: занимаюсь настройкой процессов разработки, масштабированием архитектуры, видением и бизнес-моделью продукта, финансовым и кадровым планированием. Я расскажу о пятилетней эволюции систем мониторинга saas приложения с высокой нагрузкой и доступностью. Как в условиях постоянных выкладок мониторятся ошибки, доступность, инфраструктура и производительность. Про реально работающий SLA с существенными финансовыми гарантиями. Всё это на примерах из жизни и с картинками. Доклад будет полезен всем кто собирается строить saas приложения или просто сталкивается с поддержкой сложного нагруженного решения в жизни. Теперь всё это называется модным словом devops.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von Magneta AI
Mehr von Magneta AI (20)
Hinweis der Redaktion
- О чем буду рассказывать?В такой последовательности мы развивались Как идти к SLA? Нужно быть уверенным что все реально работает сотни тысяч рублей в месяц компенсация (в худшем случае)
- Начали с мониторинга ошибок, конечно, еще до SLA. Я задался вот такими вопросами.Без тестеров и тяжелого процесса Q&A.
- Вообще, постмодерация это круто (Европа) а премодерация – почти всегда не круто (Россия). Это культурная разница. Нет задачи каждый раз построить ядерный реактор или ракету. Есть мнение у нас инженерная культура сильно подтверждена влиянию советского АПК и соответствующего образования.
- Капитан очевидность.
- В конце: Давит особенно на тех, у кого zero inbox
- Ошибки запроса: (помолимся за это).
- Валидация ввода или ошибка: на уровне модели?404? для POST / GET, REST / WebChangeConflict:не всегда исправляетсяИнтеграция UI FW: ошибки парсинга запросаAjax запросы: как выводить ошибку на клиентеРазные сообщения для конечных пользователей и программистов api
- Логгер должен быть хороший: нагрузка, потоки, падение веб сервера..перфомансНаписать базу ошибок оказалось сложно: перфоманс, хорошая группировка, юзабилити
- Что важно? Важно то, что сразу в багтрекер всё класть очень трудно – заспамит. Первые несколько лет мы далеко не на 100% ошибок реагировали моментальными фиксами. Скорее обсуждали причины, правила обработки чинили и прочее.Поэтому багтрекер это именно эволюция, а не просто сразу взять и сделать.
- Алгоритм группировки: не спамить, но и не терять повторныеНеприятный момент с общим кодом – много проектов на одной кодовой базе – дублирующиеся ошибки. Пока забили, т.к. деплой не одновременно
- Засад на самом деле почти нет
- См. пример с Diablo 3
- Судиться никто не будет, если не миллионы на кону
- Очень кратенько, пока есть время, остановлюсь на содержимом документа
- Что значит всё возвращает ошибку? Что считать дружественной ошибкой а что нет?ТЗ – а есть ли у вас ТЗ? Agile контракты? Засада!!!