Как автоматизировать и интегрировать рутинные отношения между разработчиками и IT-командами

Часто вы обновляете приложения для своих клиентов? А ваши конкуренты? Вы точно успеваете за потребностями и «хотелками» своей целевой аудитории? У вас минимальный time-to-market для обновлений и новых цифровых продуктов? Если вы ответили «да» на все вопросы, то, скорее всего, про DevOps вы уже знаете и успешно его исповедуете. Если же «нет», то послушайте, что рассказывают об этой новой IT-религии сами айтишники — CEO (генеральный директор) инжиниринговой IT-компании Tages Jump Дмитрий Голубовский и CTO (технический директор) Илья Рачкулик.

Дмитрий Голубовский: Что сейчас происходит в бизнесе в целом и в IT-сегменте в частности? Смена технологического уклада. Старая парадигма планирования проектов на три-пять лет вперед уже не работает, так жить больше нельзя, потому что срок жизни любого цифрового продукта стремительно сократился, а обновления накатываются на любое приложение чуть ли не еженедельно. Пандемия только ускорила все эти процессы, и те компании, которые поняли это и успели перестроиться, сейчас собирают сливки, пачками выкупая более мелкие бизнесы, и образуют целые экосистемы: «Яндекс», «Сбер», Mail.ru, «М.Видео» и прочие.

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

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

Мы все люди, и нам свойственно бояться всего нового. Плохо, когда человек не просто сам по себе боится внедрения новых правил, но и отвечает при этом за цифровое развитие бизнеса. Жесткая централизация всех процессов и решений, страх нового и jobs security, страх признать, что три-пять лет назад ты принял неверное решение и вот сейчас нужно снова идти к владельцу бизнеса и объяснять, что нужно опять все поменять, а на это нужен немаленький бюджет,— все это тормозит процессы цифровизации и внедрения новых методологий работы. Но уже ничто не избавит бизнес от этой необходимости. Будущее уже здесь, просто пока не все его видят невооруженным глазом.

Что такое DevOps и какие проблемы он решает?

Еще полтора-два года назад в России мало кто понимал, что это такое и зачем, сейчас в специалистах DevOps нуждаются все — от компаний-разработчиков до крупного бизнеса.

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

Однако если смотреть ближе к сути, то DevOps — это методология, которая дает возможность автоматизировать и интегрировать рутинные процессы между разработчиками и IT-командами. Она существенно сокращает сроки создания новых цифровых продуктов и вывод их на рынок (time-to-market), одновременно улучшая их качество. На языке бизнеса это означает, что внедрение новой функции в ваше уже работающее приложение можно осуществить в рекордно короткие сроки с соблюдением всех правил безопасности, существенно опередив конкурентов. Соответственно, вы получаете экономию времени и финансов, бесперебойную и безошибочную работу своих цифровых продуктов, опережаете конкурентов и буквально снимаете сливки с клиентов в виде чистой прибыли.

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

Что это даст бизнесу?

Илья Рачкулик: Сейчас все кому не лень говорят про эджайл-идеологию. Почему? Потому что она ускоряет процессы разработки. Когда ты задумываешь сделать новый релиз, продукт или приложение, то от идеи до финальной точки у тебя проходит условно год, то твой time-to-market — это год. Поздравляю! Ты уже опоздал. Твои конкуренты уже давно все выпустили и обновили 12 раз минимум. Если ты пытаешься целый год разрабатывать один продукт, то все, что ты заложил в него в самом начале, через год уже никому не интересно и не нужно. У современного бизнеса просто нет этого года. Именно поэтому agile и стал популярен — он сокращает время на разработку на 10–15%, а DevOps — в разы.

Дмитрий Голубовский: Как мы уже говорили, сейчас для бизнеса максимально важно выпустить приложение как можно скорее. Релизы выходят чуть ли не каждую неделю: выпустили MVP (minimum viable product — минимально жизнеспособный продукт) и дальше пошли его дорабатывать. Если у тебя есть условно две недели плюс неделя на все про все, то нужно понимать, что 30–50% времени должно уходить на сборку, сам релиз, раскатку, тестирование. Эти процессы нужно оцифровать и составить пайплайн — описать пошагово, что мы делаем. Раньше это делали руками и скриптами, сейчас это уже конвейерное производство: есть код, происходит сборка, тестирование продукта, выкатка его на стенд, релиз. И обеспечивает этот процесс так, чтобы все обновления для пользователей проходили максимально бесшовно, как раз DevOps.

DevOps-инженер — кто он и что делает?

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

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

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

Что должен знать и уметь DevOps?

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

Прежде всего — знать языки программирования: Python, Golang, Ruby, C, C++. Главное, конечно, не их количество — все знать невозможно,— а общее понимание принципов работы. То есть быть с кодом на ты. Он должен знать основные аспекты операционных систем, необходимых для работы, и особое внимание уделять Linux. Иметь навыки администрирования серверов, поскольку инженеру DevOps придется управлять всеми типами серверов, которых может быть больше сотни. Знать сетевую безопасность, базовые протоколы — HTTP, SSL, SSH, FTP, SMTP и пр. Важно, чтобы человек разбирался, как они настраиваются на уровне сервиса, и знал, что влияет на их безопасность. Уметь работать с веб-серверами, понимать инфраструктуру как код и управлять ею с помощью инструментов на основе кода. Знать и уметь работать с инструментами CI (непрерывной интеграции)/CD (непрерывной доставки), например GitLab CI. Вообще, лучшее резюме для разработчика — это не заполненная по всем канонам HR форма на HeadHunter, а красивый код, написанный в GitLab.

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

На текущий момент процесс DevOps закрыть одним только специалистом уже невозможно. По факту это целое отдельное направление, в рамках которого работают группы специалистов с разной специализацией — это ci/cd, мониторинг, отладка, трейсинг и трекинг, безопасность и пр.

Основные цели DevOps

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

Такая настройка помогает разом решить несколько задач:

— улучшить частоту развертывания новых релизов;

— сократить time-to-market;

— снизить частоту отказов от новых релизов;

— сократить время и затраты на отслеживание и исправление багов в продакшен-средах и средах разработки;

— сократить время на восстановление в результате каких-то ошибок и «падений» приложения.

Благодаря этому крупные IT-организации развертываются в среднем в 30 раз чаще, то есть время на выполнение заказа сокращается до 200 раз, соответственно, и время вывода продукта на рынок — тоже. Благодаря DevOps мы можем себе позволить выкатывать обновления хоть раз в две недели, а не тратить год на доработку какого-то функционала.

Хотя DevOps, а точнее, его первые проявления возникли на рынке еще в 2012–2015 годах, когда такие гиганты, как Leroy Merlin и «М.Видео» начали внедрять у себя эту практику, большая часть бизнеса до сих пор не осознала необходимости перестройки на такую «поточную» схему работы. Что важно, смена технологического уклада не подозревает тотальный снос и уничтожение всего того, что было. Умные компании, цель которых — технологическое превосходство на рынке, просто выстраивают эти процессы параллельно со старыми, чтобы постепенно переходить на новый уровень. Фактически они создают себе почву для того самого «бесшовного» перехода на новую методологию работы, практически незаметную для неискушенного глаза пользователя. Но те, кто не готов меняться и вкладываться в развитие новых методик в своем ландшафте, к сожалению, обречены на вымирание, потому что рано или поздно, но они останутся в хвосте этого локомотива, а потом безнадежно отстанут.