Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>27 май 2025</li>

3 <li>0</li>

4 </ul>Краткая экскурсия по миру DevOps, в которой мы расскажем о топологиях, практиках, культуре и взаимодействии команд.

5 Иллюстрация: Colowgee для Skillbox Media

6 Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.

7 Об авторе

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

9 Переводчик

10 Екатерина Степанова

11 DevOps (development operations) - это популярная методология, которую применяют, чтобы повысить производительность компании - независимо от того, в какой отрасли она работает. С каждым днём всё больше компаний внедряют у себя эту модель.

12 Главная цель DevOps - обеспечить стабильную поставку ПО за счёт постоянной интеграции процессов разработки и эксплуатации. При этом процессы разработки и развёртывания ускоряются и требуют меньше ресурсов, а компании экономят деньги, производя более качественные программные продукты.

13 В этой вводной статье мы объясним основы методологии DevOps, расскажем об истории её появления, опишем лучшие практики, ключевые топологии и основные преимущества.

14 Содержание

15 <ul><li><a>Что такое DevOps</a></li>

16 <li><a>Откуда взялась DevOps-методология</a></li>

17 <li><a>Культура DevOps</a></li>

18 <li><a>Практики и инструменты методологии DevOps</a></li>

19 <li><a>Топологии DevOps</a></li>

20 <li><a>Ключевые преимущества DevOps</a></li>

21 <li><a>DevOps выходит за рамки бизнес-модели</a></li>

22 </ul>Раньше в IT существовали отдельные команды разработки (developers) и сопровождения, или поддержки (operations). У них были разные руководители, обязанности, подходы и цели. Во многих компаниях они даже находились на разных этажах и почти не взаимодействовали.

23 Такая культура разрозненности мешала сотрудничать, а зону отчуждённости они преодолевали только в случае крайней необходимости. В общем, в то время работал принцип "отправь софт через сетку на другую сторону поля".

24 Успехи DevOps помогли сломать эту стену, и теперь сотрудники:

25 <ul><li>работают сообща;</li>

26 <li>разделяют обязанности;</li>

27 <li>вместе отвечают за код и каждую часть ПО на протяжении его<a>жизненного цикла</a>.</li>

28 </ul>Сегодня этому подходу доверяют даже техногиганты вроде Amazon, Google, Netflix и BMC Software. И всё чаще компании задумываются о том, как распространить эти принципы на всю организацию - то есть применять их не только в IT.

29 Инфографика:<a>BMC</a>/ Skillbox MediaДо 2000 года большинство IT-компаний применяли линейный подход к разработке ПО -<a>каскадную модель</a>, или "водопад" (waterfall).

30 При таком подходе:

31 <ul><li>уйма времени разработчиков уходила на написание и связывание между собой крупных фрагментов кода, а также на согласование инструментов разработки;</li>

32 <li>тестировщики и специалисты по сопровождению работали разрозненно и тратили больше времени на проверку этого кода.</li>

33 </ul>В итоге между релизами ПО возникали большие перерывы - порой по несколько лет. А сам код часто выходил с багами, которые приходилось устранять в многочисленных патчах между релизами.

34 С появлением методологии<a>Agile</a>отрасль перешла к итеративной разработке ПО с более частыми релизами. В этой модели заработали подходы непрерывной интеграции (continuous integration, CI) и поставки (continuous delivery, CD), которые позволили выпускать обновления быстрее и чаще.

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

36 Инфографика:<a>BMC</a>/ Skillbox MediaЧтобы перейти к новому подходу, организациям придётся:

37 <ul><li>отказаться от традиционных методов работы и управления;</li>

38 <li>пересмотреть привычный образ мышления и инструменты.</li>

39 </ul>Согласно этой методологии разработчики и специалисты по сопровождению должны работать сообща и часто общаться между собой.

40 В некоторых организациях<a>DevOps-инженеры</a>занимаются как разработкой, так и сопровождением. Их роль охватывает многое: они разделяют обязанности с другими специалистами и считают себя ответственными за весь цикл разработки.

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

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

43 Инфографика:<a>BMC</a>/ Skillbox MediaА теперь подробнее об этих практиках и инструментах.

44 Обычно разработчики вручную обновляли свой код, а затем вручную же его тестировали.

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

46 Эта практика помогает быстрее выявлять ошибки в коде и повышает качество ПО.

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

48 Все эти задачи помогают выполнять Jenkins, Bamboo, Travis, TeamCity и другие CI- и CD-инструменты.

49 Эта практика помогает как можно раньше выявлять возможные риски на всех стадиях разработки ПО - чтобы ошибки в коде не повлияли на конечных пользователей.

50 Например, когда код развёртывается на серверах сборки, запускаются автоматические модульные тесты для выявления любых ошибок. Если какие-то тесты не проходят, сборка отклоняется, а разработчик получает уведомление о том, что код нужно перепроверить.

51 Таким образом, код будет развёрнут в среде контроля качества (QA environment) для функционального тестирования, только если успешно пройдёт все модульные тесты.

52 Примечание переводчика

53 Функциональные тесты (ФТ) проверяют работу приложения снаружи, как если бы это делал пользователь, а <a>модульные тесты (МТ, юнит-тесты)</a> - изнутри, с точки зрения разработчика.

54 ФТ помогают создать приложение, которое делает ровно то, чего хочет клиент. Они гарантируют, что вы никогда не сломаете логику работы. МТ помогают писать чистый код без ошибок - надёжный, производительный, не вызывающий утечек памяти, расширяемый и так далее.

55 Согласно<a>ISTQB</a>, модульное тестирование может проверять и функциональность - в случае, если компонент (модуль, программу, функцию, объект, класс и так далее) можно тестировать отдельно от других.

56 Популярные инструменты для тестирования - Selenium, Travis и Appium.

57 Предполагается, что приложение, инфраструктура, промежуточное ПО и сети постоянно мониторятся на предмет производительности, ошибок, безопасности и соответствия требованиям.

58 Большинство компаний следят за такими показателями:

59 <ul><li>использование CPU и памяти;</li>

60 <li>использование дискового пространства;</li>

61 <li>действия клиентов;</li>

62 <li>политики безопасности.</li>

63 </ul>При постоянном мониторинге вы всегда будете в курсе проблем на любом этапе - от написания кода до продакшена. Это поможет вам обеспечить<a>высокую доступность</a>продукта.

64 Популярные инструменты непрерывного мониторинга: Nagios, Sensu, Prometheus.

65 Инфраструктура как код (infrastructure as code, IaC) - это модель, при которой инфраструктура - виртуальные машины, балансировщики нагрузки, сети и другие инструменты - настраивается и управляется программно, а не вручную. Такая инфраструктура стала необходимым компонентом в организациях, которые специально перешли на облачные платформы.

66 Например, Amazon Web Services (AWS) предоставляет API для программного взаимодействия со своей облачной инфраструктурой. Использование программного кода для определения конфигурации помогает сделать процесс стандартным и быстро развёртывать ресурсы в облаке.

67 В отличие от традиционного монолита, приложение в микросервисной архитектуре состоит из множества маленьких сервисов или компонентов. Каждый сервис отвечает за свою функциональность, а взаимодействуют они через легковесный интерфейс или код API.

68 Микросервисная архитектура - распространённое решение, и это неслучайно:

69 <ul><li>Она помогает независимо управлять ресурсами в рамках различных компонентов.</li>

70 <li>Повышает доступность системы, так как в ней нет единой точки отказа: отказ одного из компонентов не влияет на работу остальных.</li>

71 <li>Помогает добавлять дополнительные компоненты с новыми функциями, не влияя на другие компоненты.</li>

72 </ul>Способы применения DevOps сильно зависят от конкретной организации. По словам<a>Мэттью Скелтона (Matthew Skelton) и Мануэля Пайса (Manuel Pais)</a>, чтобы внедрение DevOps проходило успешно, компании применяют разные типы топологий или командных структур. Скелтон и Пайс выделяют девять типов топологий.

73 Инфографика:<a>BMC</a>/ Skillbox MediaЭто идеальная командная структура для DevOps. В ней Dev- и Ops-группы тесно взаимодействуют друг с другом:

74 <ul><li>Разработчики серьёзно относятся к задачам поддержки и прислушиваются к Ops-коллегам, если это необходимо.</li>

75 <li>А коллеги из поддержки отлично понимают, чем занимаются разработчики.</li>

76 </ul>Такая топология применяется в Netflix. Её суть в том, чтобы в команде разработки были не только программисты, но и специалисты технической поддержки.

77 Лучше всего подходит для компаний с отдельными веб-приложениями.

78 Эта топология подходит для организаций с несколькими службами, расположенными на облачных платформах, но с традиционным IT-отделом, реструктурировать который не планируется. При таком подходе Ops-группа - это, по сути, "инфраструктура как услуга" (infrastructure as a service, IaaS).

79 Некоторые организации не обладают достаточным опытом или не могут себе позволить организацию отдельного Ops-подразделения. В таком случае они могут поручить управление операционными аспектами ПО внешнему провайдеру.

80 Dev- и Ops-команды временно объединяются, чтобы достичь конкретной цели. Как только код написан и задача выполнена, сотрудников распускают.

81 Такая топология подходит слабо сплочённым командам. DevOps-адвокаты помогают как разработчикам, так и специалистам по сопровождению: рассказывают о практиках и инструментах, вовлекают в работу над кодом.

82 Эту топологию придумали в Google. В такой структуре есть группа, которая занимается "проектированием надёжности сайта" (site reliability engineering,<a>SRE</a>). Разработчики доказывают сотрудникам этой команды, что их ПО и инструменты соответствуют стандартам. SRE могут откатить изменения, если не согласны с ними.

83 При<a>контейнеризации</a>требования к развёртыванию и времени выполнения переносятся на слой контейнеров. Это убирает часть взаимозависимостей между Dev- и Ops-командами.

84 Такая структура подходит для организаций с хорошо развитой инженерной культурой.

85 С такой топологией экспериментировали некоторые организации, у которых есть приложения, подключённые к крупным централизованным базам данных. Суть структуры в том, что и в <a>DBA- (database administrator), и в Dev-группах</a>определены взаимосвязанные роли для специалистов, отвечающих за работу с базами и связанный с ними код. Это помогает преодолеть разрыв между этими двумя группами.

86 Организации, которые внедрили у себя DevOps-культуру, замечают улучшения во многих аспектах разработки ПО:

87 <ul><li>налаживание связей между командами;</li>

88 <li>повышение эффективности и продуктивности организации;</li>

89 <li>увеличение скорости выпуска ПО и обновлений кода;</li>

90 <li>повышение лояльности клиентов (они же теперь получают ПО высокого качества);</li>

91 <li>уверенность в том, что система доступна и надёжна, - благодаря тому, что угрозы и ошибки быстро находят и устраняют с помощью автоматизированных инструментов;</li>

92 <li>содействие инновациям за счёт обмена идеями и инструментами между различными командами.</li>

93 </ul>На этом видео Дэвид Риццо (David Rizzo), вице-президент по разработке ПО в BMC Software, и Дэвид Кеннеди, архитектор решений, рассказывают о том, как использовали DevOps в Compuware - чтобы подстегнуть инновации, сократить число ошибок, снизить показатель MTTR и внедрить инструменты, ускоряющие разработку.

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

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

96 При правильном применении культура DevOps может дать компаниям огромные возможности для успешного выпуска ПО.

97 <a>Практический курс: "Профессия DevOps-инженер" Узнать о курсе</a>