Devops что это за программа

Что такое DevOps?

Команды, успешно применяющие DevOps, в среднем развертывают обновления в 208 раз чаще и в 106 раз быстрее, получают в 7 раз меньше сбоев, после которых восстанавливаются в 2604 раза быстрее. В статье рассмотрим, что такое DevOps в SAFe.

Андрей Булов, SPC (SAFe Program Consultant), про теорию и практику DevOps максимально простыми словами.

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

Руководство DevOps

DevOps

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

DevOps является частью компетенции Agile-поставка Продуктов Lean-предприятия.

DevOps — акроним, состоящий из двух слов: Development (Разработка) и Operations (Эксплуатация). Без DevOps часто возникает значительное напряжение между теми, кто разрабатывает что-то новое, и теми, кто поддерживает стабильность сервисов. Предприятия, применяющие SAFe®, внедряют DevOps, чтобы разрушить функциональные колодцы и настроить Конвейер Непрерывной Поставки (Continuous Delivery Pipeline, CDP) — высокопроизводительный механизм инноваций, способный предоставлять решения с необходимой бизнесу скоростью.

Цель очень проста: доставлять ценность тогда, когда это необходимо для бизнеса. И мы видим, что эта цель достижима. Команды, успешно применяющие DevOps, в среднем развертывают обновления в 208 раз чаще и в 106 раз быстрее, получают в 7 раз меньше сбоев, после которых восстанавливаются в 2604 раза быстрее, чем команды с низкой производительностью.

DevSecOps

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

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

В одном из самых популярных учебников DevSecOps RedHat напоминает нам, что «устаревшие методы обеспечения безопасности могут свести на нет даже самые эффективные инициативы DevOps». Список 10 основных уязвимостей программного обеспечения проекта Open Web Application Security Project (OWASP) стал эффективным инструментом для налаживания сотрудничества между группами разработки, эксплуатации и безопасности. Сочетание передовых технологий DevOps и безопасности может сильно оптимизировать процесс поставки и помочь построить фабрику программного обеспечения даже в самых зарегулированных организациях. Это продемонстрировали нам ВВС США в рамках инициативы Enterprise DevSecOps Platform (DSOP).

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

Благодаря своему вкладу, безопасность укоренилась в DevOps культуре настолько, что термины DevOps и DevSecOps стали во всех смыслах неразличимы. Каждый из них подразумевает набор практик из нескольких областей — разработки, эксплуатации, безопасности, инфраструктуры, архитектуры и т. д. во всём потоке создания ценности. Все эти практики работают для обеспечения взаимодействия, скорости, качества и безопасности. SAFe поддерживает это мнение, ставя обеспечение безопасность во главу угла.

Рисунок 2. Безопасность встроена в DevOps в SAFe

Подробности

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

Смена парадигмы

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

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

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

На рисунке 4 показано, как DevOps обеспечивает Конвейер Непрерывной Поставки. Он предоставляет образ мышления, практики и инструменты, необходимые для ускорения поставки и обучения на каждом этапе.

Андрей Булов, SPC (SAFe Program Consultant), про SAFe® DevOps: обзор применения подхода на практике.

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

Андрей Булов, SPC (SAFe Program Consultant), про SAFe® DevOps: подход CALMR.

Измерение и управление зрелостью DevOps

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

Инструмент, помогающий Agile Release Train (ART) и Solution Train улучшать производительность потока создания ценности, представлен на рисунке 5 — SAFe DevOps Health Radar. Он обеспечивает целостную проверку работоспособности DevOps, оценивая зрелость четырех аспектов и 16 действий конвейера непрерывной доставки. Health Radar используется для измерения базовой зрелости на любом этапе DevOps-трансформации и последующего быстрого, инкрементального прогресса.

Андрей Булов, SPC (SAFe Program Consultant), про SAFe® DevOps Health Radar.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Источник: scrumtrek.ru

Devops что это за программа

Со временем Waterfall была раскритикована за недостаточную гибкость, а ее основная цель – формальное управление проектом, приносила ущерб срокам, стоимости и качеству.

Команды нуждались в гибкости во время разработки программного обеспечения. Необходимость реализации проекта в форме коротких «спринтов» и выпуска более частых (от двух недель, до двух дней) релизов потребовали нового подхода.

В 2001 году на смену Waterfall пришла гибкая методология разработки или Agile. Она включает ряд подходов и практик, основанных на четырех ценностях и 12 принципах «Манифеста гибкой разработки программного обеспечения» . Сюда также относят SCRUM , Kanban , Lean , Feature-driven development (FDD) и другие сходные подходы.

Agile применяется к организации работы небольших групп, которые создают продукт короткими итерациями (от двух до четырех недель). Каждая итерация выглядит как программный проект, который включает все типовые задачи: планирование, анализ требований, проектирование, программирование, тестирование, документирование. В конце итерации заказчик получает рабочий продукт.

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

Идея и культура DevOps

Методология DevOps получила широкое распространение после организованной бельгийским разработчиком Патриком Дебуа в 2009 году конференции DevOpsDays.

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

Культура DevOps предполагает, что каждый из членов команды ответственен за конечный результат. Базируется она на нескольких основных положениях:

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

Принципы DevOps

В 2010 году Дэймоном Эдвардсом и Джоном Уиллисом была разработана модель CAMS, ключевые идеи которой стали принципами DevOps. Согласно ей, развитие DevOps идет в трех направлениях: люди, процессы и инструменты. При этом важна поддержка каждого пункта на всех этапах развития.

Аббревиатура CAMS расшифровывается следующим образом:

• культура (culture);
• автоматизация (automation);
• измерение (measurement);
• обмен (sharing).

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

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

Автоматизация

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

В идеале автоматизировать нужно почти все:

• инфраструктуру;
• выпуски программного обеспечения ( software releases) ;
• тестирование;
• развертывание;
• основные задачи по безопасности;
• политику соглашений;
• задачи управления конфигурацией.

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

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

Измерять нужно показатели следующих процессов:

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

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

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

DevOps и Agile

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

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

Основные различия между DevOps и Agile:

• Разработка, тестирование и развертывание программного обеспечения происходят как в DevOps, так и в Agile. Подход Agile характерен тем, что разработка завершается сразу после развертывания. DevOps же включает операции, которые происходят постоянно, например, мониторинг и модификации программного обеспечения;
• В Agile разные специалисты несут ответственность за разработку, тестирование и развертывание программного обеспечения. В DevOps за все эти процессы отвечают специально обученные инженеры;
• Agile выступает за поэтапное развертывание после каждого спринта. Для DevOps характерна непрерывная доставка (до нескольких раз в день).

Жизненный цикл DevOps

Выделим основные этапы проекта, следующего принципам DevOps:

1. Непрерывное развитие;
2. Непрерывная интеграция;
3. Непрерывное тестирование;
4. Непрерывное развертывание;
5. Непрерывный мониторинг;
6. Постоянная обратная связь.

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

Непрерывное развитие

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

Код может быть написан на любом языке, но поддерживается с помощью средств контроля версий. Процесс поддержки называется управлением исходным кодом (SCM). В нем используются следующие инструменты: Git, SVN, Mercurial, CVS и JIRA.

Непрерывная интег рация

На этом этапе чаще всего применяется Jenkins. Когда в репозитории Git происходят изменения, Jenkins извлекает обновленный код и готовит сборку. Упакованный код переходит к следующему этапу и пересылается либо на рабочий, либо на тестовый сервер.

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

Непрерывное тестирование

На этапе непрерывного тестирования разрабатываемое программное обеспечение проверяется на наличие ошибок. Автоматическое тестирование позволяет разработчикам экономить силы и время.

Для непрерывного тестирования используются следующие инструменты: Selenium, TestNG, JUnit и т.д. Они позволяют инженерам QA тестировать несколько баз кода параллельно, чтобы гарантировать отсутствие недостатков в функциональности. При этом тестируемое приложение часто запускается в виртуальной среде или контейнерах, например, с помощью Docker.

Автоматическое тестирование выполняет Selenium, а отчеты генерирует TestNG. Весь этап можно автоматизировать с помощью инструмента непрерывной интеграции Jenkins. В конце, протестированный код повторно отправляется на этап непрерывной интеграции для обновления исходного кода.

Непрерывное развертывание

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

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

Ansible, Puppet и Chef – инструменты, которые чаще всего используются в DevOps для быстрого и непрерывного развертывания нового кода.

Не менее важную роль на данном этапе играют инструменты контейнеризации. Vagrant и Docker обеспечивают согласованность в различных средах – от разработки и тестирования, до подготовки и производства.

Непрерывный мониторинг

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

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

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

Для этого используются следующие популярные инструменты: Prometheus, Splunk, ELK Stack, Nagios и другие. Они обеспечивают полный контроль над производительностью системы, рабочего сервера и приложения.

Постоянная обратная связь

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

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

Преимущества и недостатки методологии

Преимущества DevOps:

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

Недостатки DevOps:

• Специалисты DevOps должны разбираться в разработке, тестировании, развертывании и поддержке, но эти знания могут быть поверхностными.
• DevOps – рабочая культура, которую нельзя реализовать, просто следуя жизненному циклу разработки программного обеспечения. Чтобы компания могла влиться в среду DevOps, ей необходимо постоянно соблюдать основные принципы методологии и стремиться к изменениям.
• Нанять высококвалифицированного инженера DevOps непросто. Эта специализация требует большого набора навыков, опыта и знания широкого стека технологий, поэтому требования достаточно высоки. Кроме того, DevOps – одни из самых высокооплачиваемых специалистов в IТ.

Источник: proglib.io

Кто такой девопс и что он делает

Это как системный администратор и программист в одном лице.

Как обычно пишут программы

Традиционный цикл разработки программ выглядит так:

1. Программисты пишут код небольшими порциями.
2. Когда очередная версия программы готова, она отдаётся в отдел тестирования.
3. Тестировщики пишут тесты и ищут ошибки в коде. Если нашли — отдают программистам, и всё начинается с первого пункта.
4. Если ошибок нет, код отправляется на сборку, чтобы включить его в новую версию программы.
5. После добавления этого кода в новую версию код снова тестируют — всё ли нормально, дружит ли новый код со старым и нет ли каких конфликтов. Если есть — код отдаётся обратно программистам.
6. Если всё в порядке, код идёт в бой, например, выкатывается на сайт.

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

Минусы поэтапной разработки

Всё дело в том, что с таким подходом есть чёткое разделение зон ответственности. Допустим, у нас простая разработка, которая разделена по отделам так:

• есть программисты, которые пишут код;
• дизайнеры, которые натягивают дизайн на этот код;
• тестировщики;
• и отдел выпуска финальных релизов.

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

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

DevOps-подход к разработке

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

• если что-то можно автоматизировать — автоматизируем;
• каждый отдел использует один и тот же софт и настройку;
• финальный код должен как можно быстрее доходить до того, кто пользуется этим софтом;
• единая среда для разработки, тестирования и финального выпуска.

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

Кто такие девопсы и что они делают

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

Вот что может делать девопс-инженер:

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

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

Что нужно уметь

Чтобы стать девопсом, нужно освоить много разного:

• принципы и теорию разработки ПО;
• инструменты автоматизации работы с кодом — Git, Jenkins;
• системное администрирование на уровне мидла или выше;
• виртуальные контейнеры и работу с ними — Docker и Kubernetes;
• базы данных — реляционные и нереляционные;
• веб-серверы;
• Python или другой язык для написания рабочих скриптов;
• системы управления конфигурацией серверов — Ansible;
• сбор данных по нагрузке и ошибкам во всех системах.

Если при этом девопс будет знать хотя бы на уровне джуниора выбранный язык программирования в компании — будет вообще идеально. Так он сможет учесть особенности языка и подобрать под него нужные инструменты.

Деньги

По данным Хабр Карьеры, в первом полугодии 2021 года средняя зарплата девопс-инженера — 171 тысяча в месяц. Джуниоры получают в среднем 82 тысячи, а сеньоры — 230 тысяч.

Что дальше

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

Источник: thecode.media

DevOps — новая IT-религия

Как автоматизировать и интегрировать рутинные отношения между разработчиками и IT-командами

Часто вы обновляете приложения для своих клиентов? А ваши конкуренты? Вы точно успеваете за потребностями и «хотелками» своей целевой аудитории? У вас минимальный time-to-market для обновлений и новых цифровых продуктов? Если вы ответили «да» на все вопросы, то, скорее всего, про DevOps вы уже знаете и успешно его исповедуете.

Если же «нет», то послушайте, что рассказывают об этой новой IT-религии сами айтишники — CEO (генеральный директор) инжиниринговой IT-компании Tages Jump Дмитрий Голубовский и CTO (технический директор) Илья Рачкулик.

Выйти из полноэкранного режима

Развернуть на весь экран

Фото: Евгений Павленко, Коммерсантъ

Дмитрий Голубовский: Что сейчас происходит в бизнесе в целом и в IT-сегменте в частности? Смена технологического уклада. Старая парадигма планирования проектов на три-пять лет вперед уже не работает, так жить больше нельзя, потому что срок жизни любого цифрового продукта стремительно сократился, а обновления накатываются на любое приложение чуть ли не еженедельно. Пандемия только ускорила все эти процессы, и те компании, которые поняли это и успели перестроиться, сейчас собирают сливки, пачками выкупая более мелкие бизнесы, и образуют целые экосистемы: «Яндекс», «Сбер», Mail.ru, «М.Видео» и прочие.

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

Илья Рачкулик: При внедрении любых новых технологий, методов и программного обеспечения мы неизбежно сталкиваемся с ситуацией, когда изменения вроде бы необходимы, но при этом влекут за собой целую лавину «перестроек». Это чем-то похоже на айсберг: растопить верхушку можно, но, если температурные процессы ниже его ватерлинии не изменятся, не будет и ожидаемого результата. Глыба льда, по сути, останется той же неповоротливой глыбой льда.

Мы все люди, и нам свойственно бояться всего нового. Плохо, когда человек не просто сам по себе боится внедрения новых правил, но и отвечает при этом за цифровое развитие бизнеса. Жесткая централизация всех процессов и решений, страх нового и jobs security, страх признать, что три-пять лет назад ты принял неверное решение и вот сейчас нужно снова идти к владельцу бизнеса и объяснять, что нужно опять все поменять, а на это нужен немаленький бюджет,— все это тормозит процессы цифровизации и внедрения новых методологий работы. Но уже ничто не избавит бизнес от этой необходимости. Будущее уже здесь, просто пока не все его видят невооруженным глазом.

Что такое DevOps и какие проблемы он решает?

Еще полтора-два года назад в России мало кто понимал, что это такое и зачем, сейчас в специалистах DevOps нуждаются все — от компаний-разработчиков до крупного бизнеса.

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

Однако если смотреть ближе к сути, то DevOps — это методология, которая дает возможность автоматизировать и интегрировать рутинные процессы между разработчиками и IT-командами. Она существенно сокращает сроки создания новых цифровых продуктов и вывод их на рынок (time-to-market), одновременно улучшая их качество. На языке бизнеса это означает, что внедрение новой функции в ваше уже работающее приложение можно осуществить в рекордно короткие сроки с соблюдением всех правил безопасности, существенно опередив конкурентов. Соответственно, вы получаете экономию времени и финансов, бесперебойную и безошибочную работу своих цифровых продуктов, опережаете конкурентов и буквально снимаете сливки с клиентов в виде чистой прибыли.

Как это выглядит на практике? Представьте себе какой-нибудь цифровой агрегатор скидок и «черную пятницу». Это момент, когда из-за огромного количества обращений пользователей нагрузка на сервис возрастает настолько, что он начинает в срочном порядке автоматически закупать дополнительные серверы, чтобы «не упасть».

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

Что это даст бизнесу?

Илья Рачкулик: Сейчас все кому не лень говорят про эджайл-идеологию. Почему? Потому что она ускоряет процессы разработки. Когда ты задумываешь сделать новый релиз, продукт или приложение, то от идеи до финальной точки у тебя проходит условно год, то твой time-to-market — это год. Поздравляю! Ты уже опоздал. Твои конкуренты уже давно все выпустили и обновили 12 раз минимум.

Если ты пытаешься целый год разрабатывать один продукт, то все, что ты заложил в него в самом начале, через год уже никому не интересно и не нужно. У современного бизнеса просто нет этого года. Именно поэтому agile и стал популярен — он сокращает время на разработку на 10–15%, а DevOps — в разы.

Дмитрий Голубовский: Как мы уже говорили, сейчас для бизнеса максимально важно выпустить приложение как можно скорее. Релизы выходят чуть ли не каждую неделю: выпустили MVP (minimum viable product — минимально жизнеспособный продукт) и дальше пошли его дорабатывать.

Если у тебя есть условно две недели плюс неделя на все про все, то нужно понимать, что 30–50% времени должно уходить на сборку, сам релиз, раскатку, тестирование. Эти процессы нужно оцифровать и составить пайплайн — описать пошагово, что мы делаем. Раньше это делали руками и скриптами, сейчас это уже конвейерное производство: есть код, происходит сборка, тестирование продукта, выкатка его на стенд, релиз. И обеспечивает этот процесс так, чтобы все обновления для пользователей проходили максимально бесшовно, как раз DevOps.

DevOps-инженер — кто он и что делает?

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

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

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

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

Что должен знать и уметь DevOps?

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

Прежде всего — знать языки программирования: Python, Golang, Ruby, C, C++. Главное, конечно, не их количество — все знать невозможно,— а общее понимание принципов работы. То есть быть с кодом на ты. Он должен знать основные аспекты операционных систем, необходимых для работы, и особое внимание уделять Linux.

Иметь навыки администрирования серверов, поскольку инженеру DevOps придется управлять всеми типами серверов, которых может быть больше сотни. Знать сетевую безопасность, базовые протоколы — HTTP, SSL, SSH, FTP, SMTP и пр. Важно, чтобы человек разбирался, как они настраиваются на уровне сервиса, и знал, что влияет на их безопасность.

Уметь работать с веб-серверами, понимать инфраструктуру как код и управлять ею с помощью инструментов на основе кода. Знать и уметь работать с инструментами CI (непрерывной интеграции)/CD (непрерывной доставки), например GitLab CI. Вообще, лучшее резюме для разработчика — это не заполненная по всем канонам HR форма на HeadHunter, а красивый код, написанный в GitLab.

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

На текущий момент процесс DevOps закрыть одним только специалистом уже невозможно. По факту это целое отдельное направление, в рамках которого работают группы специалистов с разной специализацией — это ci/cd, мониторинг, отладка, трейсинг и трекинг, безопасность и пр.

Основные цели DevOps

Главная цель всей работы DevOps-инженера — технически настроить сотрудничество между всеми участниками процесса: от заказчика и аналитиков до разработчиков (фронтенда, бэкенда) и тестировщиков.

Такая настройка помогает разом решить несколько задач:

— улучшить частоту развертывания новых релизов;

— снизить частоту отказов от новых релизов;

— сократить время и затраты на отслеживание и исправление багов в продакшен-средах и средах разработки;

— сократить время на восстановление в результате каких-то ошибок и «падений» приложения.

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

Хотя DevOps, а точнее, его первые проявления возникли на рынке еще в 2012–2015 годах, когда такие гиганты, как Leroy Merlin и «М.Видео» начали внедрять у себя эту практику, большая часть бизнеса до сих пор не осознала необходимости перестройки на такую «поточную» схему работы. Что важно, смена технологического уклада не подозревает тотальный снос и уничтожение всего того, что было. Умные компании, цель которых — технологическое превосходство на рынке, просто выстраивают эти процессы параллельно со старыми, чтобы постепенно переходить на новый уровень. Фактически они создают себе почву для того самого «бесшовного» перехода на новую методологию работы, практически незаметную для неискушенного глаза пользователя. Но те, кто не готов меняться и вкладываться в развитие новых методик в своем ландшафте, к сожалению, обречены на вымирание, потому что рано или поздно, но они останутся в хвосте этого локомотива, а потом безнадежно отстанут.

Источник: www.kommersant.ru