Вестник цифровой трансформации CIO.RU

Почему в новых проектах Agile+DevOps разработчикам не обойтись без помощи инфраструктурщиков
Почему в новых проектах Agile+DevOps разработчикам не обойтись без помощи инфраструктурщиков




16:55 21.11.2019  |  Дмитрий Бессольцев | 1610 просмотров



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

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

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

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

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

Революция без жертв: смешанные команды в проектах Agile+DevOps

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

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

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

Самостоятельная разработка и поддержка микросервисов: что и как

В таких проектах господствует agile-подобная разработка. Есть заказчики, от которых идут задачи, есть координаторы проектов и аналоги спринтов Scrum. Под проекты оперативно выделяются «компактные», но достаточные бюджеты. И, главное – на таких проектах работают смешанные трансграничные команды. Строго внутри организации остаются стратегия и целеполагание (бизнес-лидеры), тактика разработки (технические лидеры), «ядро» разработки и информационная безопасность. Снаружи – написание мобильных версий основных ИТ-сервисов, интеграция и обмен новых систем с внешними сервисами, эксплуатация систем.

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

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

ИТ-инфраструктурщики на DevOps-проектах: чем полезны

Быстро создают и развертывают сразу несколько разных сред

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

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

Помогают выбрать площадку для сервисов и рассчитать ресурсы под проект

В DevOps-проекте инженеры сервисной компании очень часто помогают разработчикам приложений заранее определить, какую вычислительную мощность нужно выделить под сам проект (для каждой из трех сред). Позже их услуги нужны при тиражировании на новые подразделения, ИТ-инфраструктура которых практически всегда имеет особенности, а иногда и принципиальные отличия. Также эти специалисты правильно и эффективно по затратам организуют ИТ-инфраструктуру для работы приложений в облаках (AWS, GCE, Azure), чтобы впоследствии, когда число пользователей и объем задач будут возрастать, не пришлось тратить время и ресурсы на авральный «переезд» на более подходящую площадку.

Развертывают ИТ-инфраструктуру для запуска приложений

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

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

Автоматизируют управление инфраструктурой

«Сисадмины 2.0», опираясь на ИТ-инфраструктуру, с которой можно работать как с ПО, оформляют все рутинные операции по управлению ею (обновление, подготовка нового сервера) в виде задач для систем управления конфигурациями. И уже эти системы устанавливают и настраивают ПО, приводя его в оговоренное целевое состояние и обеспечивая целостность ИТ-решения любой сложности. Это позволяет до предела упростить обслуживание ИТ-инфраструктуры – например, перегрузить «зависший» виртуальный сервер, просто зайдя в консоль и нажав кнопку Reset. Или моментально восстановить информацию, которая, казалось, была потеряна (технология моментальных снимков).

Работают с контейнеризированными приложениями

Также инфраструктурщики автоматизируют установку, масштабирование и управление контейнеризированными приложениями с помощью кластеров Kubernetes. Благодаря их настройке (включая правила доступа к API и правила межсетевого взаимодействия для приложений), разработчики могут сделать свое приложение доступным даже во время пиковых нагрузок. А также в любой момент расширить или сжать кластер – буквально за пару секунд. Это экономит время и силы разработчиков, спасает их от многочисленных сложностей и ошибок.

Выполняют требования к SSO

Зачастую новые системы работают на разных СУБД (PostgreSQL, MySQL), а при разработке приложений используются разные платформы. Естественно, у разработчиков, а потом и у пользователей, должен быть простой и безопасный доступ ко всем нужным им сервисам и инструментам, а также сквозная аутентификация (Single Sign-On, SSO). Кроме того, над проектом работают разные команды – здесь обязательно нужно разделять права доступа к сервисам, инструментам, задачам, делать технически невозможным такое совмещение прав, которое создает высокие риски для бизнеса. К сожалению, об этом функционале думают не всегда.

Отслеживают «здоровье» информационной системы

Тиражируя и масштабируя новые приложения, важно следить за их состоянием, желательно в режиме реального времени. Специалисты по ИТ-инфраструктуре могут предоставить разработчикам приложений доступ к данным, помогающим анализировать возникающие ошибки в работе приложений с помощью инструментов open source (Graylog и Elasticsearch). Они также организуют сбор всех нужных разработчикам метрик с элементов инфраструктуры и приложений, на всех уровнях (Zabbix, Prometheus, TICK Stack). Также «инфраструктурщики» могут настроить удобную визуализацию и умные предупреждения о возможных ИТ-проблемах и авариях, отслеживать и корректировать поведение разных модулей приложения при высоких нагрузках.

Налаживают резервное копирование

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

Подведем итоги

Специалистов по ИТ-инфраструктуре необходимо вводить в новые DevOps-проекты, потому что они способны уберечь разработчиков от дорогостоящих и бьющих по репутации ошибок, связанных с эксплуатацией готовых решений. При этом важны индивидуальные рекомендации, основанные на понимании, куда организация ведет разработку, какие технологии и подходы предполагает применять. «Одна инструкция на все случаи жизни» тут не поможет, тем более, что сегодня очень много направлений разработки: кто-то занят big data, кто-то – искусственным интеллектом, а кто-то – исключительно «традиционными» информационными системами.

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

 

Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group


Теги: DevOps Agile ALP Group



На ту же тему: