Комментарии 18
Задача типовая, пора привыкнуть.
3-4 источника требований и если исполнитель не понимает особенности всех этих областей, то перекидывает на уточнение тимлиду или архитектору.
Судя по описанной истории, Олег в этой компании - и швец, и жнец, и на дуде игрец. Как, впрочем, и во многих других компаниях.
Самое забавное что привыкнуть к бардаку можно, но релизы от этого быстрее выходить не станут. Пока не появится выделенный человек за среды, так и будут кидаться тикетами)
Мне кажется в этой статье маловато нейрокартинок.
Вы не думали вставлять по картинке через каждый абзац? Или может даже через каждое предложение, было бы вообще идеально.
Олег виноват. Он явно миддл. Синьер сразу понимает, чем пахнет эта задача. И что лучше замкнуть безопасников на тестеров, время от времени подкидывать нужные вопросы, подкидывать веток в костер
Даже скорее джун. По легенде он админ, а админы учатся посылать такие задачи в первый год (или не выживают в дикой природе).
А раз он джун, то директор должен был "обнять, приподнять" и выкинуть на мороз весь менеджмент ИТ (кроме Олега).
- Руководитель админов: не контролировал выполнение задач. У него сотрудник месяцами перерабатывает, ноль результат по мнению заказчиков и инциденты ИБ. Контуры прод/дев/qa не разделены (и я бы предложил делегировать многие задачи по администрированию dev/qa в dev/qa). Значимые ресурсы (алё - там 10 ТБ только одна копия) выделяются без подтверждению бюджетов. Диагноз: профнепригодность.
- Руководитель ИБ: рядовой админ не включая мозг и не спотыкаясь выносит из прода 10 ТБ с персданными. Об этом как-то узнаётся после развёртывания. Вы уволены нахрен.
- Руководитель разрабов: у вас админ должен разбираться в бизнес-логике и написании запросов с учетом бизнес-логики. По неактуальной документации. Релиз не выпущен (разработка в этом виновата по умолчанию). Может увольнять рано, но оргвыводы стоит сделать.
- Руководитель QA: принят релиз без инструкции по развёртыванию, нет сред тестирования (их обновление должно быть будничной задачкой QA), тестирвоание релиза сорвано. Методология тестирования "нам для тестов нужны прод данные" мягко говоря спорная, особенно с уточнением "прод но не совсем прод, а иногда и совсем не прод".
Если над всем этим есть еще PM/PO/CTO, то красные от стыда за управленческий бардак они заявление по собственному сами должны принести.
Первой пришла команда тестирования, и сразу выяснилось, что под словами «развернуть тестовую базу» все понимали разное.
Это новая задача. Вина Олега, в том, что он согласился на новые требования, и пустил QA в дамп. Дело не в процессе и комуникациях.
Что надо было сделать:
Возвращаем новые требования начальнику
Привязываем новые сроки к новым требованиям
Формулируем новые задачи, которые должны быть закончены до развертывания: бакап, секюрити и обфускация
Привязываем завершение задачи обфускации на подтверждение безопасников - пускать QA в дамп прода нельзя!
После этого можно брать задачу 'развернуть тестовое окружение' в работу.
В этой пьесе я почему-то не увидел реплик тимлида/того, кто ставил эту задачу.
Потому что сделать «еще раз такую же» для Олега означало повторить почти весь описанный путь заново.
А почему заново? Олег не записывал свои действия и потом удалил все скрипты которыми пользовался?
А если бы он на последнем шаге ошибся и сам бы всю базу испортил, он опять бы начал сначала конвертировать? Или у него должен был бы остаться бакап с предпоследнего шага, и он бы с него и продолжил?
Справедливое замечание, недораскрыл этот момент. Скрипты у Олега были (по крайней мере последние версии), но просто запустить их заново не сработало бы.
За время его первого захода схема БД на проде успела измениться, добавились новые таблицы со своими аномалиями. В тестовом стенде тоже что-то подкрутили и старый бекап разворачивался некорректно, поэтому пришлось брать свежий срез. Во-вторых, проблема была в самих скриптах: это был набор тяжеловесных запросов, которые дописывались прямо на ходу под вылезающие краевые случаи.
Так что начинал он, конечно, не с чистого листа, экспертиза уже накопилась, но технически он был отброшен обратно на этап подгонки скриптов и тяжелых экспериментов со свежей базой.
Знакомо..
"Разверни базу" - всегда ящик Пандоры. Пока у вас нет четкого SLA на тестовые среды и автоматического скрипта анонимизации, который прогоняется в CI/CD, каждый такой тикет будет мини-проектом
Ситуация - гордиев узел "на минималках". Всё же, ситуация требует довыяснения произошедшего: анализа требований, проверки коммуникаций. + Нужно понимание того, как выстроены процессы и система ответственности.
В первом приближении основными "виновниками" кажутся:
исполнитель,
менеджер курирующий задачу (ПМ или кто-то такой),
серьёзный изъян в рабочих процессах.
С QA ситуация не очень понятна. Если база тестовая, то логично, что её будут шатать. Другое дело "тестировщики случайно уронили базу" - как? : ) да ещё и вместе с бекапами. Тут напрашивается более внимательное изучение инцидента.
Мой опыт (тестирование и анализ требований) показывает, что тех.заданию редко стоит доверять. Иногда, самые дорогие задачи - это сформулированные <<на "отвали">> с позицией "и так всё понятно". В таких ситуациях формулировщик требований - тоже несёт частичную ответственность.
Очень смутило в этой истории: идея делать виноватым одного человека и тем более, транслировать это в чатах - довольно странно. Кстати, тоже звоночек более высокому руководству для изучения.
«Олег, разверни тестовую базу»: как таска на 5 минут сорвала финтех-релиз и поссорила три отдела