Управление highload-проектами 24 на 7

Управление highload-проектами24 на 7

Юрий Гугниндиректор по производствуADV / web-engineering co.

Кто я?

Юрий Гугнин

Директор по производствуADV/web-engineering co.

gugnin@adv.rufacebook.com/goognin

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

gugnin@adv.ru facebook.com/goognin

Спасибо за внимание!