Как и в любой другой практике, в DevOps есть свои разрушительные антипаттерны.
И некоторые из них, такие как знаменитый антипаттерн «Герой», описанный ниже, поначалу кажутся отличным решением, но в конечном итоге ведут к провалу.
Разберемся, как распознать подобные антипаттерны, откуда они берутся, и как не дать им уничтожить ваши DevOps-проекты.
В разработке программного обеспечения паттерн - шаблон решения определённых задач. Иногда этот шаблон появляется уже после создания программного обеспечения, а иногда конкретные проблемы предполагают реализацию определенного шаблона.
Антипаттерн - это паттерн, который вы применяете для решения проблемы в краткосрочной перспективе в ущерб достижению долгосрочных целей. Коварство антипаттернов не в том, что они не работают вообще, а в том, что работают они в краткосрочной перспективе, становясь причиной проблем в будущем.
Из огня да в полымя, как говорят.
Люди используют антипаттерны, потому что антипаттерны решают поставленную задачу в коротком отрезке времени. Проблема же возникает, когда антипаттерн становится новой нормой, и команда останавливается на нем. Способность осознать, что вы используете антипаттерн, и понять, как избавиться от него, является ключевым навыком для постоянно совершенствующихся команд.
Если вы вынуждены использовать антипаттерн, у вас также должно быть понимание того, что вам необходимо сделать, чтобы как можно скорее отказаться от него.
Рассмотрим классический антипаттерн «герой», когда один человек или небольшая группа прилагают невероятные усилия, чтобы выполнить проект, обычно работая сверхурочно, чтобы завершить проект в срок.
Дабы уложиться в установленные сроки, команда может использовать нестандартный или опасный код. В некоторых сферах индустрии паттерн героя не только используется, но и приветствуется. Быть “героем” проекта - почетное звание. И бывают моменты, когда командам действительно нужны герои.
Но этот антипаттерн несет за собой долгосрочные последствия. К ним относятся выгорание и возникновение негативных взаимоотношений между членами команды. Последние часто происходят из-за негодования «героев», якобы спасших проект, что остальные не пошли на те же жертвы.
Когда в итоге “герои” выгорают и покидают компанию, как правило они не оставляют информации о проделанной работе. Потому как изо всех сил пытаясь закончить все в срок, многие вещи, такие как тестирование и документация, они упускают. Это приводит к снижению качества софта и к потере уверенности стейкхолдера как в этом софте, так и в способности команды приносить ценность.
Во многих случаях геройский антипаттерн - результат плохого управления, когда работа планировалась без учета возможностей команды. У команды была задача сделать больше, чем следовало ожидать, учитывая график. Это происходит по многим причинам, включая нормативные требования, нереализуемые ожидания стейкхолдеров, бюджетные ограничения и непредвиденные проблемы.
Один из способов избежать потребности в героях - выстроить качественное управление сроками решения задач и ожиданиями. Это может быть непростой задачей, но это способ достичь поставленных целей и не привести команду к выгоранию.
Еще один способ не нуждаться в героях - провести анализ рисков проекта и определить, что может стать причиной срыва сроков. Это позволит команде включить снижение рисков в план работы. Кроме того, это поможет команде заранее оценить задачи, выходящие за рамки оптимистичного прогноза.
Вы также можете провести оценку с использованием определенного диапазона, не ожидая от нее абсолютной точности. Многие agile-команды используют числа Фибоначчи для оценок как раз по этой причине; цель такой оценки - смоделировать возможность ее изменения.
DevOps не застрахован от антипаттернов, и непрерывная сборка (Continuous Building, CB) является одним из таких примеров. Это то, что у вас происходит, когда вы настраиваете сервер непрерывной интеграции (Continuous Integration, CI), фактически не имея набора юнит-тестов или выполняя анализ качества кода на базе кода. Вы создаете программное обеспечение при каждой итерации.
(Для уточнения: CB - это подмножество CI, в котором вы выполняете только первую часть CI, а именно сборку. CI включает сборку, модульные тесты и статический анализ качества кода.)
Антипаттерн CB часто используется с устаревшими приложениями или при переходе команды к Agile и DevOps. Часто все начинается с благих намерений - вы решаете установить CI-сервер и приступить к созданию тестов. Дабы не пугать людей метриками качества кода с кучей проблем, которые вы считаете незначительными, вы решаете установить метрики после того, как почистите код.
Обсуждая с командой эту ситуацию, вы часто слышите, что «сейчас намного лучше, чем было». И зачастую так оно и есть. Лучше иметь непрерывную сборку, когда вы знаете, правильно ли компилируется и упаковывается ваше программное обеспечение, чем собирать раз в неделю, месяц или реже и беспокоиться о компиляции программного обеспечения после неопределенного количества изменений.
Раньше проекты проваливались, потому что огромные их части реализовывались изолированно, и разногласия не удавалось устранить в разумные сроки. Но то, что сейчас дела обстоят неплохо, не означает, что не может быть еще лучше.
Цель CI - обеспечить уверенность в том, что вы можете объединить код, написанный разными членами команды, скомпилировать его и продолжить работать так, как было задумано автором кода. Это невозможно без тестов, и зачастую юнит-тесты - отличное решение.
Цель выбора шаблона непрерывной сборки в CI - вернуть эту уверенность в процесс, используя юнит-тестирование и анализ качества кода. Добейтесь того, чтобы ваша команда,владелец продукта и партнер согласовали изменение ваших практик для увеличения охвата юнит-теста кода в дальнейшей перспективе.
Добейтесь также того, чтобы технический долг по качеству кода был со временем выплачен, ведь долг платежом красен. Помните, что технический долг возникает не сразу, а постепенно, поэтому и выплачиваться он тоже будет не сразу. Но без желания отдать технический долг, он так и останется с вами. Навечно.
Многие организации начинают свой путь в DevOps с добавления нового отдела, который становится посредником между dev’ами и ops’ами. Это превращается в антипаттерн, когда компания перестает объединять dev’ов и ops’ов в единую команду, сохраняя лишь DevOps-отдел.
Создание отдельного DevOps-отдела, используемого в долгосрочной перспективе, является антипаттерном.
Когда DevOps-отдел создан, целью должно стать сближение команд dev’ов и ops’ов для сознательного взаимодействия. У DevOps-отдела должно быть четко определенное время жизни как часть этапа трансформации. Рамки его существования должны быть регламентированы, скажем, от одного до трех лет, а по истечении этого времени отдел расформировывается.
По истечении трех лет организация DevOps должна иметь такую структуру.
Фактически, вся компания должна быть заинтересована в преобразовании, необходимом для того, чтобы потребность в DevOps-отделе отсутствовала. Команды dev’ов и ops’ов должны пересекаться друг с другом, а работа DevOps выполняться на этом пересечении.
Это то, что происходит, когда офисная политика накладывается на DevOps. Случается это, когда определенные функции не автоматизируются из-за того, что люди, отвечающие за эту функцию, по какой-либо причине не хотят включать автоматизацию в свою область ответственности. То, что они становятся узким местом, - не их проблема.
Чтобы добиться максимальной пользы от автоматизации, вам необходимо использовать определенные критерии при выборе того, что вы будете автоматизировать. Основаны они могут быть на наиболее повторяющихся проблемах, наиболее рискованных этапах процесса, где автоматизация сможет обеспечить высокий ROI.
Выбрав эти критерии, вы должны придерживаться их и автоматизировать процессы на основе их приоритета. Автоматизация задач с низким приоритетом снижает эффективность процесса, поскольку это создаст очередь из критически важных задач, в то время как менее приоритетные задачи будут решаться первоочередно.
Мы рассмотрели четыре особенно опасных антипаттерна, но их существует гораздо больше. По мере того, как DevOps становится основной методологией разработки программного обеспечения, вы можете научиться распознавать антипаттерны и избегать их. Поначалу они могут казаться разумным решением, однако в конечном итоге они обязательно станут разрушительны для вашей команды и вашей компании.
Запишитесь на вебинар
Расскажите о вашем проекте, мы свяжемся с вами
и вместе рассчитаем стоимость в индивидуальном порядке.
Давайте обсудим ваш проект
и разберемся, как мы можем вам помочь
Остались вопросы?
Мы перезвоним и ответим на них!
Спасибо, ваши данные успешно отправлены!
Мы свяжемся с вами как можно скорее
