Опрос выявляет неожиданное. Первый опрос показал, что в красной зоне линтер, которым сами гордились: оказалось, что пользователи недовольны, потому что он тормозит. И они запустили проект ускорения. Но они бы никогда не поняли причину красной зоны, если бы не было окошка в конце - именно туда писали, почему не довольны. Следующий опрос, в красной доне БД, это ожидаемо, потмоу что некоторое время назад сделали zero-trust политики, стало неудобнее. Но оказалось, что только половина в zero-trust, а вторая половина - flow, если что-то не сработало - неясно как разбираться. И эту часть можно решить, сделали проект с dba.

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

Опросы - просты, можно дать навигацию, пользователи получют фичи. Недостатки: низкая конверсия и люди устают. Раз в квартал - это часто, стали делать раз в полгода. А еще helicopter view от опросов - ограничен. Надо делать follow up и custdev

А дальше они хотят Instant feedback - ловушки для негатива для ключевых customer journey. Не длинный опрос, а точечная оценка и быстрый feedback. По свежему опыту использования фичи. Но есть слабые места: есть CLI-точка входа, там 800 пользователей - там нельзя показать форму, есть долгий customer journey - когда спрашивать? И можно задолбать. Поэтому присылают запрос в mattermost - оцените CJM, и не чаще, чем раз в неделю.

В отчетах на вопросы звучала популярная тема: ваша платформа скрывает внутренность сборки от разработчиков, и они перестают понимать, как оно устроено, не учатся думать. Ответ - понятен: платформа убирает рутинную часть и это дает реальный эффект на скорости разработки, который перевешивает побочные эффекты. А я тут могу заметить, что аналогичные вопросы я слышал по другим поводам. Первый раз - когда появлялись реляционные базы данных, с которыми ты работаешь на SQL, не заботясь о хранении: как же так, разработчик не будет думать про эффективность запросов (я еще работал на dbase без sql). А второй раз - с появлением Java и C#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.

В 15:00 в Зале «Шанхай» вас ждёт Александр Титов (Экспресс 42) на круглый стол «Облака, вендор или делать все самому? Как строить Platform Engineering в компании»

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

🖐 Ловите анонс докладов, которые начнутся в 15:50
⠀
🔸 Зал «Конгресс-холл». Анна Гобрусева (Ozon) «Alerts-Registry. Одно место управления алертами»

Доклад для тех, кто уже построил у себя систему алертинга и упёрся в проблемы её сопровождения. Как определять/удалять неактуальные алерты, как их версионировать, etc...
⠀
🔹 Зал «Кейптаун». Александр Бычук (VK, VK Tech) «Open Source как часть R&D»

Мы тут ждём рассказ про то, сколько на самом деле стоит свободное ПО и как принимать решение о том, покупать или брать бесплатное и допиливать.
⠀
🔸 Зал «Сингапур». Михаил Марченко (билайн) «Путь от "хаоса" к облачной инфраструктуре»

Доклад про развитие и эволюцию инфраструктуры и внутренней разработки в большом телеком-операторе, про переход к внутреннему облаку, автоматизацию и предоставление платформенных сервисов.
⠀
🔹 Зал «Уфа». Константин Ожерельев (Ozon) «DevOps для 1C-приложений»

Превосходный обзорный доклад про DevOps и 1С. Как и зачем совместить, на первый взгляд, несовместимое. Рекомендуется, если вы DevOps и хотите расширить кругозор.

🔸 Зал «Дели+Калькутта». Георгий Абрамов (АО "СберТех") «CUE — лучшая альтернатива для работы с манифестами K8s»

Если вы испытываете трудности с использованием Yaml, Helm или Kustomize, то этот доклад о CUE будет вам полезен. В нем рассказывается о базовых принципах работы с CUE и о том, как начать использовать этот инструмент.
⠀
🔹 Зал «Пекин». Сергей Губарев (Cloud.ru) «Подготовка SecChamp’ов: как обработать все проблемы и не сойти с ума»

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

В 16:20 приходите в Зал «Шанхай» на мастер-класс от Ирины Николаевой (Raft) «Локальные LLM: как с легкостью применять большие языковые модели в ежедневных задачах»
⠀
Искусственный интеллект ближе, чем кажется! Присоединяйтесь, чтобы узнать, как использовать открытые локальные LLM в повседневной работе на твоём обычном ПК. Откроете завесы над миром LLM-моделей и попробуете их в бою для анализа ошибок и поиска решений, соблюдая лицензии и требования к оборудованию.
⠀
✋ Обратите внимание, что на данный мастер-класс необходим свой ноутбук.

✋ Друзья, если вы были на докладе Антона Алексеева и по техническим причинам у вас не получилось проголосовать за доклад, пройдите, пожалуйста, по ссылке, чтобы поставить оценку:

https://conf.ontico.ru/online/dc2024/details/5393175

🖐 Дорогие участники, в 17:00 ждём вас на последних докладах DevOpsConf 2024
⠀
🔸 Зал «Конгресс-холл». Кирилл Ильин и Артем Поддубный (СберАвто) «Все как код»

Из доклада вы узнаете, как сделать архитектуру ваших сервисов в виде кода и как на это наложить техники из матрицы MITRE ATT&CK для оценки безопасности продуктов.
⠀
🔹 Зал «Кейптаун». Алексей Шкирмановский (Vi.Tech) «Переходим на мульти-ЦОД-архитектуру»

Рассказ о том, когда архитектура решения с двумя ЦОДами может не подойти и почему. И что надо учесть вашему бизнесу и вашим сервисам, если захотелось жить в трёх.
⠀
🔸 Зал «Сингапур». Максим Бочкарев (ЕВРАЗ) «DevOps в металлургии, история про большие и сложные задачи IТ в производственной отрасли»

Из доклада вы узнаете про пройденный путь и развитие DevOps в реальном секторе, опыт взаимодействия с консультантами и интеграторами, внедрение и развитие Azure DevOps, стандартизацию, автоматизацию проектов и процессов в разработке и эксплуатации.
⠀
🔹 Зал «Уфа». Максим Нифонтов (Programming Store) «DevOps приходит в 1С»

Доклад содержит разбор инструментов для построения DevOps в 1С, но культура DevOps забыта тоже не будет. Если вы работаете где-то рядом с реальным сектором и хотите помочь коллегам улучшить жизнь в 1С, то обязательно приходите!

🔸 Зал «Дели+Калькутта». Илья Лесиков (Флант) «От доработки Helm к разработке Nelm: эволюция развертывания в werf»

Helm стал стандартом упаковки приложений для Kubernetes. Но так ли он хорош, как кажется на первый взгляд? Какие проблемы есть в Helm и как их решить? Nelm — движок развертывания в werf, в будущем — drop-in-замена Helm, решит многие проблемы Helm и добавит недостающие ему возможности.
⠀
🔹 Зал «Пекин». Антон Гаврилов (Инфосистемы Джет) «Kyverno: старт без грабель»

Данный доклад будет отличным началом погружения в тему PolicyEngines на примере инструмента Kyverno и его возможностей.

#DevOpsConf Екатерина Лысенко из RoboGate. Неизбежность, или Как приучить Devops-инженеров к проектированию. В докладе две части: почему надо проектировать, вторая - что такое - проектирование. И были примеры из реальных кейсов, одни - сквозные по докладу, другие - локальные.

Итак, почему надо проектировать? Есть два подхода к работе: в рамках должностных обязанностей и в рамке бизнеса в целом. Первый вариант проявляется, когда команда работы с платежами считает, что фискализация - за пределами ответственности, или busdev полагает, что его задача ограничена коммутацией контрагентов с бизнесом.

Если приземляем на devops, то работа в рамках должностных обязанностей приводит к тому, что вы все время тушите пожары, которые непрерывно возникают из-за динамики бизнеса. Но когда devops говорят о бизнесе в целом, то они часто все равно ограничиваются автоматизацией и своим пониманием, что они могут сделать. А на вопрос "почему так" отвечают "бизнес так хотел" или "100 лет работает, не трогай". И с такими невозможно говорить.

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

На мой взгляд, тут определенный логический провал в рассуждении: почему выход за границы специализации непременно означает проектирование, и наоборот, почему работа в границах специализации не включает проектирование, ведь конвейер поставки ты же делаешь не ad hoc. На мой взгляд, ответ дает системный подход: когда ты создаешь подсистему, в данном случае - конвейвер поставки, ты, прежде всего, должен вписать ее в надсистему, а надсистемой в данном случае является работа бизнеса в целом. Внутри подсистемы можно оставаться, только если интерфейс уже кем-то определен, при чем с учетом потенциала подсистемы, а это знает именно devops. F иначе вписывание будет кривое. И в примерах необходимость проектирования была понятна, если devops не участвует, то бизнес прибегает с неразумными решениями.

Проектировщик решает следующие задачи:
* разработка продукта в соответствии с бизнес-вызовами
* поддержка и развития уровня качества продукта
* исполнение технической стратегии
* взаимодействие между бизнес-юнитами

Для решения ему надо понимать 5 проекций. Катя показывала их как уровни, но, на мой взгляд, это не совсем верно.
* Business vision. Полный, включая цели и не автоматизированные сценарии. Именно на этом уровне часто есть альтернативные варианты решений
* System vision. B тут часто надо обобщить разнородные частные решения, которые дали разные команды
* Integration vision. API, и там важно описывать содержание, бизнес-логику взаимодействия, которые лежат за пределами swagger
* Infrastructure vision. Он проявляется наверх, например, есть платежный провайдер, в какой-нибудь стране, где странно пополняют счета меняет json - и сообщения перестают проходить из-за кем-то поставленного ограничения в 1мб.
* Management vision: стратегии, культура. Компания меняет культуру от хакеров с крафтерам: не давай-давай, а тщательно делаем с архитектурой и рисками. И это - напрямую влияет на devops.

Проектирование - не только в крупном. Когда вы делаете анализ инцидента и пишете PIR, то там не так важно, как прошел инцидент. Важно - как не повторить, что изменить, какие меры применить. А это - проектирование.

Для архитектурных решений важно писать ADR - architecture decision report: почему решение было принято и какие последствия влечет. Они позволяют помнить причины решений, найти риски и ретроспективно работать, понимать причины выбора меньшего из нескольких зол, когда решение трогает за душу многих. Только его не надо писать на все решения, иначе получится большое множество очевидных документов, в которых не найдешь ценное.

Когда ADR нужны?
* Необходимо встроить новый продукт в архитектуру
* Реинжиниринг домена сервисов
* Выбор новой технологии
* Есть задачи на реализацию технической стратегии - она долгосрочна и меняется, надо понимать куда шли
Примеры: Единый клиент, оптимизация под рост нагрузки х10, перенос отчетов в BI...

В конце из зала был вопрос: как начать проектирование? На него было два исключающих ответа.
* Просто начните. Кто разрешит? А кто запретит, идешь и делаешь! А руководству показать пользу - на паре инцидентов.
* Если в компании культура тушения пожаров, то в одиночку это не изменить, и в любом случае изменение - не простое.

На этом - все.

🙌 Друзья, ловите фотографии с конференции в альбомах ВКонтакте:

День 1

День 2

Друзья, конференция DevOpsConf 2024 завершилась!

Мы благодарим каждого из вас за участие: кто был на площадке, в онлайн, спикеров и партнёров 🧡 Эти два дня были очень насыщенные и мы надеемся, что для вас они прошли плодотворно и интересно.

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

#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, смысла которого они не понимают. И все это - с одобрением аудитории, которой эти проблемы известны.

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