Devops — Направление DevOps и с чем его едят


Содержание

Что за зверь — DevOps или Среда обитания диковинных профессий

Кто такой девопс? Какие функции выполняет devops-инженер в компании? Кому и зачем стоит присмотреться к этой профессии?

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

DevOps – это акроним от английского development и operations. То есть методология, при которой объединяются два разных направления работы над конечным программным продуктом или сервисом — разработка и администрирование. Разработчик (программист) отвечает за развитие IT-продукта – создание нового, а системный администратор следит за бесперебойной работой уже созданной системы. Разрыв между этими ролями может быть настолько велик, что при наихудшем сценарии разработчик может создать такой продукт, который не будет качественно работать из-за постоянно возникающих критических ситуаций. Для формирования отказоустойчивой программной структуры и предугадывания всех возможных ошибок еще на этапе разработки идеи требуется DevOps-инженер.

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

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

Девопс смотрит на ошибки программного кода как на неотъемлемую часть проекта, его задача – минимизировать их количество и последствия для пользователя и ускорить их исправление для следующего релиза. Поэтому правило DevOps-методологии – частые релизы продукта, в которых быстро исправляются текущие ошибки.

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

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

✎ Аналитический склад ума
✎ Умение видеть и решать проблему
✎ Умение быстро осваивать сложные архитектуры и решения, в том числе сложные многослойные системы, состоящие из 3-4 ландшафтных архитектур
✎ Терпеливость
✎ Стрессоустойчивость
✎ Методичность
✎ Любознательность
✎ Постоянное саморазвитие
✎ Обучаемость
✎ Умение работать в команде
✎ Умение принимать решения
✎ Умение делегировать полномочия
✎ Внимательность к деталям

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

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

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

    ✔ При обучении в школе важно не ограничиваться только уроками информатики, но глубже интересовать сферой информационных технологий.
    ✔ Посещать кружки по программированию, робототехнике.
    ✔ Посетить iСмену и TechСмену в лагере «Профессионалы будущего», где занятия проводят настоящие айтишники, и в том числе специалисты DevOps.
    ✔ Проходить стажировки в IT-компаниях, как небольших стартапах, так и корпорациях (вроде, Microsoft или Яндекс). Только в реальных полевых условиях вы сможете понять, как строится цикл создания IT-продукта: от зарождения идеи до ее реализации. На стажировках вы сможете познакомиться и пообщаться с настоящими девопс-профессионалами.

Чтобы понять, подходит ли вам профессия девопса и работа в IT-сфере, пройдите наш бесплатный тест «Информационно-технологический профиль».

Автор: Ольга Биккулова, ЦТР «Гуманитарные технологии»

Если вы хотите получать свежие статьи о профессиях, подпишитесь на нашу рассылку.

Devops — Направление DevOps и с чем его едят

Сначала была обычная («каскадная», «водопадная») разработка. Заказчик приносил требования. Требования получали разработчики. Разработчики закрывались на пару месяцев. Заказчику показывали готовое.

Вполне нормальный, рабочий подход. Но почему возникла потребность придумывать что-то еще?

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

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

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

Заказчик приносит требования. Их разбивают на задачи и упорядочивают по важности для продукта. Разработчики набирают задач на одну-две недели. Закрываются и работают. Показывают первую версию продукта. Запускают на рынок! Далее по кругу, пока все задачи не будут сделаны, а продукт не обрастет всеми плановыми функциями.

  1. Проект становится более гибким, изменениями становится возможно управлять.
  2. Наконец-то появляется возможность апробации проекта на настоящих пользователях (а не моделирование ситуаций).

В чем, собственно, проблема, которую DevOps решает? Даже если команда работает по Scrum, функции разрабатываются «пачками». Потом «пачками» тестируются. И, наконец, внедряются в работающий продукт тоже «пачкой».

Соответственно, изменения на продукте происходят не ровно, а «скачками».

То есть по факту Agile-разработка с заявленным «ровным» темпом изменений становится тем же каскадом.

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

  • Разработчики мотивированы делать больше изменений, за них им платят. ИТ-отдел мотивирован выпускать в свет наиболее стабильный продукт (меньше изменений — меньше рисков, что что-то сломается).
  • Разработчики мыслят «главное — сделать строго по заданию». IT мыслят «главное — сделать оптимально для пользователей».
  • Разработчики делают работу в своей среде, QA зачастую настраивают свою среду для тестирования.
  • Знания разработчиков и ИТ-специалистов неотчуждаемы от них самих, у первых нет знаний вторых и наоборот.
  • Разработчики и отдел эксплуатации мало контактируют друг с другом, у них нет осознания чужих проблем.

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

Что предлагает DevOps? Методология провозглашает три развернутых ключевых тезиса (их еще называют «пути»):

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

Из того, что же можно сделать конкретно, информации не так много, как ее хотелось бы.

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

Отличная подборка нужного софта:

Тип инструмента Инструменты
Автоматизация инфраструктуры Bcfg2, CFEngine, Chef, CloudFormation, IBM Tivoli, Puppet
Автоматизации развертывания Capistrano, ControlTier, Func, Glu, RunDeck
Инфраструктура как услуги Amazon Web Services, CloudStack, IBM SmartCloud, OpenStack, Rackspace
Автоматизация сборки Ant, Maven, Rake, Gradle
Автоматизация тестирования JUnit, Selenium, Cucumber, easyb
Управление версиями Subversion, Git, IBM Rational ClearCase
Непрерывная интеграция Jenkins, CruiseControl, IBM Rational BuildForge

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


  • Самое простое: не разделять команды стенами — так они смогут общаться без помех.
  • Также рекомендуется проводить взаимные обучающие тренинги, чтобы разработчики провели ликбез среди QA и админов, а те посвятили первых в свои боли и печали (мы, например, делаем холивары по технологиям, примерно та же история.).
  • Создавать общую инфраструктуру. Причем всегда поддерживать ее актуальность. Если речь о каких-то программных инструментах — то они общие для всех, строго одинаковых версий. Если это площадка для тестирования продукта — то не нужно вручную настраивать одну среду для разработки, одну для теста и потом трястись над ней. Всё в облако, протестировали, исправили баги, удалили платформу (чтобы ни у кого не было соблазна в следующий раз «случайно» воспроизвести неведомый баг на неактуальной уже платформе).

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

Ответная мера — QA вместе с разработчиками пишут тест-кейсы, по которым потом будут оценивать работоспособность продукта (это делается на этапе планирования).

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

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

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

Допустим, даже если мы как подрядчик готовы допилить свои процессы до такого совершенства… В итоге нет.

Подход адекватен для по-настоящему крупных проектов: вроде Dropbox или Flickr. Когда есть реальная потребность в непрерывном потоке изменений, есть ресурсы для постоянного анализа и, естественно, бюджет для экспериментов.

Или для тех команд, которые пилят собственный продукт, предварительно спланировав все ресурсы.

В общем, если кто-то из IT-компаний вдруг пробовал внедрить DevOps — будем рады послушать ваш опыт.

Что и кто такое DevOps?

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

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

Зоопарк используемых технологий растёт после каждого совещания программистов, которые хотят поиграться с ElasticSearch, Elixir, Go, Lotus и бог знает с чем ещё.

Прогресс тоже не стоит на месте: редок месяц без важного обновления используемого софта и операционной системы. Ещё вчера ты жил спокойно с SysVinit, но теперь тебе говорят что нужно использовать systemd. И ведь правда нужно.

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

A system administrator, or sysadmin, is a person who is responsible for the upkeep, configuration, and reliable operation of computer systems; especially multi-user computers, such as servers.

Все эти проблемы далеко не новы – умелые сисадмины вовремя подтянули знания программирования и автоматизировали всё по-максимуму, походу дела подарив миру такие инструменты, как, например, Chef и Puppet. Но возникла проблема: далеко не все сисадмины оказались достаточно умелыми, чтобы переквалифицироваться в настоящих инженеров сложных инфраструктур.

Более того, программисты, по-прежнему слабо представляющие, что происходит с их приложениями после деплоя, упорно продолжают считать сисадминов виновными в том, что новая версия софта съела весь CPU и открыла двери нараспашку всем хакерам мира. “Мой код идеален, это вы хреново сервера крутите”, – говорили они.

В такой непростой ситуации инженерам и сочувствующим пришлось заниматься просветительской деятельностью. А какая может быть просветительская деятельность без модного словечка? Так и появился DevOps – маркетинговый термин, вызывающий у людей совершенно разные ассоциации, от “культура внутри организации” до “мастер на все руки”.

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

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

Так же в сферу DevOps включают такие темы как Continuous Integration, Continuous Delivery и т. п. Мы уже однажды немножко рассказывали о CI в статье Непрерывная интеграция, Jenkins и Middleman.

Естественным путём DevOps из разряда “культуры” и “идеологии” переместился в разряд “профессии”. Рост вакансий с этим словом внутри стремительно растёт. Но что же ждут от DevOps-инженера рекрутёры и компании? Зачастую от него ждут смеси таких навыков как системное администрирование, программирование, использование облачных технологий и автоматизация крупной инфраструктуры.

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

Здесь внимательный читатель-программист скажет:

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

Другой внимательный читатель-сисадмин скажет:

Я отлично умею пересобирать ядро Linux и настраивать сеть, зачем мне учиться программировать, зачем мне ваши Chef, git и прочий странный зоопарк?

На это мы скажем: настоящий инженер должен уметь не Ruby, Go, Bash или “настраивать сеть”, а уметь строить сложные, красивые, автоматизированные и безопасные системы, и понимать как они работают от самого низкого уровня вплоть до генерации и отдачи HTML-страничек в браузер.

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

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

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

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

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

Для работы тебе обязательно понадобится Linux. Мы очень сильно настаиваем на Red Hat дистрибутивах. Автор статьи сам в качестве основной системы использует Fedora 27 Workstation, а сервера mkdev крутятся на Centos 7.

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

Мы рассказываем, как стать более лучшим разработчиком, как поддерживать и эффективно применять свои навыки. Информация о вакансиях и акциях эксклюзивно для более чем 8000 подписчиков. Присоединяйся!

Devops — Направление DevOps и с чем его едят

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

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

Единый инструментарий

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

В наше время в сердцевине большей части документации вы можете найти файлы исходного кода, написанные на одном или более языке разметки из того множества, что есть у нас в распоряжении — например, DocBook XML, Markdown (и его 31 оттенок), AsciiDoc и reStructuredText.

Эти текстовые файлы с тэгами обычно хранятся в системе контроля версий Git (при помощи GutHub или GitLab или без таковой), той же самой платформе, которую большинство сообществ открытого ПО, а также Red Hat используют для своего кода. Многие проекты с открытым кодом хранят документацию рядом с кодом или вместе с ним, а некоторые используют интересные трюки, чтобы поток публикаций шел в ногу со сборкой проекта, а создание контента упростилось. К примеру, KDE использует хитрые скрипты, чтобы превратить Wiki-библиотеки в руководства на основе DocBook, — таким образом, вы можете писать при помощи простого Markdown и, по-прежнему, пользоваться надежными возможностями публикации DocBook.

NixOS использует менеджеров упаковки Nix, чтобы упаковать документацию Nix, а GitHub использует GitHub, чтобы документировать GitHub. Весьма описательно!

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

Вот так мы и пришли к непрерывной развертываемой интеграции в Jenkins (у нас есть непрерывная интеграция для документов!), где при каждом коммите не только проверяется вся библиотека документации по продукту на наличие битых ссылок и других ошибок, но также производится HTML и PDF, которые мы можем просмотреть через пользовательский интерфейс Jenkins. Добавьте к этому парсер на основе Publican, который превращает исходные файлы DocBook и AsciiDoc во всевозможные форматы с унифицированным стилем, автоматически публикует на пользовательском портале, объединяет запросы и проверки контента с GitLab, и вот у вас в руках довольно солидный набор инструментов.


В плане автоматизации, само собой разумеется, документация API должна за многое благодарить такие инструменты как JavaDoc, Sphinx и AsciiDoctor. Недавно последним писком моды стало модульное тестирование не только для кода, но и для документации. Подающие надежду инструменты вроде Hemingway и Emender не исправят за вас грамматику, но зато проанализируют ваш контент и сообщат о частых лингвистических промахах, таких, как слишком сложные предложения, неоднозначные глаголы и пассивный залог. Надеюсь, в будущем мы увидим больше пользы от инструментов, поскольку они могут автоматизировать самые трудоемкие задачи редактора и помочь нам сохранить целостность и лаконичность.

Постоянная поставка

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

Цукерберг рекомендует:  10 простых советов по email-маркетингу

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

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

Сотрудничество

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

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

Такие проекты, как Mozilla Developer Network, показывают, как принципы сотрудничества, присущие сообществу открытого ПО, внедряются и в сообществе контента, и на странице сообщества OpenStack можно прочитать: «С документацией надо обращаться, как с кодом, созданным сообществом». Дорога, которую предстоит пройти сотрудничеству в проектах открытого ПО, еще длинна (и все еще строится), но об этом будет подробнее в следующей статье! Стратеги контента в Red Hat теперь имеют официальное место и голосуют на всех встречах по планированию и запуску продукта, наряду с представителями всех ролей в релизе продукта.

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

Что дальше?

Теперь у нас есть практически все кусочки паззла; мы убедили менеджеров или высшее руководство, что ценный контент лучше полного, и создали все технические условия, чтобы беспрепятственно его поставлять. И все, что осталось, — заставить кого-то всё это написать, да? Ну, это зависит от многого. Когда в названии твоей должности значится слово «писатель», то так или иначе чего-то такого от тебя и ждут. Но как совладать с непостоянной армией тех, кто вносит свой вклад в открытое ПО, в основном добровольно жертвуя временем, чтобы написать код в твоем проекте, и не имеет ни времени, ни мотивации, ни уверенности в языковых навыках, чтобы написать все те документы, о которых вы все время говорите?

Об авторе: в настоящее время Майки работает старшим техническим писателем для платформы OpenStack в Red Hat, в Брно, Чехия. В свободное время, которого вечно не хватает, она возглавляет коммьюнити Write the Docs Europe, организует воркшопы для Django Girls, выступает в роли коуча в проектах с открытым кодом, страстно выступает на конференциях открытого ПО обо всем, что касается документации и Agile, много пишет в Твиттер и мало спит.

Blogerator.org

Эксклюзивные ИТ-новости, обзоры и интервью

Просто о сложном: что за зверь такой, DevOps?

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

Посему сегодня решил остановиться отдельно на непонятном многим феномене DevOps и чудесах высокоуровневой кооперации (в данном случае сфере ПО). В итоге получилась своего рода landing page для всех тех, кто не врубается в чрезвычайно полезную сущность DevOps. Единственное замечание перед тем, как подкат безжалостно засосет вас — я сделал акцент на медийном формате подачи, то есть собрал воедино пару видео-лекций об этой профессии, а также выложил парочку симпатичных презенташек по теме. Впрочем, перед этим дам и свое, предельно простое объяснение этой новомодной сущности буквально на пальцах.

Свой среди чужих, чужой среди своих

Сначала совсем краткое и отчасти формальное определение.

DevOps (акроним от англ. development и operations) — это методология разработки ПО, сфокусированная на предельно активном взаимодействии и интеграции в одной упряжке программистов, тестировщиков и админов, синхронизировано обслуживающих общий для них сервис/продукт. Главная цель этого — создание единого цикла взаимозависимости разработки, эксплуатации и деплоя программного обеспечения, дабы в конечном счете помогать организациям (сервисам, стартапам) быстрее и безболезненней создавать и обновлять их программные продукты и сервисы, эксплуатируемые в режиме реального времени или «в продакшене».

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

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

Но с точки зрения системы эта же ситуация «разумного эгоизма» маленького-человека-на-местах выглядит примерно так:

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

Графически в наиболее общем виде этот подход будет выглядеть примерно так:

В предельно идеальном случае (к которому есть смысл стремиться даже в нашем убогом не идеальном мире) это будет выглядеть примерно так (см. ниже):

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

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

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

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

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

Медиа-приложения к метологии DevOps

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

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

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

Что мы там увидим:

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

У меня плеер от Microsoft работает паршиво, поэтому кому-то будет удобней скачать это видео себе на винт по этой прямой ссылке (200Mb, 53 минут) для спокойного просмотра в режиме оффлайн.

В заключение: если всё-таки не ясно кто это и что это, читаем этот текст + внешняя ссылка на дельную статью для тех разработчиков, кто любит думать о своем будущем: How ’DevOps’ is Killing the Developer.

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

«Все ищут DevOps-инженера — но мало кто знает, зачем он нужен»

В преддверии минской конференции DevOpsBy 2020 dev.by расспросил DevOps-инженера ISsoft Алексея Денисевича о преимуществах и недостатках одной из самых «модных» и востребованных позиций последних лет.

Мода на DevOps: «Звучит круто — значит надо брать»

— В сравнении с остальным миром, где методология DevOps заработала в 2009 году, может показаться, что мы опаздываем на 7 лет: по сути, у нас «девопс» ещё только зарождается.

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

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

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


6 главных принципов «девопса»

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

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

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

3. Вводить единообразное окружение. Бывает, программисты разворачивают тестовое окружение, создают виртуальные машины и базы, а потом у тех же операторов, тестировщиков, техподдержки это не работает. Начинаются «тёрки». «У меня все отлично работает», — говорит программист. Следовательно, нужно ввести единообразие: позволить и тем и другим оперировать на идентичных окружениях.

4. Автоматизация! Поскольку человек — существо, которому свойственно ошибаться, желательно автоматизировать всё, что нужно делать вручную (в 90% случаев это осуществимая задача), особенно сложные многосоставные ручные действия. Есть конторы, у которых релизы новых версий программ занимают до шести недель (и ещё неизвестно, что сломается по дороге). Если же всё это автоматизировать, можно получить результат и за пару часов.

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

Автоматизация — самая заметная часть в обязанностях «девопса», её сразу видно.

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

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

6. Процесс улучшения — а улучшить всегда есть чего. Реализация первых 5 пунктов почти всегда несовершенна, поскольку этим опять-таки занимается человек.

Это книжные вещи, но в реальности всё примерно так и происходит. Как правило, к вашим услугам прибегают ИТ-проекты, у которых есть проблемы по всем 6-ти пунктами. Процесс настройки может быть как быстрым, так и долгим. Важно общаться со всеми: DevOps-инженер включён в очень плотное общение, с ежедневными митапами и стендапами. Иногда, в течение дня, может пройти от 6 до 8 «митингов». Если вы любите поговорить, это позиция, где нужно говорить каждый день.

Работа нон-стоп — не помню за год ни одного дня, чтобы я прохлаждался. Даже когда всё сделано, наступает пункт №6: всегда есть, что улучшить.

Сопротивление команд: «Неизвестно кто пришёл и начал диктовать»

К сожалению, мы часто сталкиваемся с инертностью, медлительностью и сопротивлением команд.

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

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

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

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

Почему лично я ушёл из админов в «девопсы»?

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

Как стать качественным «девопсом»? Тут трудно избежать клише, но важно не лениться. Это бесконечный процесс обучения.

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

Конечно, не получится знать всё: может, «девопсы», которые начинали 7 лет назад, знают и понимают фантастическое количество вещей: как-никак, они стояли у истоков. Но такого рода требования к «молодым» «девопсам» сродни требованию иметь все виды прав на все виды транспорта перед тем, как разрешить вам сесть за руль машины.

Минусы позиции: DevOps «ходит и ничего не делает»?

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

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

Некоторым может показаться, что «девопс» «ходит и ничего не делает»: во-первых, такого не бывает, а во-вторых, если и бывает, значит, у него всё настроено, и он обдумывает пункт №6.

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

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

Если промахнуться, можно трудоустроиться неудачно и потерять время.

А как у них: «девопсы» на Западе почти вышли из моды?

Мы продаём услугу «девопса» американцам, которые вроде как должны быть на 7 лет впереди.

Бытует странное мнение, что DevOps-инженеры на Западе уже почти «вышли из моды». Однако, если это так, то как объяснить интерес американских компаний к нашим «девопсам» и регулярные предложения европейских коллег?

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

Если вы решили переезжать в Европу, а у вас нет за плечами 2-5 лет продуктивного DevOps-стажа, не стоит забывать, что придётся подниматься с низов. Выхлоп может быть по итогу меньше, если с калькулятором посчитать налоги, которые нужно уплатить, стоимость аренды жилья не «на отшибе», да и просто стоимость жизни. Если вы готовы терпеть 2-3 года «айтишной» нищеты и упорно работать, то наверняка пойдёте вверх.

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

Резюме: DevOps — ответственность всей команды

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

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

DevOps

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

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

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

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

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

Цукерберг рекомендует:  Новичкам - Новички! А давайте делиться тем, что мы уже написали)

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

Процессы и объекты девопс


DevOps, как и другие Agile-практики, ориентирован на командную работу, где рассматриваются все аспекты жизненного цикла ПО, от программного кода до эксплуатации продукта конечным пользователем [2]:

  1. Code (Код) – разработка и анализ, контроль версий и слияния кода;
  2. Build (Сборка) – непрерывная интеграция различных сборок;
  3. Test (Тест) – непрерывное тестирование, обеспечивающее обратную связь по бизнес-рискам;
  4. Operate (Работа с пакетами) – репозиторий артефактов, предварительная установка приложения;
  5. Release (Выпуск) – управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
  6. Deploy (Развертывание конфигурации) – управление инфраструктурой как кодом;
  7. Monitor (Мониторинг) – мониторинг производительности приложений, опыт работы с конечным пользователем.

Процессы DevOps: Development Operations

Цели и задачи DevOps

Поскольку процессы девопс охватывают весь цикл поставки ПО, выделяют несколько основных целей этого подхода [2]:

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

Эти цели достигаются через решение следующих задач:

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

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

Главные принципы DevOps

Рассматривая DevOps как масштабирование Agile-подхода на весь процесс разработки, внедрения и сопровождение ПО, можно выделить 5 основных принципов (CALMS) его реализации с целью увеличения частоты релизов и повышения ответственности команды за продукт [1]:

  • Культура(Culture) – кросс-функциональное сотрудничество разнопрофильных специалистов и команд за счет единого информационного пространства проектного контента, открытых каналов коммуникаций и постоянного общения всех участников;
  • Автоматизация(Automatization) – использование инструментов непрерывной поставки с прогоном каждой правки кода через серию автоматизированных тестов, часто использующих облачную инфраструктуру, и последующую упаковку успешных сборок с дальнейшим перемещением на рабочий сервер с помощью автоматизированных развертываний и управления инфраструктурой как кодом через конфигурации саморазвертываемых сред;
  • Бережливость (Lean) – устранение действий с низкой полезностью и ускорение процессов, непрерывное совершенствование через регулярный ретроспективный анализ, раздельное тестирование различных инструментов, принятие поражений, возможности быстрого обнаружения проблем и их незамедлительного решения;
  • Измерения (Measurement) производительности, например, продолжительность работы пользователей с продуктом, частота появления в логах сообщений о критических ошибках – необходимы ясные и четкие критерии оценки работы, показатели эффективности процессов;
  • Обмен (Sharing) – совместная ответственность и разделение успехов, выпуск и обеспечение работы приложения осуществляются теми же людьми, что выполняли его сборку, т.е. разработчики (Developers) и операторы (Operators) взаимодействуют на каждом этапе жизненного цикла приложения.

CALMS: главные принципы DevOps

Достоинства девопс

Благодаря стандартизации и автоматизации процессов разработки и внедрения, DevOps дает следующие преимущества в управлении выпуском ПО [2]:

  • события, документированные процессы управления и подробные отчеты легко отслеживать;
  • разработчики имеют больше контроля над средой, предоставляя инфраструктуре более прикладное понимание продукта и процессов его эксплуатации;
  • значительное сокращение времени выхода на рынок за счет «бесшовного» цикла разработки и внедрения;
  • улучшение удовлетворенности клиентов;
  • повышение качества и надежности продукции;
  • увеличение производительности и эффективности;
  • быстрота реагирования и высокая скорость экспериментов;
  • расширение компетенций и ответственности разработчиков – программисты участвуют в настройке серверов и поиске ошибок, пишут автоматизированные тесты, сглаживая возможные инфраструктурные уязвимости в коде. Это сокращает количество ошибок при развертке приложения примерно в 5 раз [3].

Расширение концепции DevOps на все бизнес-процессы

Критика и недостатки DevOps

При всех достоинствах этого подхода, можно выделить следующие недостатки:

  • Неполнота цикла – за бортом процессов девопс остаются важные этапы жизни ПО, как разработка и анализ требований, а также проектирование архитектуры. Также возможно упущение ручного тестирование, что может быть критично в некоторых случаях [3]. Например, если разработчики недостаточно качественно проанализировали требования и протестировали продукт, рассматривая его с точки зрения «идеального» кода, а не с позиции пользователей, результат может быть неудобным в эксплуатации [4].
  • Недостаточный профессионализм участников, которые разбираются во всем (разработка, тестирование, развертывание, поддержка), но поверхностно.
  • Высокая нагрузка на менеджмент – если у разработчиков и операторов нет общих целей, в этом виноваты менеджеры, не организовавшие эффективное взаимодействие между командами разнопрофильных специалистов. Для решения этой проблемы нужна новая система оценки менеджеров на основе отзывов от подчиненных [3].

В каких случаях эти недостатки становятся особенно критичными и почему 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-инженер совмещает множество профессий (администратора, разработчика, тестировщика и менеджера), то он должен иметь опыт администрирования различных операционных систем и облачных платформ. Также необходимы знания сетевых технологий и умения писать скрипты и код на нескольких языках программирования [5]. Как эти компетенции разделяются с другими участниками Agile-команды, мы рассмотрели здесь.

Кто и где используется DevOps и сколько за это стоит

DevOps может быть полезен практически любой организации, связанной с разработкой приложений или управлением большим количеством серверов. Крупные ИТ-гиганты вовсю нанимают (Amazon, Adobe, Google, Facebook и т.д.) и технологичные предприятия других сфер (Netflix, Walmart, Etsy и пр.) вовсю нанимают DevOps-инженеров. В России девопс также активно используется в банковской (Сбербанк, Альфабанк, Тинькофф-Банк), телекоммуникационной и ИТ-отраслях (Билайн, МТС, Mail.ru, Яндекс).

Мелкий бизнес и стартапы, цель которых – быстрее выпустить на рынок минимально жизнеспособный продукт, чтобы проверить новую идею, пока обходятся без девопс-инженеров. Что обусловлено, помимо организационных и методологических факторов, также и финансовой стороной вопросы: DevOps-инженеры зарабатывают больше всех в отрасли. На июль 2020 года зарплата таких специалистов колеблется в районе $71 тысяча долларов в год за рубежом [6], что составляет около 350 тысяч рублей в месяц, и 130-400 тысяч рублей в месяц в РФ [7].

DevOps — continuous innovation — непрерывное улучшение всех процессов

Как стать DevOps-инженером за полгода или раньше? Часть 1

Примечание: это первая часть из цикла статей, посвященных DevOps.

Целевая аудитория

Вы разработчик и хотите направить свою карьеру в DevOps русло?

Или вы IT-специалист и хотите получить представление о том, что же такое DevOps?

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

Если ответ на все вышеперечисленные вопросы — да, то наш цикл статей призван помочь вам во всем этом разобраться!

Кстати, даже если вы много лет занимаетесь DevOps, то данная статья все равно может стать полезной для вас.

Что же такое DevOps?

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

Что же, для вас я очистил определение от лишнего мусора и вот что получилось:

DevOps- это способ доставки программного обеспечения до конечного потребителя через коллективные боль и ответственность.


Хорошо, но что же это значит на самом деле?

Это значит, что, испокон веков, разработчики (люди, создающие программное обеспечение) имеют совершенно другие мотивы, нежели IT-специалисты (люди, которые запускают программное обеспечение).

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

Однако, как IT-специалист, мне нужно внедрить в продукт как можно меньше функций, так как каждая новая функция — это перемены, а перемены рискованны.

В результате этого разительного контраста и зародился DevOps.

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

Пуристы скажут вам, что не существует такого понятия как «DevOps-инженер». «DevOps — это культура, а не должность» — будут они вам говорить.

Да, да мы поняли. Технически они правы, но, как часто бывает, термин в конце концов вышел за рамки своего первоначального смысла.

Теперь, DevOps-инженер — это что-то вроде «Программного инженера версии 2.0»

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

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

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

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

ПРИМЕЧАНИЕ: Будьте осторожны с объявлениями, наподобие: «Требуется DevOps-команда» или «DevOps-отдел». Грубо говоря, такие объявления не должны существовать, так как DevOps — это культура и «способ доставки» программного обеспечения, а не специальный отдел или команда.

Дисклеймер

Теперь, отставим стакан газировки в сторону и рассмотрим следующее.

Слышали ли вы когда-нибудь изречение о том, что «в DevOps нет junior-инженеров»?

Если не слышали, то знайте, что это очень популярный троп на таких платформах как Reddit и Stack Overflow. Но что он означает?

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

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

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

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

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

Достаточно болтовни, с чего мне начать?

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

Если вы пройдете его от начала до конца, то сможете смело называть себя DevOps-инженером! Или Cloud-инженером, если вам не нравится предыдущее название.

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

ПРИМЕЧАНИЕ: Вы должны преодолеть этот путь шаг за шагом. Начните с фундамента, не пропускайте его! Сначала изучите технологии, помеченные синим цветом (Linux|Python|AWS), затем, если позволяет время или этого требует нынешний рынок труда, изучите технологии, помеченные фиолетовым (Golang|Google Cloud).

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

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

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

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

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

Хорошо, копнем немного глубже!

Фундаментальные знания

Вверху статьи есть план под названием «Фундамент» с навыками, которыми должен овладеть любой DevOps-инженер.

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

Давайте разберем эти три столпа шаг за шагом.

Linux

Linux: там, где происходит вся магия. Можно ли быть DevOps-инженером, оставаясь при этом в экосистеме Microsoft? Конечно вы можете! Не существует закона, который бы предписывал работать исключительно в системе Linux.

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

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

Для справки, в Северной Америке очень распространен дистрибутив Linux от компании Red Hat. Поэтому имеет смысл начать с Fedora или CentOS. Кстати, если не можете выбрать графическое окружение — KDE или Gnome, ставьте KDE. Его использует Линус Торвальдс.

Python

Python: самый распространенный язык для back-end’а в наши дни. С него легко начать, и он повсеместно используется во многих сферах. Бонус: Python широко распространен в сфере искусственного интеллекта и машинного обучения, поэтому, если решите этим заняться в будущем — вам практически ничего не придется учить.

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

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


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

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

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

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

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

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

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

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

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

DevOps Инженер: Вопросы Собеседования, Которые Вы Должны Знать

В глазах многих людей, “DevOps инженер” кажется профессией будущего с невероятными возможностями (хотя это вовсе не профессия). Международные компании самого высокого уровня (вроде Netflix, Facebook и Amazon) в последнее время начали оперативно внедрять систему ДевОпс в их рабочий процесс. Конечно же, благодаря такой востребованности, необходимость в профессионалах сферы DevOps стала соразмерно расти. Именно поэтому, в данном руководстве мы поговорим о том, что должен знать DevOps инженер для успешного прохождения собеседования на одну из таких должностей.

Мы расскажем как о самых общих (что такое DevOps), так и более с

ложных темах Dev Ops, которые вы можете ожидать. Кроме того, мы дадим вам несколько полезных советов, способных помочь вам более эффективно провести время перед собеседованием.

Введение

Мы начнём с базовых вопросов – коротких, но информативных. Такого рода вопросы встречаются во вступительной части собеседования. Хотя они и называются базовыми, это вовсе не означает их простоту – просто для ответа на них не нужно выполнять какую-либо работу с кодом или вдаваться в подробности слишком глубоко.

Вопрос 1: Что Такое DevOps?

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

Проще говоря, Dev Ops является философским методом сокращения цикла разработки систем. Сам термин состоит из комбинации слов “development” и “operations”.

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

Вопрос 2: Какие Самые Популярные Инструменты DevOps?

Git, Jenkins, Docker и Selenium являются самыми популярными инструментами DevOps.

Вопрос 3: Какие Основные Отличия DevOps От Agility?

DevOps и Agility часто сравнивают друг с другом. DevOps инженер должен уметь сравнить и отличить один набор практик от других.

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

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

Вопрос 4: Что Такое Контроль Версий?

Люди считают, что DevOps инженер просто обязан это знать – это способ отслеживать предыдущие версии определённого файла.

Вопрос 5: Каковы 4 Ключевых Компонента?

Интеграция, тестирование, поставка и мониторинг. Все упомянутые методы имеют прикреплённый к ним тег непрерывного действия – они не происходят лишь раз или два, а скорее являются непрерывными процессами.

Вопрос 6: Какие Языки Программирования Использует DevOps Инженер?

В основном – Ruby, но также может использоваться Python.

Вопрос 7: Как AWS Работает с DevOps?

Это одна из тех тем, которые обязательно должен знать ДевОпс инженер – в процессе собеседования вопросы по AWS занимают не последнее место.

AWS означает Amazon Web Services. Этот сервис обеспечивает масштабируемость бизнеса, используя огромные (почти бесконечные) ресурсы и мощность.

AWS используется во многих компаниях для поддержания и доставки своих продуктов – Dev Ops просто метод, с помощью которого он используется.

Вопрос 8: Что Такое Экстремальное Программирование?

Экстремальное программирование (более известное как XP) — это метод разработки программного обеспечения. Главной целью XP является удовлетворение потребностей клиентов – все задачи, решения и методы работы нацелены лишь на эту цель.

Многие компании, которые используют ДевОпс, также практикуют XP.

Вопрос 9: Что Такое Шаблон Проектирования?

Это один из множества терминов, которые должен знать DevOps инженер. Именно поэтому вам стоит обратить на этот вопрос собеседования особое внимание.

В общих чертах, шаблон проектирования представляет собой решение какой-то проблемы, с которой сталкиваются разработчики.

Эти шаблоны помогают новым разработчикам избежать возможных проблем… что же, показывая возможные шаблоны и решения.

Всего существует три главных типа шаблонов проектирования для разработчиков – поведенческие, творческие и структурные.

Вопрос 10: Что Такое CBD?

CBD или компонентно-ориентированное программирование — это в каком-то роде уникальный способ подхода к разработке продукта.

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

Продвинутые Вопросы Собеседования DevOps

Теперь, вы уже более менее знакомы с темами, которые должен знать DevOps инженер в первую очередь. Давайте перейдём к более продвинутым вопросам. Часть “продвинутые” означает то, что данные вопросы требуют более углубленного ответа или затрагивают сразу несколько тем.


Вопрос 1: Объясните Понятие Ветвление (Контроль Версий).

Одна из самых распространённых тем, которые должен знать DevOps инженер – ваше объяснение покажет ваши знания и опыт вашей прошлой работы с этой сферой.

Существуют три различных типах ветвления (branching) – ветвление задачи, функции и релиза.

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

Вопрос 2: Как Скопировать Jenkins На Другой Сервер?

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

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

Вопрос 3: Назовите Три Способа, Которые Вы Бы Использовали Для Защиты Jenkins.

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

  • Запускать периодические аудиты безопасности.
  • Настроить лимит доступа к данным, хранящимся на Jenkins.
  • Убедиться в том, что опция “global security” включена.

Вопрос 4: Опишите Автоматическое Тестирование.

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

Вопрос 5: Каковы Основные Преимущества Использования Автоматического Тестирования?

У использования автоматического тестирования в рабочем процессе существует довольно много преимуществ. Давайте назовём только лишь самые основные.

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

Вопрос 6: Что Такое Memcached?

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

Вопрос 7: Если Какие-то Данные Изменяются, Как Вы Обновите Memcached?

Это один из сотни похожих вопросов, ответ на которые должен знать DevOps инженер. У конкретных тем, таких как Memcached, обычно есть дополнительные вопросы, поэтому рекомендуется подготовиться к этой теме как можно тщательнее.

Цукерберг рекомендует:  Глянцевое горизонтальное меню

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

Вопрос 8: Почему Компонент Непрерывного Тестирования Так Важен Для DevOps?

Мы упомянули 4 ключевых компонента DevOps в первой части нашего руководства, но очень важно узнать о каждом из них более подробно – они являются четырьмя столпами, на которых основан ДевОпс. Ведь вы понимаете, что подобные вопросы у вас точно будут?

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

Вопрос 9: Является Ли Selenium Хорошим Инструментом Для Тестирования?

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

Вопрос 10: Как Вы Можете Максимизировать Эффективность Непрерывной Интеграции?

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

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

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

Общие Советы Собеседования

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

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

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

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

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

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

Да, многие эксперты рекомендуют именно такой подход.

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

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

Заключение

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

Вы можете увидеть термины вроде DevOps или ДевОпс повсюду! Хотя честно говоря, они не совсем правильные – нет такой вещи как DevOps инженер или программист – DevOps не является профессией. Однако некоторые люди всё равно используют эту терминологию, поэтому лучше всего под неё подстроиться, чем вдаваться в сложные подробности.

В этом руководстве, мы рассказали про вопросы и темы собеседования DevOps направления. Мы затронули Memcache, Jenkins, Selenium и даже AWS DevOps. Кроме того, вы узнали некоторые общие советы, которые помогут вам как перед, так и во время самого собеседования. Желаем вам удачи и достижения ваших целей!

100 терминов DevOps или Что говорят ваши DevOps?

Что говорит твой инженер DevOps? Что такое кластер Kubernetes и почему серверы должны быть настроены с использованием манифестов Terraform? Почему вы должны заботиться об агентах Zabbix? Вы просто хотите, чтобы работа была выполнена, и проект был запущен вовремя!


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

DevOps Глоссарий

Это большой список, но далеко не исчерпывающий список терминов DevOps, объясненных простыми словами.

Агент — часть программы «сервер-агент», выполняемая в каком-либо экземпляре или контейнере для предоставления входных данных для приложения централизованного сервера (например, агента мониторинга Zabbix)

Agile (Гибкая разработка программного обеспечения)- методология доставки программного обеспечения, основанная на коротких итерационных этапах разработки, где каждый спринт должен приводить к эксплуатационному продукту. Это позволяет легко корректировать требования проекта в случае необходимости и дает возможность творчества и гибкости в командах разработчиков.

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

Amazon AWS — Amazon Web Services — самый популярный поставщик облачных услуг (CSP) согласно отчету о состоянии DevOps за 2020 год, предлагающий широкий спектр услуг облачных вычислений для предприятий любого масштаба.

Ansible — механизм автоматизации для различных ИТ-задач, таких как подготовка и настройка облачной инфраструктуры. Ansible — это инструмент с открытым исходным кодом, который взаимодействует с несколькими программными модулями через соединение SSH, скрипты PowerShell или различные API.

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

Apache — один из самых популярных веб-серверов с открытым исходным кодом (уступает только NGINX), кроссплатформенный инструмент для запуска веб-сайтов и приложений.

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

ASG — Auto Scaling Group — сервис AWS, используемый для объединения нескольких экземпляров EC2 в логические группы в целях проектирования инфраструктуры и простоты управления; группа состоит из идентичных экземпляров, которые добавляются или удаляются в соответствии с требованиями рабочей нагрузки.

AWS CLI — интерфейс командной строки AWS — инструмент AWS для управления различными сервисами и продуктами AWS из терминала командной строки.

Автоматизация выпуска приложений или ARA — общий подход к развертыванию нового кода в производстве с минимальными человеческими действиями с помощью автоматизированных конвейеров CI / CD

Amazon Aurora — сервис AWS, предоставляющий облачную реляционную базу данных, ставший самым быстрорастущим сервисом в истории AWS . Эта база данных в 5 раз быстрее, чем MySQL, и в 3 раза быстрее, чем PostgreSQL, не говоря уже о том, что она является базой данных по умолчанию для многих продуктов и сервисов AWS.

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

Bastion host — специальный сервер, используемый для доступа к частным сетям и противостояния хакерским атакам. Обычно размещает одно приложение (например, прокси-сервер) и ключи SSH для доступа и управления базовой облачной инфраструктурой.

Ветвление — ветви представляют собой отдельные копии кода проекта на GitHub или другой системе контроля версий кода, что позволяет многим разработчикам работать над проектом одновременно.

Bucket — логическая единица в Amazon S3 (Simple Storage Service), используемая для хранения нескольких типов объектов (в основном, различных данных и метаданных, которые их описывают).

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

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

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

Bare-metal — случай, когда программное обеспечение установлено на физических устройствах (жестких дисках), пропуская уровень виртуализации.

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

CD (Непрерывная доставка) — набор методов разработки и эксплуатации программного обеспечения, рабочих процессов и инструментов, направленных на обеспечение автоматизации всех рутинных операций жизненного цикла доставки программного обеспечения (сборки, тестирование, постановка, мониторинг, оповещение, ведение журнала, резервное копирование, восстановление, балансировка нагрузки и т. Д.). Единственное исключение — запуск вручную готового кода в производственной среде. Это основная практика DevOps, наряду с непрерывной интеграцией и инфраструктурой в виде кода.

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

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

CI / CD — Непрерывная интеграция / Непрерывная доставка — основа современной культуры DevOps. CI гарантирует, что новый код передается в централизованное хранилище кода несколько раз в день, чтобы пройти автоматические модульные тесты и ускорить сборку нового программного обеспечения. Если тесты пройдены успешно, CD гарантирует, что новая версия приложения будет автоматически отправлена ​​в промежуточную и производственную среды без простоев службы. Рабочий процесс CI / CD гарантирует, что все ошибки будут найдены и исправлены на ранней стадии, а продукт будет доступен в любое время.

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

Commit (Комит) — процесс отправки кода в репозиторий Git и полученный фрагмент кода.

Задание Cron — запланированный процесс, который будет запускать определенный сценарий на сервере в определенное время.

Контейнер — программная оболочка, разделяющая приложение и все ресурсы, необходимые для его запуска, и инфраструктуры, в которой оно работает. Благодаря использованию контейнеров Docker любые приложения могут работать в любой ОС с Docker, и любые проблемы с одним контейнером не влияют на остальную часть системы.

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

Configuration drift (Смещение конфигурации) — нежелательный результат независимого обновления различных серверов, что приводит к различным программным конфигурациям и состояниям. Лучше всего удалить за счет практики развертывания неизменной инфраструктуры в виде кода.

Управление конфигурацией — процесс установки и поддержания требуемых параметров программной экосистемы с помощью инструментов автоматического управления конфигурацией, таких как Kubernetes, Ansible, Puppet, Chef, Saltstack и т. Д.

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

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

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

Dockerfile — текстовое описание процесса сборки контейнера Docker, содержащее все необходимые команды. Dockerfiles позволяют легко и эффективно конфигурировать и управлять созданием и запуском контейнеров.

Docker Swarm — движок контейнерной оркестровки, разработанный Docker. Это встроенный в Docker инструмент для кластеризации и планирования контейнеров, способный запускать тысячи контейнеров одновременно. К сожалению, он не может похвастаться той же функциональностью, что и Kubernetes, и практически не используется с середины 2020 года.

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

Фреймворк Django — это высокоуровневый фреймворк Python, ориентированный на чистый дизайн, быструю разработку и высокую производительность приложений. Нашел широкое применение в веб-разработке и обработке больших данных.

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

Среда (Environment) — все ресурсы сервера (ОС, библиотеки, API, инструменты и платформы и т. Д.), Необходимые для запуска программного обеспечения на различных этапах его жизненного цикла (разработка, тестирование, подготовка, производство).

ElasticSearch — RESTful, распределенный движок для поиска и анализа данных, построенный на Apache Lucene. Как ядро ​​стека Elastic, Elasticsearch позволяет хранить и обрабатывать данные из нескольких облачных инструментов мониторинга и ведения журналов.

Envoy — мощный прокси C ++ для обработки трафика между микросервисами.

EC2 — Amazon Elastic Compute Cloud — центральное предложение Amazon Web Services, предоставляющее несколько типов виртуальных серверов для запуска приложений в облаке.

EKS — Amazon Elastic Computer Service для Kubernetes — управляемая служба Amazon, которая позволяет любому человеку развертывать и запускать Kubernetes в инфраструктуре AWS без необходимости разбираться и настраивать кластеры самостоятельно.


FluentD — инструмент для сбора и обработки данных с открытым исходным кодом, написанный на Ruby. Он позволяет вводить данные из огромного количества инструментов, таких как ElasticSearch, и выводить данные на широкий выбор панелей мониторинга, настроенных с использованием нескольких плагинов.

Fargate — Amazon Fargate — это сервис Amazon для запуска контейнеров Docker в управляемой инфраструктуре, такой как EKS, без необходимости что-либо настраивать. Он работает по схеме выставления счетов без сервера — вы указываете, что необходимо сделать, и оплачиваете потребляемые ресурсы без какой-либо ручной настройки кластера.

Fail-fast — стратегия разработки программного обеспечения, в которой идеи быстро проверяются для обеспечения быстрой обратной связи. После применения обратной связи эксперимент повторяется до тех пор, пока не будет достигнут удовлетворительный результат.

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

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

GitLab — веб-портал Git с открытым исходным кодом, настроенный на производительность DevOps, благодаря встроенной поддержке инструментов CI / CD, таких как Gitlab CI.

Gitlab CI — это бегунок CI / CD для Gitlab, который позволяет разработчикам автоматически создавать свой код после каждого коммита.

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

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

IaC — Инфраструктура как код — один из базовых принципов DevOps. Это означает, что конфигурация инфраструктуры выполняется с помощью машиночитаемых декларативных файлов, а не вручную или с использованием интерактивных инструментов. Эти файлы (например, манифесты Kubernetes или Terraform ) могут храниться в репозиториях GitHub, настраиваться и корректироваться так же, как и код, что обеспечивает эффективную автоматизацию обеспечения инфраструктуры.

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

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

InfluxDB — база данных с открытым исходным кодом для обработки событий временных рядов. Она написана на Go и используется для мониторинга инфраструктуры, хранения данных высокой доступности и аналитики в реальном времени. Лучше всего он работает с такими инструментами DevOps, как Prometheus и Grafana.

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

Пропускная способность ввода / вывода — количество операций ввода / вывода в секунду, характеристика пропускной способности сети или накопителя.

Ingress controller — программный модуль, используемый для обеспечения балансировки нагрузки в модулях Kubernetes.

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

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

Kubernetes — платформа управления контейнерами с открытым исходным кодом от Google. Kubernetes и Docker — это основы выполнения современных рабочих нагрузок в облаке.

Kibana — часть стека Elastic, отвечающая за визуализацию данных и навигацию по кластеру ELK.

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

Lead time (Время выполнения) — время, необходимое для перемещения нового пакета кода из коммита в релиз.

Микросервисы — пример сервис-ориентированного подхода в архитектуре программного обеспечения (SOA), практика разделения монолитного приложения на набор слабо связанных сервисов, отвечающих за определенный аспект операций. Эти детализированные сервисы взаимодействуют через легкие протоколы и API для обеспечения гибкости и масштабируемости продукта.

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

MTTR — среднее время до восстановления — среднее ожидаемое время, когда отказавший системный компонент снова заработает; основной параметр сценариев восстановления после сбоев, системного стресс-тестирования и проверки производительности.

Node (узел, нода)- физическая или виртуальная машина в кластере Kubernetes, используемая для размещения модулей, которые запускают контейнеры Docker.

Node pool (Пул узлов) — пул узлов Kubernetes — это группа из нескольких точек кластера, объединяющих машины с одинаковой конфигурацией, которые по сути можно рассматривать и управлять ими как одним объектом.

Nexus3 — платформа управления выпуском от Sonatype, созданная для объединения входных сигналов от нескольких модулей с открытым исходным кодом, чтобы обеспечить быстрый, безопасный и эффективный жизненный цикл доставки программного обеспечения.

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

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

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

OpenStack — платформа с открытым исходным кодом для создания локальных облачных инфраструктур.

OpenShift — платформа управления контейнерами корпоративного уровня для Kubernetes, работающая в локальных облачных инфраструктурах, разработанная Red Hat.

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

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

Provisioning (Обеспечение)- процесс предоставления новых сред для пользователей, в основном сред разработки и тестирования для разработчиков. Поскольку ресурсы виртуализированы, необходимые операционные системы и промежуточное программное обеспечение конфигурируются и поддерживаются с помощью инструментов согласования конфигурации, таких как Terraform и Kubernetes .

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

Pod — базовое структурное подразделение Kubernetes, группа контейнеров Docker, развернутых на одном хосте.

Playbook — Ansible playbook — это инструкции по развертыванию инфраструктуры с подробными руководствами по выполнению серии команд для выполнения конкретных задач.

ProxMox — основанная на Debian платформа с открытым исходным кодом для развертывания и управления виртуальными машинами.

Production environment (PROD, Производственная среда)- среда, в которой программный продукт или услуга используется целевой аудиторией.

RDS — сервис реляционных баз данных AWS, облачная база данных, использующая распределенную природу сервисов AWS.

Rolling update (Скользящее обновление) — процесс плавных обновлений для приложения без простоев, выполняемый экземпляр за экземпляром. Он использует Kubernetes для обеспечения бесперебойной доступности приложений и положительного взаимодействия с пользователем.

Rollback (Откат) — ручное или автоматическое восстановление ранее сохраненного состояния программы или базы данных.

Regression testing (Регрессионное тестирование) — комплексное тестирование обновленной версии продукта, чтобы убедиться, что последняя сборка не оказала негативного влияния на уже имеющуюся функциональность.

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

Source control — система хранения, управления и отслеживания изменений в исходном коде. Наиболее популярными являются GitHub, GitLab и BitBucket.

S3 — Amazon Simple Storage Service — сервис облачных вычислений для хранения любых объектов данных, необходимых для стабильной работы ваших приложений.

Snapshot . Amazon EBS snapshot EBS — это команда для создания статической копии содержимого вашего экземпляра EC2 в целях резервного копирования и восстановления.

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

Автоматизация тестирования — процесс использования определенного программного обеспечения для тестирования новых версий программного обеспечения на основе модульных тестов и сравнения фактических результатов тестирования с прогнозируемыми результатами.

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

Модульное тестирование (Unit testing)- основа CI / CD, модульное тестирование — это практика тестирования кода приложения небольшими блоками на основе кода автоматизированного тестирования перед сборкой приложения, чтобы минимизировать время, необходимое для обнаружения и исправления ошибок, сокращая время выхода на рынок.

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

VPC peering — AWS VPC — это сервис, который логически изолирует определенное количество общедоступного облака AWS для создания виртуальных частных облаков. AWS VPC peering позволяет объединить ресурсы нескольких таких облаков в случае необходимости.

Vault — продукт Hashicorp для безопасного хранения таких секретов, как ключи SSH, токены, пароли, ключи API и другие важные элементы инфраструктуры Kubernetes.

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

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