DevOps – что это и почему без него не обходится ни один успешный проект?

DevOps – что это и почему без него не обходится ни один успешный проект?

Рассмотрим понятие DevOps: почему сегодня оно стало практически синонимом успешного стартапа, что это такое, цели и преимущества.

Современные ИТ-проекты, будь то простой интернет-магазин или крупный проект по разработке софта, требуют комплексного подхода в создании.

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

Cодержание:

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

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

Теперь для нормальной работы сайта требуется больше серверов.

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

Чем стремительнее развивается проект, тем больше проблем появляется.

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

Для этого и нужен DevOps.

Суть DevOps – в чем удобство принципа?

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

Общая интеграция процессов и постоянное техническое обслуживание – основные задачи DevOps.

Разберемся детальнее с этим принципом работы.

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

При стандартном подходе в разработке ПО в компании, которая занимается созданием и продажей софта, работает штат программистов.

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

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

Кроме того, из-за этой задержки возникают сложности в работе:

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

Все проблемы возникают из-за сосредоточенности разработчика над своим кодом, который отличается от промышленной среды.

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

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

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

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

Таким образом, возникают сложности с развертыванием и тестированием нового кода.

Под автоматизацией подразумевают:

  • Автоматизацию тестирования нового кода;
  • Автоматизацию процессов;
  • Совершенствование инфраструктуры.

Читайте также:

Принцип работы и цели

DevOps полностью меняет подход к разработке ПО.

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

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

В результате:

  • Приложение быстрее адаптируется под различные платформы;
  • Улучшается качество кода;
  • Внедрение нового функционала можно выполнять хоть каждый день.

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

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

Её задачи:

  • Управление оборудованием (серверами);
  • Работа с операционными системами;
  • Контроль программного обеспечения;
  • Установка и управление скриптами.

Необходимо предоставить девелоперам возможность мониторить производительность приложений и оптимизировать их практически в режиме реального времени.

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

Программисты и администраторы работают совместно.

Еще один немаловажный компонент успешного внедрения DevOps – это правильные инструменты.

Они должны быть современными и иметь возможность приспосабливаться к меняющимся требованиям и условиям.

Оптимальным решением будет:

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

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

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

Читайте также:

Как стать DevOps—Engineer и что нужно знать?

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

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

Достаточно постоянно изучать принципы взаимодействия инструментов автоматизации и знать ООП.

В работе любого девелопера базовыми являются знания объектно-ориентированного программирования.

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

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

Вы должны знать и понимать следующие принципы ООП:

  • Инкапсуляция;
  • Наследование;
  • Полиморфизм.

Разберитесь детальнее, что означает каждый из этих принципов.

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

Новичкам будет проще начать с выбора любой сущности.

К примеру, напишите программу «Тигр» — задайте ему свойства, опишите функции и наследование.

Простые программы такого типа всегда эффективно раскрывают суть ООП для начинающих программистов.

Сегодня большинство крупный компаний по разработке ПО используют языки группы C (C, C++, C# и так далее) для разработки программ под Виндовс.

В первую очередь, девелопер DevOps должен досконально разбираться в инфраструктуре проектов.

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

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

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

Тематические видеоролики:

DevOps-инженер: как обучиться одной из самых прибыльных профессий

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

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

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

DevOps

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

В задачи DevOps-инженера входит синхронизация и автоматизация всех этапов разработки ПО: написание кода, тестирование кода, продакшен и выпуск обновлений и патчей. Такой специалист является одновременно и админом, и разработчиком, и тестировщиком. Он контролирует отделы разработки и эксплуатации ПО и на глубоком уровне понимает, как устроен весь этот процесс. Если хочешь, то его можно назвать менеджером, управляющим (но только в хорошем смысле).

Как стать DevOps-инженером

Это молодая профессия, и специалисты в ней крайне востребованы. Если ты хотя бы немного умеешь кодить, умеешь в системное администрирование и Linux или хочешь перерасти должность «просто админа» или программиста, перейдя на новый уровень, то тебе стоит записаться на курс DevOps Engineer, который проводит в январе школа IT-образования Level UP .

Продолжительность курса — 2 месяца. За это время ты пройдешь через специально разработанную для современных реалий (и успешного прохождения собеседований) программу, которая включает в себя просто огромный стек технологий и инструментов: Agile, Scrum, Hyper-V, Vmware, базы данных MySql, NoSql, PostgreSql, Git, Docker, Ansible, Jenkins, Kubernetes, Amazon Web Service, Zabbix.

— понимать основные принципы и философию DevOps;
— пользоваться инструментами для автоматизации процессов разработки;
— автоматизировать процессы деплоя с помощью инструментов CI/CD;
— понимать основные этапы и методы разработки ПО;
— четко видеть свою роль в процессах разработки;
— ориентироваться в современных системах хранения и обработки информации, в т. ч. «облачных»;
— лучше контролировать и управлять production, development и тестовыми средами

Это отличная возможность любому человеку, который крутится в IT, кардинально расширить свой кругозор, овладеть современными методиками разработки и продакшена приложений и сервисов. К тому же, как ты можешь догадаться, профессия открывает доступ и к другим, более высоким должностям. Курс от Level UP стоит недорого, поэтому рекомендуем записаться в ближайшее время, так как число мест ограниченно.

Что такое DevOps и зачем он нужен?

Почему полезно работать с DevOps, где применять эту технологию и какие существуют инструменты. Объясняет Алексей Климин из компании «Атвинта».

Фронтенд, Бэкэнд, Админ, DevOps. Обожаю все оптимизировать и автоматизировать. Постоянно ищу новые технологии и способы их внедрения.

Проблемы при работе без DevOps

Как DevOps улучшает процесс разработки

Что это за технология

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

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

Наиболее ярко DevOps раскрывается при разработке приложения с применением микросервисной архитектуры 1 .

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

Вариант сервис-ориентированной архитектуры ПО, ориентированный на взаимодействие небольших, слабо связанных и легко изменяемых модулей — микросервисов.

Проблемы при работе без DevOps

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

Много действий при передаче на тестирование

Разработчик устанавливает у себя на машине все необходимое: язык программирования, на котором будет вестись разработка, например PHP 7.0, базу данных, MySQL 5.7 и веб-сервер, Apache. Какая операционная система и какие версии библиотек и зависимостей будут установлены на сервере, неизвестно.

После того как нужная функциональность приложения реализована, требуется ее протестировать.

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

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

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

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

Несовместимость версий в тестовой среде и на сервере заказчика

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

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

В итоге при использовании на продакшне другого веб-сервера приходится настраивать приложение заново. А это дополнительное время.

Как DevOps улучшает процесс разработки

У нас в digital-агентстве «Атвинта» я настроил процессы таким образом, что сборка проекта, запуск автотестов и деплой на тестовый сервер происходят автоматически, а на продакшн — полуавтоматически. Если какой-либо из этапов завершился неудачно, разработчик получит оповещение.

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

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

Для единообразия окружения используем инструмент Docker.

После того как разработчик сделал определенный функционал, он отправляет код в репозиторий. Там вступает в работу процесс, называемый Continuous Integration/Continuous Delivery — непрерывная интеграция и непрерывная доставка (далее CI/CD).

Если процесс сборки и автоматического тестирования прошел успешно, приложение разворачивается на тестовом сервере (staging server), где специалист по QA проводит ручное тестирование либо тестирование с применением инструментов вроде Selenium — для автоматизации действий веб-браузера в случае веб-приложения.

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

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

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

Инструментарий для DevOps

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

  • Управление конфигурацией серверов: Ansible, Chef, Puppet.
  • Для непрерывной интеграции и доставки (CI/CD): GitLab, Jenkins, TeamCity, Drone.
  • Сбор данных для мониторинга: Prometheus, Telegraf, LogStash.
  • Для отображения собранных данных: Grafana, Kibana, Zabbix.
  • Мониторинг ошибок: Sentry, Rollbar.

Ansible — система управления конфигурациями, написанная на Python с использованием декларативного языка разметки (yaml) для описания конфигураций.

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

GitLab — система контроля версий со встроенной CI/CD.

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

Для мониторинга нагрузки серверов используется довольно популярный стек: Grafana + InfluxDB + Telegraf.

Grafana — это платформа с открытым исходным кодом для визуализации, мониторинга и анализа данных.

InfluxDB — база данных для хранения собранной статистики.

Telegraf — агент, который устанавливается на сервер и пересылает метрики, а также логи в базу InfluxDB.

Кому и для чего применять

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

Применение методологии DevOps поможет наладить бизнес-процессы и ускорить выход обновлений.

DevOps: как обойтись без контейнеров

Методологию DevOps часто отождествляют с контейнерами. Многие компании и вовсе игнорируют её потенциал, полагаясь лишь на них. Ведущий инженер компании Perrone Robotics Эрик Бруно поделился с изданием InformationWeek опытом использования DevOps-практик, которые исключают использование контейнеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DevOps – что это и почему без него не обходится ни один успешный проект?

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

Все компании, которые мне известны, создавались, развивались и росли постепенно. Какие-то быстрее, какие-то медленнее. Как это обычно происходит с точки зрения ИТ-сотрудников? Упрощённо картина выглядит так: у некого бизнеса возникает потребность в информационных технологиях, как правило — на очень ранней стадии. Появляются специальные ребята, айтишники. Среди них есть несколько программистов, несколько администраторов, и один из них становится к тому же руководителем этого отдела (в своём резюме он потом напишет: «возглавил вновь созданное структурное подразделение»). Заметим, что все эти айтишники занимаются непосредственными обязанностями по нанесению пользы. Не пишут бумажки, не рисуют планы, не согласовывают стратегии, а делают дело. Включая начальника.

Компания растёт. Ребята не справляются, не успевают, поэтому нанимают новых, дополнительных. Есть поверие, что эффективно управлять более чем семью сотрудниками невозможно, поэтому ресурсы (простите за цинизм) объединяются в небольшие группы, у каждой из которых возникает выделенный или не очень руководитель, подчиняющийся вышестоящему, который подчиняется ещё выше, и так далее. Уровней управления в среднего размера компании может быть до пяти-семи: департамент, служба, управление, отдел, группа, я даже встречал термин «бюро». Выкручиваемся как можем.

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

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

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

Второй неудобный вопрос — предположим, мы хотим сохранить руководителей в командах, пусть на время. Откуда их взять? Понятно же, что просто назначить бывших руководителей отделов на роли тим-лидов — тупиковая ветка, от них теперь требуются другие знания, другие умения, готовность экспериментировать, осознание временности своей роли, создание новой культуры выполнения работ и так далее. Назначить тех же бывших начальников — такое же зло и глупость, как переквалифицировать бывших руководителей проектов в скрам-мастеров (чем все вокруг занимаются, похоже).

Следующий неудобный вопрос — куда девать армию бывших начальников? Они все появились в компании не просто так. Каждый когда-то был нужен и важен. Многие очень хорошо знают предметную область, особенности организации, да и даже особенности отдельных личностей — как исполнителей, так и смежников, сотрудников бизнес-подразделений. Терять такое знание (недокументированное нигде) никак не хочется, но и создавать искусственные должности для тех, кто теперь не особо нужен, также странно. Ведь за это придётся кому-то заплатить, и, вспоминая уровень зарплат и бонусов, заплатить немало.

И последний неприятный вопрос. Как теперь первому лицу в ИТ (CIO, либо ИТ-директору — в зависимости от компании понимание первого лица разнится) обеспечить управляемость конструкции? Более того, как эта конструкция будет выглядеть? Нам всем понятна и привычна иерархия — все компании вокруг устроены именно так, наши и нанимаемые сотрудники мыслят в терминах подчинённости и орг.структуры. А вот что такое сеть, или холакратия, нам известно только из литературы, даже пример в дикой природе толком не найти.

Я не случайно назвал свою заметку «Неудобные вопросы» — ответов я давать не предполагал, так как по многим пунктам у меня пока есть только соображения, но не опыт. Сейчас мне важно и интересно, что вы думаете по данной теме. Актуальны ли эти вопросы? Есть ли на них ответы? Есть ли у вас опыт перестройки от иерархии в новую прекрасную реальность? Существует ли она больше, чем в чьём-то воображении?

Devops — расширяя сознание

Содержание статьи

В былые времена после каждого «дефейса» герои хацкеры винили неких «сисадминов»: мол, если он такой ламер, что не смог обновить или настроить систему, то и поделом ему. Прошло уже немало времени, и хакерские приемы поиска и эксплуатации уязвимостей развиваются семимильными шагами, методы безопасной разработки приложений также совершенствуются, не говоря уже про механизмы ОС. А что же со старыми добрыми «сисадминами»? Эволюционировали и эти ребята. Сегодня мы поговорим об одном довольном модном концепте — DevOps, и, конечно же, говорить мы будем с точки зрения безопасности!

DevOps

Раньше были некие разработчики, они писали какой-то код; были сисадмины, они настраивали и ставили серверы, потом на эти серверы накатывали приложения, написанные разработчиками. Так люди и жили, пока не возникла потребность в гибком управлении всем этим делом и увеличении темпов выкладки билдов и релизов. Теперь уже надо накатывать приложения несколько раз в день, и при этом на разных серверах с разной конфигурацией. Сложность задач росла, а время решения надо было сокращать, при этом не сильно повышая стоимость решения. Для этого отношения между разработчиками, тестировщиками и админами нужно унифицировать и «упростить» (читай: автоматизировать). В итоге сообщество профессионалов представило новый концепт — DevOps. Как видно из названия, это «разработка и операции» в одном флаконе. То есть админские ИТ-задачи, связанные с развертыванием, конфигурированием и прочим, ложатся в новую парадигму отношений разработчик — админ — тестировщик — кто-угодно-еще. Если сказать другими словами, то задачи развертывания и настройки платформы управляются командой разработчиков через некий унифицированный «интерфейс». То есть это методология разработки и развертывания как единого процесса. Вся это идея в том числе поддерживается такими простыми и понятными вещами, как автоматизация развертывания, стандартизация конфигураций, описание инфраструктуры кодом. Все эти темы существовали и раньше, но, разумеется, их можно и нужно использовать как инструменты для реализации DevOps. Таким образом, ИТ-решение в виде сервера, виртуалки, ОС, пакетов и конфигов — это часть финального продукта, который «разрабатывается» командой, а не настраивается какими-то админами, хотя все это довольно спорно и зависит от точки обзора. Тем не менее раз это «разрабатывается», то, значит, и тестируется, и тут мы говорим про интеграционные и непрерывные тесты и уже в контексте всего продукта, вместе с платформой, а не только кода приложения. Очевидно, что это плюс, в том числе и для ИБ!

DevOps и ИБ

Важно понять, что DevOps — это не какие-то «технические» решения, а идеология управления развертывания и выпуска. Вся это автоматизация, виртуализация, контроль конфигураций существовали и раньше, это просто инструменты, которые помогают поддерживать процесс, не более. Если говорить про DevOps как идею, то в некотором смысле это продолжение Agile, только в контексте платформы. В прошлом выпуске я рассуждал, что в Agile вопросы безопасности кода переходят на сторону команды. Абсолютно такая же ситуация и тут — вопросы безопасной настройки, конфигурации и ИТ-поддержки переходят на сторону команды. Так вот, что может сделать инженер ИБ, так это реализовать требования, гайды и прочее по правильной настройке компонентов, правильному деплою и так далее. Более того, мы можем делать тулзы, различные автоматизированные решения, системы мониторинга и прочие плюшки, которые не позволят командам DevOps совершить ошибку, даже если они что-то проморгали в гайдах. Таким образом, основным инструментом для нас станет всевозможная автоматизация вопросов ИБ.

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

Реализовать хороший DevOps-процесс без хорошей автоматизации — нереальная задача, поэтому большая часть проблем решается автоматизацией. Нам нужно развертывание серверов (виртуалка), накатка нужных пакетов, их конфигурация и потом уже тестирование. Чтобы автоматизировать такие штуки, мы должны иметь унифицированный подход, что, с одной стороны, ограничивает нашу гибкость, но с другой — повышает производительность. Хотя все это опять же вопрос архитектуры DevOps-системы. Тем не менее это означает и плюсы — идентичность конфигураций, то есть стандартизация в хорошем смысле этого слова! Таким образом, мы подготавливаем стандарты конфигурации для пакетов, даем инструмент управления этими конфигурациями, если нужна гибкость (а она нужна), автоматизируем задачи развертывания и тестирования. В результате у нас будет нечто вроде фреймворка для создания продукта. Для разработчиков конкретного приложения это может быть удобным инструментом, он может не знать детали — ему просто нужен Апач, но то, что этот Апач будет сконфигурирован нужным и эффективным способом, уже решит ряд вопросов при тестировании, в том числе и безопасности.

1. Стандарты

Уже было сказано, но повторим еще раз: иметь темплейты и стандарты конфигурации для используемых вещей — это круто, молодежно и безопасно. Мы знаем, как правильно настраивать SSHd, Apache, php.ini или Tomcat, — отлично, пользуемся этими темплейтами как стандартами и автоматизируем их использование. Главное — предоставить механизм для гибкости, API и/или расширенную возможность конфигурации, ведь конфиг, скажем того же Апача, дело уникальное, и на разные проекты может требоваться разная конфигурация. Кроме того, мы можем и должны предоставлять конфигурацию ОС, типа маски доступа к файлам, владельцев + noexec на /tmp /dev/shm/tmp и так далее. При автоматизации все это довольно круто улучшит положение дел, особенно если сюда добавить SELinux/AppArmor.

2. Безопасность из коробки

Нам нужен мониторинг за событиями, HIDS, WAF и конфигурация этого дела для контроля за ИБ сервера? Так интегрируй эти решения, в чем вопрос! Например, почему бы нам не расставлять rkhunter на все серверы и настраивать его по крону на проверки раз в сутки, а кроме того, и какой-нибудь скрипт для контроля целостности. В общем, эту идею можно развивать до бесконечности, главное, что мы хотим иметь контроль и механизмы оповещения о нарушениях и можем автоматизировать развертывание и настройку этого дела, и для команды разработчика эти требования будут выполняться «автоматически» и прозрачно.

3. Тестирование

Включение security-тестов в процесс интеграционного и непрерывного тестирования. При таком раскладе, грубо говоря, на каждый новый билд мы будем запускать сканер и/или скрипт проверки безопасности из коробки, да что удобно — как лучше тестировать, так и тестируешь! Главное, что мы не «забыли» и контролируем этот процесс. Один из примеров — деплоим новый виртуальный сервер на AWS и сразу же добавляем его DNS-имя в сканер безопасности, который просканит его и будет держать в листе для сканирования, пока сервер есть. Кроме того, тестировать можно и изнутри. Например, у нас есть скрипт, который проверяет, что все настройки на сервере соответствуют требованиям ИБ, и, как только сервер разворачивается для тестирования, этот скрипт пробегает детально по всем пунктам, и если он что-то определил, то это возвращается в тест-результатах.

4. Автоматизируй все, что можно

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

Вместо тысячи слов

Как уже ясно, с точки зрения организации ИБ DevOps очень похож по идеологии с Agile. Только если там мы говорили про разработку кода, то тут про разработку конфигурации. Мы переносим ответственность за конфигурации с команды системных инженеров на команду разработчика, но при этом нам надо иметь и контроль и уверенность в том, что команда все будет делать правильно. Доверяй, но проверяй — главный принцип ИБ в DevOps/Agile. Все проблемы те же и решаются очень похоже: гайды, треннинг, автоматизация. Вообще, движение в эту сторону, что DevOps, что Agile, говорит о потребностях в быстрой и эффективной разработке и такой же быстрой и эффективной выкатке билдов и сервисов, поэтому вопросы ИБ будут касаться не только финального продукта и процесса, но и сервисов и процедур, которые поддерживают этот ваш DevOps. Ведь если мы совершим ошибку или наша автоматизация будет иметь слабое покрытие и малую глубину — то подвержены этой проблеме будут все «выпущенные» сервисы! Так что, кроме очевидных плюсов, имеются и очевидные минусы. Веселого тебе DevOps’а и да пребудет с тобой Сила!

Почему вам не нужен DevOps и как его внедрить, если очень хочется

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

Когда не нужен девопс

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

Кроме того, иногда не стоит внедрять DevOps и в «тяжелый enterprise», несмотря на то, что изначально этот подход был придуман для решения проблем именно корпоративного ИТ-мира. В частности, для «монолитных» приложений, когда все функции программы реализованы в едином структурированном пространстве взаимосвязанных файлов и пакетов, DevOps в чистом виде не нужен. Несмотря на растущую популярность микросервисной архитектуры, ее поддерживают далеко не все программные решения. Например, очень многие, особенно давно существующие, финансовые системы (в банках, процессинговых услугах) организованы по принципу «монолита», который они только сейчас постепенно начинают «распиливать» на микросервисы. Именно в этом ключе они присматриваются к интегрированным концепциям DevOps [1]. Ведь в «монолите» обновления не так часты и справляться с выпуском нескольких сборок раз в 2-4 недели вполне по силам одному специалисту, без привлечения сложных средств автоматизации. А если система состоит из множества отдельных модулей, которые постоянно обновляются с разной регулярностью, потребуется уже автоматизированное решение для поставки готового продукта в работу [2].

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

Наконец, DevOps предполагает не только использование новых инструментов и перекраивание процессов, но и изменение самой корпоративной культуры. Если сотрудники или руководство игнорируют принципы и ценности подхода, не стоит тратить время и ресурсы на попытки его адаптации. В частности, опыт «Манго Телеком» показывает, что, несмотря на поддержку принципов Agile, внедрить DevOps в Scrum-команду не так просто, т.к. сотрудники не могут/не хотят отвлекаться на нововведения, когда необходимо уложиться в спринт. Кроме того, для автоматизации существующего процесса необходима документация, ценность которой не слишком высока в гибких методологиях, и потому ее полнота и качество могут не соответствовать нужному уровню актуальности [3].

Успех внедрения зависит от окружения

Как внедрить DevOps, если он не походит, но очень хочется

Тем не менее, даже тяжеловесные мастодонты (банки, нефтегазовая отрасль, машиностроение и др. отрасли промышленности) соблазняются преимуществами, которые обещает Agile вообще и DevOps в частности. Поэтому вопрос о внедрении звучит не так: «Быть или не быть?», а «Как сделать хорошо, быстро, просто и не слишком дорого?».

Как и любая идея, DevOps невозможно внедрить в чистом виде – на практике каждая компания старается взять из этого подхода самое лучшее, адаптировав его под свою специфику и вводя в пользование постепенно. Например, как это сделал «Центр Финансовых Технологий» — отечественная компания с несколькими офисами, распределенными по всей стране, которая занимается разработкой ПО для финансового сектора [1].

Постепенное внедрение девопс можно свести к следующим шагам [4]:

  1. Четко сформулируйте задачи, которые вы хотите решить с помощью девопс, например, обеспечивать выпуск 100 работоспособных сборок ежедневно, создать конвейер развертывания и т.п.;
  2. Обсудите решение с командой (разработчиками, тестировщиками, администраторами, техподдержкой), чтобы определить самые проблемные места в процессах и выбрать, какие инструменты автоматизации стоит внедрять прежде всего.
  3. Обеспечьте сотрудникам понимание и принятиеCALMS — 5 главных принципов DevOps: культуры, автоматизации, бережливости, измерений и общения. Перестройте бизнес-процессы и организацию команд вокруг продукта, а не по функциональному разделению.
  4. Автоматизируйте ту часть IT-процессов, которая больше нуждается и подходитдля этого, например, тестирование или подготовка окружений на сервере для рабочего решения. Определите метрики для оценки успешности автоматизируемых процессов.
  5. Анализируйте изменения: процессы, отношение сотрудников, ключевые показатели. Покрывают ли результаты от использования DevOps усилия, потраченные на внедрение этого подхода? Если нет, необходимо вернуться к шагу 1, пересмотреть поставленные задачи или попробовать другие организационные и технические инструменты. Если польза от частичного внедрения DevOps уже видна, следует масштабировать подход на другие процессы и проекты.

Поэтапное внедрение — лучший путь адаптации DevOps

Почему DevOps – не панацея: проблемы после внедрения

Однако, как уже было отмечено ранее, DevOps не является серебряной пулей для решения всех ИТ-проблем. Более того, использование этого похода способно спровоцировать новые, в частности [3]:

  • временноепадение производительности труда в начале использования новых методов организации работы и технических инструментов, т.к. команда только привыкает к изменениям. Это может негативно отразиться на финансовых результатах, поэтому не стоит делать глобальные выводы о неэффективности девопс по первым неудачам.
  • DevOpsне работает «в одиночку» — не стоит ждать тотального сокращения сроков вывода продукта на рынок, внедрив его только в ИТ-процессы. Если маркетинговые исследования, как и раньше, длятся годами, ускорение разработки, тестирования и развертывания ПО, не поможет быстрее доставить продукт потребителю. Поэтому, например, Райффайзенбанк расширяет ценности DevOps и на другие бизнес-процессы.
  • расширение штата сотрудников, выполняющих аналогичную работу, и увеличение объема работ – к примеру, если, согласно Agile-принципам быстрого реагирования на запросы клиентов, техническая поддержка постоянно создает новые заявки, необходимо увеличивать частоту релизов. Это, в свою очередь, приводит к найму новых разработчиков, тестировщиков и эксплуатационщиков, но не всегда кардинально повышает прибыль от итогового продукта, как справедливо отмечает директор по разработке ПО в группе «Альфастрахование».
  • повышение квалификационных требований к сотрудникам (DevOps-инженерам), которые должны глубоко разбираться во множестве технологий. Таких профессионалов на ИТ-рынке немного и стоят они достаточно дорого. А популярность термина DevOps привела к еще большему ажиотажу вокруг этого понятия. Есть такая расхожая шутка, что системный администратор со знанием Docker от DevOps-инженера со знанием Docker, отличается не знаниями, а зарплатой: 1 девопс стоит как 2 администратора [5].

Внедрение методов и инструментов — это средства, а не цель

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

Как взять лучшее от девопс и не навредить бизнесу, а также получить реальную выгоду от гибких подходов к разработке ПО и управлению проектами, мы рассматриваем на практическом курсе «Аналитика больших данных для менеджеров» в нашем учебном центре для руководителей, аналитиков, архитекторов, инженеров и исследователей Big Data в Москве.

Ссылка на основную публикацию