Category: DevOps

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»»

21
Май
2021

☸️ Первое знакомство с Kubernetes: установка кластера k8s вручную

В небольшом цикле статей мы поближе познакомим читателей с оркестратором Kubernetes. Для начала настроим кластер k8s c нуля на VPS-хостинге с помощью Kubespray.

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

Быстрый deploy приложений;

Удобное масштабирование
развернутых приложений;

Внутренние self-health;

Нулевой простой при
обновлениях приложений.

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

Варианты установки

k8s можно развернуть несколькими способами в зависимости от ваших целей и времени, которое вы намерены потратить. Есть быстрые варианты, вроде GKE (Google) или EKS (Amazon). Они позволяют быстро поднять кластер, не задумываясь о его внутреннем устройстве: вы получите результат менее чем за 5 минут.

Если вам интересно
погрузиться в тему поглубже и буквально собрать k8s в ручном режиме, эта
статья поможет. Поехали 🙂


Подготовка

В дальнейшем мы будем
использовать созданный кластер для публикации различных сервисов и поэтому установку будет производить на VPS. Для кластера потребуется несколько виртуальных машин:

Master node (CentOS 7, 1vCPU, RAM 2 ГБ, HDD 10 ГБ);

Worker node (CentOS 7, 1vCPU, RAM 2 ГБ, HDD 10 ГБ);

Worker node (CentOS 7, 1vCPU, RAM 2 ГБ, HDD 10 ГБ);

Ingress node (CentOS 7, 2vCPU, RAM 8 ГБ, HDD 10 ГБ).

На всех узлах нашего кластера k8s установлена хост-система CentOS 7. Если вы хотите использовать другую хост-систему, ищите информацию на официальном сайте Kubernetes. Рассмотрим вариант развертывания с помощью Kubespray – набора ролей Ansible для
установки и конфигурирования k8s.

Развертывание k8s

Для начала мы отключим файл/раздел подкачки и межсетевой экран на всех узлах кластера, а также сгенерируем и скопируем ключи SSH, чтобы Ansible мог ходить по хостам и творить свою магию:

Отключаем SWAP:

        swapoff -a
    

Отключаем firewall (на учебном стенде это допустимо, но на проде не стоит так делать не стоит):

        firewall-cmd --state
systemctl stop firewalld
systemctl disable firewalld

    

Наша следующая задача – сгенерировать ключ SSH и скопировать его на все узлы будущего кластера, включая
master (где ключ был изначально сгенерирован):

        ssh-keygen
ssh-copy-id [email protected]<master host IP>

    

Теперь копируем ключ на
оставшиеся хосты (команды выполняются на мастер-хосте):

        ssh-copy-id [email protected]_host
    

Далее на master устанавливаем pip
и git
:

        curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
python get-pip.py
yum install git

    

Если у вас используется старая версия Python, pip можно поставить следующим способом:

        curl "https://bootstrap.pypa.io/pip/2.7/get-pip.py" -o "get-pip.py"
python get-pip.py

    

Подготовка платформы завершена. Мы по-прежнему находимся на мастер-хосте
и до конца развертывания кластера с него не уйдем. За нас будет ходить Ansible
🙂

Для дальнейших действий потребуется репозиторий Kubespray. Клонируем его:

        git clone https://github.com/kubernetes-sigs/kubespray.git
cd kubespray

    

Устанавливаем зависимости
для Kubespray, описанные в файле requirements.txt:

        pip install --ignore-installed requests==2.23.0
pip install -r requirements.txt

    

Подведем итог наших действий:

На ноде master установлен Ansible;

Сгенерирован и скопирован ssh ключ на все узлы кластера;

Установлены необходимые зависимости из файла requirements.txt.

Конфигурация Kubespray

Чтобы Kubespray понимал, на какие узлы нужно устанавливать k8s, придется создать директорию с описанием конфигурации будущего кластера. Тему inventory в первой статье мы подробно разбирать не будем, поскольку она слишком обширная (рабочий inventory доступен по ссылке – скопируйте его).

Потребуется изменить IP-адреса. Ниже приведет пример inventory.ini c нашими адресами (у вас они будут другими):

        master-1.root.local.io ansible_host=192.168.0.3 ip=192.168.0.3
ingress-1.root.local.io ansible_host=192.168.0.6 ip=192.168.0.6
node-1.root.local.io ansible_host=192.168.0.4 ip=192.168.0.4
node-2.root.local.io ansible_host=192.168.0.5 ip=192.168.0.5

[kube-master]
master-1.root.local.io

[etcd]
master-1.root.local.io

[kube-node]
node-1.root.local.io
node-2.root.local.io
ingress-1.root.local.io

[kube-ingress-1]
ingress-1.root.local.io

[k8s-cluster:children]
kube-node
kube-master

    

Наш кластер состоит из 4 узлов:

  • один master с компонентами Control Plane;
  • один Ingress для маршрутизации трафика;
  • два Workers, на которых будут запускаться сервисы.

Control Plane (API
server, etcd, Sheduler, Controle manager) собран на одной ноде. Это очень нехорошо: обычно в секции [kube-master] больше одного узла, а в секции [etcd] – более трех. Это связано с тем, что quorum собирается не меньше
чем на 3 узлах при нечетным общем количестве узлов в etcd. Поскольку речь идет об учебной площадке, наш вариант тоже имеет право на существование.

Отредактируем k8s-cluster/k8s-cluster.yml. Нужно поменять network plugin на
flannel и имя нашего кластера на root.local:

        kube_network_plugin: flannel
cluster_name: root.local

    

Теперь поправим
k8s-cluster/k8s-net-flannel.yml. Тут обычный regexp на сеть провайдера VPS (в нашем случае это 192.168.0.0/24, но у вас подсеть может отличаться).

Исправляем:

        flannel_interface_regexp: '192\.168\.0\.\d{1,9}'
    

Сборка кластера

Поскольку inventory у нас уже
подготовлен, остается только запустить playbook на исполнение и минут
15 – 20 подождать, пока соберется кластер. Если у вас отвалится соединение SSH, и сборка прервется, ее можно будет запустить повторно – это не вызовет ошибок:

        ansible-playbook -u root -i inventory/inventory.ini cluster.yml -b --diff
    

Кластер собран. Проверяем:

        [[email protected] kubespray] kubectl get nodes
NAME                      STATUS   ROLES    AGE    
ingress-1.root.local.io   Ready    <none>   2d1h   
master-1.root.local.io    Ready    master   2d1h   
node-1.root.local.io      Ready    <none>   2d1h   
node-2.root.local.io      Ready    <none>   2d1h

    

Последний штрих – добавляем
роль нашей ноде с ingress:

        [[email protected] kubespray] kubectl label node ingress-1.root.local.io node-role.kubernetes.io/ingress=
    

Если повторно посмотреть на ingress, роль должна появиться:

        [email protected] kubespray] kubectl get nodes
NAME                      STATUS   ROLES     AGE    
ingress-1.root.local.io   Ready    ingress   2d1h   
master-1.root.local.io    Ready    master    2d1h   
node-1.root.local.io      Ready    <none>    2d1h   
node-2.root.local.io      Ready    <none>    2d1h  

    
***

Поздравляем! Вы практически вручную развернули кластер k8s, и теперь можно запустить в нем простенькое приложение. Это только начало большого пути в современное системное администрирование (или даже в DevOps). Более сложные шаги мы сделаем с вами вместе в следующих статьях. Удачи в обучении!

18
Май
2021

∞ Как освоить профессию инженера DevOps в 2021 году?

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

DevOps (англ. development and operations) – набор практик для повышения эффективности разработки (Dev) и эксплуатации (Ops) программного обеспечения. Он позволяет наладить взаимоотношения между программистами и системными инженерами, автоматизировать рабочие процессы и быстрее выпускать готовый продукт. Основные принципы DevOps мы достаточно подробно разбирали в предыдущих статьях.

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

Можно ли освоить популярную профессию, обладая минимальными познаниями в IT?

Junior DevOps существует


Новичкам доступно несколько вариантов обучения:

  • Стажировка в компании – хороший способ получить практические знания под присмотром опытных коллег, но требуется технический бэкграунд. Работодатели тщательно выбирают интернов, шанс попасть на такую стажировку с нуля небольшой. Обратите внимание на такие компании как EPAM или DINS.
  • Обучение на платных курсах подходит для всех, независимо от опыта. Организаторы таких курсов следят за актуальностью изучаемого материала, информация структурирована и подаётся по возрастающей – от простого к сложному. Главное преимущество – проработка знаний на практических заданиях и к концу обучения у вас будет портфолио, которое можно прикрепить к резюме. Определиться с выбором курсов поможет этот ресурс.
  • Самостоятельное обучение. В сфере IT специалисты-самоучки не редкость. Этому способствует доступность информации в сети: книги, документация, сообщества, каналы в YouTube – для занятий нужен только компьютер с доступом к интернету. Выбирая этот путь, вы должны быть хорошо мотивированы и дисциплинированы. Самое главное здесь – последовательность и постоянство. Лучше уделять образованию один-два часа каждый день, чем заниматься целый день раз в неделю.

Базовые знания для карьеры в DevOps

Рассмотрим необходимые навыки для развития в направлении DevOps. Если вы новичок следуйте нашим рекомендациям по-порядку. Мы подготовили план с указанием необходимой литературы, видеоуроков и ссылками на предыдущие статьи.


Знание английского трудно переоценить в любой сфере IT и DevOps не исключение. Владение языком даже на уровне A1, A2 поможет при чтении технической документации (корректный перевод получается найти далеко не всегда). Если вы совсем не знаете язык, можно переключить все устройства на английский – это позволит выработать хотя бы начальные навыки чтения.

1. Изучите основы построения компьютерных сетей, модели osi, tcp/ip.

Рекомендуемая литература:

Эти книги помогут вам заложить прочный теоретический фундамент, а практический опыт можно получить из книг по подготовке к CCNA и программы Cisco packet tracer:

2. Изучите unix-системы, в частности GNU/Linux.

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

Книги и видеоуроки по Linux:

3. Изучите скриптовый язык программирования.

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

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

Рабочие инструменты инженера DevOps

таблица инструментов инженера DevOps
таблица инструментов инженера DevOps

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

Выделим основные инструменты:

  • Git – система контроля версий;
  • Jenkins – обеспечение непрерывной интеграции(CI, англ. Continuous Integration);
  • Ansible система управления конфигурациями;
  • Docker – контейнеризация приложений;
  • Terraform/Kubernetes – системы оркестрации;
  • AWS/GCP – облачные сервисы IaaS.

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

Каналы по DevOps на Youtube:

  • ADV-IT – Денис Астахов, опытный инженер DevOps со множеством сертификатов. На его канале есть плейлисты по всем необходимым инструментам. В своих уроках Денис доступным языком и на практических примерах объясняет с чем придется столкнуться будущему специалисту. Единственный минус – не всегда грамотно поставленная речь, так как Денис живет и работает в Канаде.
  • Kirill Semaev – еще один канал по обучению Linux и практикам DevOps. Ко всем видеоуроками есть презентации и практические примеры. Недостаток – контент давно не обновлялся.
  • DevOps Channel – канал о конференциях по тематике DevOps. Он будет полезен не только в целях обучения, но и для расширения кругозора.

Другие статьи про DevOps в «Библиотеке программиста»:

***

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

Если вы всерьез решили освоить новую профессию, советуем обратить внимание на факультет DevOps образовательной онлайн-платформы GeekBrains. За 18 месяцев обучения вы получите 4 проекта в портфолио, диплом о профессиональной переподготовке и помощь в трудоустройстве.

06
Май
2021

Конференция Highload++ 2021

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

27
Апр
2021

∞ Эффективный DevOps: как прокачать команду?

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

Главные цели и задачи DevOps

DevOps (Development and Operations) – практика, направленная на объединение команд разработки и эксплуатации для быстрой и надежной сборки, тестирования и выпуска релизов программного обеспечения. Она является естественным продолжением гибких подходов (SCRUM, Kanban, FDD и других).

Основная цель DevOps – ускорить вывод продукта на рынок (за счет применения постепенных улучшений в ответ на меняющуюся среду) и создать более упорядоченный процесс разработки.

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

Активное сотрудничество всех заинтересованных в развитии проекта сторон позволяет добиться следующих результатов:

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

Что делает команду DevOps эффективной

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

  1. Предоставление обратной связи о сбоях (и их причинах) на этапе сборки для оперативного исправления проблем разработчиками. Возможность давать постоянную обратную связь сокращает время, необходимое для устранения проблем на позднем этапе. Этот процесс также известен как непрерывная интеграция (CI).
  2. Максимальная автоматизация конвейера сборки и выпуска. Таким образом, ручные усилия сводятся к минимуму, сборки/развертывания становятся организованными, что ускоряет процесс предоставления результата заказчику.
  3. Управление инфраструктурой (управление серверами на любом этапе, QA, pre-production и production) – еще один аспект, в котором инженер DevOps играет жизненно важную роль. Когда облачные сервисы, вроде AWS, используются все чаще, делать это намного проще, но управление инфраструктурой остается обязанностью инженера DevOps.
До появления DevOps эти задачи выполняли либо группы разработчиков, либо группы эксплуатации. Выполнять основную работу, параллельно занимаясь сборкой и выпуском – времязатратно. По этой причине и возник подход, повышающий эффективность команд.

Чтобы организовать команду и сделать ее эффективной необходимо следующее:

  1. Чтобы бизнес-требования организации и общее видение соответствовали целям команды DevOps. Так команда сосредоточится на конкретных бизнес-целях, а не будет просто выполнять рутинные задачи.
  2. Выбрать подходящие инструменты. Инновационный набор инструментов и своевременное внедрение стека технологий поможет команде поддерживать эффективность.
  3. Измерять эффективность команды. Например:
  • анализировать частоту развертываний: соответствует ли она целям организации?
  • проверять безопасность и качество: соответствуют ли стандарты безопасности и качества проектов стандартам организации?
  • проверять объем ошибок/багов: каков процент возникающих ошибок и сколько времени нужно командам, чтобы их решить?

Советы от ведущего DevOps-специалиста

Об эффективных способах прокачки команды DevOps нашему корреспонденту рассказал Александр Крылов, Lead DevOps ПАО СК «Росгосстрах».

О принципах

На данный момент времени я взаимодействую с командами аналитики, разработки, тестирования, инфраструктуры. В процессе разработки мы стараемся не доводить до того, чтобы, если что-то идет не так, бизнес узнал об этом. Например, идет внедрение нового продукта, появление которого требует доработок в ряде систем. Доработки продумываются, оцениваются и уходят в разработку. Параллельно командой тестирования разрабатываются тесты этого функционала, формируется методология интеграционного и регрессного тестирования по всем дорабатываемым системам.
В случае, если это бизнес-критичный функционал, для него дополнительно настраивается логирование и алертинг. Это мы проносим через культуру DevOps по всему циклу CI/CD, по необходимости, встраивая в pepeline автотесты и систему репортинга по ним, чтобы наблюдать за каждой итерацией прохождения этих тестов. Поэтому, в процессе разработки мы руководствуемся одним простым принципом – здравым смыслом.

О прокачке культуры DevOps в организации и среди команд

Для прокачки культуры DevOps в организации и среди команд существуют направления:

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

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

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

3. В компании существует матрица зрелости. О ней я упоминал в выступлении на конференции DevOps Live 2020 с темой «Построение мониторинга в дружбе с DevOps. Унификация процессов».

В концепт матрицы входит оценка системы по ряду блоков и критериев, например, тестирование или разработка. После оценки системы с лидами команд разработки и тестирования, принимается решение по тем или иным работам. Для бизнеса они обосновываются, как повышение уровня матрицы зрелости с последующим профитом, например, ускорение поставки кода в продакшн за счет внедрения CI/CD. Результатом этих работ является повышение зрелости систем и масштабирование практик DevOps в компании.

О внедрении новых стеков технологий

Регулярная активность компании – NAP, что расшифровывается, как Next Action Plan. Суть NAP – это обсуждение инициатив, например, по оптимизации процессов путем внедрения какой-либо утилитки.

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

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

Об ошибках в работе DevOps

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

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

Как развиваться в DevOps начинающему и опытному специалисту

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

По самому же DevOps, рекомендую прочесть:

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

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

Выводы

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

***

Если вы только начинаете путь в профессии, стоит обратить внимание на курс факультета DevOps образовательной онлайн-платформы GeekBrains. Программа рассчитана на новичков и практикующих IT-специалистов, решивших освоить востребованное направление. За 18 месяцев вы научитесь использовать гибкие подходы Agile и Scrum, оптимизировать CI/CD и работать с облачными решениями. Обучение построено на взаимодействии в команде, а занятия ведут действующие специалисты российских технологических компаний. Успешно окончившие курс студенты смогут добавить в портфолио полтора года практического опыта и четыре реализованных проекта, а также получат помощь в трудоустройстве.

21
Апр
2021

Как работать с апи если сайт требует SSL сертификат?

У меня есть некая программа для работы с апи DevOps. Получение данных с одного DevOps и создание user story/tasks в другом. Функция получения данных будет ниже.
Но недавно нам сказали установить SSL сертификат и заходить в девопс теперь м…

04
Мар
2021

∞ Обучение на инженера DevOps: как не имея опыта найти работу?

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

Почему в DevOps не…

25
Фев
2021

Школа Linux от КРОК

Это не курс и не вебинар, а полноценная работа с параллельным обучением для будущих Linux-администраторов. Эксперты КРОК делятся своим опытом и вы тут же применяете его на практике.
— Читать дальше «Школа Linux от КРОК»