Лучшие DevOps практики и кейсы

Роли и обязанности DevOps, и кто, чем занимается

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

Последствия развития практик DevOps

DevOps – это набор практик, методологий, направленных на улучшение сотрудничества между отделами. Первоначальная проблема заключалась в том, что разработчики и команда QA прекращали свою работу, как только код успешно прошел все тесты. После этого работа Ops-ов заключалась в том, чтобы доставить продукт пользователям, обслуживать и поддерживать приложение. Эта проблема была актуальна для многих компаний, так как такой подход был широко распространен. DevOps, как методология пытался решить эту проблему, но не просто объединив Dev с Ops, а реализовав основные принципы DevOps, как подхода:
  1. Инфраструктура как код (IaC) – все серверные среды и конфигурации описываются в файлах и хранятся в виде кода. Их может использовать и изменять любой член команды для создания серверной инфраструктуры. Можно сказать, что это шаблоны, и они могут повысить продуктивность ИТ-команды. Кстати, мы создали статью, в которой описали, как шаблоны могут значительно облегчить жизнь ваших DevOps специалистов.
  2. Непрерывная интеграция (CI) – позволяет ИТ-команде непрерывно интегрировать новые функции и запросы от заинтересованных сторон и конечных пользователей в форме новых версий программного обеспечения.
  3. Непрерывная доставка (CD) – это автоматическая доставка рабочего кода конечному пользователю. Код доставляется после прохождения всех тестов и без каких-либо дополнительных действий со стороны DevOps. Это позволяет значительно сократить время простоя сервисов и улучшить взаимодействие с пользователем.
Основываясь на этих практиках, мы можем предположить, что DevOps – это процесс и практики, а не роли в команде. Все в команде DevOps пишут код, но специалисты Ops несут ответственность за код инфраструктуры, разработчики и QA пишут автоматические тесты и код приложения для обеспечения качества. Этот сложный подход отличается от различного сочетания ролей ИТ-команды.

Роли DevOps в команде


DevOps имеет одну цель: обеспечить безопасность и производительность облачной инфраструктуры. Специалисты несут ответственность за все бутылочные горлышки производственного конвейера и должны оценивать риски с самого начала производственного процесса. DevOps строят процесс, в котором каждый новый фрагмент кода проходит тесты и загружается в репозиторий, а затем отправляет его в пользователю. Специалисты DevOps заранее думают о том, как будет работать приложение, о возможных бутылочных горлышках и ​​о том, как их избежать. Вот почему DevOps концентрируется на времени выхода на рынок и описании IT-процессов, чтобы обеспечить стабильную и надежную среду разработки.
Чтобы сделать команду DevOps продуктивной, в ней должно быть несколько ролей. Они не являются обязательными, но если вы будете следовать этому руководству, вы, вероятно, сможете улучшить свой производственный процесс.
  1. Владелец продукта (Product Owner) – отвечает за взаимодействие между командой и заказчиком. Это человек, который может интерпретировать требования бизнеса для технической команды. Кроме того, владелец продукта – это человек, который понимает, как должно работать приложение и какая инфраструктура требуется для поддержки и доставки пользователям. Владелец продукта может быть как со стороны клиента, так и со стороны технической команды.
  2. Тимлид – позиция наиболее технически продвинутого человека, умеющего оценивать требуемые технологии и делегировать задачи членам команды.
  3. Облачный архитектор – человек с практическим опытом построения облачной инфраструктуры, понимающий необходимые технологии и способы их использования для поддержки приложения.
  4. Инженер по надежности сайта (SRE) – специалист, основной задачей которого является обеспечение доступности и стабильной работы приложения в масштабной инфраструктуре.
  5. Системный администратор – это одна из основных ролей, поскольку он устанавливает и поддерживает инфраструктуру, отслеживает использование ресурсов и постоянно улучшает производительность системы.
Такой состав команды позволяет достичь требуемой производительности для большого проекта, однако в отдельных случаях структура и распределение ролей могут отличаться.

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

Статьи