Текущая версия на 13:56, 21 марта 2024

В начале марта был на конференции #DevOpsConf. Полторы тысячи офлайн-участников, Сколково, много информации и общения. Я, как обычно, вел публиковал заметки с докладов, и сейчас собираю их в отчет. Наиболее интересен для меня был доклад Игоря Курочкина, он открывал конференцию и заметки идут первыми. дальше - по порядку.

Игорь Курочкин. NextOps — что будет после DevOps

Вау-фишка доклада - Way of Ways - обобщенный путь нового движения, которое на начальной стадии порождает новые успешные практики, а потом начинает использоваться как бренд для различных паразитных практик и симулякров, которые эксплуатируют проблемы, а не решают их. И на этом этапе попытки нанести нечто полезное разбиваются о засилье этих паразитных практик. В общем, мы все знаем, что так и происходит, и это частное проявление бюрократизации, как ее исследовал Крозье, но в докладе был конкретный обобщенный путь, и это интересно. Дальше обобщенный путь наложен на DevOps и получается тоже понятная картина, DevOps уже 15 лет и как модный бренд уже прошел фазу полезного развития. Так что стоит задуматься о следующем тренде, которые Игорь назвал NextOps и который позволит сделать следующий шаг. И в докладе была попытка, на основе анализа работы отцов-основоположников DevOps и других трендах это нащупать. Это было интересно, но, на мой взгляд, не слишком перспективно, потому что опыт показывает, что гуру успешного направления очень редко становятся драйверами следующего. Хотя исключения бывают. Конспекта этой части не будет, смотрите доклад.

И тут интересно определение DevOps, которое дал Игорь. Потому что никакого нормативного определения не существует, и это - один из путей, которыми воспользовались паразитные субъекты для приватизации новой территории. Определение Игоря широкое: DevOps призван решать проблемы комомуникации, не только между разработкой и эксплуатацией, но и в других областях, и делает это общественное профессиональное движение. Проблемы решают понятным способом: через выделением паттерном и антипаттернов, и работой с ними. Что касается профессионального движения, то Игорь привел пример консорциума CNCF - Cloud Native Computing Foundation, как открытого сообщества. Наверное, было бы интересно сопоставить практики организации этого сообщества с сообществами прошлой эпохи - OMG или The Open Group.

Конкретно про DevOps надо сказать, что он проходит этап дифференциации, что естественно для каждой развивающейся практики. Появляются новые направления инженерных практик, применяемых на разных этапах конвейера поставки. По инженерным практикам у Игоря тоже широкое определение: это все, что позволяет обеспечить эффективную работы команд на большом масштабе. Тут выделяется много специализаций и направлений, в докладе были слайды. По инженерным практикам Игорь немного остановился на Relibility Engineering (SRE), который успешно развивается, и молодому Platform Engineering. Интересно, что SRE старше DevOps, ему 25 лет, но он по пути Way Of Ways находится еще на продуктивной фазе. Может быть, потому что он решал сложные инженерные задачи, в которых требовался результат - и в этих случаях не получается создавать простые симулякры.

Way of ways и его применение к devops - фото с экрана.

Комментарий Игоря Курочкина: Спасибо большое за саммари по моему выступлению. Немного поправлю и дополню, я давал определение не инженерным практикам, а инжинирингу (Engineering), ссылаясь на определение из книги Software Engineering at Google, что это прежде всего командная работа на большом масштабе. SRE немного младше и отмечает 20 лет. Описание The Way of Ways можно найти по ссылке https://medium.com/@johnpcutler/the-way-of-ways-6988b272bcc5

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

Доклад концептуальный, он принципиально меняет точку зрения на ошибки и сбои: мы не стремимся уменьшить их до нуля, увеличив время между ошибками, а определяем допустимую зону и фокусируемся на способах быстрого восстановления в случае сбоев. И это дает устойчивость системы в целом. Это подход resilience engineering (https://en.wikipedia.org/wiki/Resilience_engineering), основанного на работах ряда исследователей. В их числе Richard Cook, на работы которого Сергей много ссылался. Предлагается определить зону сбоев, которая является приемлемой, и держаться в ней, в том числе - за счет быстрого восстановления, а не только за счет снижения количества ошибок. Подробнее про подход можно посмотреть в stella.report (http://stella.report/). Идея состоит в том, что мы предусматриваем универсальные способы восстановления, которые сработают в широком спектре ситуаций. И что наоборот, частные способы могут перестать работать. Например, практика канареечных релизов, при которой новые фичи сначала предоставляются малому числу пользователей для проверки работоспособности, могут перестать выполнять свою функцию, если разработчики начнут применять feature toggle, включаемые сразу и для всех, а не постепенно - сначала релиз раскатят на всех, а потом этот флаг возьмут и включат, и проблемы посыпятся.

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

Карапет Манасян из MOEX Group. Сколько стоит платформа?

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

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

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

Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности.

Про технологический стек: нет единого требования, если бизнес выбрал некоторое решение и считает его полезным, то они должны уметь включить его в конвейер поставки от платформы. Конвейер поставки - один типовой, дальше команды докручивают. Для платформы опираются на open source решения, но когда вы забираете такие решения внутрь, то вы становитесь владельцем, надо поддерживать и дорабатывать. Часто встречающаяся проблема - развернуть несколько экземлzпров решения в рамках группы, но при этом обеспечить общую авторизацию. Приходится дорабатывать, и это непросто.

Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.

Евгений Харченко из Райффайзен Банк

Как DevOps влияет на эффективность организации? Очень интересный доклад о реально наблюдаемой корреляции между показателями инженерной культуры и метриками эффективности. На масштабе 3000 сотрудников в 148 командах. Метрики касаются применения инженерных практик и интегральной производительности по модели DORA. А по культуре - на модель Ron Westrum, которая разделяет три вида: патологическую, бюрократическую и генеративную.

Деление культур опирается на 6 факторов: обмен информацией, сотрудничество, общая ответственность, отношение к ошибкам, анализ причин, улучшения, и для определения генеративной культуры они по каждому фактору сформулировали гипотезы-вопросы, которые предлагают оценить по 5-бальной шкале Лигерта от полностью несогласен до полностью согласен. Гипотезы:

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

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

Что интересно, средний индекс культуры хорошо коррелирует с инженерными практиками и метриками производительности. В общем-то, так и должно быть, ведь не зря говорят, что devops - это культура. Однако, многие к этому относятся скептически. Метрики показывают ,что это - не так, и работа с культурой - важная составляющая. Результат работы с которой можно измерить. Ну, с точностью до того, что люди начнут подделывать ответы, но это - тоже часть культуры. Но корреляция - побочный результат. Опрос - не для этого, а чтобы увидеть картину в целом, выделить точки роста и аномалии. И успешно работать с ними.

Анастасия Граф. Как организовать базу знаний так, чтобы даже новичок-джун всё смог найти сам?

Анастасия - из Maxim Technology, разработка для Taxi Maxim, 350 ИТ-шников распределенная команда по городам России. Доклад развивает тему доклада на #TeamleadConf-2023 (есть конспект в моем отчете), но отличается фокусировка. Тогда был рассказ о процессе и технических способах организовать документацию, а здесь фокус на результат - базу знаний с легким поиском и с соучастием разработчиков в ее поддержке. И основная задача тут - изменение культуры: переход от ситуации, когда тот к кому нужна информации, обращается в чатик или к соседу, к ситуации, когда человек сначала идет за ответом в базу знаний, и только если ответ не нашел идет его искать к соседу или в чатик, а найдя ответ - еще и дополняет базу знаний. Это именно изменение культуры. Но чтобы оно произошло должны быть предпосылки.

4 требования, они были сформулированы на слайде, а потом по каждому шел рассказ.

1) Легко делиться знаниями. Чтобы писали все, а не специально выделенный человек. Для этого надо дать возможность писать всем, в том числе джунам - у них есть вопросы, есть ответы, которые будут полезны следующему джуну. И каждому должно быть понятно, что и как написать, это обеспечивает типизация контента и шаблоны структуры с подсказками по заполнению каждого поля.

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

2) Статья написана понятно читателю. Целевая аудитория часто шире, чем задумываешься. Есть люди, далекие от ИТ, которым тоже интересно не ходить с вопросами к ИТ. И здесь - ревью, обратная связь и легкость изменения. Перевести реакцию из "у вас непонятно" к "мне непонятно это и это".

3) Легко найти нужный материал. Тут есть проблема со сленгом - надо писать понятные названия. А еще работать с метками. У них документацию ведут сами команды, и они образуют дерево статей так как им удобно, в своей логике и ориентируются в своем пространстве. Которая отличается от логике соседней команды. А поиск нужен по всей документации, и метки помогают определить нужный набор страниц. И они помогают делать тематические подборки, на которых собирается вся необходимая информация.

4) Все материалы достоверны и актуальны на текущую дату. Самое сложно реализуемое. Что не надо перепроверять, а если нашел неверное - то заинтересован исправить. Реализуется за счет статусной модели для страниц, и за счет активного применения сборных страниц, которое позволяет править в одном месте. Статус - метка на странице: В работе, Ревью, Опубликована, На корректировку.

Итого, что нужно сделать:

• Дать возможность писать всем, включая джунов. Потому что у него есть что написать, ответить вопросы.
• Типизация контента. Шаблоны для каждого типа. Структуры с подсказками.
• Круг энтузиастов, которые пишут, либо встройка наполнения базы знаний включено в процесс.
• Порядок верификации и обновления. Нужен триггер обновления - когда и по какому алгоритму проверять, и алгоритм поиска устаревших страниц - через различные отчеты.

На этом - все. А мне во время доклада пришла мысль посмотреть на изменение культуры документирования как на процесс уборки и поддержания порядка: (1) есть пространства, где ты при необходимости убираешься сам, (2) есть - где активно сигнализируешь о беспорядке, (3) есть - где лишь жалуешься и страдаешь, а (4) есть - где игнорируешь. И задача - чтобы расширить пространства 1 и 2 каждого членов команды, обеспечив перекрыте всего пространства активистами. Это может дать другой взгляд.

Илья Барбашов из Авито. Developer Experience: обзор подходов и как мы их применяем

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

Контекст: в авито 2500 инженеров, 1800 микросервисов. Платформа покрывает все от создания и разработки сервиса до выкатки и эксплуатации, содержит реестр сервисов и библиотек, связей, решение типовых задач в микросервисной архитектуре. Платформа 5 лет в разработке, очевидные задачи - решены. При этом не известно, насколько мы хороши, есть много идей фич, но профит от них их - неясен, а хочется понимать заранее. И нет product manager - эту роль выполняет сама команда, тимлиды. Итого: непонятно в какую сторону работать. А хотелось бы иметь ориентиры, например, метрика.

Поискали метрики в индустрии.

• DORA 4 метрики: как часто катите, как быстро докатываете до прода, как часто падаете, как быстро восстанавливаете. И у них есть квалификация low - medium - high - elite. У них платформа позволяет работать на уровне elite, улучшения лежат уже в русле команд. А там идет работа по team maturity model компании
• SPACE: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow - всеобъемлющий, но применение неясно
• Три изменения DevEx: Flow state, cognitive load, feedback loop. Более практичен, и это не CAP-теорема, можно все три улучшать.

Flow State: если инженера прерыват встречи, срочные задачи и блокеры, автономность выбора инженером задачи, понятные цели и задачи проекта - чтобы выбирать, интересные задачи. Не решается техническими средствами, это организация. В avito есть playbook, он это как-то решает.

Cognitive load: насколько надо напрячь мозг, чтобы эту задачу сделать. Непонятный фреймворк или технология, новый бизнес-домен и так далее. Делится на два типа: полезная, которая бьет в решение задачи, и паразитная - нечеткие требования и дополнительные знания, например, кубовые манифесты. Платформа снижает типовые задачи, чтобы разработчик не думал о кубернетисе, о том, что интеграция сломается - есть проверки, можно посмотреть любой сервис и так далее.

Feedback Loops: все действия, которые надо делать разработчику пока решает задачу. Компиляция, циклы запуска тестов и так далее. И pull request при итеративном code review. CI. Итеративные согласования, например, с безопасниками. Количество циклов, вероятно, убрать не сможем, а скорость повысить - да. Они здесь работают через стандартизацию - стандартизирвоанный CI/CD, линтинг, среда разработки с автоматической настройкой зависимости. Среда может поднять для тестов все зависимости, шины данных, базы данных - если нужно для тестов.

Но дальше вопрос: как эту историю мерить? Фреймворк рекомендует три метрики: ощущаемая легкость разработки, ощущаемая удовлетворенность разработчиков, ощущаемая продуктивность. Это все - субъективно.

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

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

Опрос выявляет неожиданное. Первый опрос показал, что в красной зоне линтер, которым сами гордились: оказалось, что пользователи недовольны, потому что он тормозит. И они запустили проект ускорения. Но они бы никогда не поняли причину красной зоны, если бы не было окошка в конце - именно туда писали, почему не довольны. Следующий опрос, в красной доне БД, это ожидаемо, потмоу что некоторое время назад сделали 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#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.

Екатерина Лысенко из 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 record: почему решение было принято и какие последствия влечет. Они позволяют помнить причины решений, найти риски и ретроспективно работать, понимать причины выбора меньшего из нескольких зол, когда решение трогает за душу многих. Только его не надо писать на все решения, иначе получится большое множество очевидных документов, в которых не найдешь ценное.

Когда ADR нужны?

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

Примеры: Единый клиент, оптимизация под рост нагрузки х10, перенос отчетов в BI...

В конце из зала был вопрос: как начать проектирование? На него было два исключающих ответа.

• Просто начните. Кто разрешит? А кто запретит, идешь и делаешь! А руководству показать пользу - на паре инцидентов.
• Если в компании культура тушения пожаров, то в одиночку это не изменить, и в любом случае изменение - не простое.

На этом - все.

Из обсуждения.

Evgene Aslamov. Вопрос некорректный у докладчика. Не когда ADR нужны, а что такое архитектурное решение. Тогда будет понятно на что писать ADR

mtsepkov. Не, при такой постановке получается второй вопрос - на все ли архитектурные решения нужны ADR, может они лишние. И тут косвенно ответ был: если для нового сервиса выбираются известные технологии, то ADR они не пишут, хотя для сервиса это, безусловно, архитектурные решения.

Evgene Aslamov. Это и есть вопрос - если у тебя есть стандарт, то никакого "решения" (как ответ на вопрос "что решили?") и нет, так как ничего и не решали. Поэтому и надо определить, что является ответом на вопрос "что решили?" - это когда есть развилки, вариант и т.п. Когда у тебя нет альтернатив - мы ничего не решаем. Там же decision, а не solution.

mtsepkov. Ну, по смыслу, речь шла не только о ситуации стандарта, но и о ситуации, когда стандарта нет, но выбрана технология, уже апробированная в компании, и этот выбор не вызывал сомнений. Тогда ADR не нужен. А вот если сомнения были или выбор не однозначен - то нужен.

Evgene Aslamov. На мой скромный взгляд это равноценные ситуации. Если решение принимают за тебя, то это не решение в твоём контексте, на соц взгляд

Nadezhda Krupenkina. А просто новая фича (story) почему не может приравниваться к ADR? Она решает какую-то пользовательскую проблему

Evgene Aslamov. ADR (Descision) не решает проблему, проблему решает solution. а ADR фиксирует контекст, причины, следствия. Чтобы спустя какое-то время было понятно, почему было decision о таком нужности solution. Ну и кстати, story не решает проблему пользователя. Всего лишь "короткая формулировка намерения пользователя и того, что продукт должен сделать для него."

Nadezhda Krupenkina. Story в контексте Jira-подобных трекеров - это описание пользовательской истории (или кейсов) и требований, необходимых для соответствующей фичи. Так же там может быть solution, но необязательно, и могут перечисляться открытые вопросы, требующие решения. Пользователь (актор) может быть и системой, если история вокруг бэкенда. Думаю, удобно ли будет такой вид стори записывать как ADR? Контекст и причины у пользовательской истории тоже есть, на бизнес-уровне или на прикладном.

mtsepkov. Story, если говорить строго, это действительно потребность пользователя. Дальше для нее делают design, вырабатывая solution - решение, которое позволит удовлетворить эту потребность. Есть практика, когда в команду вкидывают уже готовый solution вместо story - а в результате решение оказывается не пригодно, потому как разработчики не понимали, для чего делают то, что делают. Когда проектируют solution, то принимают какие-то решения, в том числе архитектурные. Они могут быть очевидны - и тогда нет смысла отдельно фиксировать их основания. Потому что фиксация оснований (ADR) - работа. B ее надо выполнять, когда она реально нужна - когда решения не были очевидными, или потенциально ведут к накладным расходам, подобно новой технологии, это в докладе как раз было - набор оснований.

Nadezhda Krupenkina. Спасибо за такой развёрнутый ответ, согласна с проблемой solution без стори. Стори/юз-кейсы - один из форматов представления пользовательских требований. Помимо пользовательских, есть и другие требования, которые удобно объединять по стори.

В DocHub, о котором Вы писали ранее, предлагается в модели SEAF оформлять любое изменение (фича, баг, техдолг вроде рефакторинга) как ADR-запись с привязанными требованиями и заводить в соответствующей ветке. При этом в ADR указывается все, что нужно по шаблону - и решаемая проблема, и кто принимал решение, и контекст, если нужен. То есть ради единого процесса придумали отклонение от классического понимания ADR. Пока на практике не пробовала, но выглядит, на первый взгляд, удобно. Все ADR попадают в лог, таким образом становясь аналогом change-реквестов, по которым можно отслеживать историю и статус изменений. Каким образом оформлять solution при таких ADR - пока неочевидно, но по идее можно вписать в ADR, тк solution - это не требования, а абстракция над ними. Возможно, надо ссылаться на некое описание стандарта, на конвенцию, принимая решение придерживаться его

Константин Ожерельев из 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С я слышал уже лет семь назад, другое дело, что сам вендор не торопится с полноценной поддержкой, и разработчики консервативны. Но технические возможности - есть и они совершенствуются.

Владимир Утратенко из Uzum Market. Древние свитки CI/CD: смыслы, которые мы потеряли

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

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

От автора в обсуждении доклада: Максим, спасибо большое за отзыв! Помню Вас в зале. Над серьёзным разбором тоже задумался, но это разговор уже не на DevOpsConf, а куда-то ещё. Надеюсь, найду время сделать и рассказать.