Стать инженером devops в 2021 году: подробное руководство

Что такое DevOps? Введение

Где читать: статья на bmc.

Зачем читать: чтобы узнать об основных практиках DevOps и стандартных структурах DevOps-команд.

Один из главных приоритетов DevOps — выпускать ПО чаще и с хорошим качеством. В этом отлично помогает автоматизация процессов. Примеры:

• Непрерывная интеграция. Вместо ручного обновления и тестирования кода разработчики загружают изменения в центральный репозиторий. Там он собирается и тестируется автоматически.
• Непрерывная доставка. Это что-то вроде расширенной версии непрерывной интеграции. После сборки и тестирования код автоматически проверяется, пока не будет одобрен для продакшена. Популярные инструменты: Jenkins, Bamboo, Travis, TeamCity.
• Непрерывное тестирование. Помогает обнаружить потенциальные проблемы на самой ранней стадии. Если код не проходит автоматические тесты, он не попадёт на функциональное тестирование, а разработчики получат уведомление о проблеме. Популярные инструменты: Selenium, Travis, Appium.
• Непрерывный мониторинг. Ещё одна практика для поиска проблем. Чаще всего отслеживаются нагрузка на процессор и память, место на диске и действия клиентов. Популярные инструменты: Nagios, Sensu, Prometheus.
• Инфраструктура как код. Практика, в которой инфраструктура управляется через код, а не вручную. Её можно встретить в компаниях, полностью работающих на облачных технологиях.
• Микросервисная архитектура. Такое ПО состоит из небольших независимых компонентов, у каждого из которых есть своя функция. Микросервисы повышают надёжность программы, а добавлять и обновлять функции становится проще.

Топология DevOps

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

Дивный новый мир

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

Так в чем разница между профессиями сисадмина, DevOps и SRE? Максимально коротко

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

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

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

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

Валентина, инженер в МТС:

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

У админа есть готовое ПО, на которое он не может влиять, если там что-то не так, а только костылить вокруг и углубляться в тонкие настройки, но зато у него есть много инструкций в интернете — installation guide и статьи от других админов, которые уже ставили это же ПО и набили шишки. Пример: админ читает в инструкции, что оптимальнее запускать ПО, например, c файловой системой xfs. 

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

Василий, DevOps в Piano:

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

DevOps — это про дружбу разработки и админов (опсов), а SRE — это пожарник, который тушит прод после веселья первых двух.

История появления

Термин «DevOps» был популяризован серией встреч «DevOps Days», прошедших в 2009 году в Бельгии . Одной из наиболее важных теоретических работ по DevOps считается книга Патрика Дюбуа, Джина Ким, Джеза Хамбл и Джона Уиллис «Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях», впервые опубликованная на английском языке в 2016 году. К этому основателей нескольких софтверных компаний и независимых ИТ-консультантов подтолкнул накопленный опыт работы в крупных проектах . 

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

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

Концепция DevOps как пересечение разработки, эксплуатации и тестирования

SRE

Цель инженера по SRE — сделать так, чтобы сервис работал с такой надежностью, которая указана в соглашении о уровне оказания услуг (SLA). Стабильность работы зависит и от инфраструктуры, и от качества кода, поэтому SRE занимается и тем, и другим. Как правило, инженерами по SRE становятся опытные системные администраторы или разработчики. Разработчики даже чаще.

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

Пример требований:

• уверенные знания ОС Linux продвинутого уровня работы в консоли;
• опыт разработки на C/C++ или Go;
• понимание работы TCP/IP и HTTP;
• понимание устройства ОС (процессы, память, синхронизация);
• опыт настройки различных инструментов для мониторинга и конфигурирования серверов (Zabbix, Puppet, Ansible или подобные);
• опыт работы с Docker;
• опыт использования облачных сервисов Amazon: EC2, VPC, S3, Route53;
• опыт настройки сетей (инструменты: Nginx, HAProxy, bind, git, iptables, stunnel, OpenVPN);
• опыт настройки виртуальных машин: kvm, xen.

Пример задач:

• оптимизация имеющейся архитектуры и сервисов;
• уменьшение нагрузки на сопровождение и обслуживание сервисов за счет автоматизации;
• изучение имеющихся сервисов и поддержание актуальных знаний по ним;
• активный и проактивный поиск возможных проблем и их устранение;
• обеспечивать заданный уровень SLA & SLO;
• участвовать в инцидент-менеджменте;
• писать postmortem и разрабатывать мероприятия для повышения стабильности сервисов;
• создавать, актуализировать DRP (Disaster Recovery Plan), BCP(Disaster Recovery Plan) и проводить регулярные учения по отказам с последующим анализом результатов;
• участвовать в проработке архитектуры сервисов и изменений их конфигураций;
• оптимизация имеющихся систем observability.

Марсель, CТO в Slurm.io:

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

Сергей, СТO в Southbridge:

Я считаю, что у нас это скорее хайп, так как SRE и DevOps-инженер часто имеют одни и те же обязанности. На мой взгляд, SRE — это DevOps с бэкграундом разработки. Тут имеется в виду, что такой инженер может не просто написать скрипт на Go, а разобраться в коде и даже подсказать разработчикам, что с инфраструктурной точки зрения работает плохо и что надо улучшить.

Инженеры по SRE нужны еще в меньшем количестве компаний, чем DevOps-инженеры, и это крупнейшие организации.

Зарплаты SRE часто вообще не указывают, а если указывают, то фигурируют суммы в $2000, $2500, $4000.

Кто стоит у истоков DevOps?

Главная книжка по DevOps — «The Phoenix Project». Это такой роман, где главный герой с помощью DevOps побеждает. Сначала у них все очень просто — плохо, затем он придумывает DevOps, и у них становится все хорошо.

На обложке книги есть главные герои. Давайте рассмотрим их внимательнее:

Кого нет на обложке, но в самой книге они на задних ролях? Разработчиков! Вся книжка про то, как Ops-сисадмины придумали DevOps и с помощью него победили.

Второе доказательство: книжка «Руководство по DevOps» (DevOps Handbook). Давайте посмотрим, кто ее написал:

• Джен Ким (Gene Kim). Он написал «The Phoenix Project», то есть с ним все понятно.
• Патрик Дебуа (Patrick Debois). Он был Systems Architect, то есть сисадмином.
• Джез Хамбл (Jez Humble). Работал Deputy Director of Delivery Architecture, то есть сисадмином.
• Джон Уиллис (John Willis). Был VP of Services из компании Opscode, а Opscode — это инструмент для сисадминов.

То есть «Руководство по DevOps» придумано сисадминами.

Может, у нас более продвинутые люди? Уж они-то знают, зачем нужен DevOps и кто такие DevOps-специалисты. Открываем статью на Хабре и видим высказывание Кирилла Сергеева:

Хм, то есть Кирилл утверждает, что разработчики заинтересовались сисадминством? Интересно! Как вы думаете, кем работает этот Кирилл Сергеев? DevOps Engineer в компании EPAM! Ах вон оно что, теперь понятно, это сисадмины хотят, чтобы разработчики заинтересовались сисадминством, чтобы свалить на них часть своей работы!

Спустимся и посмотрим комментарии к этой статье:

Есть еще русскоязычный чат по DevOps в Telegram:

Вот что мы знаем: DevOps — это как сисадмины, только умеют в автоматизацию и знают английский.

Откуда же взялся этот ребрендинг? Откуда появились “DevOps-инженеры”?

Как вы и могли догадаться, это маркетинговый трюк рекрутеров. Им надо нанимать сисадминов, но сисадмины больше не хотят называться сисадминами! Поэтому рекрутеры придумали новую должность: “DevOps-инженер”.

LinkedIn выдает около 15 тыс. результатов по запросу DevOps в США. Если вы думаете, что в Питере не так, то нет — около 1300 открытых вакансий DevOps-инженеров на HeadHunter по состоянию на октябрь 2019 года.

Вот откуда ноги-то растут! Ну ладно, может быть всё не так плохо, и этим «ДевОпс-инженерам» всё-таки есть дело до задач, целей и головных болей разработчиков? Еще есть такой отчет под названием Accelerate: State of DevOps. Любой DevOps-специалист начнет вам рассказывать, как там все правильно. Пока давайте немного про версию 2018 года, а о выпуске 2019 года чуть позже.

Что измеряет State of DevOps? То, как мы деплоим код, куда код девается после того, как мы его написали, какие outages у серверов, лежат ли сервера, degraded service. То есть всё-всё-всё про DevOps. Главное измерение — это new work, то есть сколько мы тратим, создавая новые фичи. Как же он измеряется?

Никаких outages, degradation, server migrations! То есть все метрики в State of DevOps — это метрики сисадминов, и к нам, разработчикам, не имеют никакого отношения, потому что у нас есть три вида работы: фигачим новые фичи, фиксим баги или делаем рефакторинг. Ну то есть суммируя: DevOps — это в лучшем случае ребрендиг сисадминства, а, может быть, даже и попытка сисадминов переложить часть своей работы на разработчиков!

На этом, господа присяжные, я считаю доказанным, что DevOps — это заговор сисадминов против разработчиков. Но я-то разработчик, и что для меня этот new work, что для меня является сделанной работой? Где я провожу эту границу между Dev и Ops в DevOps?

Перейдем к докладу «The world needs full stack craftsmen», с которым Антон Кекс выступал на JPoint 2019. Если в двух словах, то доклад про Software Craftsmanship. Антон рассказывал о том, что значит быть full stack разработчиком, но затем он говорит что-то в духе:

Дальше он говорил про deployment, потому что иначе злой админ позвонит вам в середине ночи. Но у нас же DevOps! Разработчики же деплоят! То есть в докладе еще одно доказательство, что в теме про Software Craftsmanship никаким DevOps и не пахнет. Мы должны сделать так, чтобы системные администраторы не звонили ночью, и заботиться о том, чтобы код был в продакшене.

Далее Антон рассматривал Manifest of Software Craftsmanship:

Что-нибудь про DevOps, production, delivery? Ничего.

Что же считается хорошей разработкой по Software Craftsmanship?

Managed DevOps

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

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

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

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

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

Что ему нужно знать?

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

• Опыт системного администрирования. Объективно определить уровень непросто, так как нет точных критериев оценки, но без базовых знаний Linux и сетей придется тяжко, поскольку придется плотно взаимодействовать с Ops-командой (командой инфраструктуры).
• Навыки разработки. Нужно иметь представление о процессе разработки ПО и знания некоторых языков программирования (по многим оценкам, Python изучить легче всего. Также в тренде Java, Go и др.). Без понимания, как написать обращение к API и обработать его ответ, а также умения работы с Git точно не обойтись.
• Английский язык. Он нужен постоянно — большая часть необходимой информации публикуется на англоязычных сайтах.

Анализ и сравнение

Ключевые метрики

1. Частота развертываний. Как часто происходит развертывание новой версии приложения на продуктовое окружение (плановых изменений, исключая хотфиксы и реакцию на инциденты)?
2. Срок поставки. Сколько в среднем времени проходит между коммитом изменения (написанием функциональности в виде кода) и развертыванием изменения на продуктовом окружении?
3. Время восстановления. Сколько в среднем времени занимает восстановление приложения на продуктовом окружении после инцидента, деградации сервиса или обнаружения ошибки, влияющей на пользователей приложения?
4. Неуспешные изменения. Какой процент развертываний на продуктовом окружении приводит к деградации приложения или инцидентам и требует устранения последствий (откат изменений, разработку хотфикса или патча)?

Сколько вешать в граммах?

• Распределяем респондентов по n-мерному пространству, где координата каждого респондента — их ответы на вопросы.
• Каждого респондента объявляем маленьким кластером.
• Объединяем два наиболее приближенных друг к другу кластера в один кластер побольше.
• Находим следующую пару кластеров и объединяем их в кластер побольше.

Как пользоваться

• Калькулятор DORA
• Калькулятор Экспресс 42* (в разработке)
• Своя разработка (можно составить свой внутренний калькулятор).

• Команда внутри нашей организации соответствует нашим стандартам?
• Если нет, то можем ли мы ей помочь — ускорить ее в рамках той экспертизы, которая есть в нашей компании?
• Если да, то можем ли сделать еще лучше?

• Какие у нас команды есть;
• Поделить команды на профили;
• Увидеть: О, эти команды у нас underperforming (немножко не вытягивают), а эти — классные: они деплоят каждый день, без ошибок, lead time у них меньше часа.

калькулятор DORA

Сравнение

• В 1,5-2 раза чаще выпускали новые продукты,
• В 2 раза чаще повышали надежность и/или производительность инфраструктуры приложений.

Особенности профессии

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

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

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

Недостатки профессии DevOps-инженер

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

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

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

Как понять, движусь ли я к DevOps ?

Через вопросы

Вы можете самостоятельно понять, движетесь ли вы к DevOps-культуре, ответив на следующие вопросы:

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

• Есть ли у вас в команде/компании общий инфраструктурный репозиторий?
• Контролируете ли вы технический долг в инфраструктуре?
• Используете ли вы практики разработки в инфраструктурном репозитории?
• Нарезана ли ваша инфраструктура на слои? Можно свериться, например, со схемой Base-service-APP. Насколько сложно внести изменение?

• Время от описания фичи до выкатки в продакшен в 95 % случаев меньше недели?
• Повышается ли качество артефакта на каждом этапе пайплайна?
• Используете ли вы различные стратегии деплоя?

• Ваш мониторинг и логирование — это средство разработки для вас? Ваши разработчики, и вы в том числе, когда пишут код, думают о том, как его замониторить?
• Узнаете ли вы о проблемах от клиентов? Понимаете ли вы клиента лучше из мониторинга и логирования? Понимаете ли вы систему лучше из мониторинга и логирования?
• Меняете ли вы систему просто потому, что увидели, что тренд в системе растет и понимаете, что еще 3 недели и все загнется?

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

Преимущества профессии DevOps-инженер

Согласно статистике ЕМА, внедрение стратегии DevOps на сегодняшний день достигло 30%, и отмечается устойчивая тенденция к увеличению запроса рынка труда на DevOps-инженеров. То есть, это – перспективная профессия, но при условии, что специалист будет высококвалифицированным и стремящимся к профессиональному развитию, потому что конкуренция в этом направлении тоже растет.

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

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

У DevOps-инженера есть все шансы с легкостью найти себе работу в любой компании мира, если есть желание приобрести солидный опыт. Огромный бонус – уровень зарплаты. За рубежом даже у начинающего специалиста Development Operations суммы месячного дохода достигают 7 225 долларов США. В России цифры зарплаты выглядят несколько скромнее – от 100 000 рублей. Но, с учетом разницы в уровне жизни, для начинающего специалиста и эта сумма – приличный доход.

Где можно получить профессию DevOps-инженер?

Учитывая специфику работы DevOps-инженера, начинать обучение можно в любом ВУЗе или даже колледже по следующим направлениям: информационные технологии и коммуникации; информатика и вычислительная техника, программирование и т.д.

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

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

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

Но прежде всего стоит обратить внимание на такие ВУЗы, как:

• Санкт-Петербургский госуниверситет промышленных технологий и дизайна;
• Российский технологический университет МИРЭА;
• Национальный исследовательский университет МЭИ;
• ВШЭ;
• МГУ.

Государственный специализированный институт искусств

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	291 000,00 ₽
Бакалавриат	Очная	521 000,00 ₽

Тип	Форма	Стоимость
Бакалавриат	Очная	521 000,00 ₽
Бакалавриат	Очная	521 000,00 ₽

Московская государственная художественно-промышленная академия им. С. Г. Строганова

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	350 000,00 ₽

Тип	Форма	Стоимость
Бакалавриат	Очная	350 000,00 ₽

Национальный университет «Высшая школа экономики»

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	350 000,00 ₽

Программная инженерия

Тип	Форма	Стоимость
Бакалавриат	Очная	350 000,00 ₽

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

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	295 000,00 ₽

Национальный исследовательский университет «МИЭТ»

Зеленоград

Тип	Форма	Стоимость
Бакалавриат	Очная	273 000,00 ₽

Информационная безопасность

Тип	Форма	Стоимость
Бакалавриат	Очная	195 000,00 ₽

Программная инженерия

Тип	Форма	Стоимость
Бакалавриат	Заочная	84 000,00 ₽
Бакалавриат	Очная	195 000,00 ₽

Российская академия народного хозяйства и государственной службы при Президенте Российской Федерации

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	270 000,00 ₽

Российский экономический университет имени Г.В. Плеханова

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	270 000,00 ₽
Бакалавриат	Очно-заочная	105 000,00 ₽

Информационная безопасность

Тип	Форма	Стоимость
Бакалавриат	Очная	240 000,00 ₽

Арктический государственный институт искусств и культуры

Якутск

Московский государственный технический университет имени Н.Э. Баумана

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	225 850,00 ₽

Программная инженерия

Московский государственный университет дизайна и технологии

Москва

От DevOps к SRE

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

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

Проблема в том, что долгое время не было чёткого понимания, как воплощать принципы DevOps на практике. Редкая конференция по этой методологии обходилась без доклада «Что такое DevOps?». Все соглашались с заложенными идеями, но мало кто понимал, как их реализовать.

Ситуация изменилась в 2016 году, когда Google выпустила книгу «Site Reliability Engineering». В этой книге описывалась конкретная реализация DevOps. С неё и началось распространение SRE-подхода, который сейчас применяется во многих международных IT-компаниях.

DevOps — это философия. SRE — реализация этой философии. Если DevOps — это интерфейс в языке программирования, то SRE — конкретный класс, который реализует DevOps.

Подведем итоги!

Step	Technology	Tools	Ценность для инфраструктуры автоматизации
1	Local running	Node.js, Selenium, Appium	Наиболее популярные инструменты для web и mobile Поддержка многих языков и платформ (включая Node.js)
2	Version control systems	Git
3	Containerisation	Docker, Selenium grid, Selenoid (Web, Android)	Параллельный запуск тестов Изолированные среды Простое, гибкое обновление версий Динамическая остановка неиспользуемых ресурсов Легко настроить
4	CI / CD	Gitlab CI	Тесты часть конвейера Быстрая обратная связь Видимость для всей компании / команды
5	Cloud platforms	Google Cloud Platform	Ресурсы по требованию (платим только когда нужны) Легко управлять и обновлять Видимость и контроль всех ресурсов
6	Orchestration	Kubernetes	В контексте контейнеров с браузерами/эмуляторами внутри pods: Масштабирование / автомасштабирование Самовосстановление Обновления и откаты без прерываний
7	Infrastructure as a code  (IaC)	Terraform, Ansible	Аналогичные преимущества с инфраструктурой разработки Все преимущества версионирования кода Легко вносить изменения и поддерживать Полностью автоматизировано