После прослушивания этого доклада я ощутил смесь разочарования и потенциала. Начиная с презентации, я надеялся увидеть четкие, практические подходы к управлению проектами, но вместо этого мне пришлось столкнуться с бесконечным потоком слайдов и хаосом в организации материала. Особенно это касается момента, когда обсуждалась "проблема часа инженера". Введение концепции 'слотов времени' и универсальных единиц измерения работы инженера кажется непродуктивным. Это упрощает понимание человеческого таланта и креативности до простых цифр, что, на мой взгляд, не отражает истинную ценность инженерной работы. Докладчик казался потерянным в собственных объяснениях, что подрывает доверие к представляемым методам. Как можно ожидать, что кто-то захочет применять эти методы, когда даже спикер кажется неуверенным в их пользе? Ещё один критический момент - это непрекращающееся переключение слайдов. Это отвлекает и делает следование за ходом доклада утомительным. Каждый раз, когда докладчик пытался объяснить свои методы, это звучало скорее как отчаянная попытка звучать убедительно, нежели как демонстрация эффективного решения. Если бы Стив Джобс находился в зале, я уверен, он бы поставил под вопрос столь сложный подход к измерению работы инженеров, упускающий из виду важность инноваций и креативности. Он всегда подчеркивал, что величайшая ценность заключается не в количестве потраченных часов, а в качестве и влиянии созданного продукта. Нужно сосредоточиться на том, как эти методы могут реально улучшить работу команды. Этот доклад был упущенной возможностью демонстрации эффективной интеграции скрама и канбана в рабочем процессе. Надеюсь, что в следующий раз мы увидим от Фланта более вдохновляющий и понятный доклад.
@sergeygoncharuk62585 күн бұрын
Иван, привет! Рад видеть, что бывшие коллеги-ПМы интересуются моим докладом, правда очень странно видеть отзыв на доклад о фреймворке, написанный таким образом, как будто ты не знаешь, как это работает в жизни и требуешь практических подходов, по которым работал сам. За критику по количеству слайдов спасибо! Учту в будущем. А сейчас, так как ты смотрел этот доклад в видео-версии, предлагаю лайфхак: можно нажать паузу и внимательно рассмотреть слайд, я старался сделать так, чтобы информация на нем иллюстрировала слова, которые я говорю и делала их наглядными. К сожалению, тема доклада довольно узкая, а времени на ее раскрытие не так много, чтобы в доклад уложить еще и методы развития и проявления творческих способностей инженеров команды. Да и тебе ли не знать, что во Фланте существуют для этого иные механизмы, например performance review, с описанием которого можно ознакомиться в этом докладе kzbin.info/www/bejne/oJLTp5mprNOqqsk Ну и наконец, если бы Стив Джобс был на моем докладе, я был бы счастлив, что такого масштаба человек пришел, чтобы послушать меня и задает вопросы по существу. Удачи, Иван!
@maks-xn6rg11 күн бұрын
Чет водичка какая-то)) старый доклад актуальнее
@user-if1iw8dg5q12 күн бұрын
26.21 "если у Вас в одном кластере живет и дев и прод ...." - Чегооо? Отвага и безумие + экономия. Не делайте так(
@PahaUsd12 күн бұрын
было интересно
@junegton2 ай бұрын
после фразы "куб не предназначен для одновременной работы с несколькими командами" - можно расходиться, у вас руки не из того места растут
@jidckii2 ай бұрын
Рассказал про проблемы, а что это такое и как его использовать и кейсы, чёт ничего не рассказал. Зачем вообще мне этот вектор нужен? От того, что он "классный", чёт как то попробовать не захотелось)
@user-ec8lg6jt2n2 ай бұрын
Настроил vector года 2 назад. Логи контейнеров в elasticsearch, логи nginx отдельно в clickhouse, до сих пор работает стабильно. Правда в clickhouse по факту через http вставляет, тот самый json insert.
@spiritcxz2 ай бұрын
смешно 😄 1. что мешает держать тестовый и прод в разных кластерах или в разных неймспейсах. 2. так же допустим для теста в gitops репе можно создать тестовую и продовую папку для манифестов. 3. еще ни разу не было проблем с деплоем. 4. выпрямите руки и делайте правильное тегирование и проблем не будет. уже как неделю юзаю flux и проблем не знаю
@SlavaVy02 ай бұрын
Классный доклад, архитектору бы немного подтянуть речь, чтобы голос был совсем дикторским, было бы прям совсем огонь!
@ivanbrykalov99552 ай бұрын
Спасибо, было весьма интересно. Уже используем декхаус, подумаем ещё над Лантри)
@batazor3 ай бұрын
werf в эпоху flux/argocd не очень понятен для меня а вот Nelm наверно будет интересно посмотреть
@andrew20663 ай бұрын
Эх, я думал что в ролике будет идти речь чем заменить K8s (nomad, serverless etc) а тут просто о надстройке над ним для энтерпрайза.
@cucumbaislife3 ай бұрын
спасибо за подробный доклад. Именно такие вещи и двигают opensource. Желаю werf стабильного развития!
@semremal3 ай бұрын
Спасибо за демонстрации разницы между нормальными управленцами и теми, кто считает, что скрама (или альтернативы) достаточно
@user-gw6df6ns7e4 ай бұрын
Не всегда можно назад состояние откатить. Например прошла миграция в базу и убрали поля из таблицы. В модели они при откате появятся 😢.
@Lev6374 ай бұрын
ну, это каждому на свой вкус и цвет. лично мы используем популярные фреймворки и очень довольны. конечно, каждый их под себя адаптирует, но если управлять этим с коучем или аспро.agile, например, то адаптация проходит проще
@sergeygoncharuk62584 ай бұрын
"это каждому на свой вкус и цвет" - вот тут согласен на все 146%, если в вашем конкретном производственном процессе подходит готовое, то изобретать велосипед ни к чему
@smaileee4 ай бұрын
вообще-то это была створка двери, а не крышка рояля...
@andrey.nekrasov4 ай бұрын
"Голый докер в 2024 вряд ли будет использоваться". Пишу из 2024. Ну более-менее докер уже начинает нами использоваться и кажется многие его уже не боятся :) Хотя некоторым бы стоило уже начать делать свои поделки в докере, мне все же удобнее было бы разворачивать, но они еще не умеют.
@berg4mut4 ай бұрын
Все это очень круто, но кто готов интегрироваться во флан продукты вместо того что-бы юзать ванильные решения, вопрос. Фор фан - гуд, для прода нот реди ет.
@ilyalesikov38684 ай бұрын
werf опенсорсный, свободный и в CNCF (как и Helm), никаких других продуктов Фланта для работы не требует. Активных за последний месяц проектов (обычно один проект - один репозиторий), использующих werf, больше 10 тысяч. Конечно, не Helm, но всё же. Скоро ещё выделим эту новую подсистему развертывания в отдельный продукт (Nelm), он не будет затрагивать сборку и ряд других вещей, которыми werf занимается. Nelm будет прямой альтернативой Helm.
@VilikSpb4 ай бұрын
Спасибо, очень интересно. Запишите по возможности подобное видео по trdl.
@DimosMos4 ай бұрын
Должен ли DevOps знать все детали разработки? Может, каждый должен заниматься своим делом? ✌️😉
@youmeek4 ай бұрын
Спасибо. Отличный доклад!
@nobody_nowhere_5 ай бұрын
очень не хватает еще vs helmfile вышло бы поинтереснее..
@Flant5 ай бұрын
на 52:12 как раз об этом:)
@romann12955 ай бұрын
Спасибо большое, было интересно. Пока только хельм юзаем, стоит рассмотреть и другие подходы
@evseevav5 ай бұрын
Как можно так скучно рассказывать про такую интересную вещь?
@jidckii5 ай бұрын
Потому, что они разработчики, а не рассказчики
@evseevav5 ай бұрын
@@jidckii нельзя было найти разработчика-рассказчика? Ну или изложение более интересное сделать.
@ilyalesikov38684 ай бұрын
@@evseevav Посоветуйте, что не так, постараюсь получше в следующий раз
@ilyalesikov38684 ай бұрын
Хотя, справедливости ради, в этот раз мне самому не понравилось, как выступил. Когда пытался пересмотреть, хватило меня на пару минут. Мало времени выделил на подготовку, в итоге подтупливал и какое-то все такое вышло. Но если есть конкретные пожелания, я бы послушал
@alexanderr26882 ай бұрын
@@ilyalesikov3868 а мне наоборот понравилось, всё по делу. Отдельно хочется отметить хорошее разрешение камеры, освещение и звук
@Flant5 ай бұрын
Вопрос, на который мы отвечали письменно в чате встречи: Вопрос: будет ли в werf поддержка Timoni + CUE? Ответ: У нас как раз появился новый движок деплоя, который пришел на замену helm и совместим с helm. Давать несколько альтернативных вариантов для деплоя - немного не наш путь, такой подход больше практикуется например в skaffold, который поддерживает множество бекендов, в том виде как они есть. У werf другой подход, мы стараемся предлагать один вариант и сильно дорабатываем его так, чтобы он соответствовал некоторым базовым требованиям.
@werf88885 ай бұрын
верф это мое имя
@aleks_strong6 ай бұрын
спасибо, сжато и чётко)
@kl45gp7 ай бұрын
сволочи такую лекцию прервали!
@Holms7 ай бұрын
а gitlab autodevops это gitops или это gitops+ciops? там есть обратная связь, измены регистри там не имеет значения ) я удалил все образы и даже подменял существующий gitlab agent'у на это вообще плевать :) ну и там два способа либо pull либо push deployment. тоесть pull когда хранишь манифесты в репо и агент пулит в кластер изминения, а push когда совственно ci/cd пушит изминения но там есть обратная связь в deploy пайплайне и там собирается хелм сам по шаблонам что удобно при множестве микросервисов, мне вообще писать скрипты не надо все шаблонно :) правда вот со стэйджом я пока не разобрался но наверно у них есть решение и для стэджа с полным окружением под ревью и для миграций тоже.
@Flant5 ай бұрын
GitLab Auto DevOps - это «сахар», который в простых сценариях позволяет не думать о части конфигурации доставки приложения и настройки различного рода интеграций (в том числе с Flux, который реализует устоявшееся понимание GitOps). Но по большому счету, то, что дает GitLab AutoDevOps, можно самостоятельно построить на базе того же GitLab CI/CD или любой другой CI-системы.
@eletenkov7 ай бұрын
Слишком много воды.
@JohnSmith-ok1vi7 ай бұрын
Иначе бы Дима не заработал 30 лямов за 22 год😁
@panchwall_devops7 ай бұрын
доходчиво как и всегда. спасибо
@alexandrkulakov78848 ай бұрын
Этот спич весьма занятен) Благодарствую)
@a1dwow8 ай бұрын
какое ПО вы используете для создания таких красивых презентаций ?
@andreypolovov52408 ай бұрын
Google slides, который не очень подходит для таких объёмов + дизайнеры с чувством прекрасного :)
@mixalic8 ай бұрын
Чет грустно стало, на хрен я это посмотрел(
@mixalic8 ай бұрын
Интересно на самом деле, спасибо за лекцию
@8462bb19 ай бұрын
Наконец Привет
@Setapus9 ай бұрын
вода.
@xxxxPomaHxxxx9 ай бұрын
Сделали бы, для поиграться, в докере эту штуку, как с ранчером одна команда и готово `docker run --net host --privileged rancher/rancher`
@user-em3nt3kr2z9 ай бұрын
да все круто,ждем новую встречу!)
@user-di3nd4dk7d9 ай бұрын
Максим все круто но лучше пару таблеток валерьяны выпить иначе слушать сложно и больно
@russiantime77810 ай бұрын
Очень интересно, спасибо. От себя добавлю что каждый, условный критикал алерт должен автоматически порождать тикет в service desk. То есть должна быть интеграция системы мониторинга и SD. Тогда и ложных срабатываний меньше, потому как более ответственный подход будет к настройке триггеров. В своё время, лет 10 назад, Zabbix с OTRS пытался подружить).
@zuzexsupportonline10 ай бұрын
Спасибо ребята! Вы спасли столько часов в моей жизни!! Очень круто что вы разработали верфь!
@Petyaumniy10 ай бұрын
werf run максимально странное решение для тестирования. И вот почему. Я как разработчик уже имею полностью описаное развертывание своего приложения в helm chart. А это значит минимальными манипуляциями с имеющимся чартом (оборачиванием всех ресурсов в условные их отключатели) я могу поднимать необходимое количество уже настроеных на взаимодействие ресурсов для конкретного теста. В дефолтном хелм есть стандартный тестовый хук и аннотации для автоматического удаления созданых ресурсов после завершения теста. Раньше (год назад) я мог в верфе используя стандартный уже имеющийся чарт поднять необходимую тестовую инфраструктуру и тригернуть хук теста созданый на основе имеющегося бекенда со всеми енвами, секретами, инит/и_не_инит контейнерами, лимитами и т.д. Сейчас так могу только в хелме. В верфе сейчас мне предлагается первую часть (инфраструктуру теста) деплоить по старому чартом, а потом для чего-то взять и повторить вторую часть (сам тест) - всю тут работу, которая уже была выполнена в имеющейся конфигурации хелм чарта, которая всех устраивает, которая максимально близка к проду, взять и перенести её в werf run и потом сопровождать это одно и тоже в 2 местах!!! sic! У меня как пользователя возникает вопрос: а для чего собственно этот werf run нужен? - Если предполагается каноническое "само в себе" unit тестирование или linter - я предпочту уменьшить уровень абстракций. Не запускать gitlab-ci image:werf:stable, который потом сходит через werf в какой-то еще k8s кластер по api и запустит там тест. А запустить сразу image: repo:image-commit_hash и 1 тестовую команду в нем. Такой запуск гораздо понятнее для меня как для разработчика не желающего погружаться в devops тулзы и вообще их видеть. Вопросы тагирования? Ну дак они все так же автоматически решаются для меня выше с имутабельностью, скоростью, маштабированием и всеми плюшками. - Если это kind of e2e тестирования - я лучше добавляю помимо отключения ненужных сервисов в своем хелм чарте переопределение entrypoint/args уровня sleep infinity и лайвнес пробы в том контейнере в котором собираюсь запускать тесты, задеплою тестовое окружение и выполню тест через kubectl. Для меня как для разработчика главное чтобы мне не приходилось делать 2 раза одну и ту же работу в которой я могу ошибиться. Все эти возможности: что оно что-то там предварительно соберет - это ничто по сравнению с делать неинтересную работу 2 раза (от такого подхода самого по себе уже подгорает). И к тому же даже если оно и может что-то собирать, кто же ему позволит? Я не готов на стади выполнения тестов (= реквесты/лимиты контейнера пулящего строки с куба) резервировать ресурсы еще и под сборку. "Разделяйте стадии сборки и исполнения" 12 factors app (c). Из моего опыта (выше) он не нужен ни для чего. Очень печально (для меня :() что у разработчиков другое мнение и другие юз кейсы.
@ilyalesikov38689 ай бұрын
Для запуска тестов, требующих инфру, предлагается: 1. По умолчанию: "werf converge --set infra.enabled=true" + "werf converge --set tests.enabled=true". По сути это то же, что и "helm install" + "helm test". 2. Другой вариант: "werf converge --set infra.enabled=true" + "werf kube-run". Этот вариант для того, чтобы по-простому выгрузить артефакты из теста (kube-run --copy-to/--copy-from), либо если лень делать отдельный чарт для тестов. Выгрузку артефактов добавим в будущем и в werf converge. Для запуска тестов без инфры: 1. `werf kube-run myimage -- mycommand`. Погружаться тут ни во что не нужно, это просто запуск команды в контейнере в кубе вместо локальной машины (хотя учиться работать с кубами разрабам придется в любом случае). Для тестирования/разработки у вас ведь всё-равно кубы есть? Вот их и используйте. Пока есть вариант ещё с `werf run`, оно работает в Docker'е локально, может и оставим его. kube-run добавляли из расчета, что и разработка и тестирование будут в кубах, и мы сможем полностью отвязаться от Docker'а (что было бы полезно в процессе миграции на Buildah). Основное предназначение kube-run - интерактивный запуск контейнеров при локальной разработке на той же платформе, на которой крутится прод (Kubernetes), а также запуск простых задач в CI (с точки зрения эксплуатации это не сильно отличается от "docker run", кроме того, что вычисления переносятся в кубы и их проще масштабировать). kube-run - это гибрид `docker run` и `kubectl run`.
@ilyalesikov38689 ай бұрын
Большинство команд, отличных от `werf build`, действительно (по умолчанию) делает сборку. Хотя если образы уже были собраны, то оно, грубо говоря, просто скачает конечный образ, если он ещё не скачан. Большинство команд должны иметь флаг `--skip-build`, чтобы вместо пересборки просто упасть, если собранный образ не был найден в репозитории. Сейчас заметил, что в kube-run флага нет, и это мы что-то упустили, надо добавить. А вообще я с вами согласен в том, что мне тоже не нравится попытка собрать образы практически перед каждой командой. Мне `--skip-build` по умолчанию для CI было бы удобнее, но тут надо с коллегами обсуждать.
@ilyalesikov38689 ай бұрын
И ещё по поводу этого: "В верфе сейчас мне предлагается первую часть (инфраструктуру теста) деплоить по старому чартом, а потом для чего-то взять и повторить вторую часть (сам тест) - всю тут работу, которая уже была выполнена в имеющейся конфигурации хелм чарта, которая всех устраивает, которая максимально близка к проду, взять и перенести её в werf run и потом сопровождать это одно и тоже в 2 местах!!! sic!" Такого не предлагаю, здесь лучше оставить всё как есть, разве что аналога `helm test` у нас сейчас нет, поэтому вторую часть (тест) надо как-то через `--set` включать/выключать вместо использования test-хука. Есть ещё более простой вариант, если инфра поднимается быстро: сделать тест post-install/update-хуком, и катить и инфру и тесты одним релизом с `werf converge`. И по поводу "потом сопровождать это одно и тоже в 2 местах": в этом, конечно, смысла никакого нет. Либо держите джобу с тестом в чартах, либо используйте `kube-run` для этого теста, но только что-то одно, оба сразу смысла нет.
@Rundik10 ай бұрын
"он премайс"
@Rundik10 ай бұрын
ДатаВолум
@sergeydev827310 ай бұрын
Флант конечно лютые!) Качество материала и подачи просто пушка!
@evgeniipetrenko201910 ай бұрын
А хранилище используется на Linstor DRBD?
@Flant10 ай бұрын
Да, LINSTOR. Вот тут подробнее можно почитать, что под капотом системы виртуализации: habr.com/ru/companies/flant/articles/715426/
@evgeniipetrenko201910 ай бұрын
@@Flant интересно ваше мнение о Harvester hci
@kvapskvaps10 ай бұрын
@evgeniipereverzev2070 Harvester неплохой, на данный момент он выглядит наиболее завершённым проектом использующим KubeVirt. Однако хранилище longhorn не самое быстрое, и есть некоторые вопросы к отказоустойчивости. Сеть реализуется в класическом режиме бриджами, когда кубовая сеть подов используется только как дополнительная management network
@simplewhite947210 ай бұрын
А еще интересно то, что при внедрении istio вы теояете Qos guarantee, из-за невозможности переопредения реквестов/лимитов у istio-init. То есть все ваши поды теперь будут burstable
@TheBasfeo10 ай бұрын
Один лучших докладчиков, которого интересно слушать. Что по линстору, что по небуле.
@musicthreads10 ай бұрын
Чесанул от призыва?
@vandud10 ай бұрын
мне кажется он слишком стар для этого
@musicthreads10 ай бұрын
@@vandud А мне кажется, что он слишком умён для этого