Comments 17
Спасибо за статью!
Есть ли команда, которая подружит команду CI с командами разработчиков и админов? :)
Вы упомянули StatusBoard — это опенсорсный проект? Умеет ли он устанавливать maintenance mode для сервисов, чтобы не отсылать ложноположительные алерты или это просто список текущих работ, никак не влиящий на сервисы мониторинга?
Присутствует ли механизм, который позволяет «в один клик» откатить неудачный релиз до старой версии (в т.ч. откат миграции базы, если она была)?
Есть ли команда, которая подружит команду CI с командами разработчиков и админов? :)
Вы упомянули StatusBoard — это опенсорсный проект? Умеет ли он устанавливать maintenance mode для сервисов, чтобы не отсылать ложноположительные алерты или это просто список текущих работ, никак не влиящий на сервисы мониторинга?
Присутствует ли механизм, который позволяет «в один клик» откатить неудачный релиз до старой версии (в т.ч. откат миграции базы, если она была)?
Привет!
Отвечу по порядку.
У нас нет отдельной такой команды. CI занимаются либо сами команды разработки сами, либо вместе с нами, в зависимости от ситуации.
Про StatusBoard — мы работаем над тем, чтобы его заопенсорсить. С системами мониторинга он никак не связан, все эвенты по сервисам там устанавливаются вручную.
Вы про какую разработку? Про ту, что внутри нашей команды IO или про продуктовые команды?
Отвечу по порядку.
У нас нет отдельной такой команды. CI занимаются либо сами команды разработки сами, либо вместе с нами, в зависимости от ситуации.
Про StatusBoard — мы работаем над тем, чтобы его заопенсорсить. С системами мониторинга он никак не связан, все эвенты по сервисам там устанавливаются вручную.
Вы про какую разработку? Про ту, что внутри нашей команды IO или про продуктовые команды?
Когда я говорил про команду CI я имел в виду команду CD/DVD-IO. Это была шутка относительно того, что программисты и админы теперь дружат. но теперь нужно подружить со всеми и вас. Вероятно, нужна еще одна команда :)
Когда говорил про откат, я имел в виду механизм версионирования образов с сервисами, предоставляемых вашей платформой. Фиксируется ли как-то версия кода с версией окружения.
Т.е. например обнаружился баг, который появился в какой-то старой версии, есть ли *легкий* способ развернуть сервис с версией месячной давности, с необходимым окружением? Или всегда используются :latest образы, и никакого версионирования не подразумевается?
Когда говорил про откат, я имел в виду механизм версионирования образов с сервисами, предоставляемых вашей платформой. Фиксируется ли как-то версия кода с версией окружения.
Т.е. например обнаружился баг, который появился в какой-то старой версии, есть ли *легкий* способ развернуть сервис с версией месячной давности, с необходимым окружением? Или всегда используются :latest образы, и никакого версионирования не подразумевается?
Посмею поправить Дениса, по поводу StatusBoard и попробовать ответить на ваши вопросы.
StatusBoard уже связан с нашей системой метрик и алертинга — Prometheus.
Когда мы создаём какое-нибудь событие в StatusBoard и указываем maintenance mode — он вешает silence(на конкретные лейблы метрик прометея, в зависимости от сервиса, на которое создано событие) на Prometheus AlertManager и нам не идут ложноположительные алерты.
Про откат:
Т.к. приложения в k8s собираются и деплоятся через CI/CD pipeline, то каждый MR, обычно, порождает создание отдельного Docker image, который хранится во внутреннем Docker Registry и может быть задеплоен в какой-нибудь из кластеров k8s. Все образы версионируются(именами тегов или SHA коммита).
При необходимости отката — можно просто запустить необходимую job'у из pipeline и она установит требуемую версию приложения в нужный кластер. Даже если образ уже удалён из Docker Registry — его всегда можно пересобрать и запушить/задеплоить вновь.
StatusBoard уже связан с нашей системой метрик и алертинга — Prometheus.
Когда мы создаём какое-нибудь событие в StatusBoard и указываем maintenance mode — он вешает silence(на конкретные лейблы метрик прометея, в зависимости от сервиса, на которое создано событие) на Prometheus AlertManager и нам не идут ложноположительные алерты.
Про откат:
Т.к. приложения в k8s собираются и деплоятся через CI/CD pipeline, то каждый MR, обычно, порождает создание отдельного Docker image, который хранится во внутреннем Docker Registry и может быть задеплоен в какой-нибудь из кластеров k8s. Все образы версионируются(именами тегов или SHA коммита).
При необходимости отката — можно просто запустить необходимую job'у из pipeline и она установит требуемую версию приложения в нужный кластер. Даже если образ уже удалён из Docker Registry — его всегда можно пересобрать и запушить/задеплоить вновь.
UFO just landed and posted this here
Перекладывание обязанностей вообще вечная проблема, даже внутри каждого из отделов. Не совсем понял насколько вам удалось решить именно ее? Если несколько человек работает на сервисом, который упал, кому из программистов позвонит дежурный админ? А если тот кому он позвонит считает, что за этот факап ответственен другой член команды, он будет сам чинить или позвонит другому программисту и переведет стрелку на него?
Картинка в тему
Весьма адекватная картинка, нужно только улыбочки ребятам справа стереть.
Вёдер-то всего два. Что должны делать улыбающиеся ребята — бросаться ладошками вычерпывать, мешая при этом ребятам с вёдрами? Нет, здесь всё грамотно, сидят и создают противовес, не поддаваясь панике. Глядишь и дойдёт до них, что нужно брешь параллельно заделывать, потому что до ребят с вёдрами это никак не доходит, некогда им думать.
Вёдер-то всего два. Что должны делать улыбающиеся ребята — бросаться ладошками вычерпывать, мешая при этом ребятам с вёдрами? Нет, здесь всё грамотно, сидят и создают противовес, не поддаваясь панике. Глядишь и дойдёт до них, что нужно брешь параллельно заделывать, потому что до ребят с вёдрами это никак не доходит, некогда им думать.
С позволения honig отвечу: в каждой команде есть ответственный за проект. Он принимает на себя все вызовы, разбирается с причинами и дальше, если считает нужным, подключает других людей из команды.
Достаточно легко можно понять (?) проблема на стороне проекта или на стороне инфраструктуры. Когда это нельзя понять, садимся парами человек из команды и человек от админов и дальше разбираемся.
Достаточно легко можно понять (?) проблема на стороне проекта или на стороне инфраструктуры. Когда это нельзя понять, садимся парами человек из команды и человек от админов и дальше разбираемся.
Справа джун, слева сеньор.
Кажется, вы изобрели Knowledge Transfer Process.
Не вдаваясь в детали — примерно так давно уже рекомендуют делать в куче «лучших практик». Однако, в недавнем прошлом произошёл крен в сторону веса мнения разработки и имеем что имеем.
Не вдаваясь в детали — примерно так давно уже рекомендуют делать в куче «лучших практик». Однако, в недавнем прошлом произошёл крен в сторону веса мнения разработки и имеем что имеем.
А что у вас сталось с Deis'ом в итоге? Вы всё ещё используете его или уже с него съехали на Kubernetes + инструментарий?
Мы тоже на него прыгнули и хорошо жили (всё нужное из коробки: и поскейлить и лимиты задать), пока его не убила купила Microsoft. Теперь думаем, как съезжать. Рассматриваем просто голый Kubernetes + Helm.
Да, в итоге съехали. Больше у нас его нет. Сначала был просто Deis, потом Deis Workflow, а с него уже на Kubernetes.
Спасибо! А можете рассказать, как мигрировали приложения с Deis Workflow на Kubernetes? Мы рассматриваем путь писания вручную манифестов с помощью Helm и Keel, но пока наши инсталляции Deis переживают апгрейды нижележащих кластеров Kubernetes, то всё чёт откладываем.
Как один из инженеров в команде Дениса — попробую ответить на вопрос.
У нас не было необходимости мигрировать все приложения сразу. Мы растянули этот процесс на несколько месяцев.
Миграцию приложений проводили сами разработчики приложений. Для них мы подготовили:
В целом, процесс прошел довольно хорошо. Если при переносе первого приложения в k8s вопросы ещё были, то дальше разработчики уже переносили всё сами, иногда присылая нам MR на ревью каких-то сложных моментов.
Нам оставалось только докидывать ресурсы в k8s namespace'ы команд, чтобы туда заезжали новые приложения.
PS Helm мы попробовали, но он не зашел легко и быстро. Особенно при работе с несколькими инсталляциями k8s(изначально сами пробовали деплоить DEIS через Helm, прежде чем рассказывать о нём внутри компании).
Собственная утилита для деплоя в k8s формирует финальные манифесты из jinja2 шаблонов манифестов и файла конфигурации. Выглядит легко и хорошо встраивается в наш CI/CD процесс.
У нас не было необходимости мигрировать все приложения сразу. Мы растянули этот процесс на несколько месяцев.
Миграцию приложений проводили сами разработчики приложений. Для них мы подготовили:
- Несколько докладов внутри компании.
- Документацию. Как, зачем, особенности инсталляции.
- Базовый пример, на котором можно поиграться с Kubernetes и взять его за основу для деплоя приложения.
- Утилиту для работы с манифестами и их деплоя в Kubernetes.
- Нашу поддержку на пути переноса приложений :)
В целом, процесс прошел довольно хорошо. Если при переносе первого приложения в k8s вопросы ещё были, то дальше разработчики уже переносили всё сами, иногда присылая нам MR на ревью каких-то сложных моментов.
Нам оставалось только докидывать ресурсы в k8s namespace'ы команд, чтобы туда заезжали новые приложения.
PS Helm мы попробовали, но он не зашел легко и быстро. Особенно при работе с несколькими инсталляциями k8s(изначально сами пробовали деплоить DEIS через Helm, прежде чем рассказывать о нём внутри компании).
Собственная утилита для деплоя в k8s формирует финальные манифесты из jinja2 шаблонов манифестов и файла конфигурации. Выглядит легко и хорошо встраивается в наш CI/CD процесс.
Почему отказались от mattermost?
Слово «инциденты» еще долго будет будоражить умы менеджеров. Они со временем перестанут понимать, что им больше нужно: новые решения или отказоустойчивость. Есть системы, где второе приоритетнее, а новые «вкусности» не дают такого существенного выхлопа. И происходит то, что я наблюдаю во многих конторах: чтобы с инцидентами можно было разобраться быстро нужно сильно бить палкой и набирать «ноуледж бейз» по устранению. Так чтобы не 2 часа, и не 30 минут, а чтобы за 5 минут устранялся сбой. И тут начинается обратный процесс: система костенеет, бюрократические процессы становятся бессмысленными, а знания по быстрому устранению инцидентов становятся так же громоздки, как и большая советская энциклопедия. Это не мое личное нытье. Это то, что я наблюдал и наблюдаю в ряде организаций за последние лет 10 и мое мнение разделяют многие. IT становится в таких организациях «мертвым» и неподвижным. Вирусы-шифровальщики весной прошлого года только обнажили эти проблемы.
Удачи проекту 2GIS, надеюсь, вы все также будете живы и динамично развиваться. Только не перегните палку с бюрократией и не постройте сами себе пирамиду, в которой сами же себя и похороните.
Удачи проекту 2GIS, надеюсь, вы все также будете живы и динамично развиваться. Только не перегните палку с бюрократией и не постройте сами себе пирамиду, в которой сами же себя и похороните.
Sign up to leave a comment.
Как подружить команду админов с командами разработки?