Илья Ильичев
IT Manager компании Linxdatacenter
30.04.2021

«DevOps?», или Что вам не говорят о трендовой ИТ-профессии

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

Илья Ильичев

IT Manager компании Linxdatacenter

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

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

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

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

Джентльменский набор

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

Базовое требование: для хорошего старта нужен серьёзный опыт в работе с ИТ-инфраструктурой. Лучшие шансы у разностороннего специалиста с очень глубоким знанием Unix и родственных систем.

Далее, в требования к современным DevOps-инженерам входит обязательное знание одного-двух языков программирования на уровне, позволяющем писать скрипты для автоматизации процессов, запускать тесты и так далее – например Bash, Python, Go.

Поскольку практически вся работа сегодня строится на облачных решениях, необходимо хорошо разбираться в настройке облачных платформ: AWS, Azure, Google Cloud, VMware vDirector и других. Если у компании свои дата-центры или серверы, вам необходимо тесно работать с серверным «железом», знать технологии виртуализации, уметь настраивать сеть или разворачивать свое приватное облако.

Тут без знаний KVM, Xen, Open Stack, Proxmox, Vagrant, Apache CloudStack, VMware, MS Hyper-V, Nutanix не обойтись.

Все данные где-то приземляются, разнообразие файловых систем и систем хранения также очень велико.  В зависимости от задач и потребностей вы выберете себе или файловую систему хранения, или блочную, или объектную: NFS, samba, s3, zfs, iscsi, FC сети, ceph, gluster и другие vSAN.

Для сурового enterprise применяются системы посерьёзней, как правило это закрытые решения с обязательной поддержкой и гарантией от таких вендоров как Dell EMC, NetApp QNAP, HPE, IBM, 3par, Oracle, Lenovo, Fujitsu, Hitachi. Это лишь неполный список технологий, с которыми вы должны быть знакомы, а некоторые знать и использовать нужно будет на все 100%.

Нюанс здесь в том, что каждая компания будет использовать свой технологический стек, куда, помимо всего вышеупомянутого, будут также входить контейнеры – Kubernetes, Docker, OpenShift, системы управления конфигурациями (SCM) – Ansible или Puppet, и другие платформы и решения для CI/DI (Continuous Integration and Continuous Delivery – процесс непрерывной интеграции и непрерывного развертывания ПО).

Наконец, требуется умение разбираться и настраивать элементы legacy-инфраструктуры компании. Некоторые компании ищут DevOps с хорошим уровнем знаний по сетевым технологиям, или хотя бы не ниже Cisco CCNA.

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

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

Я в DevOps’ы бы пошёл

Всё ещё хочется в DevOps? Тогда продолжим.

Немного о требованиях к знанию языков программирования.

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

Вполне хватит владения на уровне «решить задачу автоматизации ИТ-администратора» или проанализировать ошибку «компиляции» кода. К примеру, создать конфиг на Ansible, вызвать какой-нибудь самописный скрипт и тому подобное.

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

Говоря о конкретных языках, можно отметить востребованность Python, Go, Ruby, Scala и C, а также языки сценариев командной оболочки – bash для Linux и PowerShell для Windows.

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

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

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

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

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

Скрипач не нужен

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

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

DevOps-специалистов в каждую компанию, которая серьёзно развивает какой-то ИТ-продукт, нужно 1-2 человека.

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

Нужно учитывать и всеобщую автоматизацию разработки в ИТ, различные low code/no code платформы для запуска прототипов и MVP – DevOps-инженер автоматизирует и упрощает всё, что можно, и подмастерья для этого ему не нужны.

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

Это всё сегодня автоматизируемо, а у многих автоматизировано уже полностью.

Главная задача на перспективу – максимально ускорить предварительно настроенный и чётко понимаемый процесс обновления релизов (CI/DI).

Противотренд – слабый

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

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

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

Инфраструктура как код: ЦОДы и DevOps

Некоторые компании развертывают часть или все свои ИТ-систем на open source решениях, и, скорее всего, они предпочтут разместить свое оборудование в ЦОДе.

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

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

Можно это автоматизировать в Puppet/ Ansible/ Chef/ Vagrant, а управлять этой автоматизацией посредством программного кода в этих системах.

Постепенное освоение компетенций профессии возможно через работу с парадигмой «инфраструктура как код» (Infrastructure as code, IaC).  Не за горами повсеместное внедрение SDN (программно-определяемые сети) и SDDC (программно-определяемый ЦОД)

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

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

Другие новости и публикации

Вас также могут заинтересовать

Linx Outsourcing
Аудит, модернизация и оптимизация ваших серверных мощностей
Подробнее
Аутсорсинг управления дата-центром
Linx Network
Обеспечьте отказоустойчивость и бесперебойную работу сети
Подробнее
Сетевые услуги
Linx DraaS
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Подробнее
Аварийное восстановление DRaaS

Напишите нам

Как мы оптимизировали управление ЦОДами клиента

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

Тарас Чирков, руководитель ЦОД Linxdatacenter в Санкт-Петербурге 

Константин Нагорный, главный инженер ЦОД Linxdatacenter в Санкт-Петербурге 

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

В главной роли – управление 

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

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

Высокий уровень «аптайма» – безаварийной работы дата-центра без простоев – очень сильно зависит от команды инженеров, которая занимается управлением площадки. А единой формализованной школы управления ЦОДами не существует.  

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

В масштабах страны  

На практике в России ситуация с эксплуатацией ЦОДов выглядит так.  

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

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

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

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

Факторов, приводящих к такому положению дел, много, один из главных – отсутствие систематизированной документации по выстраиванию эксплуатационных процессов. Есть пара вводных статей Uptime Institute, которые дают представление о проблеме и путях ее преодоления. Но дальше необходимо выстраивать систему своими силами. А на это ресурсов и компетенций хватит далеко не у каждого бизнеса.  

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

Кейс: через тернии к относительному порядку 

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

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

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

И здесь началось самое интересное.  

Познай себя 

Чтобы оценить уровень работы ЦОДов с точки зрения соответствия стандартам, нужно знать точные требования бизнеса к ИТ-системам: каков уровень внутренних SLA, допустимый период простоя оборудования и т.д.  

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

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

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

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

Улучшения в процессе 

Наши специалисты выезжали на площадки для оценки инфраструктуры, читали имеющуюся документацию, проверяли уровень соответствия проектов ЦОДов фактической реализации.  

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

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

Однако правильная оптимизация управления «инженеркой» ЦОДа предполагает выполнение задачи научить людей правильно оценивать процессы и писать под них уникальную документацию исходя из специфики конкретного объекта.  

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

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

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

Что сделано 

В процессе работ нам удалось решить несколько серьезных вопросов.  

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

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

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

Но нас удивило легкомысленное отношение компании к своей ИТ-инфраструктуре: от отсутствия резервирования критичных систем до хаоса в структуре и управлении.  

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

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

Выводы 

В целом перспективы консалтинга в сфере операционного управления дата-центрами, по нашему мнению, самые яркие.  

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

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

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

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

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

«DevOps?», или Что вам не говорят о трендовой ИТ-профессии

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Клиент:

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!