Как подружить команду админов с командами разработки?


    Процесс создания сервиса не ограничивается разработкой и тестированием. Помимо этого есть ещё и эксплуатация сервиса в продакшн-инфраструктуре.

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

    В статье речь пойдет о том, как мы в 2ГИС выстраивали процессы работы в команде Infrastructure & Operations (9 человек) и взаимодействие с командами разработки (5 команд). На первый взгляд, всё просто и логично.

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

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


    О наших баранах

    Если три упомянутых выше проблемы вас не впечатлили, посмотрите на список моментов, с которыми столкнулась наша команда:

    • С коммуникациями всё сложно. Обращаться за помощью было не принято и инструменты выбирались без консультаций, исходя не из задачи, а из удобства. Получалось, что люди приходили уже с готовым решением, часто нагугленным, а не с проблемой.
    • Частично ручное конфигурирование сервисов. С разрастанием количества сервисов объём ручной работы увеличивался. Люди были перегружены, нервозность в коллективе нарастала.
    • Уникальность сервисов. Каждый проект был уникален как снежинка, соответственно, время разбора инцидентов было очень большим — сначала нужно разобраться в работе сервиса, потом понять, в чём проблема, а потом уже чинить. К тому же, часто разработчики не интересовались, существует ли уже в компании какой нибудь кластер PostgreSQL или Rabbit и деплоили свой.
    • Не были сформулированы и зафиксированы правила работы системных администраторов и таск-трекинг. Фидбек от разработчиков — «Фиг знает, чем они там занимаются».
    • Не были формализованы каналы коммуникаций. В итоге — что-то пишется на почту, что-то в скайп, что-то в Slack, о чём-то договариваются по телефону.


    В совокупности все эти факторы приводили к увеличению времени разработки продуктов и нервозности в коллективе.

    Что делать?


    Принцип

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

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

    Технические решения


    Итак, из технических решений в плане инфраструктуры у нас был OpenStack. Что он позволяет делать? Создавать всю необходимую инфраструктуру для проекта — виртуальную машину, DNS, IP и т.д. Но при этом всё-таки остаётся необходимость написания деплоя продуктов, организации мониторинга, логирования, обеспечения отказоустойчивости. Всё это остаётся в зоне ответственности команды разработки и отъедает у неё время.

    Платформа

    Мы решили провести эксперимент — кардинально сменить дистрибуцию приложений. Несколько небольших проектов, которые предстояло выпустить в ближайшее время, решили выпускать в Docker.

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

    Выбор пал на платформу для запуска web-приложений Deis. Как они сами о себе говорят — MicroPaaS или небольшой клон Heroku. Micro — потому что позволяет запускать только stateless-сервисы. Сейчас Deis больше не поддерживается, но нам он сослужил хорошую службу в плане адаптации людей к новым технологиям. Подробнее об этой платформе и её технических аспектах мои коллеги делали уже доклады здесь и здесь. Я лишь остановлюсь на том, что в итоге получили наши разработчики.

    Deis даёт 3 способа запустить приложение:

    1. Можно собрать Docker Image самому и отдать его Deis.
    2. Можно просто написать Dockerfile.
    3. Самый простой вариант — команда ‘git push deis master’. Он сам по Heroku buildpack собирает Docker Image.

    Сейчас уже вышла вторая версия Deis Workflow, которая работает на Kubernetes. Так что мы успешно проапгрейдились и сохранили user experience и дали нашим более технологически сложным проектам Kubernetes.

    Что мы получили с переходом на контейнерную инфраструктуру?

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

    Backing services

    Хорошо, у нас готово решение для приложений, но помимо самого кода есть ещё и базы данных. У многих проектов есть уникальные инстансы баз данных с разной степенью отказоустойчивости различных версий, которые требуют времени на поддержку. Здесь мы понимали, что счастье абсолютно для всех мы сделать не сможем. Увы. Мы взяли однотипные проекты — их было большинство — которым не требуется запись в несколько дата-центров. Для них подняли один большой кластер Postgres на железе и постепенно перевезли туда указанные проекты.

    Теперь разработчики могут просто деплоить код в платформу, реквестить базу у админов и всё. Однако, «могут» — это не значит, что будут делать обязательно.

    Распространение технологий

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

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

    1. Написали документацию — FAQ, Quick start.
    2. Провели серию внутренних TechTalks, на которых рассказывали, какие именно проблемы разработки мы решаем.
    3. В отдельных случаях садились непосредственно в команду и разбирали возникающие вопросы и проблемы.

    IaC, CI и вот это всё

    Внедрение новых инструментов не было бы возможным, если бы мы не воспользовались подходом IaC + CI. В своей работе мы придерживаемся следующих правил:

    1. Вся инфраструктура должна быть в Git.
    2. Обязательно должен быть CI.
    3. Непосредственно на сервера ходим только в крайних случаях, всё остальное через CI.
    4. Каждое изменение должно пройти ревью как минимум двух коллег.

    Процессные решения


    Входное и выходное ревью

    Для контроля попадания проектов в нашу новую инфраструктуру мы придумали следующий процесс — техническое ревью проектов.

    Он состоит их двух шагов.

    Входное ревью — на стадии проектирования, то есть как только команда придумала, как её сервис будет выглядеть.

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

    Выходное ревью — за несколько дней до предполагаемой даты релиза

    • Цель: проверить готовность продукта к релизу.
    • Комитет: Те же + техподдержка.
    • На выходе: дата релиза и список совместных действий.


    Прижилось не сразу, так как процесс был воспринят как сдача экзамена или защита проекта — сразу же возник вопрос «А почему я, собственно, это должен делать?»

    Мы ответили, что это не сдача экзамена какому-то конкретному отделу, а консультации со специалистами на тему того, как сделать продукт лучше и стабильнее.

    Это + ещё несколько удачных кейсов спасения проекта от оверинжиниринга + найденные неучтеные проблемы помогло техническому ревью всё-таки взлететь.

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

    Планирование

    Опять же, чтобы знать, что происходит и что будет происходить, мы ввели процесс планирования, которого раньше в команде системных администраторов не было. Сделали таким же, как и для остальных команд разработки. Таск-трекинг в Jira, месячные итерации, процентов 30-40 времени закладываем на непредвиденные таски. Так же мы участвуем во всех больших планированиях, где решается, над чем будет вестись работа в ближайшие полгода.

    On-call rules

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

    Дежурства


    По принципу очереди. Есть Primary On-call, есть Secondary On-call, есть все остальные. Каждую неделю происходит смена — Primary перемещается в конец очереди, Secondary становится Primary. Задача дежурного — в максимально короткие сроки восстановить работоспособность сервиса. Если же админ понимает, что проблема вне зоны его компетенции, он сообщает об этом разработчикам сервиса.

    Postmortem meeting или разбор полётов

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

    На этом митинге документируются следующие аспекты:

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

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

    Коммуникации

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

    Исходные данные у нас были такие:

    • Существующие каналы: Slack, почта, телефон, Mattermost.
    • Входящая в команду информация: проблемы, вопросы, фича-реквесты.
    • Исходящая информация: работы на сервисах.

    Сейчас процессы выстроены следующим образом:

    Быстрые вопросы и сообщение о проблемах — в открытый канал в Slack, чтобы могли все видеть.

    Если это реальная проблема, то вслед за сообщением обязательно заводится тикет в Jira. Фича-реквесты однозначно сразу идут в Jira.

    Для информирования команд о работах в инфраструктуре был написан свой сервис Status Board. В нём человек заводит ивент на сервис, в котором содержится информация: когда будут производиться работы, сколько сервис будет недоступен и т.д., а Status Board рассылает необходимые нотификации.

    Выводы


    Эксплуатация — неотъемлемая составляющая жизни сервиса. И начинать думать о том, как он будет работать в продакшне, нужно с самого начала работы над ним. Стабильность сервиса обеспечивают как инфраструктурные инженеры, так и разработчики, поэтому они должны уметь общаться — сидеть вместе, вместе разбирать проблемы, иметь прозрачные друг для друга процессы, разделять ответственность за инциденты, планировать работы. Не забудьте уделить время и создать удобный инструментарий для совместной работы. Напишите FAQ, проведите TechTalk, но убедитесь, что недопонимания не осталось.

    Подружить команду администраторов с командами разработчиков непросто, но однозначно игра стоит свеч.

    Видеоверсию статьи можно посмотреть на techno.2gis.ru
    2ГИС 222,94
    Карта города и справочник предприятий
    Поделиться публикацией
    Комментарии 17
    • 0
      Спасибо за статью!
      Есть ли команда, которая подружит команду CI с командами разработчиков и админов? :)
      Вы упомянули StatusBoard — это опенсорсный проект? Умеет ли он устанавливать maintenance mode для сервисов, чтобы не отсылать ложноположительные алерты или это просто список текущих работ, никак не влиящий на сервисы мониторинга?
      Присутствует ли механизм, который позволяет «в один клик» откатить неудачный релиз до старой версии (в т.ч. откат миграции базы, если она была)?
      • –1
        Привет!
        Отвечу по порядку.
        У нас нет отдельной такой команды. CI занимаются либо сами команды разработки сами, либо вместе с нами, в зависимости от ситуации.

        Про StatusBoard — мы работаем над тем, чтобы его заопенсорсить. С системами мониторинга он никак не связан, все эвенты по сервисам там устанавливаются вручную.

        Вы про какую разработку? Про ту, что внутри нашей команды IO или про продуктовые команды?
        • 0
          Когда я говорил про команду CI я имел в виду команду CD/DVD-IO. Это была шутка относительно того, что программисты и админы теперь дружат. но теперь нужно подружить со всеми и вас. Вероятно, нужна еще одна команда :)

          Когда говорил про откат, я имел в виду механизм версионирования образов с сервисами, предоставляемых вашей платформой. Фиксируется ли как-то версия кода с версией окружения.
          Т.е. например обнаружился баг, который появился в какой-то старой версии, есть ли *легкий* способ развернуть сервис с версией месячной давности, с необходимым окружением? Или всегда используются :latest образы, и никакого версионирования не подразумевается?
          • +1
            Посмею поправить Дениса, по поводу StatusBoard и попробовать ответить на ваши вопросы.

            StatusBoard уже связан с нашей системой метрик и алертинга — Prometheus.
            Когда мы создаём какое-нибудь событие в StatusBoard и указываем maintenance mode — он вешает silence(на конкретные лейблы метрик прометея, в зависимости от сервиса, на которое создано событие) на Prometheus AlertManager и нам не идут ложноположительные алерты.

            Про откат:
            Т.к. приложения в k8s собираются и деплоятся через CI/CD pipeline, то каждый MR, обычно, порождает создание отдельного Docker image, который хранится во внутреннем Docker Registry и может быть задеплоен в какой-нибудь из кластеров k8s. Все образы версионируются(именами тегов или SHA коммита).

            При необходимости отката — можно просто запустить необходимую job'у из pipeline и она установит требуемую версию приложения в нужный кластер. Даже если образ уже удалён из Docker Registry — его всегда можно пересобрать и запушить/задеплоить вновь.
      • +4
        Если убрать конкретные примеры реализации, то как в поговоре «все новое хорошо забытое старое» в данном случае годов 1975-ых. Во всяком случае я сейчас читаю «Мифический человеко-месяц или как создаются программные системы» (переиздание 1995) и вижу проблемы, которые уже были описаны в этой книге, и собственно говоря решения по сути те же самые.
        Создается ощущение, что народ с 90-х годов в принципе ничего нового и не придумал, а только забывает как пользоваться старыми знаниями. При этом наступает на те же грабли с регулярной периодичностью и описывает давно известные решения.
        • 0
          И для решения старых проблем, пишем новый слой
        • 0
          Перекладывание обязанностей вообще вечная проблема, даже внутри каждого из отделов. Не совсем понял насколько вам удалось решить именно ее? Если несколько человек работает на сервисом, который упал, кому из программистов позвонит дежурный админ? А если тот кому он позвонит считает, что за этот факап ответственен другой член команды, он будет сам чинить или позвонит другому программисту и переведет стрелку на него?
          Картинка в тему

          • 0
            Весьма адекватная картинка, нужно только улыбочки ребятам справа стереть.
            Вёдер-то всего два. Что должны делать улыбающиеся ребята — бросаться ладошками вычерпывать, мешая при этом ребятам с вёдрами? Нет, здесь всё грамотно, сидят и создают противовес, не поддаваясь панике. Глядишь и дойдёт до них, что нужно брешь параллельно заделывать, потому что до ребят с вёдрами это никак не доходит, некогда им думать.
            • 0
              С позволения honig отвечу: в каждой команде есть ответственный за проект. Он принимает на себя все вызовы, разбирается с причинами и дальше, если считает нужным, подключает других людей из команды.

              Достаточно легко можно понять (?) проблема на стороне проекта или на стороне инфраструктуры. Когда это нельзя понять, садимся парами человек из команды и человек от админов и дальше разбираемся.
            • 0

              image
              Справа джун, слева сеньор.

              • 0
                Кажется, вы изобрели Knowledge Transfer Process.
                Не вдаваясь в детали — примерно так давно уже рекомендуют делать в куче «лучших практик». Однако, в недавнем прошлом произошёл крен в сторону веса мнения разработки и имеем что имеем.
                • 0

                  А что у вас сталось с Deis'ом в итоге? Вы всё ещё используете его или уже с него съехали на Kubernetes + инструментарий?


                  Мы тоже на него прыгнули и хорошо жили (всё нужное из коробки: и поскейлить и лимиты задать), пока его не убила купила Microsoft. Теперь думаем, как съезжать. Рассматриваем просто голый Kubernetes + Helm.

                  • 0
                    Да, в итоге съехали. Больше у нас его нет. Сначала был просто Deis, потом Deis Workflow, а с него уже на Kubernetes.
                    • 0

                      Спасибо! А можете рассказать, как мигрировали приложения с Deis Workflow на Kubernetes? Мы рассматриваем путь писания вручную манифестов с помощью Helm и Keel, но пока наши инсталляции Deis переживают апгрейды нижележащих кластеров Kubernetes, то всё чёт откладываем.

                      • +2
                        Как один из инженеров в команде Дениса — попробую ответить на вопрос.

                        У нас не было необходимости мигрировать все приложения сразу. Мы растянули этот процесс на несколько месяцев.
                        Миграцию приложений проводили сами разработчики приложений. Для них мы подготовили:
                        • Несколько докладов внутри компании.
                        • Документацию. Как, зачем, особенности инсталляции.
                        • Базовый пример, на котором можно поиграться с Kubernetes и взять его за основу для деплоя приложения.
                        • Утилиту для работы с манифестами и их деплоя в Kubernetes.
                        • Нашу поддержку на пути переноса приложений :)

                        В целом, процесс прошел довольно хорошо. Если при переносе первого приложения в k8s вопросы ещё были, то дальше разработчики уже переносили всё сами, иногда присылая нам MR на ревью каких-то сложных моментов.
                        Нам оставалось только докидывать ресурсы в k8s namespace'ы команд, чтобы туда заезжали новые приложения.

                        PS Helm мы попробовали, но он не зашел легко и быстро. Особенно при работе с несколькими инсталляциями k8s(изначально сами пробовали деплоить DEIS через Helm, прежде чем рассказывать о нём внутри компании).
                        Собственная утилита для деплоя в k8s формирует финальные манифесты из jinja2 шаблонов манифестов и файла конфигурации. Выглядит легко и хорошо встраивается в наш CI/CD процесс.
                  • 0
                    Почему отказались от mattermost?
                    • 0
                      Слово «инциденты» еще долго будет будоражить умы менеджеров. Они со временем перестанут понимать, что им больше нужно: новые решения или отказоустойчивость. Есть системы, где второе приоритетнее, а новые «вкусности» не дают такого существенного выхлопа. И происходит то, что я наблюдаю во многих конторах: чтобы с инцидентами можно было разобраться быстро нужно сильно бить палкой и набирать «ноуледж бейз» по устранению. Так чтобы не 2 часа, и не 30 минут, а чтобы за 5 минут устранялся сбой. И тут начинается обратный процесс: система костенеет, бюрократические процессы становятся бессмысленными, а знания по быстрому устранению инцидентов становятся так же громоздки, как и большая советская энциклопедия. Это не мое личное нытье. Это то, что я наблюдал и наблюдаю в ряде организаций за последние лет 10 и мое мнение разделяют многие. IT становится в таких организациях «мертвым» и неподвижным. Вирусы-шифровальщики весной прошлого года только обнажили эти проблемы.

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

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

                      Самое читаемое