Devops для разработчиков (или против них?!)

Введение Open Policy Agent (OPA)

Перевод

Что такое OPA?

Это проект, стартовавший в 2016 году, направленный на унификацию применения политик в различных технологиях и системах. Сегодня OPA используется гигантскими игроками в технологической индустрии. Например, Netflix использует OPA для управления доступом к своим внутренним ресурсам API. Chef использует его для предоставления возможностей IAM в своих продуктах для конечных пользователей. Кроме того, многие другие компании, такие как Cloudflare, Pinterest и другие, используют OPA для обеспечения соблюдения политик на своих платформах (например, кластеры Kubernetes). В настоящее время OPA является частью CNCF в качестве инкубационного проекта.

Текущая ситуация: консерватизм трехуровневой системы техподдержки

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

Классическая техподдержка, построенная согласно принципам управления ИТ-сервисами (IT Service Management), имеет трехуровневую иерархию.

• Уровень 1. Это находящаяся в непосредственном контакте с пользователями — обычно по телефону — служба технической поддержки (Service Desk). Нацелена на предоставление техподдержки среднего уровня по неспециализированным вопросам. Основная задача — поддержание стабильного качества услуг при условии решения большинства поступающих запросов здесь же, на первом уровне.

• Уровень 2. Обычно тесно связан с первым, но подразумевает более глубокие общие или специальные знания и навыки сотрудников. Специалисты второго уровня, например, могут проходить дополнительное обучение по поддержке распространенных операционных систем (таких как Microsoft Windows) или аппаратного обеспечения, получая необходимые навыки для решения более сложных проблем.

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

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

• Клиентам предоставлен единый канал общения с техподдержкой независимо от природы проблемы.

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

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

Путешествие клиентского обращения в службу поддержки может закончиться уже на первом уровне, практически не начавшись. Фактически во многих организациях часть обращений обрабатывается с помощью полностью автоматизированных сервисов, которые часто называются «нулевым уровнем» (Level zero).

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

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

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

Было предпринято немало попыток рассчитать сравнительную стоимость решения проблемы на каждом из уровней поддержки. В этой работе 2014 года, например, средняя стоимость закрытия тикета на первом уровне оценивается в 22 $, на втором — в 62 $, а на третьем — в 85 $ (согласно другим исследованиям последняя цифра больше в несколько раз).

Ops’ы такие разные

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

• TechOps — системные администраторы эникеи aka HelpDesk Engineer
• LiveOps — системные администраторы, преимущественно отвечающие за продуктивные среды
• CloudOps — системные администраторы специализирующиеся на публичных «облаках» Azure, AWS, GCP, etc.
• PlatOps/InfraOps/SysOps — системные администраторы инфраструктуры.
• NetOps — сетевые администраторы
• SecOps — системные администраторы специализирующиеся на информационной безопасности — PCI compliance, CIS compliance, patching, etc.

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

Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.

Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.

Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.

С чего начинается DevOps… и куда он может привести

Возможно, вы уже умеете писать отличный код. И может, у вас уже есть реальное представление, как работает платформа, виртуализация и сеть с безопасностью. Но что, если вы не хотите углубляться ни в одну из этих областей? А может, вы уже думали о переходе в DevOps, где требуется много знаний и со стороны dev, и со стороны ops, но не нужно становиться хардкорным разработчиком? Тогда у нас хорошая новость — начинать в DevOps можно в любом возрасте и с любой технической специализацией.

Тому пример — Александр Шуляк, который нашел себя именно в Девопсе. Накануне конференции DevOps 2021 мы встретились с Сашей и поговорили о том, как и с чего начался его DevOps, а также к чему он пришел в этой карьере.

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

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

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

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

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

Дополнительные ответы экспертов

Артём Моралес

DevOps-инженер компании-разработчика российского офисного ПО МойОфис

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

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

Каждый день DevOps-инженер оперирует большим количеством инструментов. Их можно условно разделить на разные группы — к примеру, те, что связаны со средой непрерывного развёртывания (CI/CD-tools), с автоматической конфигурацией, мониторингом, облачной инфраструктурой и др. При выборе каждой технологии специалист обязан чётко осознавать, как внедрение того или иного решения повлияет на процессы в команде. Такие сотрудники должны обладать широким кругозором: это очень востребованная в наше время профессия, и настоящие профи ценятся на вес золота.

Михаил Сарычев

директор по развитию DBI

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

Конференция DevOps Conf 2021

31 мая – 1 июня, Москва, От 24 000 до 48 000 ₽

tproger.ru

События и курсы на tproger.ru

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

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

• проектирование инфраструктуры;
• настройку, поддержку и управление облачными сервисами;
• управление конфигурацией рабочих, тестовых, production-серверов;
• управление непрерывной интеграцией CI/CD (в этом пункте на ум сразу приходят инструменты Jenkins/Bamboo/TeamCity);
• миграция приложений в облако;
• мониторинг инфраструктуры и приложений;
• управление поставкой ПО.

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

Кирилл Семёнов

DevOps Engineer, TL, DataArt

Начнём с того, что DevOps — подход, а не инженер. Роль DevOps в проекте основополагающая. Проект и всё, что с ним связано, базируется на DevOps-процессах. DevOps — это связать вместе разные части всей экосистемы (Dev, QA, Ops, Sec) и автоматизировано обеспечить SDLC.

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

Чем DevOps отличается от сисадмина? Практически всем. Сисадмин отвечает за конкретные задачи: управление доступом пользователей, настройка сетевой составляющей инфраструктуры, почтовые/DNS-серверы, VMS, обновления ОС и т. д. В сложной экосистеме и процессах, связанных с проектом и SDLC, это малая часть задач, относящихся к Ops.

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

• CI/CD (Jenkins, Teamcity, Octopus, Gitlab CI и т. д.);
• Automation (tests automation, tasks automation, updates automation, backups automation, ALL automation);
• IaC (Terraform, Cloud Native: ARM, Cloud Formation и т. д.);
• Alerting/Monitoring;
• Backup/Restore;
• Disaster Recovery;
• Security Management (DevSecOps);
• Release Management и многое другое.

Каждый пункт можно разложить на десятки подзадач. Счёт технологий идёт на сотни. База выглядит вот так:

• CI/CD tools (f.e. Jenkins);
• Cloud (AWS/Azure/GCP);
• IaC (Terraform);
• Containers (Docker, K8s);
• Scripting Languages (PS, Python, Bash).

Топология команды DevOps

Какая структура или топология команды DevOps подходит для организации, зависит от многих вопросов, например:

• Каков набор выпускаемых и поддерживаемых продуктов – чем меньше продуктов, тем больше взаимосвязь Dev и Ops.
• Степень, сила и эффективность технического руководства — имеет ли Dev и Ops общую цель.
• Готова ли организация на трансформацию роли ИТ эксплуатации от «принеси-подай» во встроенной в бизнес процесс.
• Есть ли в организации лидеры, которые готовы указывать на проблемные области и сопровождать изменения.
• Чаще всего построение «команды мечты» потребует последовательной смены нескольких моделей.

Проблемы трехуровневой модели

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

• Многоуровневая поддержка подразумевает несколько очередей. Поскольку первый уровень стремится решать проблемы максимально быстро, все, что не удалось исправить сразу, ставится в очередь. Фактический статус проблемы меняется, и она переходит из разряда текущих в отложенные. По существу уровни 2 и 3 являются складами задач, находящихся в процессе выполнения (Work in Progress), что является проблемой в рамках Lean-философии, которая лежит в основе DevOps. Успешное внедрение DevOps как части Lean требует решительных шагов по сокращению незавершенки (Work in Progress). Уже только эта проблема является существенным сдерживающим фактором прихода DevOps в техническую поддержку.

• Многоуровневая поддержка может заблокировать путь к нужному специалисту. DevOps ратует за увеличение самостоятельности и вовлеченности сотрудников. Поощряется поддержка кода самими разработчиками. Компаниям, практикующим DevOps, удается достичь более высоких скоростей обработки обращений пользователей (согласно отчету «Состояние DevOps» (State of DevOps) за 2016 год в 24 раза быстрее). Но от этого нет никакой пользы, если тикет должен прорваться через несколько очередей, прежде чем попасть к нужному специалисту. Однажды во время обсуждения внедрения Swarming в службе поддержки пользователей один из менеджеров поддержки BMC (Би-эМ-Си) задал справедливый вопрос: «Почему мы помещаем наших лучших людей в конце цепочки?»

DevSecOps: что это и в чем отличие от DevOps

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

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

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

Чего мы добились, используя принципы DevOps

Основное, чего мы добились для бизнеса, работая по принципам DevOps, — это тиражируемость технологических решений. Все решения, которые мы предоставляем, типовые, масштабируемые и построены на шаблонах. Для всех проектов общая концепция процесса CI/CD остается неизменной: выполняются коммит в git и автоматическая сборка (building) — деплой на тестовые серверы (deploying) — функциональное и прочие виды автотестирования (testing) — продвижение сборки в стабильные (promoting) — публикация на GUS (publishing) — распространение через FUS на инфраструктуре заказчика (delivering) — установка или обновление продукта на серверах (installing & updating).

IDEF0-схема типового процесса CI/CD

На каждом из этапов наш отдел помогает разработчикам и тестировщикам решить конкретные технические задачи:

• обеспечить хранение кода в системе GitLab (выделить им проект);
• разработать сборочную конфигурацию на базе одного из типовых шаблонов и обеспечить хранение собранных артефактов в системе Artifactory;
• реализовать конфигурации для деплоя артефактов на серверах тестировщиков и помочь им с подготовкой тестовых конфигураций;
• в случае успешного тестирования — продвинуть сборку, то есть переместить ее в хранилище протестированных артефактов в Artifactory, для чего также создается специальная конфигурация;
• при необходимости опубликовать сборку на корпоративном сервере Global Update, откуда она будет автоматически распространена на FUS-серверы для заказчиков;
• при помощи скриптов на базе SaltStack развернуть сборку на конкретном сервере.

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

О первых шагах нашей команды в DevOps, о том, с какими проблемами мы столкнулись, как выстраивали процесс CI/CD и к чему пришли в итоге, можно почитать в статьях на Хабре:

• Миссия выполнима: как развить DevOps в компании со множеством проектов,
• Личный опыт: как выглядит наша система Continuous Integration,
• Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps.

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

Что со всем этим делать

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

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

• Процессы и культура;
• Site Reliability Engineering;
• Cloud Native;

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

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

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

• Разработчиков, которые занимаются инфраструктурой. Для вас больше всего подойдут группы докладов про SRE и Cloud Native.
• Системных администраторов. Тут сложнее. DevOops — не про системное администрирование. К счастью, на тему системного администрирования есть масса прекрасных конференций, книг, статей, видео в интернете и т.п. С другой стороны, если вам интересно развиваться в плане понимания культуры и процессов, изучения облачных технологий и подробностей жизни с Cloud Native, то мы будем рады вас видеть! Подумайте вот о чем: вот вы занимаетесь админством, а дальше что вы будете делать? Чтобы внезапно не оказаться в неприятной ситуации, стоит учиться уже сейчас.

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

Слайд из доклада Konstantin Diener в Мюнхене

DevOops 2020 Moscow пройдет в Москве, билеты уже можно приобрести на официальном сайте.

Кроме того, вы можете подать свой доклад до 8 февраля

Обратите внимание, что при заполнении формы вы должны выбрать целевую аудиторию, которой ваш доклад принесет больше пользы (внутри списка зарыт сюрприз)

Управление инфраструктурой Open Telekom Cloud с помощью Ansible

Open Telekom Cloud

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

Open Telekom Cloud – международная публичная облачная платформа, основанная на OpenStack. Платформа идеально подходит для компаний или стартапов, которые работают с европейскими пользователями, чьи персональные данные должны храниться в пределах Евросоюза: сервис разработан Deutsche Telekom и соответствует стандартам защиты данных GDPR (Генеральный регламент о защите персональных данных) EC.

Если вам интересна эта тема, добро пожаловать под кат!