С чего начать devops?

Gitlab-CI и проверка корректности синтаксиса Ansible-lint

Всем привет! Мы продолжаем серию статей про DevOps и ищем наиболее эффективные способы управлять конфигурацией, делясь с вами опытом. В прошлых статьях мы рассматривали, как выстроить управление конфигурацией Ansible с помощью Jenkins и Serverspec, а теперь по вашим просьбам рассмотрим, как организовать управление конфигурацией с помощью GitLab-CI. Ansible-lint — это утилита для проверки корректности синтаксиса плейбука и стиля кода, которую можно интегрировать в CI-сервис. В нашем случае мы внедряем её в gitlab-ci для проверки плейбуков на этапе принятия Merge-Request и выставления статуса проверок. GitLab (GitLab Community Edition) — это opensource-проект, менеджер git-репозиториев, изначально разрабатывающийся как альтернатива платной корпоративной версии Github.

Знания, умения и личные качества

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

Специалист обязательно должен знать несколько языков программирования. В первую очередь это необходимо для автоматизации. Пригодятся языки Python, Bash, Ruby, Go, PowerShell. Достаточно знать основы синтаксиса, скрипты для автоматизации, понимать объектно-ориентированное программирование.

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

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

И вот еще тот минимум, что надо знать:

• системы оркестрации, такие как Docker и Kubernetes;
• системы конфигураций Chef, Ansible, Puppet;
• системы сборки GitLab, Jenkins;
• языки разметки JSON и YAML;
• базы данных;
• сервисы мониторинга и оповещений;
• сервисы логирования;
• настройки кибербезопасности;
• процессы CI/CD;
• английский язык;
• периодическая таблица DevOps.

Список того, что нужно знать и уметь DevOps-специалисту можно продолжать долго. Но только практикуясь станет понятно, что именно изучать и как.

Для DevOps-инженера важны и личные качества:

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

Это только основные требования. Конкретные условия зависят от работодателей.

Бэкапы для HashiCorp Vault с разными бэкендами

Недавно мы публиковали статью про производительность Vault с разными бэкендами, а сегодня расскажем, как делать бэкапы — и снова на разных бэкендах: Consul, GCS (Google Cloud Storage), PostgreSQL и Raft.

Как известно, HashiCorp предоставляет нативный метод бэкапа только для одного бэкенда — Integrated Storage (Raft Cluster), представленного как GA в апреле прошлого года. В нем можно снять снапшот всего одним curl’ом и не беспокоиться о каких-либо нюансах.

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

Поэтому важно искать пути для консистентного бэкапа

Где учат DevOps?

Соответствующее образование можно получить в одном из ведущих государственных ВУЗов, к примеру:

• МФТИ;
• ВШЭ;
• МГТУ им. Н. Э. Баумана;
• МГУ ВМК.

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

Практически все современные учебные платформы предлагают соответствующие программы или интенсивы, которые будут полезны даже тем, кто уже трудоустроен:

1. Skillbox
2. Нетология
3. SkillFactory
4. Geekbrains
5. ProductStar
6. Otus

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

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

Согласно данным ИТ-специализированного кадрового агентства Spice IT, топ компаний, опыт работы в которых высоко оценивается на рынке, выглядит так:

Противотренд – слабый

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

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

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

Какими задачами занимается DevOps-инженер

Есть несколько типов задач, которые решают DevOps-инженеры в ABBYY.

Задачи, связанные со средой непрерывной интеграции (CI-средой)

Настроить качественный CI pipeline, проработать схемы доставки до продакшна вместе с другой командой. Сюда также относится выдача наших артефактов — инструментов, которые производит разработка для использования в других командах, когда им нужно развернуть нашу платформу у себя в кластере и проверить случаи совместимости. DevOps-инженер готовит Helm-чарты для всех новых сервисов, которые будут создаваться. Helm — это пакетный менеджер для кластера Kubernetes, он позволяет удобно раскатать этот сервис в кластер.

Вопросы запуска нашего решения в on-premise-окружении

В последнее время мы фокусировались на облаке, но уже есть задача подготовить продукт к on-premise, а с этим всё сложнее. Задачи могут быть как исследовательские (выбрать подход к тому, как мы будем разворачиваться, например), так и непосредственно связанные с имплементацией. Например, мы должны найти инструмент, который поможет удобно развернуть все машины без самостоятельного написания скриптов. При этом DevOps-инженер сам никуда не выезжает, мы пытаемся эмулировать среду on-premise на основании фидбэка от менеджера продукта.

Исследование новых технологий

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

Мониторинг рабочих окружений: dev, staging и pre-production

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

Мониторинг расходов на облачную инфраструктуру

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

Рынок DevOps ресурсов

Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.

Итак:

• с 1 по 6 — системный администратор
• 7 — немного сетевого администрирования, что тоже укладывается в сисадмина, уровня Middle
• 8 — немного безопасности, что обязательно для сисадмина уровня Middle
• 9-11 — Middle System Administrator
• 12 — В зависимости от поставленных задач либо Middle System Administrator, либо Build Engineer
• 13 — Виртуализация — Middle System Administrator, либо так называемый CloudOps, расширенные знания именно сервисов конкретной хостинг площадки, для эффективного использования денежных средств и снижения нагрузки на обслуживание

Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.

Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.

Рассмотрим иную вакансию:

Разбираем:

• 1 — Senior System Administrator
• 2 — В зависимости от смысла вкладываемого в этот стэк — Middle/Senior System Administrator
• 3 — Опыт работы, в том числе, может означать — «Кластер не подымал, но создавал и управлял виртуалками, был один Docker хост, доступ к контейнерам натил» — Middle System Administrator
• 4 — Junior System Administrator — да, админ не умеющий писать элементарные скрипты автоматизации, вне зависимости от языка, не админ — эникей.
• 5 — Middle System Administrator
• 6 — Senior System Administrator

Резюмируя — Middle/Senior System Administrator

Еще одна:

Посмотрим:

• 1 — Хм… Что ребята имеют в виду? =) Скорее всего они сами не знают что за этим скрывается
• 2 — Build Engineer
• 3 — Middle System Administrator
• 4 — Софт-скил, рассматривать пока не будем, хотя Agile еще одна вещь, которую интерпретируют так, как удобно.
• 5 — Слишком пространно — это может быть скриптовый язык, либо компилируемый. Интересно, а писал в школе на Pascal и Basic их устроит? =)

Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем ‘build framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.

Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.

Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.

С низов ИТ до DevOps-инженера

Вадим Князев, DevOps-инженер «Нетологии-групп»:

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

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

Но я смотрел на коллег-разработчиков и системных инженеров и очень хотел разобраться, как все устроено. В перерыве между перезагрузками роутеров что-то читал, приставал с вопросами к коллегам, пытался делать сам — покупал старые компьютеры, объединял их в сеть, пробовал поднимать разные приложения, сначала все руками, потом показали, что есть менеджеры конфигураций, тогда первый раз попробовал Puppet. В итоге перешел с первого уровня поддержки на второй. Там уже приходилось решать более сложные технические вопросы. Затем меня повысили до системного администратора, и я стал поддерживать инфраструктуру, — рассказывает Князев.

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

Работа разработчиком Владимиру Князеву казалась скучной

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

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

В «Нетологию-групп» он пришел уже на работающую инфраструктуру, нужно было только все поддерживать и развивать. Князев считает, что делать все с нуля гораздо проще, чем принимать то, что уже работает. Зачастую приходится изучать новые инструменты и подходы, которые были внедрены до тебя. Самой большой трудностью для него стал Kubernetes: «я много читал о нем, всегда хотел попробовать, но предыдущие проекты не позволяли его использовать. У меня был страх, что я не разберусь, но когда на собеседовании меня спросили «А не боишься, что не разберешься?», я ответил, что не боюсь. Пришлось разобраться».

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

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

Источник фото — «Нетология-групп»

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

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

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

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

Что нужно узнать, чтобы стать DevOps-инженером

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

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

Каждый DevOps должен уметь:

• работать с GitLab, создавать пространство для коллективной работы, разрешать внутренние конфликты версий, настраивать CI/CD — конвейер, который позволяет непрерывно вносить в код небольшие изменения и быстро запускать приложения на боевых серверах;
• программировать на Python. Это понадобится, чтобы писать программы для автоматизации и в целом понимать специфику работы программистов;
• работать с контейнерами Docker — ПО для автоматического развёртывания и управления приложениями в средах с поддержкой контейнеризации;
• настраивать всю инфраструктуру разработки;
• мониторить статусы сервисов, серверов и сетевого оборудования с помощью инструментов вроде Zabbix;
• настраивать инструменты для автоматизации тестирования.

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

Например, вот требования к DevOps в одной из вакансий. Обещают зарплату 200–250 тысяч рублей

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

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

Методы и средства реализации: как работает DevOps

Методологически девопс поддерживает принципы Agile и Continuous delivery – непрерывной поставки ПО. Для организации процессов могут быть использованы такие методы Agile, как Scrum, Kanban и их варианты.

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

• Распределенный контроль версий (Git, Mercurial, Subversion, CVS);
• Контейнеризация (Docker, Rocket, Kubernetes);
• Непрерывная интеграция – сборка и тестирование конечного продукта (Jenkins, TeamCity, Bamboo);
• Управление инфраструктурой как кодом (Puppet, Chef, Ansible);
• Виртуализация (Vagrant);
• Балансировка облачных ресурсов (VMware DRS).

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

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

Инструменты Devops

Сам себе DevOps: строим cloud-only CI для веб приложения

Из песочницы

Привет, Хабр! Сегодня мы поговорим немного о DevOps и самоорганизации.

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

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

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

Rebrainme

Преимущества:

• Вы попадаете на виртуальную стажировку в DevOps-агентство Fevlake.
• Проходите практикум в удобное для вас время. Срок практикума неограничен.
• Поэтапно проходите более 200 заданий. К каждому заданию прилагаются необходимые материалы для его выполнения.
• Закрытые мастер-классы экспертов.
• SLA 24 часа на каждое сданное задание.
• Есть вопрос по заданию? Спрашиваете у авторов практикума и экспертов в закрытом чате Telegram.
• Полный кейс агентства Fevlake.
• Готовят ваше резюме и передают HR.
• Помогут подобрать интересный проект.

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

Linuxtrainingcenter

Курсы DevOps рассчитаны как на начинающих, так и на специалистов, кто уже работает в IT в таких направлениях как – Support, QA, Development (если программный продукт вашей компании работает на Linux). После обучения, вы сможете подняться из джуниора (junior – начальный уровень специалиста) до миддла (middle – средний уровень) или синьора (senior – высококвалифицированный специалист).

Все обучение DevOps проходит на русском языке и состоит из 6 частей:

• Курс Linux (состоит из 3-х частей: LPIC-1, LPIC-2, RHCSA)– изучение основ работы с Linux и настройки серверов. Сервера используются для всех последующих операций
• Курс git – узнаете, как работать с кодом с разных ветках и с версиями кода с помощью GIT, а также как соединять код воедино
• Курс Jenkins – изучите, как оформить и предоставить клиенту код, который лежит в git в виде понятного интерфейса
• Курс aws и курс aws sysops – узнаете, как с помощью облачных сервисов от Amazon настроить, даже самую сложную инфраструктуру и легко ею управлять
• Курс Docker – автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации
• Курс Kubernetes. Certified Kubernetes Administrator (CKA) – CKA это новая программа сертификации, по праву считающаяся главным экзаменом для инженеров, специализирующихся в области Kubernetes, и охватывает все аспекты работы с этой системой

После прохождения курсов DevOps обучению на русском языке вы сможете:

• Эффективно работать в любой IT команде;
• Командно выполнять поставленные задачи;
• Быстро решать возникающие проблемы;
• Автоматизировать процессы системы;
• Уверенно работать с системами управления базами данных;
• Разбираться в современных методиках девопс;
• Создавать безопасное окружение и оптимизировать его для разработки ПО.

Преимущества курса DevOps онлайн на русском языке:

• Весь материал систематизирован и усложняется от базовых навыков работы с Linux до создания высокодоступных кластеров и отсылка идет к уже пройденному материалу.
• В процессе обучения DevOps онлайн познакомитесь с ключевыми моментами данного подхода, поймете технологию внедрения, преимущества и приоритет использования девопс для IT компании, получите теоретическую и практическую базу знаний по каждому курсу, изучите одни из самых популярных инструментов DevOps, поймете принцип их использования при внедрении подхода DevOps.
• На выходе вы будете понимать и уметь строить весь процесс CI&CD (непрерывную интеграцию и доставку). А полученные знания инструментов и принципов DevOps позволят организовать автоматизированный процесс разработки программного обеспечения или приложения, благодаря которому ваша IT компания будет иметь возможно делать быстрые релизы и обновления программного продукта.
• Специалисты готовят DevOps инженеров, которые будут уже иметь знания и практический опыт внедрения девопс, с применением нужных инструментов, в процесс разработки любой IT компании т. к. все обучение строится на практических заданиях по каждому курсу.
• После окончания обучения вы сможете устроиться на престижную и современную работу DevOps инженера, что сделает вас востребованным IT специалистов для любой IT компании!

LinuxTrainingCenter уже более 3 лет на рынке онлайн и оффлайн обучения. Знания, полученные в процессе обучения, крайне востребованы в IT-сфере. Вы можете открыть любой сайт по поиску IT-специалистов и для всех будут общие требования – это знания Linux и связанные с ним, прямо или косвенно, вещи (DHCP DNS MySQL), AWS или Amazon cloud, CI & CD. Все это вы найдете в курсе DevOps.

DevOps and site reliability engineering (SRE)

Site reliability engineering (SRE) uses software engineering techniques to automate IT operations tasks — e.g. production system management, change management, incident response, even emergency response — that might otherwise be performed manually by systems administrators. SRE seeks to transform the classical system administrator into an engineer.

The ultimate goal of SRE is similar to the goal of DevOps, but more specific: SRE aims to balance an organization’s desire for rapid application development with its need to meet performance and availability levels specified in service level agreements (SLAs) with customers and end-users. 

Site reliability engineers achieve this balance by determining an acceptable level of operational risk caused by applications — called an ‘error budget’ — and by automating operations to meet that level. 

On a cross-functional DevOps team, SRE can serve as a bridge between development and operations, providing the metrics and automation the team needs to push code changes and new features through the DevOps pipeline as quickly as possible, without ‘breaking’ the terms of the organizations SLAs. 

Самые распространенные возражения

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

«Зачем вообще что-то менять, у нас и так все хорошо. И лучшее — враг хорошего». К сожалению, если мы не меняемся, то все плохо, потому что меняется все вокруг нас. Например, история трехлетней давности о том, как Equifax пострадал из-за дырки в безопасности настолько капитально, что CEO пришлось уволиться. Они ничего не делали, а мы не можем себе позволить ничего не делать.

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

Элияху Голдратт написал книгу The Goal, которая как раз про оптимизацию процессов. Она вышла в виде комикса, поэтому после того, как мы совсем устали читать 100500 книжек, полистать комикс и поучить оптимизацию очень приятно.

«Регуляции — это ого-го какой тормоз для DevOps, потому что мы не можем сейчас все автоматизировать и дать разработчикам доступ в продакшене, у нас регуляции». Если считать регуляции тем, что надо сертифицировать и проверять каждый релиз — это медленно и нудно. Но на самом деле регуляции не говорят, что надо проверять каждый релиз. Великолепно можно сертифицировать не релиз, а ваш pipeline. И ни один из регуляторов еще не говорил: «Нет, нельзя сертифицировать pipeline» и при помощи этого потерять свои регуляции. Поэтому сертифицируйте свои pipeline, и с регуляцией никаких проблем тоже не будет. А DevOps именно о pipeline и автоматизации и говорит.

«Вот эта история о том, чтобы релизить быстрее — невозможна! Потому что нам нужно гарантировать качество, безопасность и много других вещей. Это все требует времени, мы не можем просто так выкидывать всё в продакшн». Время обычно экономится при использовании какого-то робота или автоматизации. Автоматизируйте все, что надо делать. И на самом деле эта автоматизация помогает не только с тем, что времени будет хватать, а еще с тем, что ее проще будет сертифицировать.

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

Давайте суммируем две ключевые точки доклада.

• Изучайте модель Influence Without Authority, она вам может помочь не только с DevOps-трансформацией, но и с многими другими инициативами в вашей профессиональной жизни.
• Учитесь работать с возражениями.

5 вещей о наблюдаемости данных, которые должен знать каждый дата-инженер

Перевод

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

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

Джесси Андерсон, управляющий директор Big Data Institute и автор книги «Команды инженерии данных: создание успешных Big Data команд и продуктов», и Барр Мозес, соучредитель и генеральный директор Monte Carlo, делятся всем, что вам нужно знать, чтобы начать работу на этом новом уровне стека данных.

Инжиниринг данных (Data Engineering) часто называют «водопроводом data science» — обычно, имея в виду способ, которым инженеры по обработке данных обеспечивают правильное функционирование всех конвейеров и рабочих процессов, а также правильные данные, поступающие в нужных направлениях к нужным заинтересованным сторонам. Но большинство дата-инженеров, с которыми я разговариваю, имеют одно вполне конкретное мнение о водопроводчиках: вы звоните им только тогда, когда что-то идет не так.

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

Как стать DevOps-инженером?

Вообще DevOps-инженер — это больше про опыт, нежели про знание конкретного софта. Девопс-ребята постоянно учатся, изучают и тестируют новые проекты и технологии. Они должны постоянно задавать себе вопрос: улучшит ли эта технология наш проект? Что лучше выбрать в качестве языка: Ruby, Python, Go или написать на чистых плюсах? А как мы будем доставлять изменения в продакшен, чтобы не поломать работающие системы?

Главное, что надо понимать, — DevOps-специалист обладает действительно хорошим кругозором. Чтобы его расширить необходимо постоянно заниматься самообучением. Ниже я привел примерные шаги, которые помогут вам вырасти из, например, системного администратора в DevOps-инженера. Запомните: список всего лишь указывает направление, оттачивать навыки придётся вам самим.

1. Сразу напишем небольшое приложение. Язык выбираем абсолютно любой. Приложение будет отдавать информацию о пользователях через HTTP. По сути, простенькое API.
2. Теперь давайте добавим работу с базой: пусть наши пользователи хранятся в базе. Идеально структуру базы хранить рядом с кодом и научиться прогонять миграции при новых изменениях. Таким образом ваше приложение само синхронизирует базу до нужной структуры.
3. Регистрируемся на GitHub/Bitbucket и закидываем весь исходный код нашего приложения туда.
4. На своей машине поднимаем Jenkins/TeamCity и настраиваем автоматическую сборку приложения из нашего репозитория по кнопке.
5. Усложняем задачу. Настроим webhooks на GitHub/Bitbucket, которые будут автоматически запускать сборку на Jenkins/TeamCity.
6. Добавим тестов в Jenkins: как минимум можно прогонять линтер по нашему коду или набросать unit-тесты.
7. Переключимся на настройку dev окружения. Берём в руки Ansible, Chef, Puppet или SaltStack и настраиваем виртуалку с нуля: создаем пользователей, устанавливаем необходимые библиотеки и зависимости.
8. Подводим все это дело под Vagrant: виртуалка должна автоматически подниматься и настраиваться.
9. Подключаем vagrant к Jenkins с помощью соответствующего плагина: при пуше в Git наше приложение собирается, и поднимается виртуальное окружение с помощью Vagrant + Configuration System Management.
10. Ищем best practices по деплою приложений на языке, который вы выбрали. Можно заворачивать всё в deb-пакеты, можно деплоить Ruby с помощью Capistrano. Главное — выбрать решение.
11. Выбор сделан, реализуем его и конфигурируем Jenkins, чтобы после пуша в репозиторий, Jenkins, помимо сборки приложения и развертывания окружения, выкладывал и запускал наш код.
12. Добавляем смоук-тесты: после запуска Jenkins должен запросить список пользователей у нашего API и убедиться, что получает ответ.
13. Добавляем мониторинг нашего проекта: изучаем time series базы, настраиваем prometheus, grafana, автоматически подключаем новый инстанс нашего приложения к мониторингу.
14. Улучшаем мониторинг: интегрируемся со Slack и PagerDuty, чтобы получать нотификации.
15. Читаем про Docker, пишем Dockerfile и оборачиваем наше приложение.
16. Изучаем увлекательные статьи про настройку систем оркестрации Swarm, Kubernetes, Rancher Cattle. Следуем рекомендациям и поднимаем кластер.
17. Меняем Jenkins: собираем Docker-образ, прогоняем тесты, запускаем собранный докер на кластере Kubernetes, проводим smoke-тесты, вводим наше приложение в балансировку.

Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps-специалиста — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на Go? Теперь пишем на Ruby. Использовали Jenkins? Берём TeamCity. Поднимали Kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.