DevOps-инженер – компетенции и зоны ответственности. Типичные ошибки при выстраивании процессов ИТ-разработки

Максим Морарь. На рынке наблюдается очень сильная нехватка квалифицированных DevOps-специалистов. Почему это происходит? Во-первых, рынок ИТ, как и других секторов, быстро меняется. Всем требуется трансформация и переход «в цифру», чтобы быстрее разрабатывать цифровые продукты для конечных пользователей и обгонять своих конкурентов, завоевывая рынок. Именно поэтому бизнесу необходимо сокращение показателя Time To Market (TTM) и увеличение скорости разработки цифровых продуктов. Чтобы улучшить эти показатели, необходима, в первую очередь, качественная команда, состоящая из группы разработки и группы ИТ-инфраструктуры, а также связующее звено — DevOps, которое применяет подходящие методологии, выстраивает необходимые связи и т. д. Поэтому спрос на таких специалистов очень высок, при этом квалифицированных кадров не хватает. За последний год рынок ИТ вырос очень значительно — более, чем на 14%. На рынке в данный момент около 400000 активных вакансий, которые рекрутеры не могут закрыть, включая вакансии DevOps-инженеров, аналитиков и т. д.

Самая большая сложность для ИТ-руководителя — оценка квалификации кадров на входе. Это связано с тем, что зарплата специалистов выше, поэтому неспециалисты начинают переквалифицироваться в DevOps, изучая, например, Kubernetes, СI/CD в типовом по размеру проекте (pipeline) и пытаются переквалифицироваться в DevOps-инженеров. Мы, как и наши средние и крупные заказчики, сталкиваемся с тем, что такие специалисты плохо понимают что-либо, например, ниже уровня Kubernetes. И, когда необходимо спуститься, например, на уровень операционной системы или ядра Linux и исправить какую-либо ошибку, возникают проблемы. А таких проблем хотелось бы избежать. Поэтому большую роль играет качество найма, учитывая быстрый рост спроса на DevOps, консультационные услуги и услуги сервис-провайдеров, которые решают конечную бизнес-задачу для клиентов «под ключ».

DevOps-сообщество

Мы состоим в сообществе DevOps-инженеров. В Telegram-чате этого сообщества свыше 4 500 участников. Мы заинтересовались, как часто у всех этих инженеров в течение дня бывает свободное время и как они его проводят, и провели анонимный опрос и получили около 200 ответов.

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

Пример из практики. Неквалифицированный DevOps — горе в семье

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

Когда мы погрузились в этот проект, мы обнаруживали месиво. Testing и production были настроены в бэкенде. Backend-приложение было неким Python-приложением, упакованным в один единственный контейнер, который был размещен на одном единственном физическом узле сети. С точки зрения отказоустойчивости и возможности развертывания без простоя решение было абсолютно непригодно.

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

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

Как избежать проблем?

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

1. Во-первых, это качественный наем. Необходимо понимать, что наем квалифицированного специалиста — это нагрузка на ФОТ и время на поиск и встраивание такого специалиста в команду, но на выходе вы получаете действительно качественного специалиста, решающего вашу конечную бизнес-задачу. Это логичный, хотя и длительный путь.
2. Во-вторых, можно воспользоваться популярными сейчас на рынке Managed Services — управляемыми услугами (экспертная поддержка и аутсорсинг выстраивания команды), которые есть в портфолио многих провайдеров. Как правило, услуги предлагают люди, которые внедрили не один десяток таких проектов, спроектировали не один десяток инфраструктур, отстроили процессы в компаниях разных размеров и отраслей и имеющие огромный опыт, набившие кучу шишек и гарантирующие конечный результат. От заказчика требуется поставить бизнес-задачу, а специалисты с точки зрения своего опыта предлагают архитектурные решения и внедряют рекомендуемый ими или другой приемлемый для заказчика технологический стек.
   
   

PaaS

Можно возразить, что на рынке уже есть услуга PaaS — Platform as a Service, предоставляемая облачными провайдерами и позволяющая получить, например, Kubernetes в стандартном виде за 3-5 минут. PaaS, безусловно, выход из ситуации. Мы также пользуемся PaaS и в облаке предлагаем Kubernetes as a Service. Однако необходимо понимать, что PaaS — это не панацея. Это некое коробочное решение, которое невозможно или сложно кастомизировать. Как правило, такие решения не подходят для больших проектов или для проектов со сложными интеграциями и требованиями к защите ИТ-инфраструктуры.

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

Плюсы и минусы услуг

Поэтому выбирается выделенная инсталляция Kubernetes, которую можно настроить своими руками. Альтернатива — небольшие команды разработчиков, стартапы, которым быстро требуются ресурсы или платформа. Такая платформа может быть стандартной и не особо функциональной или надежной. Основной критерий — быстрое получение endpoints и развертывание в Kubernetes.

Важно понимать, под какую задачу необходима инфраструктура и как эту задачу можно решить.

Почему PaaS — не всегда хороший выход

Некоторые заказчики предъявляют требования, которые, по нашему мнению, нельзя реализовать в публичных облаках в формате Platform as a Service. Например:

• Тонкое разграничение сетевого взаимодействия через политики безопасности Pod Security Policies. Такое требование не всегда удается выполнить в классической коробке и иногда приходится спускаться на уровень ниже. В таких случаях заказчики выбирают альтернативу в виде выделенной инсталляция Kubernetes с полным управлением.
• Конфигурация ОС и кластеров k8s в соответствии с фреймворками безопасности CIS, OpenSCAP, PCI/DSS. Это требование актуально, например, для банков. Для конфигурации OpenSCAP необходимо спускаться до уровня операционной системы и ядра Linux и настраивать именно его. В классических коробочных решениях это невозможно, поэтому заказчики всегда выбирают альтернативу в виде собственной инсталляции.
• Разграничение прав доступа к API, интеграция с Active Directory. Это не самое распространенное требование, поскольку не всем требуется интеграция AD и Kubernetes. При этом в рамках PaaS его не всегда можно выполнить.
• Внедрение и интеграция с внешними системами защиты сред контейнеризации, такими как Aqua Security или аналогами. При внедрении этих требований в классический PaaS также открывается множество подводных камней. По нашему опыту, нужно выбирать альтернативу, чтобы не получить неработающие решение, которое внешне может соответствовать требованиям к защите ИТ-инфраструктуры, а с точки зрения функционала налагает огромные ограничения.
• Внедрение дополнительных СЗИ для соответствия требованиям 152-ФЗ.
• Интеграция с текущими средствами логирования и мониторинга.
• Документация. Как правило, на границу Kubernetes необходимо поставить, например, Fortigate для межсетевого экранирования. В таком случае также появляется много нюансов, когда дело доходит до внедрения этих инструментов на классической PaaS какого-то облачного провайдера. И очень важно понимать конечную задачу и конечные требования всех участников (команд) заказчика с точки зрения защиты ИТ-инфраструктуры, разработки, инфраструктуры, архитектуры и выбирать работающую альтернативу.

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

Технические трудности

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

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

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

 

Организационные трудности

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

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

• Неспособность руководителя команды справиться с работой или нежелание делить ответственность.

• Значительная нагрузка на HR и невозможность обеспечить быстрое расширение. 

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

Мы меняем процессы ИТ-разработки в несколько этапов:

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

— Отрисовка текущего процесса работы и зон ответственности.

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

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

— Подготовка списка метрик для контроля загрузки и скорости работы ИТ-команды.

— Реализация и контроль изменений.

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

Следует обращать внимание на следующее:

• Опыт внедрения или сопровождения аналогичных проектов (например, по технологическому стеку, размеру или профилю компании). Мы рекомендуем ссылаться на рейтинг, (например, 50 крупнейших компаний отрасли) и спрашивать у провайдера об опыте работы с компаниями из такого списка, успешности такого опыта, рекомендациях предыдущих заказчиков.
• Наличие в штате провайдера специалистов с сертификатами, например, Certified Administrator Kubernetes CNCF. Сертификат — показатель качества и вероятности успешности вашего проекта, который будет внедрять такой специалист.
• Строгий SLA (например, доступность конечных сервисов 99,95%) для конечного сервиса (вплоть до уровня приложения), что гарантирует отказоустойчивость построенного решения и готовность к этапу production.
• Готовность провайдера обеспечивать индивидуальный подход для каждого заказчика, разбираться в его бизнесе и предлагать кастомизированные решения с учетом потребностей бизнеса и поставленных целей. Все эти проекты — не типовые, их очень сложно поставить на конвейер и выдавать в коробочном виде. Каждый проект уникален, потому что каждый заказчик имеет свой инфраструктурный стек, свою инфраструктурную команду и команду разработки, свои бизнес-требования, целевой показатель TTM и т. д.

Именно на этом этапе важно понимание, что именно выбранная команда сможет подобрать наилучшее кастомное решение. Например, K2 Cloud — это собственная разработка, AWS EC2/S3 API, серверная инфраструктура и программно-управляемое хранилище, построенные на базе решений Dell Technologies. В публичном коммерческом облаке K2 Cloud уже размещено более 550 заказчиков в сегменте Enterprise.

 

Михаил Орленко. Dell Technologies предлагает решения для создания инфраструктуры и решения описанных проблем.

Dell Technologies — технологическое лидерство, стремление к инновациям и обширные инвестиции

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

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

ИТ-департаменты решают массу проблем одновременно

 

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

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

Участие ИТ-департамента в работе организации

 

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

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

    

Развитие ИТ-инфраструктуры с серверами PowerEdge

  

Мы считаем основными преимуществами наших серверов три ключевые технологические инновации:

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

 

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

Адаптивные вычисления

Недавно мы выпустили новое поколение серверов, в частности, на процессорах Intel Sсalable третьего поколения. Эти серверы уже можно использовать в своих проектах.

Адаптивные вычисления созданы для оптимального использования передовых технологий.

В рамках только последнего выпуска серверов (11 новых серверных платформ для абсолютно разных классов задач) мы закрываем нашими системами на Intel практически все задачи заказчиков. 99% всех существующих задач может быть реализовано при помощи серверов на базе платформы x86 со специализированными требованиями, например:

• Использование вычислительных ускорителей с GPU. Мы предлагаем довольно плотные конфигурации — до четырех мощных самых последних GPU компании Nvidia или AMD.
• Специализированные решения для новой области граничных вычислений, которые будут интересны телеком-компаниям, компаниям, занятым производством, логистикой или любой деятельностью, требующей размещения серверов в нестандартной инфраструктуре — не внутри ЦОДа, а на телеком-вышке, в цехах, на складе. Эти серверы подготовлены, работают надежно, используют современные технологии охлаждения и предоставляют полноценные возможности как по компоновке, так и по удаленному управлению и по автоматизации управления серверами.
• Системы для основных серверных задач, таких как виртуализация, новые контейнерные инфраструктуры и другие решения для специализированных задач, таких как высокопроизводительные вычисления.
• Масштабные облачные инфраструктуры.
• Специализированные модели, которые скоро можно будет заказать в K2 Cloud.

Адаптивные вычисления

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

Автономная вычислительная инфраструктура

Наши программные решения OpenManage Enterprise, поставляемые с нашими серверами, позволяют значительно упростить администрирование, рутинные процессы, которые используются при эксплуатации серверов, и это затрагивает все возможные операции на протяжении всего жизненного цикла серверных решений:

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

Автономная вычислительная инфраструктура

 

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

Infrastructure as Code (IaC) — подход к описанию и конфигурированию инфраструктуры ЦОД (всех серверных ресурсов на предприятии или в облаке) с использованием конфигурационных файлов.

Такой подход позволяет:

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

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

Основы IaC

В каждом сервере есть специализированный контроллер удаленного управления сервером — конфигурационный файл, в котором хранится некий профиль сервера, т.е. описано состояние инфраструктуры. Server Configuration Profile (SCP) — конфигурационный файл в формате JSON или XML, который применяется к серверу вручную (через веб-интерфейс или CLI) или с использованием средств автоматизации. SCP можно получить через:

• вызовы WebGUI или CLI$
• вызовы RestAPI;
• OpenManage Enterprise (GUI или RestAPI).

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

Использование Dell EMC OpenManage Enterprise

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

Конфигурационные файлы также позволяют автоматизировать массу операций, связанных с жизнью серверов:

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

Интеграция с внешними системами управления

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

Такие возможности доступны для работы с серверами Dell EMC PowerEdge и со всеми нашими системами.

Интеграция с внешними инструментами управления

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

Дополнительные ресурсы

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

Все эти материалы вы можете использовать в своей работе. Все вопросы можно направлять как в K2 Cloud, так и в Dell Technologies. Мы всегда постараемся подобрать решение для ваших задач и совместно проработать все аспекты такого решения.

Вопрос. Расскажите о проектах в крупных компаниях, где вы улучшали процесс разработки? Какие бизнес-метрики вы замеряли?

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

Компания хотела решить две основные проблемы. Во-первых, нам была поставлена задача повысить показатель TTM и сократить срок внедрения с полутора месяцев до двух недель. Во-вторых, каждый релиз выпускался буквально с потом и кровью, а также длительным простоем. После выкатки релиза в production приходилось вносить много исправлений, откатывать и выкатывать заново. Соответственно, мы должны были решить проблему нестабильной выкатки.

Мы провели аудит текущих процессов, текущего инфраструктурного и технологического стека и стека разработки, разобрались в ролях и зонах ответственности и по результатам отрисовали список «узких мест». После этого мы модернизировали архитектуру конечного приложения — ушли от концепции монолитов к концепции микро-сервисов. Мы улучшили процессы разработки, внедрив определенные инструменты, понятный и кастомный pipeline CI/CD, такие инструменты как Jenkins, Docker как средство контейнеризации, Kubernetes и т. д., т. е. стандартные инструменты из DevOps-стека.

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

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

 

Вопрос. Dell по-прежнему не производит ARM-серверы?

Михаил Орленко. Вопрос с подвохом. Компания Dell выпустила серверы на базе ARM одной из первых. Нашим специализированным заказчикам, которые занимаются облачными инфраструктурами, они были доступны еще на заре технологии ARM. Реализованные тогда проекты не продемонстрировали достаточный уровень эффективности и на массовый рынок не вышли. Естественно, мы следим за развитием технологий. Если вы знакомы с историей компании Dell, вы наверняка слышали, что Майкл Делл в свое время неспроста сделал ставку на x86. Это был абсолютно осознанный шаг. Его принципом всегда была доступность передовых технологий для пользователей и использование самых популярных технологий на рынке для своих решений. Поэтому я не удивлюсь, если мы с вами увидим в ближайшем или не очень ближайшем будущем серверы ARM. Вполне возможно, что это произойдет в наших лабораториях, где тестируются и обкатываются самые разные технологии.

Кроме того, компания Dell известна тем, что вместе с решениями для масс-маркета вместе такими компаниями, как Microsoft, Amazon и Google разрабатывает различные специализированные решения для задач упомянутых провайдеров. У этих компаний есть и свои разработки. Но, например, кэш-серверы Google, которые стоят по всему миру, в том числе у всех российских операторов, это серверы Dell PowerEdge в специализированной конфигурации. В этих серверах применяется нестандартная внутренняя компоновка. Но, тем не менее, даже такие мировые компании понимают, что для некоторых задач оптимально использовать не свои системы, которые себя оправдывают в ЦОДах, где стоят десятки тысяч машин.

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

Вопрос. Реализовывали ли вы проекты, связанные с сельским хозяйством?

Максим Морарь. Да, безусловно, мы реализовывали такие проекты как для государственных заказчиков, связанных с сельским хозяйством, так и для коммерческих компаний, в частности для одного из крупнейших агропромышленных комплексов. Проект для этой компании заключался в том, что мы строили для клиентов частные облака на базе оборудования Dell Technologies, виртуализацию, отстраивали Kubernetes-кластеры, предлагали поддержку до уровня приложений, т. е. Managed Service.

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