Эта статья является продолжением интервью c Максимом Козиненко, первую часть которого читайте здесь.
В: Каким образом передаются заказчику необходимый объем знаний?
- М: Как показывает практика, в качестве первой линии саппорта достаточно использовать какой-либо operation center, который работал у заказчика и раньше в режиме 24 на 7. Если решение построено грамотно – необходимость вмешательства в его работу практически отпадает.
В: Ты имеешь ввиду команду NOC(network operation center)?
- М: Нет. NOC подразумевает наличие более или менее квалифицированных специалистов, которые могут быстро решить довольно сложные задачи. В нашем же случае, когда мы делаем релиз платформы, нам не нужны настолько квалифицированные люди. Соответственно в поддержке сидят люди, которые просто регистрируют проблемы и отправляют их на вторую линию, то есть к разработчикам. В идеале, ребята из operation center должны хорошо уметь отлавливать аномалии.
В: Для этого они собирают набор метрик с приложений? Вы им даете этот набор, чтобы они знали, что отслеживать?
- М: Да. Для этого есть такие инструменты, как, например, New Relic, Datadog, Prometheus, Sysdig. В итоге мы можем зайти в консоль и посмотреть что у нас на каком уровне происходит.
В: А можно ли использовать для этих целей, например, Zabbix?
- М: Можно использовать всё, что угодно. Набор инструментов большой роли не играет. С любым инструментом есть свои проблемы в ряде определённых решений. Не бывает идеальных инструментов. Есть инструмент, который подходит для решения определенной задачи и есть, который не подходит. Вот и всё.
В: Хорошо. Давай вернёмся к процессу передачи знаний. Как вы делаете трансфер знаний команде NOC?
- М: Мы даже не им делаем трансфер в прямом смысле. Им передаются дашборды и настраиваются уведомления. Мы можем проводить трансфер команде из одного-двух DevOps-ов у заказчика или нашей же команде саппорта. Даже в объёмном проекте достаточно для поддержки крайне небольшого количества сотрудников. В принципе, при грамотной реализации проекта (в том числе процессов), инфраструктурные проблемы не возникают вообще.
В: Это потому что используются такие облачные сервисы как Amazon AWS, Microsoft Azure, с которыми возникает мало проблем?
- М: Со всеми облачными провайдерами возникают проблемы J Просто нужно проектировать self-healing решения. То есть, в случае возникновения какой-то инфраструктурной проблемы решение само себя восстанавливает. Например, если в AWS упала availability zone – система может работать на тех, которые живы и, при необходимости, масштабировать себя там автоматически.
В: Предположим на проекте используется стек: PHP, PHP-FPM и MySQL и физические сервера. И нет желания переезжать в облако. Таких проектов на нашем рынке подавляющее большинство. Как бы ты применял тут CI/CD-процесс? Что бы ты использовал в качестве основных компонентов?
- М: Вариантов море. Нужно смотреть на требования, аттрибуты качества и кучу других метрик. И помнить, что использовать облачные сервисы –дешевле и надежнее. Иногда выходит, что смысл работы компании с он-премис датацентром сводится к поддержке своих серверов.
В: И все же мне кажется, что в ближайшее время ситуация не изменится.
- М: Я думаю, изменится. DevOps больше платят J поэтому так или иначе сисдамины, исторически задействованные в поддержке такого рода «проектов» будут развиваться и уходить.
В: А что по твоему представляет собой Ops-team? Это администраторы?
- М: В массовом понимании, как правило, это — команда поддержки физического оборудования базового уровня. А в общемировой практике, это люди, отвечающие за работу софта как такового. Инфраструктура, сеть, восстановление после сбоев, диагностирование неполадок и тд. Получается как DevOps, просто без взаимодействия с Dev и QA. Не взлетел софт на платформе — отправляем его обратно разработчикам на доработку.
В: Давай вернемся все же к проблеме поддержки облачных сервисов. Ведь в Украине даже проблематично найти специалистов данного профиля.
- М: Для поддержки облака необходимо гораздо меньше ресурсов, поскольку рутинные процессы гораздо проще автоматизировать.
В: С этим я согласен. Но заказчики боятся переходить в облако именно потому, что в случае чрезвычайной ситуации сложно найти специалиста, который сможет быстро решить проблему. И эта ситуация усугубляется маленькими бюджетами на оплату труда ИТ-поддержки.
- М: Варианты есть всегда. Можно начать с классической виртуализации – тут спецов хватает. И уже потом эволюционировать в контейнерную виртуализацию. Это, на данный момент, единственный способ убедиться, что среда разработчика будет полностью соответствовать среде продакшена. И приложение будет иметь все те же библиотеки во всех случаях.
В: Тогда возникает ситуация, когда всем надо перейти в Docker. Это ведь тоже большой объем работы.
- М: Мне не кажется, что это большая проблема, но, при этом, гораздо проще автоматизировать весь процесс. Как автоматизировать? Можно взять, например, GitLab и довольно быстро и просто построить все процессы.
В: Что насчёт управления контейнерами?
- М: Здесь есть нюансы. Нужно смотреть на масштабы проекта. Если у нас один компонент, то два-три скрипта будет достаточно. Если контейнеров много, и нам нужно ещё и как-то масштабироваться, то тут уже надо смотреть на оркестрацию. Если приложение состоит из большого количества микросервисов, то нужно смотреть на что-то типа Kubernetes.
В: Под компонентами ты имеешь ввиду количество Docker-образов?
- М: Разные приложения, а не экземпляры одного и того же приложения. Так что в общем да – образов.
В: Хотелось бы ещё обсудить с тобой не технический вопрос. А именно: менеджерские позиции в DevOps – как ты их видишь и как охарактеризуешь ситуацию на этом рынке вакансий?
- М: В DevOps есть менеджерские позиции. По сути – это человек, который обеспечивает работу определённого количества инженеров. Любых инженеров: QA, automation, release и так далее. Только он использует принципы методологии DevOps. И отвечает за бесперебойную и налаженную работу вверенного ему отдела. Он же является, что очень важно, коммуникацией между бизнесом и своими инженерами. Я всё пытаюсь донести свою основную мысль: DevOps – это не конкретная должность или конкретный человек. Это идеология. У нас в Украине сейчас немного неправильное понимание этого. У нас абсолютно разных инженеров называют DevOps-ами, начиная от release-инженера до специалиста по поддержке продуктов Atlassian.
В: Если говорить о позициях более высокого уровня в DevOps, что требуется от таких соискателей с твоей точки зрения?
- М: В Украине на такие должности примерный стек технологий выглядит так: Amazon Web Services (AWS) или, реже, Google Cloud Platform (GCP); знание как минимум одной из CI/CD-платформ, например, Jenkins; умение писать скрипты, в основном, Ruby и Python; в последнее время требуется знание Docker. Понимание принципов Agile. Умение переводить требования бизнеса в технические и наоборот. Неплохо еще широкий технический бэкграунд в целом – это обеспечивает Big Picture View.
В: Это только технические навыки. А что по поводу управленческих?
- М: Опыт J. Сын ошибок трудных.
В: То есть больше опыта и больше проектов?
- М: Да, именно.
В: Я встречал вакансии DevOps Director. Что это такое?
- М: В большинстве случаев, это означает, что люди в корне не понимают, зачем им нужен такой человек.
В: Возможно, они хотят нанять человека, который возьмёт на себя роль интегратора и двигателя изменений.
- М: Думаю, да. Все ждут что человек придет и нарисует им кнопку «сделать все хорошо». И забывают про бардак, который творится на уровне процессов. Даже если от человека ждут что он процессы эти реформирует (релиз, разработку, качество) – никто не думает, что для эффективности таких преобразований нужно менять еще и бизнес процессы.
About The Author
Виктор Карабедянц
ИТ директор (CIO), руководитель нескольких DevOps команд. Профессиональный руководитель проектов по внедрению, поддержке ИТ систем и обслуживанию пользователей.