Флант

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

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

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

Что значит DevOps

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

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

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

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

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

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

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

В среде разработки всё работает нормально. Теперь это проблема эксплуатации

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

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

DevOps — это процесс

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

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

  • разработчикам — быстрее выпускать новые инструменты для редакции и пользователей;
  • разработчикам — увидеть, как их код «ведёт себя» на серверах, чтобы писать его лучше;
  • разработчикам и системным администраторам — понимать друг друга, быстрее договариваться о целях и средствах для достижения общих результатов.

DevOps — это не список инструментов

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

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

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

DevOps как сервис

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

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

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

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

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

Использование публичных облачных провайдеров западными компаниями — статистика за первый квартал 2020 года от Statista

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

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

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

Принципы работы DevOps как сервиса

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

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

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

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

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

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

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

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

  • постоянное общение команд разработки и эксплуатации в чате (куда же сегодня без Slack);
  • возможность для клиента в любой момент увидеть, есть ли какие-то актуальные инциденты и что с ними происходит;
  • прозрачную информацию о прогрессе по развитию инфраструктуры: обо всех изменениях в задачах клиент сразу узнаёт в Slack, а еженедельные встречи-созвоны менеджера команды с клиентами помогают лучше понимать друг друга и двигаться к общей цели.

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

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

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

0
10 комментариев
Популярные
По порядку
Написать комментарий...

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

1

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

* На эту тему есть картинка, быстро ставшая классической в среде DevOps и сочувствующих: «Deployed my blog on Kubernetes» :-)

3

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

0

Да нет, на самом деле docker сделал всё ещё проще. Не надо на VPS раскатывать LAMP, а достаточно установить докер из apt, yum одной командой и запустить docker.yaml, который всё сделает за вас сам. 

0

А компания Флант тогда зачем?

0

Затем, что она подправит конфиг docker, который будет пересоздавать контейнер с данным, чтобы вы каждый раз не начинали с чистого листа. :)

ЗЫ: WP в Docker вообще отлично! Переносится очень легко и запускаться может из другого места. Если мы делаем HA на нём, то там некоторые нюансы могут быть решены проще.

1

Особый контейнер с данными вместо именованого volume? Аж олдскулы свело!

0

Чувак просто не девопсер, ему нужна консультация

0

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

1

Действительно стало проще, но автор вроде как больше жаловался про «девопсеров поверх кубера». А для «мелкого бложика» это явные излишки, потому что получится… как на картинке выше (она именно про Kubernetes, не Docker).

0
Читать все 10 комментариев
re:Store продал Macbook Pro с раскладкой azerty и серийный номер ноутбка не совпадает с серийным номером на коробке
«Неслучайная случайность», или как рождаются крипто стартапы на примере Freya

Статья носит сугубо ознакомительный характер и не призывает к инвестированию в какие либо активы.

Доколе? Уже 3 года ссылки с VC.RU на Facebook никуда не ведут

Если привязать аккаунт Facebook к VC.RU, то в профиле появляется ссылка на эту соцсеть, но она никуда не ведёт. Разработчики VC.RU уже 3 года не могут поправить этот баг, зато выпустили корпоративную звонилку.

И сотрудников тоже касается: кибербуллинг на рабочем месте
Design vector created by pikisuperstar - www.freepik.com
Глава американской компании Better.com уволил 900 сотрудников одним видеозвонком Статьи редакции

«Если вы сейчас смотрите это, значит вы в той невезучей группе, которую увольняют», — сказал работникам директор.

Я пришёл к вам с плохой новостью. Рынок изменился, как вы знаете, и мы должны двигаться за ним вперёд, чтобы выжить, процветать и исполнять нашу миссию. [...] Я делаю это второй раз в своей карьере и не хочу повторять. В последний раз, я плакал, но на этот раз надеюсь быть сильнее. [...] Если вы сейчас смотрите это, значит вы в той невезучей группе, которую увольняют.

Вишал Гарг
Дайджест новостей Сбера: сайт Digital Пётр, сценарии для умного дома и платина от Forbes

Прошлый дайджест мы целиком посвятили 180-летию Сбера, поэтому новостей накопилось много. Среди них — запуск сайта по распознаванию рукописей Петра I, большое обновление на платформе умного дома Sber и другие. Рассказываем всё самое интересное.

Картинка, сгенерированная ruDALL-E по запросу «рыжий котик»
SkillFactory раздает подарки: повышенная ставка и новогодний марафон для вебмастеров

В преддверии Нового года мы решили порадовать своих настоящих и будущих партнеров — участников партнерской программы школ Skillfactory, Contented и Product LIVE. Это возможность получить денежный бонус и заодно увеличить прибыль от продажи наших курсов.

Доказал, что миллиардеры не видят разницы между вином за $500 и $10 тысяч: история Руди Курниавана Статьи редакции

Курниаван продавал подделки под видом редких вин предпринимателям, генеральным директорам и голливудским продюсерам и обманул их более чем на $35 млн.

Руди Курниаван LA Times
Яндекс Еда по подписке завышает цену доставки

Доброе утро

Как обманывает Учи.ру, пытаясь заработать больше денег

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

Продавец eBay из Кургана стала победителем в финале Всероссийского конкурса «Молодой предприниматель России 2021»

27 ноября в Москве состоялся финал ежегодного конкурса «Молодой предприниматель России 2021». В нём приняли участие предприниматели и самозанятые в возрасте до 35 лет. Всего было подано более 300 заявок из 43 регионов страны.

null