Category: DevOps

22
Фев
2022

📜 20 самых ценных ИТ-сертификатов для системных инженеров

Почему профессиональные сертификаты так востребованы в портфолио инженера? Какие преимущества сертификаты дают специалисту? И какие ТОП-20 сертификаций необходимы системному инженеру? Мы постарались собрать ответы в этой статье.

27
Янв
2022

👽 Гиперконвергенция – это что-то из области математики? (нет) Объясняем, что это и почему она может вам пригодиться

Без снобизма о гиперконвергенции.

Гиперконвер… что? Можно поподробнее?

Термин «гиперконвергенция» описывает класс строительных блоков для ИТ-архитектуры. Такие блоки максимально стандартизированы и в одном устройстве объединяют вычислительные ресурсы, хранилище данных и другие компоненты. Например, гиперконвергентная система HPE SimpliVity 380G Gen10 предоставляет вычислительные ресурсы и распределенное хранилище данных со встроенными механизмами дупликации и сжатия, а также дополнительный набор функций для резервного копирования. При этом управление всеми процессами осуществляется через плагин, устанавливаемый в консоль гипервизора.

Скажите как есть: гиперконвергенция лучше или хуже традиционной трехуровневой архитектуры?

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

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

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

Подробную информацию о новых продуктах и решениях, новости компании, советы и инструменты для бизнеса, расписание вебинаров и мероприятий вы можете найти в наших соцсетях https://t.me/hpedigitize и https://m.vk.com/hperussia.

Ок. А что выбрать мне?

Здесь все зависит от задачи. Классическая гиперконвергентная система HPE SimpliVity 380G Gen10 отлично подходит для установки в крупной филиальной сети или в небольших офисах за счет простого управления большим количеством территориально распределенных кластеров. Положительно сказывается и возможность обеспечения высокой доступности в двухузловой конфигурации, наличие встроенной системы резервного копирования виртуальных машин и возможность оптимизации передачи данных между кластерами за счет механизмов сжатия и дедупликации данных.

Дезагрегированная гиперконвергентная система HPE Nimble Storage dHCI подходит для использования в центрах обработки данных для размещения приложений с высокими требованиями к производительности и «асимметричным» масштабированием ресурсов. Она обладает следующими преимуществами:

  • Механизмы отказоустойчивости корпоративной СХД с гарантией 99,9999% доступности.
  • Высокая и хорошо предсказуемая производительностью хранилища.
  • Глобальная дедупликация и сжатие данных «на лету» с гарантией HPE Store More.
  • Унифицированное управление всеми ресурсами через плагин VMware vCenter.
  • Возможность комплексной предиктивной аналитики с помощью HPE InfoSight.

Если коротко, из каких компонентов составить решение?

Дезагрегированное решение HPE Nimble Storage dHCI состоит из следующих компонентов:

  • Система хранения данных HPE Nimble или HPE Alletra 6000 со встроенным программным обеспечением dHCI Stack Setup, dHCI Stack Manager и dHCI Stack Upgrades;
  • Серверов HPE ProLiant 300-й или 500-й серии;
  • Двух 10 или 25 Гбит/с Ethernet коммутаторов для центров обработки данных;
  • Гипервизора VMware vSphere.

Данное решение также может быть развернуто на уже имеющихся у заказчиков серверах HPE ProLiant 9-го и 10-го поколений.

Звучит интересно. Есть тест-драйв?

Одно дело описать преимущества, и совсем другое – увидеть их в действии. Ознакомиться с HPE Nimble Storage dHCI можно прямо сейчас на тест-драйве со следующим набором функций:

  • Мониторинг состояния всего решения из единого интерфейса.
  • Управление ресурсами через гипервизор.
  • Быстрое добавление серверов в кластер и обновление ПО на всех компонентах в один клик.
19
Ноя
2021

«Чёрная пятница» в GeekBrains

На выбор есть факультеты, профессии, программы и курсы по 7 направлениям: программирование, IT-инфраструктура, аналитика, дизайн, маркетинг, менеджмент и школьникам.
— Читать дальше ««Чёрная пятница» в GeekBrains»

08
Ноя
2021

∞ 11 лучших каналов YouTube, посвященных DevOps

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

27
Окт
2021

Не работает код GD php

Делаю обработку изображения с помощью расширения GD. У меня локально всё работает, на деве и проде проекта нет, картинка загружается но кода GD как будто нет вообще, проходит мимо. Но дело в том что сборка у нас 1 в 1. phpinfo 1 в 1. В чем…

01
Окт
2021

Какое из 8 направлений IT-стажировки вам подходит? Тест от Tproger и Kaspersky

Шуточный тест, чтобы определить, какое направление стажировки SafeBoard может вам подойти. Просто выбирайте решения, которые вам ближе всего.
— Читать дальше «Какое из 8 направлений IT-стажировки вам подходит? Тест от Tproger и Kaspersky»

30
Сен
2021

∞ ТОП-10 актуальных книг по DevOps: от новичка до профессионала

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

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

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

Книги на русском языке

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


Авторы: Джез Хамбл, Джон Уиллис, Патрик Дебуа.

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

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

Хотя это не техническая книга, она дает четкое понимание методологии и описывает профессиональные практики, которые необходимо учитывать во время трансформации компании и внедрении DevOps.

Книга также наполнена реальными сценариями и опытом таких компаний, как Etsy, Nordstrom, Google, Facebook, Alcoa и Target.

Подходит для новичков.

Отзывы:

Книга хорошо и подробно описывает вопросы перехода от традиционных разработки и эксплуатации к подходам DevOps, со многими сложностями и подводными камнями на этом пути (многие книги зациклены на том, как все сделать правильно сразу – т.е. стартап). Большой плюс – в наличии целой главы, посвященной вопросам безопасности и соответствия государственным/отраслевым нормам. Success stories приятно разбивают повествование, давая голове отдохнуть.
Источник: Ozon.ru.

2. Ускоряйся! Наука DevOps. Как создавать и масштабировать высокопроизводительные цифровые организации


Авторы: Джез Хамбл, Джин Ким, Николь Форсгрен.

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

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

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

Отзывы:

Хорошая книга, дает понимание основных понятий по DevOps. В плане практического применения больше подходит для аналитиков, чем для инженеров, но будет полезна и тем, и другим.
Источник: Ozon.ru.
Конечно, эту книгу взахлеб будут читать руководители и сотрудники ИТ-компаний. Но она не только для них. Она для всех нас, коллеги!
Книга дает главное – методологию масштабирования вашей компании и бизнеса. И полезные прикладные практики работы.
Источник: litres.ru.

3. Unix и Linux: руководство системного администратора


Авторы: Эви Немет, Гарт Снайдер, Трент Хейн.

Руководство по установке, настройке и обслуживанию любой системы Unix или Linux, включая системы, обеспечивающие базовую интернет-инфраструктуру и облачную инфраструктуру.

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

Подходит для новичков.

Отзывы:

Отличная книга для тех, кто хочет разобраться с администрированием систем. Сам до этого ничего не изучал по этой теме и скажу, что книга дает основы, понимание концепции в целом. Дальше разобраться с любой конкретной системой проблем не будет.
Источник: litres.ru.
Когда-то эта книга была моей первой книгой по Linux. Рекомендую для начинающих админов. Материал изложен понятно, но рассчитывать, что в одной книге вам подробнейшим образом расскажут и про sendmail и про bind не стоит. Идеальна для получения ОБЩИХ представлений об ОСНОВНЫХ вещах.
Источник: livelib.ru.

4. Осваиваем Kubernetes. Оркестрация контейнерных архитектур


Автор: Джиджи Сайфан.

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

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

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

Отзывы:

Отлично подойдет для знакомства с технологией, в противовес чтения документации на английском. Легко читается, изложены все ключевые концепции. Но местами идет описание каких-либо ресурсов или компонентов переведенных на русский. Нужно ловить себя на мысли, что речь сейчас идет именно о DeploymentConfig, который в тексте звучит как «конфигурация развертывания», немного странно.
Источник: Ozon.ru.

5. Использование Docker


Автор: Эдриен Моуэт.

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

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

Подходит для новичков.

Отзывы:

Замечательная книга для кодера, который хочет выйти из каменного времени классического развертывания приложения и начать работать с кластерами облачных технологий.
Некоторые моменты устарели, однако, это не недостаток книги т.к. описание от чего шел проект Docker позволяет понять почему он сделан именно так.
Источник: Ozon.ru.
Нужна была книга для «быстрого старта», в итоге, она подошла для этого – прекрасно. Главное, что получилось развернуть кластер с её помощью.
Источник: litres.ru.

Книги на английском языке

6. Learning DevOps: The complete guide to accelerate collaboration with Jenkins, Kubernetes, Terraform and Azure DevOps


Автор: Mikael Krief.

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

Затем вы ознакомитесь с управлением версиями исходного кода с помощью Git и построением конвейера CI/CD с использованием Jenkins, GitLab CI и Azure Pipelines. Эта книга также поможет в создании контейнеров и развертывании ваших приложений с помощью Docker и Kubernetes.

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

Отзывы:

Книга позволяет узнать о различных инструментах, используемых в DevOps. Помимо объяснения на очень хорошем уровне, в книге есть ссылки для просмотра исходного кода в репозиториях Git. Рекомендую!
Источник: Amazon.com.

7. Infrastructure as Code: Dynamic Systems for the Cloud Age


Автор: Kief Morris.

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

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

Книга подходит для инженеров DevOps и системных администраторов.

Отзывы:

Эта книга полна отличной информации о том, как управлять кодом IaC. Кроме того, полно шаблонов и анти-шаблонов, которые специально предназначены для кода IaC.
Источник: Amazon.com.

8. Operations Anti-Patterns, DevOps Solutions


Автор: Jeffery D. Smith.

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

Книга подходит как для DevOps-инженеров, так и для ИТ-менеджеров.

Отзывы:

В этой книге рассматриваются сценарии, с которыми вы, скорее всего, столкнетесь на работе, объясняется, почему многие решения, основанные на здравом смысле, терпят неудачу, и предлагаются отличные решения, которые можно попробовать. Книга будет полезной как для DevOps-инженеров, так и для менеджеров. Ее можно читать от корки до корки, содержит много информации, но при этом легкая в чтении с небольшой долей юмора.
Источник: Amazon.com.

9. DevOps Adoption Strategies: Principles, Processes, Tools, and Trends: Embracing DevOps through effective culture, people, and processes


Автор: Martyn Coupland.

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

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

Подходит для новичков.

Отзывы:

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

10. Engineering DevOps: From Chaos to Continuous Improvement…and Beyond


Автор: Marc Hornbeek.

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

Книга состоит из пяти частей:

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

Книга подходит как для DevOps-инженеров, так и для ИТ-менеджеров.

Отзывы:

Независимо от вашего уровня знаний, эта книга поможет полностью заполнить пробелы. Несколько человек давали мне разные объяснения методологии DevOps, но только эта книга стала для меня исчерпывающим и авторитетным источником информации. Есть много ссылок, которые можно дополнительно использовать в обучении, а в дополнениях книги есть полезные рабочие листы.
Источник: Amazon.com.
Мы собрали актуальные книги для специалистов DevOps, вышедшие за последние несколько лет. Удачи в изучении одного из самых перспективных и высокооплачиваемых направлений в сфере ИТ!

***

Если вы находитесь только в начале пути, стоит обратить внимание на курс Факультета DevOps образовательной онлайн-платформы GeekBrains. Эксперты-практики из ведущих российских технологических компаний научат вас использовать методологии Agile и Scrum, оптимизировать CI/CD и работать с облачными технологиями. Курс подойдет как новичкам в IT, так и опытным специалистам, которые хотят сменить направление.

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

Успешно окончившим курс студентам HR-специалисты GeekBrains помогут создать резюме и предложат вакансии. Гарантия трудоустройства закреплена в договоре.

30
Сен
2021

∞ Зачем разработчику DevSecOps?

С повышением объёмов данных растёт необходимость их защиты. Здесь как раз требуется DevSecOps, где DevOps – процесс разработки и доставки программы, а частица Sec отвечает за защиту этого приложения.

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

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

Каким разработчиками требуется знания DevSecOps?

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

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

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

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

Разница между DevOps и DevSecOps

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

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

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

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

Особенности разработки

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

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

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


Важность DevSecOps

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

Методологию, кстати, можно использовать не только для разработки ПО, но и в других сферах:

  • Автомобилестроение. Сокращения времени цикла при соблюдении стандартов, вроде MISRA и AUROSAR.
  • Здравоохранение. Обеспечение цифровизации при сохранении конфиденциальности и безопасности данных в соответствии с HIPAA.
  • Финансы и коммерция. Избавление от OWASP 10 (основные риски веб-безопасности) и обеспечение безопасности данных платёжных карт по стандартам PCI DSS для транзакций.
  • Гаджеты. Предотвращение возникновения CWE 25 (самые опасные программные ошибки).

Мифы о DevSecOps

  • Для применения методологии требуются крутые спецы. Не до конца правдивое утверждение. Конечно, опытные работники со своими задачами справятся лучше, но не стоит утверждать, будто только одарённые разработчики спасут безопасность. Если же стоит задача воспитать своих программистов в рамках DevSecOps, это вполне реально.
  • DevSecOps может заменить Agile. В корне неверно. DevSecOps дополняет, а не заменяет Agile. Agile ориентирован на совместную работу и мгновенный фидбэк, но, в отличие от DevSecOps, никак не покрывает доставку ПО через тестирование, QA и производство. Совместное использование методологий позволяет закрыть все дыры.
  • Можно купить DevSecOps. Нельзя. Приобрести можно только инструменты, а сам процесс – никак. Это скорее методология разработки или философия. Ту самую совместную работу и фокус на собственной и коллективной ответственности купить не получится, только воспитать и привить.

Хорошие практики DevSecOps

Как у каждой методологии, у DevSecOps есть собственные стандартные практики, упрощающие её использование:

  • Практика безопасного кода. Пусть и очевидно, но только так можно писать хороший код, защищённый от компрометации. Да, скорее всего это создаст дополнительную задержку и расходы, но позволит избежать проблем с информационной безопасностью: утечек данных и нарушения работоспособности сервисов. Создание стандартов позволит упростить процесс разработки.
  • Автоматизация. Как и в DevOps, автоматизация является ключевой характеристикой DevSecOps. Чтобы темп проверки безопасности поспевал за темпом разработки, автоматизация должна применяться изначально, особенно в крупных компаниях. Есть и обратная сторона: выбор неправильных инструментов приведёт к большой проблеме.
  • Смещение (сдвиг) влево. Методология тестирования, когда проверка безопасности встраивается в разработку с самого начала, не дожидаясь цепочки поставки. Очевидная выгода – проблемы засекаются сразу и работа по их исправлению завершается намного раньше. К тому же, чем раньше замечается баг, тем дешевле его починить. Проблема в том, что «сдвиг влево» может нарушить рабочий процесс и потребуется время для привыкания.
  • В DevSecOps есть три «кита»: люди, процесс, технологии.
  • Люди. Если работники не заинтересованы в DevSecOps, то никак не получится добиться соблюдения всех правил. Сначала следует убедить всех, что оно того стоит. Впрочем, здесь будет несложно – в последнее время очень часто вскрывают утечки конфиденциальных данных, которые наносят огромный ущерб тем, кто их допустил. Чего стоит одна история со взломом Kaseya.
  • Процесс. Важные его части: стандартизация и документация. Обычно, разные команды выполняют разные процессы, но DevSecOps призывает к созданию согласованных и совместному их исполнению для повышения безопасности при разработке.
  • Технология. Технология и есть. Та же автоматизация, менеджмент версий проектов, методология Security as Code и прочие возможности ПО, которые обеспечивают выполнение задач.

Краткий список инструментов DevSecOps:

  • Static application security testing (SAST). Статическое тестирование безопасности приложений. Инструменты сканируют код для выявления ошибок и конструктивных недостатков, которые приводят к появлению уязвимостей. SAST в основном используется на этапах создания кода, сборки и разработки SDLC. Coverity – один из вариантов.
  • Software composition analysis (SCA). Анализ состава ПО. Сканируется исходный код и двоичные файлы для выявления известных уязвимостей в компонентах с открытыми исходниками и продуктами сторонних разработчиков. Оценивается уровень риска безопасности для приоритизации ошибок и ускорения их исправления. SCA интегрируется в CI/CD процессы для постоянного мониторинга ошибок в компонентах с открытыми исходниками.
  • Interactive application security testing (IAST). Интерактивное тестирование безопасности приложений. Инструменты работают в фоне во время ручных или автоматических тестов. Анализируется поведение веб-приложений. Например, Seeker IAST наблюдает за взаимодействиями, поведением и потоком данных между запросами и ответами приложений. Находит уязвимости, воспроизводит и тестирует результаты, предоставляя информацию разработчикам. Вплоть до строки кода, где появляется ошибка.
  • Dynamic application security testing (DAST). Динамическое тестирование безопасности приложений. По сути это автоматизированный чёрный ящик, имитирующий поведение хакера. Работает он через сетевое соединение и исследует исполнение приложения со стороны клиента. Таким инструментам не нужен доступ к исходникам или настройкам для сканирования: они работают с приложением и ищут уязвимости с низким уровнем ложных срабатываний.

Заключение

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

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

***

Если вы заинтересованы в развитии карьеры в этой сфере, стоит обратить внимание на «Факультет информационной безопасности» образовательной онлайн-платформы GeekBrains. На 70% учебная программа состоит из вебинаров с преподавателями, которым вы сможете задать все интересующие вопросы по темам и оперативно получить от них обратную связь.

Кроме того, куратор и менеджеры GeekBrains помогут освоиться и решить технические сложности на разных этапах обучения, а постоянная практика (в том числе командные соревнования по информационной безопасности в формате Capture the flag) не дадут застрять на месте.

Продолжительность обучения – один год. За это время вы освоите современные технологии и компетенции, которые необходимы специалистам по безопасности: Application Security Engineer, пентестеру, специалисту по информационной безопасности или DevSecOps-инженеру.

24
Сен
2021

Курс «Python для инженеров»

Курс заточен на системных администраторов и девопс-инженеров, Будут разбирать задачи инфраструктуры, связанные с Ansible, Docker, Kubernetes.
— Читать дальше «Курс «Python для инженеров»»

15
Сен
2021

Набор на стажировку в Dell Technologies

Dell Technologies приглашает студентов дневного отделения технических вузов Санкт-Петербурга на оплачиваемую стажировку. На выбор есть 5 направлений: программирование на Java, C++ или Python, тестирование ПО, DevOps и администрирование.
— Читать дальше…

08
Сен
2021

☸️ Первое знакомство с Kubernetes: публикация приложения в интернет

Продолжая знакомиться с Kubernetes, разберемся с проверкой работоспособности приложений (Health check probe) и рассмотрим объект Ingress, который позволит сделать приложения кластера доступными из интернета.

30
Авг
2021

TestCon Moscow 2021

Международная конференция по тестированию и обеспечению качества ПО. 3 дня докладов и мастер-классов от ведущих мировых специалистов.
— Читать дальше «TestCon Moscow 2021»

25
Авг
2021

∞ Современный подход к кибербезопасности: как внедрить в компании методики DevSecOps?

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

DevSecOps – это философия интеграции практик безопасности в процесс DevOps.

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

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

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

О внедрении методик DevSecOps нашему корреспонденту рассказал Иван Пискунов, Senior DevSecOps engineer «NewIty», Ltd. – международной компании-разработчика ПО.

Понятие DevSecOps

Если понимать DevSecOps дословно, то это безопасный DevOps. Другими словами, это именно практики разработки, внедрения и эксплуатации продукта (приложения, сайта, банк-клиент платформы, облачного сервиса и т.д.) с учетом требований к информационной безопасности.

Речь идет о превентивном выявлении недостатков кода, которые потом могли бы вылиться в уязвимости ПО (то что еще называется термином Secure SDLC или SSDLC).

Также это проработка и внедрение механизмов защиты от мошеннических операций и разного рода фрода (например, это очень актуально для банк-клиент приложений, электронных бирж и обменников криптовалюты) в разрабатываемый продукт, обеспечение безопасности облачной среды (AWS, GCP, Yandex.Cloud и т.д.), где он эксплуатируется. То есть распределение прав доступа к ресурсам, определение пользовательских ролей в системе, мониторинг Kubernetes-кластера как ядра системы, выявление инцидентов и реагирование на них.

Каким компаниям действительно нужен DevSecOps?

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

Правдивость известной фразы «Безопасность стоит дорого, но ее отсутствие еще дороже» не раз была доказана на примере крупных взломов. Например, можно вспомнить скомпрометированную цепочку поставок SolarWinds или нашумевшую атаку на Capital One в 2019 году, когда было потеряно 30 ГБ данных, содержащих записи о 106 млн. пользователей, ну и ярко отметившуюся в 2018 году cryptojacking-атаку на компанию Tesla, Илона Маска.

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

Основные преимущества DevSecOps

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

Это прежде всего снижение расходов на стадии поддержки продукта. Если еще до релиза на этапе разработки исключить критические уязвимости (CVE, CWE) и баги, то не понадобится выпускать патчи (исправления) или вовсе отзывать продукт с рынка.

Еще одно преимущество – это соответствие комплаенс-требованиям: как российским (например, ЦБ РФ для финансовых учреждений), так и международным (Cloud Security Alliance (CSA), Cloud Native Computing Foundation (CNCF), PCI DSS, GDPR и т.д.). Это дает возможность проходить аудиты соответствия требованиям контролирующих органов, получать соответствующие лицензии и сертификаты на вид деятельности (особенно критично для бирж, обменников, систем банк-клиент), подтверждать свою ответственность перед клиентами и партнерами.

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

Этапы внедрения DevSecOps в компании

Классический подход к внедрению DevSecOps описан в нескольких книгах:

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

К тому же нужно понимать, что внедрение SDLC (безопасного цикла разработки ПО) – это часть общих работ по запуску DevSecOps в компании, и они отличаются между собой по сложности и длительности. В самом простом варианте это всегда определение целей и задач, выставление требований к продукту и процессу его разработки (то что называется secure by design), планирование работ, внедрение технических и программных средств защиты, мониторинг и поддержка.

Проблемы, которые могут возникнуть при внедрении DevSecOps

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

Конкретно ИБ-шной спецификой можно назвать борьбу с ложными срабатываниями статического анализатора кода (SAST), централизованное управление секретами с минимальными издержками на производительность и удобство работы в системе, разработка кастомных правил безопасности под каждый независимый контур – Dev, Stage, Prod.

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

Как правильно внедрить DevSecOps в команде?

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

Следующий фактор – это наличие бюджета на закупку и поддержку различных средств безопасности. Нужно понимать приоритетность внедрения решений, а также обладать специфической экспертизой в некоторых тонкостях реализации защиты периметра или отдельных end-point хостов. Если бюджета нет, то на первых порах можно обойтись средствами open sources, которые, конечно, не дадут того уровня, что дают коммерческие решения, но все таки не оставят в чем мать родила.

И обязательно отмечу использование best practices от вендоров ПО, методические рекомендации и гайды специализированных проектов, таких как международного комьюнити OWASP, европейского CIS, американского стандарта NIST-800, SANS TOP 25 Most Dangerous Software Errors, матрицы MITRE ATT&CK, которые рассказывают, как лучше всего реализовать ту или иную функцию безопасности в корпоративном периметре.

Лучшие практики DevSecOps


Описание каждой практики достойно отдельной статьи. Однако можно упомянуть ключевые bullet points при внедрении DevSecOps, а именно:

  • Организация безопасного цикла разработки ПО, включающего моделирование угроз, оценку рисков, статический и динамический анализ кода, использование защищенных технологий: HTTPS/TLS, CORS, CSP, 2FA, Data encryption и т.д.;
  • Усиление текущей облачной инфраструктуры с помощью как нативных опций безопасности, предоставляемых от поставщика услуги, так и коммерческих средств и систем защиты – Web Application Firewall (WAF), SIEM и SoC мониторинг, IDS\IPS-систем, хостовых EDR, защита Kubernetes-кластера, Anti-DDoS и Load balancing и т.д.;
  • К вышеперечисленному можно добавить важность создания в компании внутренней базы знаний о проблемах безопасности, современных рисках и угрозах, типовых решениях и рекомендациях для разработчиков, тестировщиков и инженеров;
  • Сюда же можно отнести и обучение команды разработчиков правилам написания безопасного кода. Это большой вклад в общую культуру разработки, которая несомненно сделает конечный продукт лучше. Некоторые другие рекомендации можно почерпнуть из моей авторской книги «Kubernetes security. Guide for beginners from zero to hero».

Выводы

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

Согласно отчету исследовательской компании Gartner, 80% предприятий, которым не удастся к 2023 году внедрить современный подход к безопасности, столкнутся как с повышенными эксплуатационными расходами, так и с большими последствиями кибератак.

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

***

Если вы заинтересованы в развитии карьеры в этой сфере, стоит обратить внимание на «Факультет информационной безопасности» образовательной онлайн-платформы GeekBrains. На 70% учебная программа состоит из вебинаров с преподавателями, которым вы сможете задать все интересующие вопросы по темам и оперативно получить от них обратную связь.

Кроме того, куратор и менеджеры GeekBrains помогут освоиться и решить технические сложности на разных этапах обучения, а постоянная практика (в том числе командные соревнования по информационной безопасности в формате Capture the flag) не дадут застрять на месте.

Продолжительность обучения – один год. За это время вы освоите современные технологии и компетенции, которые необходимы специалистам по безопасности: Application Security Engineer, пентестеру, специалисту по информационной безопасности или DevSecOps-инженеру.

06
Авг
2021

∞ 9 главных специализаций в DevOps: какое направление выбрать осваивающему профессию новичку?

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

04
Авг
2021

☸️ Первое знакомство с Kubernetes: создаем приложение для развертывания в кластере

Изучив основы и подготовив тестовый полигон, мы переходим к практической части. Сегодня разберем, как создать первое приложение на Python + Flask и развернуть его в кластере k8s.

Мы изучили, что находится под капотом у оркестратора Kubernetes, разобрали базовые объекты и научились разворачивать кластер k8s для экспериментов. Стоит перейти к практике и написать простенькое веб-приложение на стеке Python и Flask, а затем задеплоить его в кластер.

Пишем приложение (Python + Flask)

Поскольку Python – единственный язык программирования, на котором я что-то умею писать, особого выбора у
меня нет. Приложения будет запускаться как веб-сервер, слушать
указанный порт и при обращении выдавать приветствие “Hello from Python”. Кроме Python потребуется фреймворк Flask.

Код приложения:

app.py
        from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello from Python"
if __name__ == "__main__":
    app.run(host='0.0.0.0')

    

В первых двух строчках мы подключаем Flask, а далее создаем обработку
корневого запроса. Приложение неидеально, но как минимальный вариант для развертывания в кластере k8s оно сгодится. Так как k8s – это среда запуска
контейнеров, для переноса приложение необходимо упаковать, например, в Docker.

Упаковываем приложение в контейнер Docker

Чтобы собрать контейнер, нужно поставить Docker на локальную машину (да,
да – Капитан очевидность). Инструкция по инсталляции есть на официальном сайте – процесс довольно несложен. Далее собирать образ можно
средствами Docker, я использую для этих целей утилиту buildah. Она ни разу меня не подводила, рекомендую.

Для сборки контейнера на хосте должны быть установлены Docker и buildah. Все действия я провожу в CentOS, в других дистрибутивах Linux они могут немного отличаться.

Для начала создаем директорию, из которой
будем собирать контейнер. Первый файл в директории назовем, например, app.py (его код приведен выше). Для установки зависимостей нам потребуется файл requirements.txt. Поскольку приложение простенькое, достаточно добавить только модуль Flask:

requirements.txt
        Flask==1.0.2
    

Третий
файл называется Dockerfile – без расширения. Его содержимое:

Dockerfile
        FROM python:3.9-alpine
RUN mkdir /app
WORKDIR /app
ADD . /app/
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "/app/app.py"]

    

Разберем его построчно:

  • FROM python:3.9-alpine – добавляем в контейнер интерпретатор Python 3.9, сборка alpine.
  • RUN mkdir /app – создаем директорию /app внутри контейнера.
  • WORKDIR /app – позволяет один раз указать конкретный путь (каталог на диске), после чего большинство инструкций (например, RUN или COPY) будут выполняться в контексте этого каталога.
  • ADD . /app/ – очень важная команда, если мы делаем контейнер для k8s. Дело в том что когда отрабатывает запуск контейнера, k8s думает, что нам необходима внешняя директория /app. Ее в кластере нет, и контейнер падает с ошибкой (не найден файл /app/app.py).
  • RUN pip install -r requirements.txt – запускаем pip и скармливаем ему файл зависимостей. Flask скачивается и устанавливается в контейнер.
  • EXPOSE 5000 – пробрасываем порт 5000 для общения с нашим приложением.
  • CMD [“python”, “/app/app.py”] – запускаем интерпретатор Python и наше приложение app.py.
Готово, директория в итоге должна содержать следующие файлы: app.py, requirements.txt, Dockerfile.

Находясь в директории
с файлами, выполняем команду для сборки контейнера на основе Dockerfile с
помощью утилиты buildah:

        buildah bud -f ./Dockerfile .
    

Запустится сборка, прогрузятся все зависимости из requirements.txt, и в
итоге сгенерируется хеш – строка Storing signatures, которая нам в дальнейшем
понадобится (копируем ее в буфер обмена)


Дальше необходимо запушить сборку в локальный репозиторий Docker.
Выполняем следующую команду, подставляя в параметры свой хеш:

        buildah push dedd9a5526d3c97231e9a0b73ca1e4a91ece0d70a7f7bff254f61f7d28d8e9fb docker-daemon:app:v0
    
  • :app – это имя нашего контейнера (можно указать свой).
  • :v0 – это tag. Обычно через него выставляется версионность для удобной навигации в репозитории.

Контейнер уже можно увидеть в списке локального репозитория Docker, выполнив следующую команду:

        docker image ls
    

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

        docker run --rm -d -v `pwd`:/app -p 5000:5000 app:v0
    

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

Чтобы это сделать, потребуется авторизоваться на
Docker Hub и создать пустой репозиторий. Детально описывать эту процедуру не
буду: процесс похож на создание Git-репозитория.

        docker login
<выполните авторизацию>. Делается один раз, пароль и логин запоминаются

    
        docker tag app:v0 <ваш логин docker hub>/<ваш репозиторий>/app:v0
buildah push <image ID> <ваш логин docker hub>/<ваш репозиторий>:app

    

Теперь можно на любом хосте с Docker запустить
контейнер и в качестве расположения указать уже не локальный репозиторий, а
Docker Hub.

        docker run --rm -d -v `pwd`:/app -p 5000:5000 test/learn_images:app:v0
    
Дальнейшие действия проводятся в кластере k8s. Как его развернуть, мы уже писали.

Цель – развернуть приложение Python из контейнера, но уже в кластере k8s
в нескольких репликах.

Для этого необходимо создать два объекта (подробнее мы рассматривали их в предыдущей статье):

  • Deployment – развернет приложение и будет поддерживать необходимое количество реплик.
  • Service – обеспечит сетевое взаимодействие внутри кластера.

Создаем Deployment для приложения в кластере k8s

Дополнительные материалы
Чтобы не путаться в терминах, вспомним, что под капотом у системы оркестрации Kubernetes.

Заходим по SSH на мастер-узел (ноду), проверяем работоспособность kubectl.
Далее необходимо создать deployment.yaml.

deployment.yaml
        apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: <ваш логин docker hub>/<ваш репозиторий>:app
        ports:
        - containerPort: 5000
          protocol: TCP
          name: http
        resources:
          limits:
            cpu: 50m
            memory: 20Mi
          requests:
            cpu: 50m
            memory: 20Mi

    

Разбираем подробнее:

  • kind: Deployment – определяем, какой у нас будет объект. В данном случае Deployment, но может быть и Service или, скажем, Pod.
  • name: app – имя нашего Deployment (именно так он будет отображаться в кластере k8s).
  • matchLabels: и app: app – метка приложения, ее уникальный идентификатор для дальнейшего мапинга с сервисом и другими объектами k8s.
  • replicas: 2 – сколько экземпляров приложения необходимо создать
  • containers: – этой секции описывается, откуда нам спулить контейнер (ясно дело, с Docker Hub). Порт для сетевого взаимодействия.
  • resources: – интересная секция. Тут описаны минимально необходимые ресурсы для запуска (limits). Без этих ресурсов приложение не стартует и планировщик кластера будет искать подходящий узел, удовлетворяющую минимальным ресурсам. Запрашиваемые (requests) – это ресурсы, которые резервируются на ноде для вашего приложения. Сверх этих ограничений приложение не получит ресурсов CPU и RAM.

Сохраняем файл deployment.yaml и выполняем команду для развертывания приложения:

        kubectl create -f deployment.yaml
    

Если
ошибок в файле не было, успешный исход – активное приложение в 2 репликах.
Посмотреть состояние можно следующей командой:

        kubectl get pod -o wide
    

Приложение
развернуто в двух репликах – с помощью curl можно обратиться к каждой из них по IP пода, но это плохой вариант (поды рано или поздно
переедут на другие узлы и IP поменяются). Давайте напишем еще один объект
кластера, который закроет эту проблему – Service.

Создаем Service приложения в кластере k8s

Из статьи по базовым объектам кластера k8s мы уже знаем, что объекты Service нужны для мапинга всех реплик приложения на один IP (endpoint).

Создаем еще один файл service.yaml.

service.yaml
        apiVersion: v1
kind: Service
metadata:
  labels:
    app: app
  name: app
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 5000
  selector:
    app: app
  type: ClusterIP

    

Его главные отличительные особенности:

  • ports: port – порт, по которому Service будет принимать трафик.
  • targetPort – порт для связи с приложением.
  • selector: – мапим наш Deployment и все реплики по этой метке.
  • type: clusterIP – тип объекта Service. В нашем случае для сетевого взаимодействия внутри кластера k8s.

Запускаем процедуру создания следующей командой:

        kubectl create -f service.yaml
    

Далее
смотрим детали Service:

        kubectl get svc -o wide
    

Супер! У нас есть IP, по которому можно обращаться к сервису в
кластере с любого пода.

Подведем итог статьи. Мы добились следующих результатов:

  • Написали приложение на Python + Flask.
  • Упаковали приложение в контейнер Docker.
  • Разместили контейнер в репозитории Docker hub.
  • Сделали Deployment и Service в кластере k8s.
Использованные в статье файлы YAML можно скачать здесь.

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

16
Июл
2021

JetBrains опубликовала ежегодный отчёт о мире разработки The State of Developer Ecosystem 2021. Основные тезисы

JetBrains опросила разработчиков из 183 стран, чтобы составить ежегодный отчёт об экосистеме разработки в 2021 году. Вот основные тезисы исследования.
— Читать дальше «JetBrains опубликовала ежегодный отчёт о мире разработки The State of Developer Ecos…

10
Июл
2021

∞ Легко ли перейти из сисадминов/разработчиков в DevOps?

Развитие сферы IT делает некоторые профессии неактуальными, и пальма первенства переходит к более востребованным на рынке. Направление DevOps – одно из таких. Мы расспросили разработчицу и сисадмина о том, почему и как они перешли в DevOps.

Инженер DevOps и разработчик/сисадмин: в чем разница?

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

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

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

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

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

Обычно в обязанности системного администратора входит следующее:

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

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

  • настройка облачных виртуальных машин и сервисов;
  • навыки программирования и написания сценариев;
  • понимание непрерывной интеграции (CI);
  • понимание безопасных и эффективных стратегий развертывания ПО;
  • навыки управления конфигурациями;
  • знание методов контейнеризации приложений;
  • практический опыт работы с платформами IaaS, вроде AWS и Microsoft Azure;
  • навыки коммуникации и другие soft skills.
Рассматривая разницу между DevOps-инженером и разработчиком, важно отметить, что последний сосредоточен на соответствии программного продукта потребностям клиента. Спектр обязанностей DevOps-инженера гораздо шире и включает разработку и развертывание программного обеспечения, а также обеспечение оперативной поддержки заказчиков.

В обязанности разработчика входит:

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

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

Опыт специалистов

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

Глафира Иванова, DevOps Engineer компании MedIndex

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

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

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

В какой-то момент все мои коллеги-бэкендеры уволились и я стремительно выгорела, поэтому решила поискать другую работу. Учитывая, что опыт в программировании у меня был к тому моменту не слишком положительный, я подумывала о том, чтобы слегка сменить сферу деятельности (что довольно нетрудно в IT, особенно вначале).

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

Об обязанностях специалиста DevOps

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

Это включает множество различных задач:

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

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

О навыках

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

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

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

О необходимом для специалиста стеке технологий


Советую изучать:

  • ОС Linux;
  • какой-нибудь из скриптовых языков (Python, например, но наверняка придется писать и на Bash);
  • Docker;
  • Kubernetes;
  • Ansible;
  • Prometheus;
  • ELK-стек;
  • инструменты для CI/CD (Jenkins/GitLab CI);
  • полезно попробовать работать с публичными облаками (например, с AWS).

О проблемах, которые могут возникнуть в начале карьеры

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

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

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

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

Дмитрий Евстюхин, Senior Cloud Solutions Architect компании Provectus

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

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

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

Об обязанностях специалиста DevOps

Роль DevOps-инженера очень разнится от компании к компании. Есть определенные схожие функции, например, настройка и поддержка CI/CD пайплайнов. Часто к этой роли относят и инфраструктурные вопросы, особенно в облаках. Мне также приходилось проектировать и настраивать инфраструктуру со всеми нужными сервисами: мониторингом, логированием и так далее. Помогал командам разработки настроить их процесс, щедро сдобрив его автоматизацией и петлями обратной связи. Иногда нужно было помочь разработчикам лучше использовать возможности среды, объяснить, как правильно жить в облаке или Kubernetes.

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

О навыках

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

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

Из hard skills я бы выделил скрипты и арсенал поверхностного понимания технологий. К примеру сертификация уровня Associate любого облака дает такой арсенал. Чем шире арсенал, тем лучше, но это не имеет большого смысла, если нет фундамента. В роли фундамента для хорошего специалиста DevOps обычно выступает глубокая экспертиза в администрировании Unix-like систем и сетевое администрирование.

О необходимом для специалиста стеке технологий

В первую очередь новичку в DevOps нужно закладывать фундамент, то есть осваивать операционные системы и сетевые технологии. Если есть достаточное понимание вышеперечисленного, стоит изучить скрипты на Bash/Python. Потом перейти к Ansible, Terraform, Jenkins, Kubernetes.

О проблемах, которые могут возникнуть в начале карьеры

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

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

Как влиться в новую команду?
Команда команде рознь. Самый главный метод адаптации – найти ментора, который поможет, покажет и научит. Хотя обычная ситуация, когда DevOps команды «в огне»: людей не хватает, задач много, все горит и никто ничего не успевает… в этом случае нет времени на новичка, и ему требуются недюжинные навыки самоорганизации, настойчивость, чтобы получить всю нужную информацию и стать полезным.

Выводы

В итоге именно вы решаете в каком направлении двигаться – стать системным администратором, разработчиком или перейти в DevOps. Как и во многих смежных направлениях, эти роли частично пересекаются. Системные администраторы уже имеют опыт написания сценариев и могут быть знакомы с технологиями автоматизации развертывания приложений, управления конфигурациями и так далее. Многие разработчики имеют представление о системном администрировании, так что изучать неофиту придется не половину (Dev или Ops), а немного меньше.

***

Если вы только собираетесь освоить популярную профессию, стоит обратить внимание на курс «Старт в DevOps: системное администрирование для начинающих» образовательной онлайн-платформы Skillbox. Там вы сможете получить навыки администрирования Linux, научитесь настраивать веб-серверы и поддерживать работу сайтов, а также усвоите базовые знания для развития в DevOps-инженерии.

За год занятий с экспертами-практиками вы соберете портфолио и сможете начать карьеру системного администратора в IT-компании. Если ваша цель – стать инженером DevOps, вы сможете попрактиковаться на реальных проектах и получите базовые навыки для развития. Продолжить обучение можно на продвинутых курсах: «Профессия DevOps-инженер», «Профессия DevOps-инженер PRO» и «Инфраструктурная платформа на основе Kubernetes». Все интересующие вопросы вы сможете задать куратору в чате Telegram, а ваши домашние задания лично прокомментирует преподаватель и даст полезные советы.

08
Июл
2021

🐧 Проектирование контейнеров (часть 2): в чем важность пространства пользователя?

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

23
Июн
2021

🔄 Сетевой инженер или DevOps: в каком направлении развиваться сисадмину?

Развитие сферы ИТ приводит к тому, что некоторые специальности постепенно теряют актуальность. Есть мнение, что системный администратор – одна из умирающих профессий. Разбираемся правда ли это и в каком направлении стоит развиваться сисадмину.

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

Основные обязанности системного администратора:

  • Установка и настройка компьютеров и оргтехники;
  • Обслуживание локальной сети и АТС;
  • Обеспечение бесперебойной работы серверов;
  • Создание учетных записей пользователей;
  • Определение уровней доступа сотрудников;
  • Установка и обновление ПО;
  • Контроль безопасности данных и их резервное копирование;
  • Инвентаризация и закупка оборудования.
Получается, сисадмин – специалист широкого профиля, без которого трудно себе представить работу даже небольшого офиса. На портале hh.ru по запросу «Системный администратор» можно найти более пяти тысяч вакансий с зарплатной вилкой от 30 000 рублей для начинающего специалиста, до 100 000 рублей для опытного профессионала. Непохоже на вымирающую должность, но некоторые проблемы в этой сфере все-таки есть.

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

Бизнесмены, запомните: хорошему сисадмину платят за то, что он не работает!

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

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

Будущее системного администратора

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

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

Сетевой инженер


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

Главное отличие от сисадмина в том, что сисадмины чаще обслуживают готовую инфраструктуру (если не считать небольших организаций, где айтишники «от скуки на все руки»), а сетевой инженер должен уметь построить и задокументировать корпоративную сеть с нуля. Также его работа предполагает взаимодействие с активным сетевым оборудованием таких вендоров, как Cisco, Mikrotik, Juniper и т.д.

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

Чтобы стать сетевым инженером вы должны знать:

  • Компьютерные сети на уровне не ниже CCNA/CCNP;
  • Основы безопасности сетей;
  • Основы дизайна сетей;
  • Активное сетевое оборудование (маршрутизаторы, коммутаторы, межсетевые экраны);
  • Технологии виртуализации;
  • ОС Linux и Windows Server;
  • Скриптовые языки программирования (bash, python).
Темпы карьерного роста зависят в основном от усердия и желания учиться. Если регулярно тратить на саморазвитие час-полтора в день, можно менее чем за два года вырасти с джуна до синьора. Ключевое различие между ними в том, что джуны обычно выполняют простые рутинные задачи, а синьоры занимаются более комплексными и сложными проектами, а также архитектурой сети и глобальными преобразованиями в ней. Чтобы расти, стоит начать собирать схемы в виртуальной лаборатории и изучить работу протоколов.

Инженер DevOps


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

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

Инженер DevOps – специалист, который внедряет эти методики в рабочий процесс.

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

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

Также в задачи специалиста входит написание большого количества кода на скриптовых языках: Python, GoLang или Bash.

Чтобы стать инженером DevOps вы должны знать:

  • Основы компьютерных сетей;
  • Администрирование Linux;
  • Скриптовые языки программирования;
  • Технологии виртуализации;
  • Облачные сервисы;
  • Инструменты DevOps:
  • Системы мониторинга и тестирования.

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

Другой материал по теме: как освоить профессию инженера DevOps.

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

***

Если вы не стоите на месте и хотите развиваться, обратите внимание на факультет «Сетевой инженер» образовательной онлайн-платформы GeekBrains. За одиннадцать месяцев вы изучите основы сетевых технологий, коммутацию и маршрутизацию, безопасность, масштабирование сетей и автоматизацию сетевой инфраструктуры, сделаете 2 проекта для портфолио, а также получите диплом о переподготовке и помощь в трудоустройстве.

21
Июн
2021

Конференция ZeroNights 2021

Эксперты по информационной безопасности, 4 тематических секции, воркшопы, встречи и конкурсы в городском пространстве Санкт-Петербурга.
— Читать дальше «Конференция ZeroNights 2021»

17
Июн
2021

Project Hiring Week

EPAM набирает команду разработчиков, инженеров, тестировщиков и аналитиков для работы в проектах Выделенного Центра Разработки. Оффер через 48 часов и welcome-бонус в размере одного оклада.
— Читать дальше «Project Hiring Week»

16
Июн
2021

∞ Путь в профессию: интервью с инженером DevOps

Библиотека программиста продолжает серию интервью с представителями IT-индустрии. Наш корреспондент побеседовала с Алексеем Шараповым, Head of DevOps компании «ЦРПТ». Он рассказал о своем пути в отрасли, какие требования к кандидатам предъявляют работодатели и стоит ли считать DevOps профессией или только ролью.

Библиотека программиста: Добрый день, Алексей! Расскажите, пожалуйста, для начала о своем бэкграунде. Где учились, работали, прежде чем стать инженером DevOps?

Алексей Шарапов: Учился в Ярославском Государственном Техническом Университете по специальности «Органическая химия», но вскоре понял, что больше люблю разработку и все, что с ней связано.

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

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

Б.П.: С чего начался ваш путь в профессию, почему решили уйти именно в DevOps?

А.Ш.: Мой путь в профессии начался с двух направлений параллельно. На основной работе я занимался администрированием парка серверов и в это же время разрабатывал сайты на фрилансе. После этого более глубоко погрузился в администрирование, Linux сервера. При этом разработку не бросал никогда, делал простые задачи, изучал Java и даже брался за задачи по разработке наравне с коллегами. Также проходил курсы по разработке на Java для более глубокого погружения, курсы по PHP и JavaScript, так как хотелось больше узнать о программировании изнутри.

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

Б.П.: Дайте свое определение DevOps.

А.Ш.: DevOps – это практики, направленные на взаимодействие между отделом разработки и отделом Ops, которые помогают быстрее поставлять продукт с меньшим количеством ошибок и проблем.

Б.П.: По вашему мнению, DevOps – это профессия или часть обязанностей?

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

Б.П.: Опишите основные требования, которые предъявляют к специалистам разных уровней работодатели.

А.Ш.: Требования к специалистам с одной стороны растут, даже к джуниорам. С другой стороны – нехватка хороших инженеров DevOps позволяет на некоторые вещи закрыть глаза.

На данный момент я определяю требования к специалистам разных уровней следующим образом:

  1. Junior – это базовые знания Linux-администрирования, базовые знания одного-двух языков программирования, для старта этого бывает достаточно;
  2. Middle – к требованиями выше добавляются знания базовых инструментов контейнеризации, оркестрации, систем сборок, понимания принципов построения CI/CD процессов;
  3. Senior – ко всему прочему добавляется широкий бэкграунд в разных технологиях, а также умение правильно построить процесс и дать грамотную оценку задачи. Немаловажным является умение наладить контакт с коллегами. У специалиста, который будет в роли прокси-сервера между отделами, так называемые софт скиллз должны быть на высоте.

Б.П.: Опишите ваш типичный рабочий день.

А.Ш.: Типичный день обозначить очень сложно, так как каждый приносит что-то новое и интересное.

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

Б.П.: Какой стек технологий вы используете в работе?


А.Ш.: Стек технологий, который я использую в работе, достаточно широк. Это и K8S для запуска сервисов, GitLab CI для процессов CI (непрерывной интеграции), Ansible в связке с Python – для автоматизации всего.

Вокруг этих инструментов сосредоточен еще очень большой набор технологий. Например, Helmfile для накаток на разные среды, Argo CD в других проектах, иногда приходится писать на Go (например для экспортеров), где-то копаться в Java.

Б.П.: Какие технологии сейчас становятся более популярными, что учить, чтобы быть на шаг впереди остальных?

А.Ш.: Я бы выделил K8S, сейчас без него никуда. А также весь около K8S стек технологий. Это и Helm и GitOps-инструменты. Ну и облачные платформы – AWS и GCD идут впереди планеты всей и позволяют делать невероятные вещи.

Б.П.: К каким трудностям в профессии специалист DevOps должен быть готовым?

А.Ш.: Первое, что я выделил бы – понимание того, что коммуникации будут составлять достаточно большую часть вашей работы. Второе – вы должны всегда успевать за стеком разработчиков, за их изменениями и нововведениями. Ну и третье – отслеживать, что нового в индустрии, а новостей всегда много: K8S без Docker, Ansible без модулей и все в этом духе. Высокий темп в этой области превосходит многие другие.

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

Б.П.: Сколько лет вам понадобилось, чтоб вырасти до уровня senior? Что больше всего повлияло на ваш рост, как специалиста?

А.Ш.: До senior я морально вырос спустя семь лет с начала работы. Сейчас я лид направления DevOps в компании, руковожу лидами DevOps в группах разработки, но не бросаю и работу руками. Работаю с командами разработки, эксплуатации. Стараюсь уделять внимание и той и другой стороне.

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

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

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

Самая моя любимая книга для новичков – «Unix и Linux: руководство системного администратора», Немет Эви, Снайдер Гарт.


Полезно смотреть видеозаписи крупных российских и зарубежных конференций, таких как DevOpsConf, KubeCon, DockerCon.

Из ресурсов я читаю в основном блоги на официальных сайтах Docker, K8S, Red Hat, ну и Хабр, он до сих пор несет много полезной информации.

Выводы

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


***

Если вы находитесь только в начале пути, стоит обратить внимание на курс Факультета DevOps образовательной онлайн-платформы GeekBrains. Эксперты-практики из ведущих российских технологических компаний научат вас использовать методологии Agile и Scrum, оптимизировать CI/CD и работать с облачными технологиями. Курс подойдет как новичкам в IT, так и опытным специалистам, которые хотят сменить направление.

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

Успешно окончившим курс студентам HR-специалисты GeekBrains помогут создать резюме и предложат вакансии. Гарантия трудоустройства закреплена в договоре.

09
Июн
2021

Хакатон INNOHACK 2.0

Команды из разработчиков, аналитиков, тестировщиков, DevOps-инженеров и UI/UX-дизайнеров должны решить одну из 5 бизнес-задач. Призовой фонд — 1,2 млн рублей. Заявки принимаются до 15 июня.
— Читать дальше «Хакатон INNOHACK 2.0»

01
Июн
2021

Курс «Fullstack-разработчик на Python»

За 15 месяцев можно стать Fullstack-разработчиком с портфолио и получить работу при поддержке карьерного центра SkillFactory.
— Читать дальше «Курс «Fullstack-разработчик на Python»»