В этой заметке решил написать сказку на ночь. Все действующие лица вымышлены, а совпадения случайны.
Вводная.
Существует сложная высоконагруженная система с большим количеством пользователей.
Система имеет трех звенную клиент серверную архитектуру. Серверная часть включает сервер субд in-memory развёрнутый на нескольких нодах, и N серверов приложений.
В настоящий момент система проходит трансформацию в виде смены платформы и переноса унаследованного кода.
Смена СУБД и изменение архитектуры привело к возникновению ряда проблем с производительностью и устойчивостью/надёжностью работы системы.
При этом, как и в любой сложной системе, технические проблемы вызванные миграцией на новую платформу имеют разные причины.
В их числе можно выделить:
- Исходная конфигурация аппаратного обеспечения
- Настройка аппаратной(серверной) части и ОС/СПО.
- Настройка серверного ПО (СУБД in memory, серверов приложений, межсерверных сетевых взаимодействий)
- Адаптация унаследованного кода под изменившуюся архитектуру.
- Пользовательские настройки системы (на уровне Прикладного ПО)
Для комплексного анализа сложившейся ситуации и решения выявленных технических проблем создаётся группа высокопрофессиональных специалистов разного профиля. Для простоты будем называть её ГАРПия (Группа Анализа и Решения Проблем).
До этого момента все вполне традиционно и шаблонно. Впрочем так будет продолжаться и дальше 
С технической точки зрения вполне обычная ситуация.
Что меня заинтересовало в этой ситуации?
Организационная часть проблемы.
Предыдущее рассмотрение ситуации делалось из роли Технического специалиста (инженера) в широком смысле этого слова. Теперь попытаемся переключиться в роль Организатора(менеджера) и посмотреть на ситуацию с другого ракурса.
По понятным причинам, для реализации масштабного проекта миграции, у конечного заказчика нет требуемого количества ресурсов (специалистов) подходящей квалификации.
Поэтому для реализации проекта привлекается Исполнитель.
Настройка и развёртывание серверной части системы находится в области ответственности Заказчика. Проблемы возникают в момент проведения Нагрузочного Тестирования (НТ).
Группа анализа и решения проблем, простите, ГАРПия, состоит из технических специалистов и Руководителей Проекта со стороны Исполнителя и Заказчика.
Со стороны Заказчика отсутствует формально выделенный ответственный за процесс решения проблем.
Существует явный конфликт интересов между двумя менеджерами Исполнителя. Один из них отвечает за работоспособность технической части (назовём его Тех.менеджер) и заинтересован в скорейшей стабилизации системы . Второй отвечает за функциональность/бизнесовую часть (назовём его Функ.менеджер) и соответственно ответственен за тестирование/приёмку бизнес функционала.
Поскольку работа ГАРПии состоит из череды экспериментов, требует постоянного изменения настроек/кода системы и проведения Нагрузочного Тестирования, это неизбежно мешает Фунциональному Тестированию.
Да, физически система одна, НТ и ФТ проводятся на ней, и это вызывает постоянную конкуренцию за ресурс.
При этом, довольно забавно наблюдать, как Функ.менеджер периодически пытается встать в роль Тех.специалиста/Архитектора и влиять на принятие технических решений, за реализацию которых он не отвечает, и подозреваю, даже не понимает до конца всех последствия реализации своих пожеланий.
Тех.менеджер заказчика, грамотный технический специалист, хорошо ориентируется в своей области, но обладает двумя особенностями.
Во первых, периодически предлагает настолько радикальные технические решения, что даже у профессиональных специалистов Исполнителя которые привыкли “рвать зубы через задний проход” , они вызывают широкий спектр эмоций. От искреннего удивления, до полного неприятия.
Во вторых, с точки зрения организации процесса он проповедует режим полного аджайла. Формализация процесса не нужна, есть проблема, есть группа специалистов(пул ресурсов) .
Кидаем в чат скопированный кусок отчета/текста из специализированной программы диагностики состояния системы. Возьмите и решите. Такой подход обычно называется так: “ты профессионал/ка, реши проблему” или “сделай мне приятно”.
В целом, подход вполне рабочий для малых групп и небольшого количества проблем. Но в данном конкретном случае, размер команды ГАРПии вышел за эмпирический предел “мы можем накормить команду двумя пиццами”, а количество проблем требует более формализованного подхода с явным выделение очереди задач, описанным алгоритмом/методом обработки и передачи результата работ.
Какие возможные варианты развития событий я вижу?
К сожалению, на этом месте я понял что формат сказки грозит перерасти в производственный роман, а трекер pomodoro советует сделать перерыв. Поэтому первую серию на этом закончим.
Продолжение >> Сказка на ночь.ГАРПия или в чем проблема