12 Анти-Паттернов Devops

Это философия.

Это образ мышления.

DevOps поддерживается процессами и инструментами.

DevOps, по данным Джин Ким , основан на трех основных принципах, известных как «Три пути».

Первый способ подчеркивает эффективность всей системы — потока создания ценности.

Второй способ говорит о сокращении и ускорении цикла обратной связи.

Третий способ заключается в создании культуры, которая способствует непрерывному обучению и пониманию.

Неплохо.

У вас есть процесс разработки программного обеспечения, который соответствует ценностям DevOps, но Agile не означает, что вы внедрили DevOps. DevOps передает agile-ценности отделу администрирования, позволяя оптимизировать поток задач, поступающих к администраторам, и позволяя этому потоку идти дальше к клиенту, превращая задачи в ценность для конечного пользователя.

МГР: «Уже сделано, сегодня утром мы поменяли вывески на дверях отделения.

Мы настолько круты, что теперь у нас есть 2 команды DevOps».

Ну супер просто.

И я уверен, что у вас сейчас много DevOps-инженеров.

Если вам повезет, они могут сесть рядом с вами за обедом.

Я очень прошу тебя.

Уже? Отличная работа! Вы внедрили DevOps. Фактически, то, что вы только что сделали, создало еще один бункер.

Теперь у вас есть еще одна команда, которую вам нужно попытаться интегрировать в текущий процесс.

Еще одна команда, окруженная стенами, которые нужно разрушить.

Может, нам стоит вернуться, сделать ребрендинг, создать 3 DevOps-команды и стать супер-крутыми? DevOps — это не вытягивание нескольких человек из отдела разработки и администрирования и объединение их в новую команду.

Вы должны принять и реализовать.

Объедините команду разработчиков с командой администратора или наоборот. Вам необходимо полностью разрушить барьеры/стены/охрану между командами и сформировать их в единое целое с общими целями и обязанностями.

Это означает, что развитие становится более важным, потому что развитие стоит на первом месте.

проблемы? DevMgr — «?-э, мы сейчас занимаемся DevOps. Моим ребятам нужно научиться работать на производстве».

OpsMgr — «?-э-э… хорошо.

Так кто же будет разрабатывать код? „ DevOps — умное слово.

Это производное.

Это означает, что это сочетание двух слов, образующее новое слово, которое придает новое значение.

Это даже имеет некоторую эффективность.

Это не значит, что мы взяли слово «операции» и заменили его словом «разработка».

Так почему бы вам не попробовать использовать DevOps именно таким образом? DevOps требует, чтобы обе команды использовали свои основные навыки.

И они поделились тем, что должно быть общим для совместной работы.

Узнайте, чему необходимо научиться, чтобы улучшиться.

Это не означает переподготовку.

Это не означает кросс-функциональности (однако это может быть и положительным побочным эффектом).

Это означает предоставление обратной связи и прозрачности для улучшения.

DevOps — это как медаль, которую нужно выиграть.

DevOps — это больше, чем просто красивое слово.

Это состояние ума.

Вы должны принять его ценности, вы должны помочь другим принять его ценности, и вы должны постоянно совершенствоваться сами и помогать другим совершенствоваться, чтобы добиться успеха.

Как только вы отбросите все свое эго и начнете работать вместе, вы сможете заставить людей думать, что слово «DevOps» действительно может звучать круто.

По сути, вы заставляете свою команду разработчиков и администраторов работать вместе.

Они что-то курят, а затем приносят в жертву курицу.

Как только вы это сделаете, ваша организация никогда не будет прежней.

Вы сможете доставлять программное обеспечение быстрее, чем когда-либо прежде.

Конфигурация будет самоуправляемой.

Ваши инструменты развертывания станут интеллектуальными.

Ваши команды разработки и администрирования почувствуют гармонию.

Сделай это.

DevOps — это тяжелая работа! Для большинства это требует изменения культуры! Это одна из самых трудных вещей, которых вы когда-либо пытались достичь.

Для опытных разработчиков и администраторов, с которыми вы пытаетесь это сделать, это будет похоже на стояние на голове.

Не пытайтесь сделать это в одночасье, иначе вы потерпите неудачу.

DevOps не контролируется разработка.

DevOps не контролируется администрация.

Если вам нужна среда разработки, хорошо, создайте ее.

Только не называйте это DevOps. Потому что это не так.

Взгляните на эту статью как пример .

«В DevOps программисты остаются программистами».

- Точно! «Аналогично и в DevOps администраторы есть администраторы».

- Мы уже готовы! «Традиционно задача доставки программного обеспечения в производство входила в обязанности администраторов или команды разработчиков».

Подождите минуту.

«Администраторы создают стратегии развертывания, чтобы минимизировать время простоя и обеспечить стабильность за счет гибкости и оперативности».

Да, мы вернулись на знакомые рельсы.

и тут бац! «Управление релизами через разработку» — WTF? Ситуация ухудшается «Управление релизами в процессе разработки использует другой подход и смотрит на то, как развертывания могут происходить как можно чаще и проще.

Однако такое внедрение не обязательно происходит в производстве.

С точки зрения процесса, к непрерывной доставке предъявляются два больших требования: во-первых, сам процесс должен быть устойчивым за пределами разработки.

Это означает, что он должен быть устойчивым, как и любой процесс, который может реализовать традиционная команда администраторов».

Нет. Нет. Нет. Неж.

На.

Нее.

Нейн.

Развитие может быть процессом.

Это просто не DevOps. Заменять администраторов автоматизированным процессом развертывания — нонсенс.

Нет? Итак, вы самый удивительный оперативник на планете.

Если бы Чак Норрис был администратором, он был бы вами.

Кто-то недавно сказал мне, что они не могут заниматься DevOps, потому что «у них не те разработчики и администраторы…».

Есть ли у них разработчики, которые не умеют писать код? Я подумал про себя: «В моей компании плохие разработчики — люди, которые не умеют программировать, они работают в отделе кадров и маркетинге!» DevOps способствует сотрудничеству между разработкой и администрированием.

Такое сотрудничество должно развиваться на уровне политики всей компании.

И не говорите, что на вас работают «не те» люди.

Вы просто не умеете их готовить.

Борись с этим.

Ты трахал себя.

Ну и что? Мы все это делаем.

Но теперь вы хотите, чтобы ваши администраторы встали с постели в 2 часа ночи и начали убирать то, о чем они ничего не знают. Они администраторы, а не «уборщики», как Майкл Клейтон.

Ждать возникновения ошибки во время развертывания, чтобы инициировать связь между разработчиками и администраторами, — отстой.

Для этой проблемы уже слишком поздно.

но, возможно, не для следующей.

У вас есть команда разработчиков и администраторов, которые разговаривают (или спорят в 2 часа ночи) друг с другом, но, по крайней мере, они разговаривают. Поддерживайте диалог постоянным.

Получите ретроспективный обзор того, что произошло, и того, как вы можете это исправить в будущем.

Если вы столкнулись с такой ситуацией, то постарайтесь сохранить диалог между командами.

Откройте каналы связи между разработчиками и администраторами как можно раньше.