Портал №1 по управлению цифровыми
и информационными технологиями

Семь распространённых мифов о DevOps

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

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

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

Миф 1. DevOps — это CI/CD

Одно из самых больших заблуждений заключается в том, что многие считают, что DevOps это то же самое, что и CI/CD (непрерывная интеграция и непрерывная поставка). Да, это, действительно, ключевые компоненты DevOps, но помимо них, это ещё и определённая культура и ответственность в команде. Подход подчеркивает необходимость участия каждого в задачах друг друга, что улучшает сотрудничество и общение в команде.

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

Миф 2. DevOps — это отсутствие команды эксплуатации (NoOps)

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

При этом NoOps, как считается, будет уже следующим этапом эволюции модели разработки после DevOps. Цель та же — улучшить поставку ПО, позволяя разработчикам сосредоточиться на разработке приложений, а не на инфраструктуре и её обслуживании.

Миф 3. Автоматизация устраняет все узкие места

Автоматизация — одно из самых больших преимуществ DevOps. Но это не серебряная пуля, которая решает разом все проблемы.

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

Автоматизация конвейера CI / CD помогает устранить узкие места только между этапами написания кода и развертывания. Но это лишь один из шагов процесса поставки ПО. Если разработчики и тестировщики не будут сотрудничать, то проблемы будут продолжать возникать. Скорее всего, узкие места просто переместятся в другие этапы конвейера.

Миф 4. Один-единственный конвейер

Идея о том, что у может быть один универсальный процесс, который подходит для всех команд и компаний, невозможна, вопреки распространённому мнению. У каждой организации разные нужды и требования. Даже для проектов в одной организации могут потребоваться по-разному организованные конвейеры непрерывной поставки в зависимости от количества сред, используемых в в каждом проекте. Поэтому каждый конвейер непрерывной поставки специфичен и должен быть «заточен» под тот процесс выпуска, который используется в определённом проекте.

Миф 5. DevOps — это лишь инструментарий

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

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

Миф 6. Релизный цикл как у Amazon / Facebook / Google

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

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

Миф 7. Постоянные релизы

Распространённая идея частых релизов заставляет многие компании беспокоиться о том, а так ли часто (непрерывно) они выпускают ПО. «Релизиться часто» стало отраслевым стандартом. Но не всегда понятно, что такое «часто». Это может быть и каждые две-три недели, и несколько раз в день.

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

Непрерывная поставка не означает, что вы должны выпускать релизы как можно чаще — нет. Она предоставляет возможность выпускать релизы так часто, как это требуется. А что такое «часто» должно быть определено уже вашей организацией.

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

Источник

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Самое свежее

    • Новый взгляд на управление знаниями
      В конце 1990-х годов я увлёкся концепцией явного и неявного знания. Это был расцвет эры управления знаниями, и как отраслевому аналитику мне посчастливилось регулярно встречаться …
    • ITIL®4 Specialist CDS: внутренняя культура и коммуникации
      Внутренняя культура организации является одним из наиболее важных компонентов управления услугами, но в большинстве случаев разговоры о ней  ограничиваются словами о «мягких …
    • Технический долг: как не стать жертвой невидимого врага
      Зачастую о техническом долге говорят как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Что подготовить в компании, чтобы заработало управление ИТ-активами?
      Автор — Андрей Боганов, ITSM/ITAM эксперт, тренер курса «Управление ИТ-активами (ITAM)» Для организации управления ИТ-активами «навести порядок» только в ИТ …
    • Технический долг и беклог
      Не могу оторваться от темы беклога, ведь это именно то место, где принимаются решения. Продолжу о вопросах вокруг технического долга и способности команды инвестировать в его …
    • маленькие релизыТри визуализации, которыми я объясняю Agile
      Хорошая визуализация помогает объяснять достаточно сложные вещи. Вместо большого количества слов достаточно одной картинки. У большинства консультантов есть свои любимые …
    • Что дальше в DevOps: AIOps?
      Уже со времен появления гигантских хранилищ и анализа больших данных эксперты говорили о том, какими огромными становятся ИТ—инфраструктуры, и что скоро они станут настолько …
    • Как “продать” место в очереди
      Очередь — одна из раздражающих вещей и пережиток советской эпохи. Она повсюду: в магазине на кассу, у лифта в офисном здании, пробка на дороге – это ведь тоже очередь. …
    • Есть ли польза от оценок трудозатрат разработчиков для самих разработчиков?
      Мы знаем, что заказчикам и заинтересованным сторонам проекта нужны оценки по срокам реализации задач. На их основании они строят планы, расставляют приоритеты и планируют даты …
    • Кто тут крайний?
      Забудем на минуту про единорогов, бирюзовые компании, холакратию и прочие мифические концепции. Они, конечно, где-то есть, но не очень рядом. Представим себе традиционную …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT