Как разработчику «влиться» в тему DevOps20.02.2016 12:03

30b3cb09f64d4f8380835e949f533f3a.jpg

Сегодня мы решили взглянуть на ситуацию с Java- и Python-разработчиком, который задумался о «погружении» в тему DevOps в тот момент, когда он начал все больше отдаляться от привычных инструментов в пользу работы с Oracle Weblogic и shell-скриптами. Он решил совместить свой опыт в области разработки с новым опытом в работе с процессами.

Мы посмотрели на основные советы экспертов в области DevOps на Quora и дополнили рассказ примерами из опыта команды 1cloud.

Джонатан Феноччи (DevOps разработчик в Bazaarvoice): Мне очень нравится работать в сфере облачных технологий и заниматься темой DevOps. Зачастую, этот термин используют, чтобы описать системных программистов (иногда также называют инфраструктурными разработчиками, системными разработчиками, разработчиками процессов (операций), или, самым неподходящим способом, системными администраторами).

DevOps означает совсем не это, но в контексте карьерного роста, в этих определениях отражается понимание того, чем занимается «современный» системный программист.

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

Что подразумевает под собой работа в области DevOps:

  • Разработку ПО;
  • Разработку инструментов;
  • Инфраструктурное проектирование;
  • Регулярное решение сложных задач;
  • Масштабирование, потому что оно необходимо;


  • *NIX;
  • Мониторонг;
  • Виртуализация;
  • Быть на связи при отключении электричества в 2 часа ночи;
  • Техническое обслуживание (например, решение проблемы с утечкой памяти виртуального хоста);


  • Гибкая методология разработки;
  • Циклы выпуска ПО и контроль за ними;
  • Автоматизация, автоматизация и снова автоматизация;
  • Метрики/отчетность (идут параллельно с мониторингом);
  • Разработка плана по использованию веток и релизов продукта для конкретных СУВ (SCM) (git, Mercurial, svn, др);


  • ИБ;
  • Облачные технологии;
  • Оптимизация/тонкая настройка;
  • Тестирование и замеры уровня нагрузки/производительности;
  • Управление конфигурацией (Puppet, Chef, Ansible, и прочее);


  • Сервисы аутентификации;
  • Системы управления пакетами;
  • Умение работать с командной строкой (awk);
  • Балансировка нагрузки/ проксирование (служб, систем, компонентов и процессов);
  • CI/CIT/CD — непрерывная интеграция, интеграционное тестирование и развертывание новых версий (deploy);


  • Базы данных (SQL, NoSQL, без разницы);
  • Уверенное знание систем (сетевого стэка, жесткие диски/файловые системы/системная память/процессор).


Что НЕ подразумевается под работой в области DevOps: 


  • Простота (по сравнению с разработкой ПО);
  • Отсутствие необходимости программировать;
  • Установка Linux и прощание с твоей любимой ОС;
  • Намного «интереснее», чем разработчик ПО;
  • Совершенно новая область работы.


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

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

Получить опыт работы используя свои навыки разработчика ПО для построения инструментов, а не ПО. Изучить OpenStack. Важно понимать различие компонентов и их важность.

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

Нужен ли существенный опыт? Я задавал этот вопрос себе множество раз. Я начинал с разработки, и менее чем за год работы с операциями стал DevOps-разработчиком. Я не обладал заметными алгоритмическими способностями, но опыт разработки у меня был приличный. Хороший разработчик хорош во всем: и в написании ПО, и в его развертке. Необходимо понимание сложности систем и интуитивное понимание того, как они все влияют друг на друга.


Ярослав Ворожко (DevOps разработчик в Delivery Hero): По большому счету, DevOps затрагивает очень широкий круг знаний, с которым сложно и интересно работать.

Вот как выглядит моя обычная рабочая неделя:

  • Развертывание (выпуск ПО и автоматизация развертывания ПО на Fabric и Python);
  • Управление инцидентами (работа с возникающими проблемами, написание восстановительных процедур и мониторинг);
  • Мониторинг ПО, находящегося в эксплуатации (Icinga, Newrelic, Munin, управление логами, например, с помощью Splunk);
  • Управление конфигурацией (Saltstack, Chef, Puppet и Ansible, весь стэк служб, которые необходимы для работы приложения);
  • Написание различных скриптов (с bash и python, работа с awk, sed, grep, sort, uniq, cat, cut, echo, fmt, tr, nl, egrep, fgrep, wc).


Мы решили привести и пару примеров из практики команды 1cloud.

Так, технологический стек back-end разработчика составляет: .NET, C#, ASP.NET MVC, Visual Studio, Team Foundation Server.

С точки зрения API, SDK: Vcloud SDK .NET, vSphere SDK .NET, NetApp Manageability SDK C#.

Управление инцидентами осуществляется с помощью ServiceNow, для мониторинга используется Zabbix. Для работы с различными скриптами применяется bash, PowerShell. В дальнейшем планируется переход на управление конфигурацией с помощью Puppet.

Вот так выглядит список ежедневных задач администратора систем Microsoft:

  • Решение пользовательских инцидентов;
  • Выполнение заявок пользователей;
  • Работа над текущими проектами (настройка серверов на базе Windows Server для предоставления клиентам сервисов: терминальные службы, MS SQL и других);
  • Планирование изменений (cоставление планов перед проведением работ на серверах — ServiceNow);
  • Общение с вендорами по проблемам в работе с ПО;
  • Написание скриптов для автоматизации проводимых работ (PowerShell);
  • Анализ событий от системы мониторинга (SCOM).


Базовые обязанности менеджера по информационной безопасности:

  • Мониторинг событий ИБ в Security Information and Event Management system (SIEM) AV USM, в TrendMicro Deep Security, PaloAlto 2050, WAF ModSecurity;
  • Управление уязвимостями ИБ, проведение внутреннего и внешнего сканирования (OpenVAS на основе AV USM и Qualys);
  • Получение лицензии ФСТЭК на ТЗКИ и ФСБ «на криптографию» (аттестация помещения и АРМов, сбор и подготовка документов);
  • Проведение обучения работников по вопросам ИБ;
  • Управление инцидентами (работа с возникающими проблемами, написание восстановительных процедур и мониторинг).


P.S. Парочка дополнительных материалов о работе над нашим облачным сервисом на Хабре:

© Habrahabr.ru