Почему развитие противодействует операциям?

Я все еще студент, но я не разбираюсь в операциях, и мой английский все еще плох.

Мой вопрос: почему развитие противодействует операциям ? Когда разработка противодействует операциям?

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

Традиционно, из-за каскадных развертываний и крупномасштабных обновлений, разработка может привести к различным проблемам при развертывании из-за неадекватного тестирования, изменения серверных сред, список можно продолжать и продолжать. По сути, обновления были слишком большими для операционной группы, чтобы иметь возможность эффективно их развертывать без каких-либо проблем в процессе. Эти проблемы могут быть причиной того, что вы считаете, что разработка противостоит операциям .

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

Tldr: DevOps стремится свести на нет теорию о том, что разработка противодействует операциям , создав мышление, при котором операции и разработка работают вместе, чтобы часто развертывать продукты своевременно и легко воспроизводимо.

Я думаю, что вы уже получили исчерпывающие ответы, но вы сказали, что ваш английский не очень хороший, поэтому я постараюсь дать очень краткий и понятный ответ:

• Основной целью развития является внесение изменений.
• Основная цель операций - поддерживать стабильность среды.

Эти две вещи конфликтуют. При этом развитие и эксплуатация не должны противопоставляться друг другу. Они должны работать вместе, чтобы обеспечить достижение обеих целей. Это цель DevOps.

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

За разработчиками часто судят по скорости и количеству проблем, которые они могут решить и объединить в репозиторий кода, и их вознаграждение часто не связано с тем, что код действительно работает или работает правильно. Гораздо меньше масштабирование, производительность и другие факторы.

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

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

DevOps - это своего рода набор решений этой проблемы:

• Некоторые из них могут быть организационными, где процессы и стимулы команд могут меняться. Например, если работа разработчиков помечена как выполненная, только если она некоторое время работала в рабочей среде, проблем не было, и рабочая группа соглашается принять на себя ответственность за код. Точно так же об операциях можно судить больше по скорости, с которой принимается код, в то время как среда все еще находится в определенных пределах стабильности.
• Другой частью решения может быть общение и кросс-поляризация, когда вы объединяете оперативных сотрудников в команду разработчиков и наоборот. Вы разбиваете стену между этими командами, и инженеры DevOps часто являются результатом такого типа соединения.
• Инструменты, поддерживающие процессы, такие как Continuous Integration и Continuous Deployment, являются еще одной частью решения, которое может повысить скорость изменений, сохраняя при этом высокое качество и быстрое восстановление производственной среды в случае любых проблем, связанных с откатом кода или быстрым выполнением исправления. в производство.

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

Важно понимать, почему такой подход к блокированию успеха блокирует успех бизнеса и часто не может улучшить организацию в целом. И это влияет не только на разработку и эксплуатацию, но и на все остальные функциональные возможности большой организации, такие как команда обеспечения качества, финансы, управление продуктами и проектами.

Поскольку руководителям каждого функционального бункера предписывается улучшаться за счет сокращения затрат или увеличения скорости, их реакция часто такова:

• Я полностью ошеломлен решением проблем с последним улучшением. Оставь меня в покое.
• Что вы хотите, чтобы я делал, выполнял свои обязанности или работал над проектами по улучшению? У меня нет времени, чтобы сделать оба.
• Не снова! Вот еще одна программа месяца.

С этими типичными реакциями любой руководитель, предпринимающий незначительные усилия по улучшению, редко встречается с энтузиазмом. Менеджеры оказываются в жесткой конкуренции с другими функциональными областями за ресурсы, необходимые для выполнения их улучшений. Поэтому неудивительно, что команда по улучшению усиливает межфункциональные баталии!

Даже когда менеджер завершает свою часть проекта по улучшению, он встречает другие функциональные области и другие организации (поставщики, подрядчики и т. Д.), Которые не выполняют свою работу. Это уменьшает или полностью сводит на нет результаты.

Это межфункциональное напряжение не ограничивается усилиями по улучшению. Он лежит в основе ежедневного принятия решений и оценки эффективности управления в организации. Вот один пример из жизни:

Финансовому менеджеру сказали "улучшайся". Он решил заблокировать найма подрядчиков, которые стоят больше, чем номинальная цена, принятая на рынке. Он внедрил новую политику и заявил, что в этом году сэкономил 1 миллион долларов. Поскольку разработчики и ИТ не могут нанять подрядчиков, чтобы помочь им использовать контейнер и контейнерную оркестровку, так как эти подрядчики дороги. Менеджер по ИТ-операциям в той же компании подсчитал, что отсутствие улучшения в их инфраструктуре обходится компании в более чем 100 000 долларов в месяц дополнительных расходов. При этом ежегодная экономия на найме подрядчиков была израсходована до конца года.

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

Эти межфункциональные конфликты обусловлены подходом бункера, когда организация измеряет каждый бункер независимо. Если вы являетесь центром затрат, естественно, улучшение означает большую эффективность или снижение затрат в вашем хранилище.

В этой системе отсчета затраты рассматриваются как подчиняющиеся «аддитивному» правилу. Затраты на каждый бункер, сложенные вместе, равны общей стоимости организации. Таким образом, менеджеры видят любое сокращение расходов в своей области как «хорошее», так как они видят прямой перевод экономии средств для компании в целом. В этой системе отсчета усилия по улучшению распространяются повсеместно, чтобы атаковать затраты и потери по всей организации.

Отличный пример, когда команды разработчиков начинают работать с Agile и отправляют код в QA и Operations каждые две недели, а не каждый квартал, как это было раньше. QA и Operations не готовы к таким изменениям и обвиняются в ослаблении. Опять же, это не сильно способствует любви между людьми в разработке и эксплуатации.