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-сфере, пройдите наш бесплатный тест «Информационно-технологический профиль».

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

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

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

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 и как им стать: план обучения

Рассказывает Василий Озеров, SVP of Infrastructure

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

С Unix системами я познакомился в далеком 2005 году, еще будучи учеником лицея. О да, те незабываемые ночи, проведенные за установкой FreeBSD и компиляцией KDE из исходников. К слову, именно благодаря этому я и нашел свою первую работу, где разрабатывал небольшие проекты на QT/C++, занимался настройкой Cisco, а также поднимал почтовые сервера. И вот, наконец, я попал в геймдев компанию, где и начал свою карьеру DevOps инженера. Активное взаимодействие разработчиков и команды эксплуатации погрузили меня в доселе невиданный мир. До этого момента путь кода от разработчика на продакшн виделся мне огромной черной бездной, в которой было невозможно ничего разглядеть. Но, окунувшись в нее с головой, я понял, что все не так уж и страшно. Я увидел, как приложения собираются, как тестируются, как уходят в продакшн, где их видит весь интернет. Давайте приподнимем завесу тайны и посмотрим, как же стать успешным DevOps инженером.

Что такое DevOps?

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


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

  • Build Engineer — человек, отвечающий за сборку кода. Подтягивание зависимостей, разбор конфликтов в коде — это все про него.
  • Release Engineer — отвечает за доставку кода от разработки в продакшн. Какая ветка пойдет в тестирование, какой билд попадет на продакшн, релиз-инженер занимается именно этим.
  • Automation Engineer — инженер по автоматизации. Автоматизирует все, что движется. А что не движется, двигает и тоже автоматизирует. Автоматическая сборка при пуше в гит, прогон тестов, деплой на staging, деплой в продакшн — это все его задачи. Ключевая роль в DevOps подходе.

В целом можно выделить еще несколько ролей. Например, Security Engineer, который будет отвечать за прогон security-тестов и изучение уязвимостей в используемых компонентах. В реальном мире все (или почти все) эти роли по отдельности обычно совмещает какой-нибудь другой человек. К примеру, роль билд инженера можно отдать в руки разработчика. Да и автоматизация настройки серверов обычно отдается системным администраторам. А DevOps инженеру остается проработать и автоматизировать процесс сборки и доставки кода от разработчика в продакшн.

Минимальные знания, необходимые DevOps инженеру

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

Senior System Administrator

Или хотя бы middle. Идея в том, что вы должны на хорошем уровне разбираться в среде, в которой будут работать ваши приложения. Как они стартуют (init, systemd), что делать, если вы видите ошибку too many open files, использовать или не использовать swap. Все это очень сильно пригодится, когда вы будете запускать реальные проекты.

«Росбанк», Москва, до 60 000 ₽ (до налогов)

  1. Пройдите базовый курс по Linux.
  2. Я учился по сайту lissyara.su, речь тут идет больше о FreeBSD, но, изучив все статьи, получится хорошо расширить свой кругозор по часто используемом софту.
  3. Самое главное во время обучения — с головой окунуться в происходящее. Этому очень способствуют тематические форумы и телеграмм-каналы.

Networking — CCNA

Очень важная вещь, хотя про это забывают многие разработчики. Я считаю, что нельзя писать онлайн-сервисы, не понимая, как работает сеть. Никто не говорит, что надо заучивать семь уровней модели OSI, но точно потребуется знать, как работает IP, TCP/UDP и, конечно, протокол уровня приложения — например, HTTP, HTTP/2. Это сохранит вам кучу нервов выискивая причины ошибки Connection Refused.

  1. Запишитесь на курс CCNA.
  2. Установите себе GNS 3 и прокачивайтесь в настройке сетевого оборудования.

Junior Developer

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

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

  1. Изучить основные типы используемых данных.
  2. Посмотреть на основные применяемые алгоритмы.
  3. Почитать про паттерны программирования.
  4. Пройти простой курс по любому языку программирования, например, у golang есть неплохой интерактивный онлайн-туториал.

Junior DBA

На самом деле это входит в предыдущий пункт, но я все же решил его вынести отдельно. Поскольку все текущие проекты в любом случае используют базы данных, было бы неплохо уметь писать SQL запросы, использовать explain и понимать, как работают и зачем нужны index‘ы. Ну и до кучи посмотреть на популярные nosql решения.

  1. Самое простое — это пройти какой-нибудь курс, например от Enterprise DB.
  2. Если курс не хочется,то открываем документацию по postgres, устанавливаем базу, создаем таблички и изучаем основные команды, такие как select , insert , join . Смотрим на execution plan запроса, создаем индексы, а также бекапим, восстанавливаем и настраиваем репликацию.

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

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

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

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

  1. Сразу напишем небольшое приложение. Язык выбираем абсолютно любой. Приложение будет отдавать информацию о пользователях через HTTP. По сути, простенькое API.
  2. Теперь давайте добавим работу с базой: пусть наши пользователи хранятся в базе. Идеально структуру базы хранить рядом с кодом и научиться прогонять миграции при новых изменениях. Таким образом ваше приложение само синхронизирует базу до нужной структуры.
  3. Регистрируемся на github.com/bitbucket.org и закидываем весь исходный код нашего приложения туда.
  4. На своей машине поднимаем jenkins/teamcity и настраиваем автоматическую сборку приложения из нашего репозитория по кнопке.
  5. Усложняем задачу. Настроим webhooks на github/bitbucket, которые будут автоматически запускать сборку на jenkins/teamcity.
  6. Добавим тестов в jenkins: как минимум можно прогонять lint по нашему коду или набросать unit тесты.
  7. Переключимся на настройку dev окружения. Берем в руки ansible/chef/puppet/salt и настраиваем виртуалку с нуля: создаем пользователей, устанавливаем необходимые библиотеки и зависимости.
  8. Подводим все это дело под vagrant: виртуалка должна автоматически подниматься и настраиваться.
  9. Подключаем vagrant к jenkins с помощью соответствующего плагина: при пуше в git наше приложение собирается, и поднимается виртуальное окружение с помощью vagrant + configuration system management.
  10. Ищем best practices по деплою приложений на языке, который вы выбрали. Можно заворачивать все в deb/rpm пакеты, можно деплоить ruby с помощью capistrano. Главное — выбрать решение.
  11. Выбор сделан, реализуем его и конфигурируем jenkins, чтобы после пуша в репозиторий, jenkins, помимо сборки приложения и развертывания окружения, выкладывал и запускал наш код.
  12. Добавляем смоук тесты: после запуска jenkins должен запросить список пользователей у нашего API и убедиться, что получает ответ.
  13. Добавляем мониторинг нашего проекта: изучаем time series базы, настраиваем prometheus, grafana, автоматически подключаем новый инстанс нашего приложения к мониторингу.
  14. Улучшаем мониторинг: интегрируемся со slack и pagerduty, чтобы получать нотификации.
  15. Читаем про докер, пишем Dockerfile и оборачиваем наше приложение.
  16. Изучаем увлекательные статьи про настройку систем оркестрации swarm, kubernetes, rancher cattle. Следуем рекомендациям и поднимаем кластер.
  17. Меняем Jenkins: собираем docker образ, прогоняем тесты, запускаем собранный докер на кластере kubernetes, проводим smoke тесты, вводим наше приложение в балансировку.
Цукерберг рекомендует:  Галереи с пред просмотром миниатюр

Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps инженера — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на golang? Теперь пишем на ruby. Использовали jenkins? Берем teamcity. Поднимали kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.

Заключение

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

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 Методология

DevOps (от англ. development и operations; по-русски обычно произносится как «дево́пс») — набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения и нацелен на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и услуги.

Содержание

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

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


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

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

Популярность методологии значительно возросла в последние годы. По данным RightScale 2020 State of the Cloud Report: DevOps Trends [1] , принятие DevOps увеличилось с 66% в 2015 году до 74% в 2020 году, а среди крупных организаций принятие методологии еще выше – 81%.

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

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

Трансформация профессии системного администратора под влиянием DevOps

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

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

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

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

Использование в России

Сбербанк «подсел» на гибкую разработку: вслед за Agile — внедрение DevOps

Сбербанк внедряет практики DevOps в разработку автоматизированных систем. В качестве консультанта для этого банк по итогам конкурса в июле 2020 года привлек компанию McKinsey [2] .

Из опубликованной Сбербанком конкурсной документации следовало, что банк внедряет DevOps в части подпроцессов непрерывной сборки, развертывания и поставки (Continuous Integration, Delivery и Deployment). Автоматизированные системы для внедрения DevOps из числа целевых систем банка должны были быть выбраны совместно с McKinsey. Подробнее здесь.

«Альфа-Банк» ускорил ИТ-разработку в 60 раз за счет DevOps-культуры

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

В 2020 году мы совершили большой шаг в сторону DevOps-культуры — культуры гибкого проектирования и интеграции операционных и проектных процедур — и смогли создать в

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

Что такое DevOps?

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

Определение DevOps

DevOps — это сочетание разработки (Dev) и эксплуатации (Ops). Это объединение людей, процессов и технологий, позволяющее постоянно предоставлять преимущества клиентам.

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

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

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

Быстрый выход на рынок

Адаптация к условиям рынка и конкурентной среде

Поддержание стабильности и надежности системы

Сокращение среднего времени восстановления

DevOps и жизненный цикл приложений

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

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

Разработка

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

Доставка

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

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

Использование

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

Культура DevOps

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

Совместная работа, прозрачность и согласованность

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

Изменения в сфере участия и ответственности

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

Сокращение циклов выпуска

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

Непрерывное обучение

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

Узнайте, как команды в Майкрософт внедрили культуру DevOps

Методики DevOps

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

Непрерывные интеграция и поставка (CI/CD)

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

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

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

Управление версиями

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

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

Управление версиями также является необходимым элементом в других методиках, таких как непрерывная интеграция и инфраструктура как код.

Гибкая разработка программного обеспечения

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

С гибкой методикой связаны две популярные концепции — канбан и Scrum.

Инфраструктура как код

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

Цукерберг рекомендует:  System.out.println(hello); - Можно сделать хорошую игру на Java в 15лет

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

Управление конфигурацией

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

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

Непрерывный мониторинг

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

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

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

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

DevOps и облако

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

Облачная гибкость


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

Kubernetes

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

Бессерверные вычисления

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

Чем различаются Agile и DevOps

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

Что такое Agile. Это методика разработки, в которой, согласно основополагающему документу «The Agile Manifesto», приоритеты имеют:

  • индивидуумы и взаимодействия над процессами и инструментами;
  • работающее ПО над подробной документацией;
  • совместная работа с заказчиками над согласованием условий контрактов;
  • реагирование на изменения над следованием плану.

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

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

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

Методология vs развертывание. Agile — методика разработки ПО. После того, как ПО создано и выпущено, команда разработчиков формально за него больше не отвечает, приступая к другой работе.

С другое стороны, методика DevOps направлена на то, чтобы взять готовое ПО и развернуть его как можно более безопасным и надежным способом. При этом DevOps не зависит от ПО, разработанного с помощью методики Agile. Поэтому при использовании DevOps вполне можно применять водопадную модель разработки (waterfall development).

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

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

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

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

Команда или команда команд? Подход к ежедневному общению, предусмотренный в модели scrum, требует, чтобы Agile-команды были небольшими. Вряд ли такой способ можно применить к команде, состоящей из тысячи человек.

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

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

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

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

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

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

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

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

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

Краткий гид по видам стейков

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

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

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

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

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

Теперь, когда общее разделение понятно, перейдем к самим стейкам.

Рибай стейк

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

Рибай на кости (Ковбой стейк)

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

Нью-Йорк стейк (Стриплоин стейк, стрип стейк)

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

Филе-миньон

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

Флорентийский стейк (Портерхаус)

Это классический премиальный стейк, в котором сочетаются два очень разных вида мяса: ароматный Нью-Йорк и нежный филе-миньон, разделенные Т-образной костью. Купить Портерхаус в Бараниенбауме.

Ти-боун

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

Топ-блейд

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

Фланк стейк

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

Скерт стейк

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

Хэнгер стейк (онглет)

Очень редкий и вкусный стейк. В отличие от всех других отрубов, этот не является парным. То есть одно животное – один онглет, весом всего около 1–1,5 кг. Невероятный мясной аромат и сравнимая с филе-миньоном нежность отличают этот стейк. Есть одно но: сухожилие проходит через центр куска и, если вам оно мешает, вырежьте его перед приготовлением. Купить стейк онглет в Бараниенбауме.

Сирлоин стейк

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

Трай Тип

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

Что и кто такое 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 подписчиков. Присоединяйся!

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