Upload
advweb-engineering
View
386
Download
3
Embed Size (px)
DESCRIPTION
Доклад Юрия Гугнина, директора по производству ADV/web-engineering, на крупнейшей российской интернет-конференции Неделя Российского Интернета.
Citation preview
Управление highload-проектами24 на 7
Юрий Гугниндиректор по производствуADV / web-engineering co.
ADV?
Одна из крупнейших отечественных компаний на рынке разработки и развития интернет-решений с 1997 года
High-load проекты: http://vtb24.ru/ http://eldorado.ru/ http://lotopobeda.ru/ http://panasonic.ru/
Платформы:1С-BitrixMS SharePoint
Hiload-проекты сделаны давно
И их очень опасно переделывать с нуля
Почему hiload-проекты переделывать опасно?
—Невозможно описать весь функционал
—Постоянно появляются новые фичи, и их приходится делать в двух версиях
—Практически невозможно безболезненно обкатать новую систему в условиях высоких нагрузок и 24-часовой доступности
Выход – рефакторинг
Почему рефакторинг?
—Проект постоянно работает и приносит доход
—Новые фичи легко интегрируются
—Минимум стресса при публикации новых версий
Команда
Главное – команда
—Постоянная и выделенная—Сработанная—С четкими ролями—Но с возможностью
взаимной замены игроков
Менеджеры
— Да, их нужно двое— Один делает крупные задачи— Второй – задачи поменьше— О, чудо, они могут ходить в отпуска
— Собирают задачи с клиента— Управляют бюджетами— Управляют требованиями— Принимают решение о релизах
Тимлид
— Собирает с клиента задачу— Планирует итерацию— Распределяет задачи по команде— Мержит— 30% времени пишет код сам— Проверяет чек-листы на тестирование— Принимает решение о релизах
Архитектор
— Консультирует— В отдельном потоке
решает сверхсложные задачи (нагрузочное тестирование, «магические зависания»)
Админ
— Публикует на реальную зону— В отдельном потоке
решает сверхсложные задачи (нагрузочное тестирование, «магические зависания»)
Разработчики
— Их должно быть минимум двое (отпуска, болезни, свадьбы и т.д.)
— Они оба должны знать всю систему— Если нет отдельного разработчика
на мелкие задачи – вводится дежурство
Тестировщики
— В идеале их должно быть столько же, сколько разработчиков
— Как минимум нужен один, но постоянный
— Пишет чек-листы— Проверяет по ним вручную— Делает автотесты
Клиент
— Помогает команде собирать требования
— Участвует в планерках— Защищает результаты работ— Выделяет ресурсы в своей компании
Рабочий процесс
2-недельные итерацииРабота тимлида
2 нед.1 нед.
Хотфиксы предыдущей итерации
Сбор требований и планирование на следующую итерацию
Разработка текущей итерации
Мерж, тестирование, публикация
2-недельные итерацииРабота тестировщиков
2 нед.1 нед.
Тестирование предыдущей итерации
Написание чек-листов на текущую итерацию Тестирование Тестирование x2
3-звенная архитектура
—Максимум безопасности—Минимум доступов—Желательно немецкий хостинг
3-звенная архитектураTest
—Лежит где угодно—Нужен для внутреннего тестирования—SSH-доступ и доступ в CMS для всех
3-звенная архитектураStage
—Лежит в окружении, максимально близком к боевому
—Рабочая копия боевого сервера—SSH-доступ имеет админ и тимлид—CMS-доступ
—Админский у тимлида—Контентный у контент-менеджеров
3-звенная архитектураProd
—SSH-доступ имеет админ—CMS-доступ
—Админский у руководителя отдела—Контентный у контент-менеджеров
Дежурство
—4 дежурных в режиме «сутки через трое»
—Или использование разных часовых поясов
—Обязательные инструкции на случай аварии
Риски
—Хостинг от другой компании
—Вторая команда разработки
—Доступы к prod у клиента
?
Контактная информация:Юрий ГугнинДиректор по производствуADV/web-engineering. co
[email protected] facebook.com/goognin
Спасибо за внимание!