Если команды большие то уже наверное я бы искал варианты разделить свою роль.
Уже хотелось бы отдельно ba и может даже не один, уже можно лид qa выводить и выделять отдельную integration team (по типу integration team в nexus) чтобы вопросы технического анализа шли с опережением и со стабильно равномерной проработкой задач.
Задачи по др, приездам и всему такому ещё можно делегировать hr и travel manager если такие предусмотрены.
Правда комментарий немного дальше чем тема статьи.
В моем представлении работу менеджера можно разделить на условно администрирование (операционное управление проектом и его связями с внешним миром относительно проекта) и управление производством (процессы разработки, часто vision sharing, ba, часто части роли po).
Сильные команды сами понимают язык бизнеса и могут отвечать техническими решениями. А командам, которые ещё стремятся к этому, надо немного помогать.
Здесь я имею ввиду, что когда все понятно и организованно, менеджер может уделить больше внимания интеграции и деливери. Что хорошо в общем то.
Спасибо
У меня девопсы хорошо справляются с
— описание инфраструктуры и ее использования
— описания архитектуры (если еще не записал никто)
— администрирование проекта (хотя часто может и qa)
И в таком духе.
Ой, так это же любой менеджер иногда так поступает. По разным на то причинам.
Главное своевременно понять что что-то не так и почему.
Вот прямо так взять и выдать ссылку на статью затрудняюсь.
Помню что когда пытался разобраться в чем дело откопал на инглиш статью на тему блокировок.
Тестировал.
Если просто сделать в цикле короткие select и короткие update много раз — все чтение с изменяемой таблицы приостанавливается, т.к. пока идут короткие селекты большие не успевают отработать.
Пришел к выводу, короткие апдейты часто — не плохо, как и селекты.
Плохо чередование много раз.
Не согласен. Не получается так.
Лок на строку все равно не даст сделать select ... where
В MySQL основная проблема с запросами типа INSERT/DELETE/UPDATE в том, что при сколь угодно коротком запросе происходит блокировка всей таблицы. А это в свою очередь означает, что пока будет выполняться любой из этих запросов никакие другие происходить не будут.
В целом, если запросов такого плана мало и они происходят не очень часто, то проблема с конкурентным доступом в таблицы легко решается с LOW PRIORITY.
В таком случае все INSERT/DELETE/UPDATE будут дожидаться, пока выполнятся все запросы типа SELECT и потом будут выполняться сами, а если в очереди появится другой SELECT пока INSERT/DELETE/UPDATE ждет, то он тоже пойдет на конвеер. Тут можно ориентироваться на продолжительность самого длинного и среднего запроса в БД. Как правило, максимальная задержка INSERT/DELETE/UPDATE может составлять около
Однако надо учитывать один существенный момент:
Если у Вас по каким-либо причинам происходит чередование SELECT и INSERT/DELETE/UPDATE, то никакие LOW PRIORITY Вас не спасут, очередь будет очень быстро заполняться из череды коротких запросов, а все остальное будет ожидать. На фронте это, как правило приводит к тому, что сайт долго генерирует страничку, т.к. сравнительно тяжелые пользовательские запросы постоянно стоят в очереди, дожидаясь снятия блокировки таблиц. А при коротком снятии блокировки их выполнение не успевает завершиться, и запрос снова попадает в очередь на ожидание.
С моей точки зрения я бы предложил перейти на PostgreSQL с тем, чтобы на корню решить проблему конкурентности. С точки зрения PHP это не должно быть сложным ввиду того, что базовые запросы примерно совпадают. Надо будет только чуть чуть подшаманить запросы.
В случае, если — же вопрос стоит таким образом, что переход не предусматривается — тут на мой взгляд вариант только один — избегать чередования запросов типа SELECT и INSERT/DELETE/UPDATE.
Относительно оптимизации СУБД
По моей практике оптимизация СУБД в MySQL дело не сложное. Работы по оптимизации надо вести под нагрузкой. Идеально — когда нагрузка растет по мере роста посещаемости сайта.
А все потому, что Вам будет понятно поведение СУБД только тогда, когда начнут формироваться очереди из запросов и их можно будет спрофилировать с тем, чтобы далее уже настраивать и оптимизировать.
А на стадии разработки оптимизация СУБД есть оптимизация PHP кода и запросов.
Абсолютно согласен.
Здесь я вежливо намекаю, что не все коллеги правильно понимают и используют принципы аджайл. Довольно часто встречаюсь с тем, что менеджеры замыкают все на себе.
Вместо прокси менеджера будет мидл-мен, что приводит к искажениям и потере информации.