«Сайт лежит, на чьей стороне проблема?»: разговор о DevOps и его пользе для бизнеса

Простыми словами о деятельности команды, которая, помимо других известных сайтов, сопровождает vc.ru.

Привет. Это компания «Флант». Мы помогаем интернет-проектам развиваться, поддерживая их инфраструктуру. Если точнее — мы делаем так, чтобы разработчики проектов могли фокусироваться на программировании бизнес-логики и меньше переживали о том, как их код обновляется и работает в реальных условиях. К нашей сфере деятельности можно применить термин DevOps.

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

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

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

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

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

Разрыв, которым занимается мы, находится между разработчиками и системными администраторами. И здесь тоже есть немало аналогичных историй.

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

В крупных компаниях этот разрыв усиливался идеей о том, что нужно разделять ответственность над проектами: «создание нового» (то есть разработку — development) и «стабильную поддержку» (эксплуатацию — operations), чтобы на этом конфликте мнений проект становился лучше. Однако в реальности конфликты сильно мешают адаптироваться к быстрым переменам.

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

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

Чтобы описанная конструкция работала, создаются и развиваются специальные технические инструменты, применяемые на стыке Dev (разработки) и Ops (эксплуатации): Docker и Kubernetes, Ansible и Chef, Jenkins и GitLab CI.

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

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

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

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

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

Такая модель внедрения DevOps — заказ всего процесса как готовой услуги у стороннего партнёра — называется «DevOps как сервис» (DevOps as a Service).

Часто в России скептически относятся к аутсорсингу, однако в случае с ИТ, он стал частью глобального тренда. Компании по всему миру, в том числе в России, доверяют свои данные и критичные для бизнеса приложения облачным поставщикам. Аналогично аутсорсинг в области ИТ стал уже устоявшейся сферой и переживает в России активный рост.

К примеру, среди наших заказчиков — такие известные компании, как «Первый канал», Leroy Merlin, Lamoda, «Альфа-Лизинг», «Делимобиль» и собственно vc.ru. Очевидно, все они беспокоятся о репутации и безопасности, учитывают многочисленные риски.

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

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

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

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

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

Например, для онлайн-СМИ наиболее критичными могут оказаться как отдача новых, «горячих» материалов (причём с достаточной скоростью) для конечных пользователей, так и доступность админки для редакции (иначе эти сотрудники просто теряют рабочее время). А подозрительным сигналом, который тоже не стоит оставлять без внимания, может быть уменьшающееся число просмотров у новых публикаций.

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

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

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

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

Это наш первый материал на vc.ru, поэтому будем очень рады узнать, про какой опыт, какие технологии из нашей области вам интересно читать в дальнейшем.

#devops