Что нужно знать, чтобы стать devops-инженером: ключевые навыки

How we got to DevOps

Until just before 2000, most software was developed and updated using waterfall methodology, a linear approach to large-scale development projects. Software development teams would spend months developing large bodies of new code that impacted most or all of the application. Because the changes were so extensive, they spent several more months integrating that new code into the code base. 

Next, quality assurance (QA), security and operations teams would spend still more months testing the code. The result was months or even years between software releases, and often several significant patches or bug fixes between releases as well. And this “big bang” approach to feature delivery was often characterized by complex and risky deployment plans, hard to schedule interlocks with upstream and downstream systems, and IT’s “great hope” that the business requirements had not changed drastically in the months leading up to production “go live.”

To speed development and improve quality, development teams began adopting agile software development methodologies, which are iterative rather than linear and focus on making smaller, more frequent updates to the application code base. Chief among these methodologies are continuous integration and continuous delivery, or CI/CD. In CI/CD smaller chunks of new code are merged into the code base every one or two weeks, and then automatically integrated, tested and prepared for deployment to the production environment. Agile evolved the “big bang” approach into a series of “smaller snaps” which also compartmentalized risks.

The more effectively these agile development practices accelerated software development and delivery, the more they exposed still-siloed IT operations — system provisioning, configuration, acceptance testing, management, monitoring — as the next bottleneck in the software delivery lifecycle. 

So DevOps grew out of agile. It added new processes and tools that extend the continuous iteration and automation of CI/CD to the rest of the software delivery lifecycle. And it implemented close collaboration between development and operations at every step in the process.

What is DevOps?

By definition, DevOps outlines a software development process and an organizational culture shift that speeds the delivery of higher quality software by automating and integrating the efforts of development and IT operations teams – two groups that traditionally practiced separately from each other, or in silos.

In practice, the best DevOps processes and cultures extend beyond development and operations to incorporate inputs from all application stakeholders — including platform and infrastructure engineering, security, compliance, governance, risk management, line-of-business, end-users and customers — into the software development lifecycle. 

DevOps represents the current state of the evolution of software delivery cycles during the past 20+ years, from giant application-wide code releases every several months or even years, to iterative smaller feature or functional updates released as frequently as every day or several times per day.

Ultimately, DevOps is about meeting software users’ ever-increasing demand for frequent, innovative new features and uninterrupted performance and availability.

Как обычно пишут программы

Традиционный цикл разработки программ выглядит так:

1. Программисты пишут код небольшими порциями.
2. Когда очередная версия программы готова, она отдаётся в отдел тестирования.
3. Тестировщики пишут тесты и ищут ошибки в коде. Если нашли — отдают программистам, и всё начинается с первого пункта.
4. Если ошибок нет, код отправляется на сборку, чтобы включить его в новую версию программы.
5. После добавления этого кода в новую версию код снова тестируют — всё ли нормально, дружит ли новый код со старым и нет ли каких конфликтов. Если есть — код отдаётся обратно программистам.
6. Если всё в порядке, код идёт в бой, например, выкатывается на сайт.

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

Почему это работает

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

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

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

У DevOps есть несколько основных особенностей.

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

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

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

Автоматизированное тестирование. Непрерывное тестирование — один из ключевых компонентов DevOps подхода. Для этого используются специализированные инструменты, такие как Travis CI и Selenium.

Быстрая и надежная доставка обновлений. Благодаря тесному сотрудничеству между командами и внедрению автоматизации выпуска приложений (application-release automation), программное обеспечение обновляется быстрее, чем при традиционном процессе разработки. ARA позволяет ускорить процесс развертывания новых сборок с минимальным временем простоя и меньшим количеством ошибок конфигурации, которые обычно возникают при развертывании вручную.

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

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

Как стать инженером DevOps: требования и навыки

В современных реалиях ИТ-рынка большинство DevOps приходят в профессию из техобслуживания, развивая свои навыки в сфере разработки продуктов. Это связано с тем, что изначально 70-90% задач такого специалиста были связаны с поддержанием инфраструктуры — систем, баз данных, серверов, сетей, и только 10-30% требовали понимания разработки или автоматизации. В течение нескольких последних лет наметился тренд на повышение требований к соискателю: компании хотят видеть опыт не только в поддержке, но и практические навыки в программировании — это позволяет будущему сотруднику быстрее принимать решения и устранять ошибки в процессе реализации проекта.

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

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

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

Управление исходным кодом

SVN

SVN – это централизованный инструмент контроля версий и исходного кода, разработанный Apache.

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

Git

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

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

Bitbucket

Bitbucket – это веб-хостинговая платформа, разработанная Atlassian.

Bitbucket также предлагает эффективную систему проверки кода и отслеживает все изменения в коде.

Его можно легко интегрировать с другими инструментами DevOps, такими как Jenkins, Bamboo.

GitHub

GitHub – это платформа для размещения кода, предназначенная для контроля версий и совместной работы.

Он предлагает все функции распределенного контроля версий и управления исходным кодом (SCM) в Git в дополнение к своим функциям.

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

Ant

Apache Ant – это инструмент для сборки и развертывания на основе Java с открытым исходным кодом.

Он поддерживает формат файла XML.

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

Maven

Maven – это инструмент для автоматизации сборки, который в основном используется для Java-проектов.

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

Grunt

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

Это хорошая альтернатива для таких инструментов, как Make или Ant.

Gradle

Gradle – это система автоматизации сборки с открытым исходным кодом, основанная на концепциях Apache Maven и Apache Ant.

Он поддерживает Groovy правильный язык программирования вместо XML-файла конфигурации.

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

Кто такой DevOPS-инженер и что он делает?

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

Перед специалистом стоит несколько основных задач:

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

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

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

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

Чтобы выполнять свои задачи специалист должен владеть целым набором инструментов:

• Git, Mercurial, Subversion, CVS – для распределенного контроля версий.
• Применять Docker, Rocket, Kubernetes – для контейнеризации.
• Jenkins, TeamCity, Bamboo, GitLab, Github Actions, AWS CodePipeline – для непрерывной интеграции.
• Puppet, Chef, Ansible, Terraform – для управления инфраструктурой.
• VMware DRS, AWS, Google Cloud Platform, Microsoft Azure, Huawei Cloud, Яндекс Облако, Mail.ru Cloud Solutions – для работы с облачной архитектурой.
• Vagrant, lxc – для виртуализации.
• Prometheus, Grafana, Zabbix – для мониторинга.

Также, специалист должен владеть языками программирования. Практика показывает, что нет одного или нескольких «правильных» языков, главное то, что человек умеет использовать свои знания для автоматизации. Но чаще всего инженеры знают Python, Ruby, Node.js, Go, Rust, C или C++. Не лишним будет умение работать с оболочкой Bash, дистрибутивом Ubuntu, знание баз данных MySQL.

Базовый набор инструментов можно вместить в достаточно простую схему:

DevOPS Tools

Но в процессе развития, работы над разными проектами и в разных компаниях, список инструментов хорошего инженера может существенно расшириться… Примерно так:

В рамках этой профессии можно выделить несколько основных ролей со своей узкой специализацией:

Build Engineer	Отвечает непосредственно за сборку кода, разбирает конфликты и подтягивает зависимости.
Automation Engineer	Специализируется на автоматизации процессов. Именно эта функция является ключевой в подходе Девопс
Release Engineer	Его сфера полномочий – доставка кода между разработкой и продакшном. Он определяет, какую ветку отправить на тестирование, а что попадет в продакшн.
Security Engineer	Отвечает за выявление уязвимых мест в коде, проведение тестов на безопасность.

FAQ

Могу ли я устроиться на позицию Девопс-инженера без опыта работы в ИТ?

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

Какой опыт работы нужно иметь, чтобы претендовать на должность инженера?

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

Можно ли работать в небольших компаниях или стартапах?

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

Целевые показатели: SLA, SLI, SLO

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

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

Показатели доступности вырабатываются вместе с продакт-оунером и закрепляются в соглашении о целевом уровне обслуживания — Service-Level Objective (SLO). Оно становится гарантом, что в будущем разногласий не возникнет.

Специалисты по SRE рекомендуют указывать настолько низкий показатель доступности, насколько это возможно. «Чем надёжнее система, тем дороже она стоит. Поэтому определите самый низкий уровень надёжности, который может сойти вам с рук, и укажите его в качестве SLO», сказано в рекомендациях Google. Сойти с рук — значит, что пользователи не заметят разницы или заметят, но это не повлияет на их удовлетворенность сервисом.

Чтобы понимание было ясным, соглашение должно содержать конкретные числовые показатели — Service Level Indicator (SLI). Это может быть время ответа, количество ошибок в процентном соотношении, пропускная способность, корректность ответа — что угодно в зависимости от продукта.

SLO и SLI — это внутренние документы, нужные для взаимодействия команды. Обязанности компании перед клиентами закрепляются в в Service Level Agreement (SLA). Это соглашение описывает работоспособность всего сервиса и штрафы за превышение времени простоя или другие нарушения.

Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.

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

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

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

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

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

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

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

Журналирование и мониторинг

Журналирование и мониторинг — очень важные аспекты инфраструктуры.

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

Каждая компания будет иметь отдельный уровень инфраструктуры под журналирование. Обычно используются такие стеки, как Splunk, ELK и Graylog. Кроме того, существует несколько SaaS-компаний, таких как Loggly, которые предоставляют инфраструктуру для централизованного хранилища журналов.

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

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

Как инженер DevOps, вы должны иметь доступ к журналам и уметь устранять неполадки во всех средах (Dev, QA, Stage, Prod)

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

AWS

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

Вы спросите, можно ли начать с Google Cloud или Azure? Безусловно! Но после серьезного падения доллара, самым безопасным вариантом, по крайней мере, в 2018 году остается AWS.

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

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

“Когда ты обнаружил еще одну функцию AWS, о которой ты никогда не знал”. Фото Tom Pumford опубликованное на Unsplash

Шучу, это был сарказм. Хорошая новость в том, что вам не нужно знать каждую функцию AWS.

Начните со следующего: VPC, EC2, IAM, S3, CloudWatch, ELB и всех продуктов из меню «Безопасность, идентификация и соответствие требованиям». Этого достаточно для начала работы с облачными сервисами.

У AWS есть собственный веб-сайт предназначенный для изучения их функций и это отличное место для начала обучения.

Я рекомендую вам уделять хотя бы по 30 минут в день на практику Python, Linux и AWS.

ПРИМЕЧАНИЕ: В целом, я считаю, что тратить ежедневно по часу, пять раз в неделю, достаточно для того, чтобы за 6 месяцев или меньше сложилось четкое представление о том, что происходит в DevOps сфере.

Но это касается только фундаментальных знаний!

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

Кто стоит у истоков 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?

DevOps culture

It’s generally accepted that DevOps methods can’t work without a commitment to DevOps culture, which can be summarized as a different organizational and technical approach to software development.

At the organizational level, DevOps requires continuous communication, collaboration and shared responsibility among all software delivery stakeholders — software development and IT operations teams for certain, but also security, compliance, governance, risk and line-of-business teams — to innovate quickly and continually, and to build quality into software from the start.

In most cases the best way to accomplish this is to break down these silos and reorganize them into cross-functional, autonomous DevOps teams that can work on code projects from start to finish — planning to feedback — without making handoffs to, or waiting for approvals from, other teams. When put in the context of agile development, the shared accountability and collaboration are the bedrock of having a shared product focus that has a valuable outcome.

At the technical level, DevOps requires a commitment to automation that keeps projects moving within and between workflows, and to feedback and measurement that enable teams to continually accelerate cycles and improve software quality and performance.

Что нужно уметь

Чтобы стать девопсом, нужно освоить много разного:

• принципы и теорию разработки ПО;
• инструменты автоматизации работы с кодом — Git, Jenkins;
• системное администрирование на уровне мидла или выше;
• виртуальные контейнеры и работу с ними — Docker и Kubernetes;
• базы данных — реляционные и нереляционные;
• веб-серверы;
• Python или другой язык для написания рабочих скриптов;
• системы управления конфигурацией серверов — Ansible;
• сбор данных по нагрузке и ошибкам во всех системах.

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

Про культуру и процессы

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

Например, описанием разницы между сисадминским и SRE-шным подходом к service management начинается знаменитая Google SRE Book. Интересные исследования проведены в рамках опроса DORA — видно, что самые лучшие разработчики каким-то образом умудряются деплоить новые изменения на продакшн быстрее, чем раз в час. Они же тестируют руками не больше 10% (это видно по прошлогоднему DORA). Каким образом у них это получается? «Excel or die» – говорит один из заголовков отчета. За подробным обсуждением этой статистики в разрезе тестирования можно обратиться к кейноуту Баруха Садогурского «У нас DevOps. Давайте уволим всех тестировщиков» на другой нашей конференции, Heisenbug.

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

Общая идея DevOps в том, чтобы наладить взаимодействие между ролями и отделами. В первую очередь это достигается не каким-то хитро настроенным софтом, а практикой общения. 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	Аналогичные преимущества с инфраструктурой разработки Все преимущества версионирования кода Легко вносить изменения и поддерживать Полностью автоматизировано