#DevOpsConf Константин Ожерельев из Ozon. DevOps для 1C-приложений. Если кратко, то доклад был о том, что DevOps для 1С - есть. Нужен ли он - вопрос к бизнесу, у них создание DevOps инициировано требованиями аудиторов по устойчивости процессов обновления софта для публичной компании. Но эффект не ограничивался удовлетворением аудиторов, реально получена устойчивость прода за счет автоматизации доставки обновлений и разработки автотестов, выполняемых в конвейере доставки.

И в докладе были подробности - за счет каких именно средств это достигается, и как организовано. Конвейер доставки есть для обоих вариантов разработки: EDT + Git и Конфигуратор + Хранилище (собственная система контроля версий от 1С). Вариант Конфигуратор + Git формально существует, но фактически рабочим не является, поэтому не рассматриваем. Стартом для процесса DevOps в обоих случаях служит Git, просто при использовании хранилища синхронизация с Git обеспечивается отдельной утилитой GitSync. При этом не получается использовать feature branch, разработка ведется в единой dev-ветке, а чтобы иметь возможность исключать функционал отдельных фич из обновления используют стандартный паттерн feature toggle. А дальше все стандартно: dev - test - release со своими средами развертывания и тестирования. Для того, чтобы в конвейере процессе сборки выполнять скрипты, в том числе специфичные для 1С используется OneScript - продукт, который позволяет писать скрипты на языке 1С, исполняемые вне среды, работает поверх .Net и .NetCore. Смысл OneScript в том, что язык получается знаком 1С-разработчиком и их может поддерживать сама команда 1С. В мире 1С принято, что развертывание поддерживает команда, а не отдельные devops. Об остальных средствах - смотри презентацию на слайдах.

На этом про доклад - все, а от себя отмечу, что первый доклад про реализацию CI/CD для 1С я слышал уже лет семь назад, другое дело, что сам вендор не торопится с полноценной поддержкой, и разработчики консервативны. Но технические возможности - есть и они совершенствуются.

#DevOpsConf Владимир Утратенко из Uzum Market. Древние свитки CI/CD: смыслы, которые мы потеряли. Это был доклад за все хорошее против всего плохого. О том, что не взирая на лучшие практики, многие по-прежнему работают по-старому. Хранят код, конфигурации, тесты и описание конвейера в разных репозиториях с непонятной синхронизацией, а кое-что может лежать вообще вне репозиториев. Что запуск тестов, особенно нагрузочных, и разворачивание среды для этого может быть магией, доступной отдельному инженеру. Что патчи могут собираться вручную и пересылаться по почте. А если тесты запускаются автоматом и падают, то разработчики могут их отключать, а не чинить, или просто игнорировать. Что никакой integration в рамках CI не происходит, а просто сборка отдельного продукта. А реальный continuous delivery - вообще редкий зверь, потому что на пути к проду часто стоит ручной регресс, который делают много месяцев. Что несмотря на рекомендации делать частые коммиты и мержить ветки, разработчики накапливают изменения несколько месяцев в стремлении сделать все-все-все, а потом мерж фичи занимает несколько недель и приводит к переписыванию заново, потому что этот же код активно правили. И вообще, CI/CD для части людей превратились в buzzword, смысла которого они не понимают. И все это - с одобрением аудитории, которой эти проблемы известны.

К сожалению, от того, что людям лишний раз напоминаешь про хорошие практики, они начинают их использовать. Сколько человек по утрам делают зарядку или ходят в фитнес? А скольких можно побудить к этому, рассказав про ожирении и разные проблемы, которые ждут в будущем, или даже в настоящем? Увы! Так что тут, по-хорошему, нужен серьезный разбор причин и способов работы, включая методы изменения привычек и культуры - ведь проблема-то в них. Впрочем, доклад был хороший и с юмором, так что, не исключаю, что, слушая его, участники увидят на свой портрет в сатирическом зеркале и решат измениться.

#DevOpsConf Сергей Реусин из СберМаркет. Инженерия устойчивости как основной инструмент выживания вашей организации: история, подходы и примеры внедрения. Это был доклад первого дня, на который я забыл опубликовать конспект. Доклад концептуальный, он принципиально меняет точку зрения на ошибки и сбои: мы не стремимся уменьшить их до нуля, увеличив время между ошибками, а определяем допустимую зону и фокусируемся на способах быстрого восстановления в случае сбоев. И это дает устойчивость системы в целом. Это подход resilience engineering, основанного на работах ряда исследователей. В их числе Richard Cook, на работы которого Сергей много ссылался. Предлагается определить зону сбоев, которая является приемлемой, и держаться в ней, в том числе - за счет быстрого восстановления, а не только за счет снижения количества ошибок. Подробнее про подход можно посмотреть в stella.report. Идея состоит в том, что мы предусматриваем универсальные способы восстановления, которые сработают в широком спектре ситуаций. И что наоборот, частные способы могут перестать работать. Например, практика канареечных релизов, при которой новые фичи сначала предоставляются малому числу пользователей для проверки работоспособности, могут перестать выполнять свою функцию, если разработчики начнут применять feature toggle, включаемые сразу и для всех, а не постепенно - сначала релиз раскатят на всех, а потом этот флаг возьмут и включат, и проблемы посыпятся.

Это - интересный взгляд. Потому что в погоне за высокой доступностью часто применяют сложные и дорогие технические решения, и несут неоправданные затраты. В то время как альтернативные способы могут быть гораздо легче. Я тут поделюсь своим опытом. В свое время мы проектировали систему розничного магазина для Спортмастера, и спросили их - а могут же быть разные проблемы с работой системы: электричество, сеть и так далее. А они рассказали, что на этот случай есть план-Б: автономный сканер ШК (ТСД), в который загружен каталог с актуальными ценами, и который умеет фиксировать продажи, сканируя ШК, и простая дешевая касса, на которой можно пробивать чеки в автономном режиме и которая работает от обычного бесперебойника, и в результате при любых проблемах магазин 6 часов способен вести продажи. Что позволяет не слишком заморачиваться с доступностью именно информационной системы. И аналогичный подход у них дальше применялся при переходе на централизованную систему лояльности: при сбоях интернета владельцам карт предоставлялась специальная скидка, размер которой их обычно удовлетворял, так что проблемы не вызывали негатива. И как побочный эффект такое решение снижало требования к доступности централизованной системы лояльности - план-Б со специальной скидкой работал и в этом случае.

Один из антипаттернов наблюдаемости — это Wall of Dashboard. Как говорится, стоит стена высокая, а что за ней — непонятно. Как правило, куча дашбордов — это куча проблем, которые приводят к информационной перегрузке, потере фокуса и сложности восприятия. А что самое грустное, довольно сложно найти и исследовать какой-то инцидент.
⠀
Если вы, глядя на свой дашборд, не понимаете, работает ваша система или нет, стоит обратить внимание на статью: https://habr.com/ru/companies/vk/articles/805029/
⠀
SRE в VK Рекламе Кирилл Борисов расскажет, как организовать мониторинг, упрощающий нахождение проблем и не перегруженный лишней информацией.

Друзья, у нас открыта продажа видеозаписей докладов DevOpsConf 2024 🙌
⠀
В плейлисте 80+ докладов. Спикеры поделились опытом: как крупные компании строят свои платформы и как можно реализовать подобный опыт в вашей компании; как создаются надёжные системы в крупных компаниях; что делать, если вы работаете с одной из акул рынка, но ограничены в выборе инструментов; и многое другое. А ещё посмотрели, что нового в отрасли, поговорили о новых фичах и утилитах. Обсудили, как использовать ИИ в эксплуатации. Рассмотрели ChatGPT без хайпа: только практические кейсы.
⠀
✅ Купить видеозаписи можно на сайте
⠀
⭐ Топ-5 докладов:

1) Как мы вырастили отказоустойчивость Яндекс Go. Денис Исаев (Яндекс)

2) Kafka. Деградировавший кластер, или 168 часов траблшутинга. Максим Ванюшкин (Тинькофф)

3) Hardening Jenkins: как подать блюдо, чтобы оставили чаевые. Лев Хакимов (Wildberries)

4) Платформа — это продукт. А что, вообще, такое — продукт? Виктор Попов (Samokat.tech)

5) JumpStart для новых сервисов. Владимир Дроздецкий (Magnit Tech)

Друзья, у нас готов отчетный ролик с DevOpsConf 2024! Посмотрите, вы услышите отзывы участников, чем отличается DevOpsConf от других конференций, почувствуете энергию и атмосферу на площадке 😉. Спасибо всем участникам, вы крутые!

До встречи на DevOpsConf 2025 🙌

Запись доклада «K8s-операторы для СУБД: быстро готовим сотни стейджей» Александра Качкуркина с DevOpsConf 2024

Как штамповать базы данных (и не только) для каждого изолированного окружения в тестинге и, как следствие, ускорить time-to-market в разы? Об этом в докладе Александра

Смотреть здесь: https://www.youtube.com/watch?v=JtURJCCT8eU

После просмотра видео пишите вопросы в комментарии к этому посту, а в четверг-пятницу (25-26 апреля) Александр на все ответит. Ставьте тег #ВопросCпикеру

Вы тоже не любите писать бойлерплейт-код?
⠀
Хочется, чтобы большое количество связей и однотипных переиспользуемых пакетов в микросервисных приложениях как-то генерировалось само. Но генераторов микросервисов не так уж много.
⠀
Разработчики из компании Last.Backend поделятся, как сделали свой генератор микросервисов и с какими сложностями столкнулись. Расскажут, как использовали Protobuf, Uberfx, писали хуки, рефлектили всё, что можно, стандартизировали работу с логами, конфигами и процесс сборки и деплоя.
⠀
Подробности в статье: https://habr.com/ru/companies/oleg-bunin/articles/810155/

Запись доклада «Древние свитки CI/CD: смыслы, которые мы потеряли» Владимира Утратенко с DevOpsConf 2024

Доклад для тех, кто считает, что CI/CD — это просто написать пачку YAML'ов. Это возврат к рассказу о базовых вещах — что такое и зачем нужен CI, что такое и зачем нужен CD. И да, это не просто сборка кода при создании pull request и деплой по кнопке, а много чего, кроме этого.

Смотреть видео: https://youtu.be/F4nC3diZo1M?si=JnlHD4Und3AC6xqM

Презентация доклада

После просмотра пишите вопросы в комментарии к этому посту, а в четверг-пятницу (16-17 мая) Владимир на все ответит. Ставьте тег #ВопросCпикеру

Запись доклада «Логи: как EFK нас довел... до Vector и Clickhouse» Дмитрия Синявского с DevOpsConf 2024

Альтернативный взгляд на системы логирования. Стек Vector. dev и ClickHouse — это только лишь хайп или реальное решение насущных проблем? Дмитрий подробно разобрал плюсы и минусы этого решения. А дальше вы сможете принять решение, стоит ли мигрировать на него.

https://youtu.be/4Xu-DaGkldU

Скачать презентацию доклада можно здесь

Ещё у Дмитрия есть статья на тему доклада, прочитать можно здесь

Друзья, после просмотра записи пишите вопросы в комментарии к этому посту, а в четверг-пятницу (23-24 мая) Дмитрий на все ответит. Ставьте тег #ВопросCпикеру

Kubernetes сейчас запускают везде! Даже в критических информационных инфраструктурах, где с Интернетом очень плохо или его нет совсем.
⠀
Поэтому поговорим про установку самого популярного решения для запуска контейнеров там, где не ступал ни один пакет из публичной сети.
⠀
Лид Kubernetes-платформы Deckhouse в компании Флант Максим Набоких покажет целевую схему закрытого контура и расскажет нюансы работы инструментов для создания безопасной среды: https://habr.com/ru/companies/oleg-bunin/articles/798317/

Запись доклада «Как внедрить телеметрию в on-premise-инфраструктуре» Алексея Колоскова с DevOpsConf 2024

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

Смотреть видео: https://youtu.be/Ei2hmvwqJuo?si=zgHlA2MqKfho_rXE

Скачать презентацию доклада можно здесь

После просмотра видео пишите вопросы в комментарии к этому посту, а в четверг-пятницу (30-31 мая) Алексей на все ответит. Не забывайте ставить тег #ВопросCпикеру

Запись доклада «Неизбежность, или Как приучить Devops-инженеров к проектированию» Екатерины Лысенко с DevOpsConf 2024

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

https://youtu.be/BTdfWGL33sw

Скачать презентацию доклада можно здесь: https://disk.yandex.ru/i/wzBAj7vtAUJdPQ

После просмотра пишите вопросы с тегом #ВопросCпикеру в комментарии к этому посту и в четверг-пятницу (6-7 июня) Екатерина лично на все ответит.

Запись доклада «Envoy Proxy — один за всех Load Balancer» Дмитрия Самохвалова с DevOpsConf 2024

Доклад о переходе с NGINX, HAProxy на Envoy из-за ограничений старых систем для динамической конфигурации. Освещается, как Envoy улучшает быстрые обновления, его интеграция через envoy-control-plane, успешное внедрение, рекомендации и лайфхаки для эффективного перехода.

https://youtu.be/tJt7BjERM4M?si=B-d4wX_WlrtHzjA0

Скачать презентацию доклада можно здесь

После просмотра пишите вопросы с тегом #ВопросCпикеру в комментарии к этому посту и в четверг-пятницу (13-14 июня) Дмитрий лично на все ответит.

Это история про то, что такое CI/CD. Про то, что это не просто написать пачку YAML'ов или собрать код при создании pull request и деплой по кнопке, а много чего ещё.

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

Head of Infrastructure and Security в Uzum Market Владимир Утратенко провёл антинаучное исследование на нерелевантной выборке, но вывод интересный: 25 из 30 DevOps-инженеров на собеседовании путают CI и CD.

✅ Подробности в статье: https://habr.com/ru/companies/oleg-bunin/articles/821867/