Forwarded from mtsepkov (Maxim Tsepkov)
#DevOpsConf Илья Барбашов из Авито. 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 и вопросы - по путям пользователя.
Контекст: в авито 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 и вопросы - по путям пользователя.
Forwarded from mtsepkov (Maxim Tsepkov)
Опрос выявляет неожиданное. Первый опрос показал, что в красной зоне линтер, которым сами гордились: оказалось, что пользователи недовольны, потому что он тормозит. И они запустили проект ускорения. Но они бы никогда не поняли причину красной зоны, если бы не было окошка в конце - именно туда писали, почему не довольны. Следующий опрос, в красной доне БД, это ожидаемо, потмоу что некоторое время назад сделали 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#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.
Разработчик готов мириться с неудобствами, но только если они редки. Часто повторяющиеся операции должны быть безупречны. Лучше сделать проще, но понятно и предсказуемо.
Опросы - просты, можно дать навигацию, пользователи получют фичи. Недостатки: низкая конверсия и люди устают. Раз в квартал - это часто, стали делать раз в полгода. А еще helicopter view от опросов - ограничен. Надо делать follow up и custdev
А дальше они хотят Instant feedback - ловушки для негатива для ключевых customer journey. Не длинный опрос, а точечная оценка и быстрый feedback. По свежему опыту использования фичи. Но есть слабые места: есть CLI-точка входа, там 800 пользователей - там нельзя показать форму, есть долгий customer journey - когда спрашивать? И можно задолбать. Поэтому присылают запрос в mattermost - оцените CJM, и не чаще, чем раз в неделю.
В отчетах на вопросы звучала популярная тема: ваша платформа скрывает внутренность сборки от разработчиков, и они перестают понимать, как оно устроено, не учатся думать. Ответ - понятен: платформа убирает рутинную часть и это дает реальный эффект на скорости разработки, который перевешивает побочные эффекты. А я тут могу заметить, что аналогичные вопросы я слышал по другим поводам. Первый раз - когда появлялись реляционные базы данных, с которыми ты работаешь на SQL, не заботясь о хранении: как же так, разработчик не будет думать про эффективность запросов (я еще работал на dbase без sql). А второй раз - с появлением Java и C#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.
👍1
В 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-специалистов, обучить команды и переложить на них задачу работы с инструментами безопасной разработки на команды.
⠀
🔸 Зал «Конгресс-холл». Анна Гобрусева (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-моделей и попробуете их в бою для анализа ошибок и поиска решений, соблюдая лицензии и требования к оборудованию.
⠀
✋ Обратите внимание, что на данный мастер-класс необходим свой ноутбук.
⠀
Искусственный интеллект ближе, чем кажется! Присоединяйтесь, чтобы узнать, как использовать открытые локальные LLM в повседневной работе на твоём обычном ПК. Откроете завесы над миром LLM-моделей и попробуете их в бою для анализа ошибок и поиска решений, соблюдая лицензии и требования к оборудованию.
⠀
✋ Обратите внимание, что на данный мастер-класс необходим свой ноутбук.
🔥1
✋ Друзья, если вы были на докладе Антона Алексеева и по техническим причинам у вас не получилось проголосовать за доклад, пройдите, пожалуйста, по ссылке, чтобы поставить оценку:
https://conf.ontico.ru/online/dc2024/details/5393175
https://conf.ontico.ru/online/dc2024/details/5393175
👌1
🖐 Дорогие участники, в 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 и его возможностей.
⠀
🔸 Зал «Конгресс-холл». Кирилл Ильин и Артем Поддубный (СберАвто) «Все как код»
Из доклада вы узнаете, как сделать архитектуру ваших сервисов в виде кода и как на это наложить техники из матрицы 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 и его возможностей.
Forwarded from mtsepkov (Maxim Tsepkov)
#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: почему решение было принято и какие последствия влечет. Они позволяют помнить причины решений, найти риски и ретроспективно работать, понимать причины выбора меньшего из нескольких зол, когда решение трогает за душу многих. Только его не надо писать на все решения, иначе получится большое множество очевидных документов, в которых не найдешь ценное.
Итак, почему надо проектировать? Есть два подхода к работе: в рамках должностных обязанностей и в рамке бизнеса в целом. Первый вариант проявляется, когда команда работы с платежами считает, что фискализация - за пределами ответственности, или 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: почему решение было принято и какие последствия влечет. Они позволяют помнить причины решений, найти риски и ретроспективно работать, понимать причины выбора меньшего из нескольких зол, когда решение трогает за душу многих. Только его не надо писать на все решения, иначе получится большое множество очевидных документов, в которых не найдешь ценное.
Forwarded from mtsepkov (Maxim Tsepkov)
Когда ADR нужны?
* Необходимо встроить новый продукт в архитектуру
* Реинжиниринг домена сервисов
* Выбор новой технологии
* Есть задачи на реализацию технической стратегии - она долгосрочна и меняется, надо понимать куда шли
Примеры: Единый клиент, оптимизация под рост нагрузки х10, перенос отчетов в BI...
В конце из зала был вопрос: как начать проектирование? На него было два исключающих ответа.
* Просто начните. Кто разрешит? А кто запретит, идешь и делаешь! А руководству показать пользу - на паре инцидентов.
* Если в компании культура тушения пожаров, то в одиночку это не изменить, и в любом случае изменение - не простое.
На этом - все.
* Необходимо встроить новый продукт в архитектуру
* Реинжиниринг домена сервисов
* Выбор новой технологии
* Есть задачи на реализацию технической стратегии - она долгосрочна и меняется, надо понимать куда шли
Примеры: Единый клиент, оптимизация под рост нагрузки х10, перенос отчетов в BI...
В конце из зала был вопрос: как начать проектирование? На него было два исключающих ответа.
* Просто начните. Кто разрешит? А кто запретит, идешь и делаешь! А руководству показать пользу - на паре инцидентов.
* Если в компании культура тушения пожаров, то в одиночку это не изменить, и в любом случае изменение - не простое.
На этом - все.
Media is too big
VIEW IN TELEGRAM
Друзья, конференция DevOpsConf 2024 завершилась!
Мы благодарим каждого из вас за участие: кто был на площадке, в онлайн, спикеров и партнёров 🧡 Эти два дня были очень насыщенные и мы надеемся, что для вас они прошли плодотворно и интересно.
До встречи на DevOpsConf 2025 🙌
Мы благодарим каждого из вас за участие: кто был на площадке, в онлайн, спикеров и партнёров 🧡 Эти два дня были очень насыщенные и мы надеемся, что для вас они прошли плодотворно и интересно.
До встречи на DevOpsConf 2025 🙌
❤16⚡6👍6❤🔥3