Стабильность проекта в условиях непрерывной интеграции Организация работ на долгосрочных проектах Денис Митрофанов Генеральный директор QSOFT +7 (495)

Основные причины падений Сбой на уровне «железа» Сбой на уровне канала (хостинга) Сбой на уровне ПО (ОС, БД, web-сервер) Сбой на уровне Продукта Сбой от высокой неплановой нагрузки Сбой в результате обновления Продукта

Обновления – естественное состояние развивающегося проекта Мы знаем точно только состав одной версии Требования изменяются в результате опыта эксплуатации и изменений на рынке Нужно поддерживать работающую версию Нужно учитывать функционал и данные работающей версии при обновлениях

Почему нельзя сразу сделать все Нельзя спланировать и спроектировать на 5 лет вперед (3 года назад не было iPad) Изменения требований ко 2-й версии после запуска 1-й «Парадокс проектирования» (цена растет нелинейно от объема + точность)

Плохой код – тоже причина падений По мере развития проект превращается в «ласкутного монстра» Никто не знает как он работает и почему Доработка нового функционала требует нечеловеческих усилий Проект «ложиться» под нагрузками

Замкнутый круг Сайты чаще всего падают из-за обновлений Обновления неотъемлемая часть развития Развитие (изменения, переделки) порождает плохой код Чем хуже код, тем выше вероятность сбоя при обновлении

Как обеспечить стабильность растущего проекта? 1)Процессы отгрузок 2)Качество кода

Разделение на Минорные и Мажорные итерации (3-6 мес.) Рефакторинг Нагрузочное тестирование Доработка архитектуры, документирование Проблема «продажи» рефакторинга: нет видимого результата (важно чтобы у заказчика был технический специалист) + видимые метрики

Разделение производства и Поддержки. Культура отгрузок Разделение Производства и поддержки. Минорных и мажорных итераций Разные цели (KPI) и парадигмы Производства и Поддержки Отгрузки через отдел Поддержки

Не уверен – не отгружай! Независимый аудит кода перед отгрузкой Сфокусированная ответственность за отгрузку Регулярный выборочный контроль кода со стороны эксперта (тех директора) Автотесты План-тесты и таблицы связанного функционала (работа отдела качества)

Dev Local host 2 Local host 1 Local host N Stage Боевой

Тренируйтесь на кошках Частичная отгрузка на боевой – в идеале если пользуетесь сами или часть лояльных пользователей Отгрузка для части боевых пользователей (на выделенный сервер) Полная идентичность финального тестового стенда и боевого (включая окружение) Тестирование на реальных данных Отгрузка одной кнопкой

DNS Балансировщик Node 1 Node 2 Node N Типовая схема

DNS Балансировщик Node 1 Node 2 Node N Stage Отключаем одну ноду и обновляем со Stage

DNS Балансировщик Node 1 Node 2 Node N Тестовый трафик Включаем ноду в тестовом режиме

DNS Балансировщик Node 1 Node 2 Node N Раздаем изменения с обновленной ноды

Надежность и быстродействие Откуда проблема: нельзя иметь 30-ти кратный запас по «железу» - все свободные ресурсы «отъест» плохой код Ограничения по железу при разработке Запуск нового для части трафика на отдельной ноде

Стабилизация команды. Сохранение культуры Люди устают, один проект надоедает, деньги не мотивируют Своевременная передача знаний и культуры, а не удержание любой ценой 5-ти человек 5 лет Команда 5-10 человек, 2 архитектора Стабильный поток объемов

Вопросы? Митрофанов Денис Спасибо за внимание!