Devops-инженер

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

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

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

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

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

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

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

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

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

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

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

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

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

Swarming на практике: пример структуры для DevOps

У Swarming нет единственной четко определенной структуры. Отчасти это объясняется новизной и, соответственно, малой распространенностью. Однако показанный ниже пример (основанный на swarming-методах поддержки пользователей, применяемых в BMC) является типичным. Он существенно улучшил работу службы поддержки (о чем было рассказано на UK’s Servicedesk and IT Support Show в 2015).

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

Первичная сортировка в структуре Swarm

Каждая группа (Swarm) ­— это небольшая команда, которая обрабатывает поступающие заявки в режиме, близком к реальному времени:

“Severity 1” Swarm (Группа по работе с инцидентами первой степени тяжести)

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

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

Эта группа нацелена на решение самых серьезных проблем. Ее участники координируют реакцию на сложные ситуации, подключают нужных людей, стараются организовать максимально быстрое решение критических проблем. Этот процесс не сильно отличается от процедуры реакции на серьезные происшествия (Major Incident), применяемой в традиционной многоуровневой модели. Однако параллельно развернута и другая группа, обрабатывающая гораздо большее количество обращений:

Dispatch Swarm (Группа диспетчеризации)

Проводит встречи каждые 60–90 минут.

Сфокусирована на регионах и продуктовых линейках.

Основное внимание: «схватить вишенку» (в первую очередь браться за то, что можно исправить очень быстро).

Вторичная задача: проверка обращений перед их отправкой командам поддержки продуктовых линеек.

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

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

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

Использование Dispatch Swarming приводит к быстрому решению значительного числа задач (в BMC их количество составляет примерно 30%), а оставшиеся обращения попадают в очереди более привычных команд поддержки, которые занимаются отдельными линейками продуктов. Здесь многие задачи будут знакомы и понятны рядовым членам команды, поэтому их решение не должно вызывать трудностей. При этом еще одна часть обращений (возможно, около 30%) могут оказаться достойны внимания лучших специалистов службы поддержки независимо от их структурной принадлежности.

Здесь используется группа третьего типа: Backlog Swarm.

Backlog Swarm (Группа работы с накопившимися задачами)

Проводит встречи регулярно, обычно ежедневно.

Основное внимание: решение сложных задач, полученных от команд поддержки продуктовых линеек.

Вторичная задача: замена одиночных экспертов.

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

Так кто же такие DevOps инженеры?

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

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

Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.

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

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

Чем люди занимаются в DevOps (на самом деле)

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

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

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

Есть и техническая часть вопроса, конечно. Если у тебя новый код на тестирование попадает через месяц, а в релизе оказывается только через год, и ускорить всё это физически невозможно — до хороших практик можно не дожить. Хорошие практики поддерживаются хорошими инструментами. Например, держа в голове идею Infrastructure-as-Code, можно использовать что угодно, от AWS CloudFormation и Terraform до Chef-Ansible-Puppet. Всё это надо знать и уметь, и вот это уже вполне инженерная дисциплина

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

  • Улучшение взаимодействия между ролями и отделами
  • Принятие ошибок как неотъемлемой части работы
  • Постепенное осуществление изменений
  • Использование тулинга и прочей автоматики
  • Измерение всего, что можно измерить

Это не просто какой-то набор утверждений, а конкретное руководство к действию. Например, на пути принятия ошибок нужно будет разобраться с рисками, измерить доступность и недоступность сервисов с помощью чего-то вроде SLI (service level indicators) и SLO (service level objectives), научиться писать постмортемы и сделать так, чтобы писать их было не страшно.

В дисциплине SRE использование инструментов — только одна из частей успеха, впрочем, немаловажная. Нам нужно постоянно развиваться в техническом плане, смотреть, что происходит в мире и как это можно применить в своей работе.

В свою очередь, сейчас стали очень популярными решения Cloud Native. Согласно современному пониманию Cloud Native Computing Foundation, технологии Cloud Native позволяют организациям разрабатывать и запускать масштабируемые приложения в современных динамичных средах, таких как публичные, приватные и гибридные облака. В качестве примера можно привести контейнеры, сервис-меши, микросервисы, неизменяемую инфраструктуру и декларативные API. Все эти техники позволяют слабосвязанным системам оставаться эластичными, управляемыми и хорошо наблюдаемыми. Хорошая автоматика позволяет инженерам делать большие изменения часто и с предсказуемыми результатами, не превращая это в адский труд. Все это поддерживается стеком из всем известных инструментов, таких как Docker и Kubernetes.

Это довольно непростое и развесистое определение связано с тем, что и область довольно непростая. С одной стороны утверждается, что новые изменения в эту систему должны добавляться достаточно просто. С другой стороны, чтобы разобраться в том, как сделать некую контейнеризованную среду, в которой слабосвязанные сервисы живут на software-defined инфраструктуре и поставляются туда с помощью непрерывного CI/CD, и выстроить вокруг всего этого DevOps-практики — на всем этом надо не одну собаку съесть.

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

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

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

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

Чем занимается DevOps-инженер

В ситуации с DevOps важно не путать термины. Дело в том, что DevOps — это не какое-то конкретное направление деятельности, а профессиональная философия

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

Соответственно, DevOps-инженер — это специалист, который внедряет эту методологию в процесс работы:

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

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

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

С чего начать, чтобы стать DevOps engineer?

Начните с полезных статей:

  • Эффективный DevOps: 6 способов прокачать команду и себя
  • Как IT-специалисту ввести культуру DevOps в своей компании
  • Кто такой DevOps и как им стать: план обучения

Посмотрите видео на канале ADV-IT, где подробно расписано, что учить и в каком порядке:

Получите более уверенные знания из нескольких книг:

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

DevOps — это не просто набор техник, это философия

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

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

Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения.

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

Эберхард Вольф познакомит вас с популярными передовыми технологиями, облегчающими труд разработчиков: Docker, Chef, Vagrant, Jenkins, Graphite, ELK stack, JBehave и Gatling. Вы пройдёте через все этапы сборки, непрерывной интеграции, нагрузочного тестирования, развёртывания и контроля.

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

И помните, что от этого специалиста требуется тщательная проработка целого ряда вопросов.

Как стать 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.

Новостные каналы

Mops DevOps — Kubernetes, DevOps, Docker, CI/CD, SRE и многое другое

Записки админа — Linux и администрировании серверов

OrangeDevOps — Канал для сисадминов и devops. Ссылки на интересные материалы.

DevOps&SRE Library — Библиотека книг и статей по теме DevOps и SRE.

DevOps Deflope News — Новостной канал

ДевОпс Инженер — ДевОпс, какой он есть

Флант (анонсы) — Анонсы статей от наших инженеров, видео с докладами, обновлений по Open Source-проектам.

Приятно провести время

Мир IT c Антоном Павленко — IT новости, статьи и видео

Технологический Болт Генона — До Декарта никогда не существовало рационализма

ДЕВОПСИНА — Юморим и поднимаем неудобные айтишные темы

Terraform

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

Terraform — идеальный инструмент по управлению ресурсами в облаке. Через него можно полностью управлять: сетями, фаерволами, роутерами, ip-адресами, балансировщиками, жесткими дисками, виртуальными машинами и многим другим. Также есть возможность создания шаблонов, так называемых модулей. Через них можно упростить работу с ресурсами в облаке, достаточно просто указать название модуля и передать нужные переменные, все остальное Terraform сделает сам. Для совместной работы группы DevOps-инженеров есть возможность хранить стейтменты (состояние работы Terraform) в удаленном хранилище от hashicorp или любом S3 совместимом.

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

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

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-файла конфигурации.

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

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

Open Telekom Cloud

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

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

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

Практика создания единого шаблона проектов на базе Azure DevOps (TFS)

В одной из прошлых статей мы писали, как всей компанией перешли на единый трекер на базе Azure DevOps (TFS). Это позволило нам создать единый свод правил для ведения проектов. Рассказываем, как наш проектный офис разработал логику, по которой сейчас работают все наши команды.

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

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, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector