DevOpsConf - профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации. Проходит как самостоятельно, так и в составе фестиваля "Российские интернет-технологии++" (ritfest.ru/).
На канале публикуем материалы о поддержке и эксплуатации IT-проектов: логирование и мониторинг, технологии виртуализации и контейнеризации, управление конфигурацией, непрерывное развёртывание и деплой, технологии отказоустойчивости и катастрофоустойчивости, а также управление в эксплуатации.
Присоединяйтесь к крупнейшему комьюнити IT-инженеров!
Следующая профессиональная конференция DevOpsConf, полностью посвященная инженерным процессам и практикам, состоится в марте 2024 года.
Приглашаем на DevOpsConf 2024, которая пройдет 4 и 5 марта 2024 в Москве. Программа, подробности и билеты по ссылке: devopsconf.io/moscow/2024
мне интересно другое: если так гонять кандидата по траблшутингу, то какой же пипец там творится с их организацией труда и планированием? в основном куча пожаров случается там, где всем всё пох и все чилят вместо того, чтобы думать
в нормальной команде должны быть SOP и алерты. Срабатывает алерт, там инструкция для джуна которую нужно выполнить. А не "где искать, куда смотреть" вооооот....
Здравствуйте, обращаем ваше внимание, что доклад можно обсудить со спикером на официальном канале конференции t.me/DevOpsConfChannel и задать в чате канала конференции свои вопросы t.me/DevOpsConfTalks
Полностью согласен с автором данного видео. Я бы добавил ещё пост-проверки, после вливания. Например, проверки на уязвимости - тяжелая проверка и её стоит выполнять останавливая процесс вливания. Также можно добавить динамический анализатор кода после вливания. Такие проверки выполнять, например, один раз в сути и производить разбор отчётов.
Здравствуйте, обращаем ваше внимание, что доклад можно обсудить со спикером на официальном канале конференции t.me/DevOpsConfChannel и задать в чате канала конференции свои вопросы t.me/DevOpsConfTalks
Как говорил классик - "Называй меня хоть Сьюзанной, главное плати нормально". Почему так восхваляют девопс - это может быть хороший linux админ с опытом или ямл девелопер. Собеседуем людей, больше половины валятся на вопросах о LA, далее про контейнеры и оркестраторы, начинаешь лезть на уровень ниже, то все - плывем... Куда мы катимся то?
А зачем девопсу лезть на уровень ниже, вот у меня есть мэнэджэд кубер, я деплою туда приложения, кто меня пустит на тот уровень про который вы спрашиваете, я же не инфраструктурный инженер, зачем мне это надо знать?
@@rusik2293 базу надо знать. Например ситуация у вас контейнеры с таймаутами отвечают. В чем проблема? В приложении кривом, в сети кубера, в внешней сети или вообще у вас tcp mem коннекты не освобождает по какой то причине. Вот такие ямл девелоперы Нина,Илья,Харитон, Ульяна,Яков не смогут провести дебаг и имя команды будет по первым буквам коллег...
@@rusik2293 всё чаще бывают случаи когда у тебя не менеджед кубер (тот же гугл/авс повышает цены и не слабо) и их несколько в инфре, под разные проекты. тогда появляються требования понимать что у тебя "внизу", а не только отвечать на собесе - "я пишу пайпланы для деплоя"
На самом деле интересное предложение, архитектор согласно разрабатываемому приложению и его функциям разрабатывает набор инструментов, девопс приходит на встречу и выражает своё фи или не согласие с использованием инструмента "по какой-то своей причине", архитектор сидит и чешет репу, как ему сделать софт согласно требованиям, которые к нему спустили остальные отделы, а девопс идёт дальше пить смузи. Наверное так и буду делать. =)
Слов много, в основном про архитектуру и принципы её проектирования. Причём тут ДевОпс??? Все проблемы поднятые в докладе решаются грамотным Архитектором и опытными бэками\фронтами. Такое ощущение что кейсы от какого то стартапа, где каждый имеет 2-3 смежных обязанности. ДевОпсы НЕ должны лезть в архитектуру при наличии грамотного Архитектора в компании. Если Архитектора в компании нет, но она замахивается на критичные приложения со сложной интеграцией - здоровья погибшим! Доклад делал человек который "не очень верит в аналитиков, не очень верит в архитекторов"(с) и пытается их заместить кем то еще.
Вот про таких людей как вы и говорил докладчик: Я буду ансиблой тераформить и не лезьте ко мне =) понятно, что в условном банке так не будет как говорит докладчик.Но, в адекватной компании, где считают деньги, девопс может принимать архитектурные решения.
@@user-mu3dl8jp1k у нас есть архитектурный комитет, два архтектора которые разрабатывают архитектуру приложений. если (крайне редко) в архитектуре используется устаревший компонент/сервис, то девопсы могут на это указать и предложить изменения, но ни коим образом не лезут с наыязыванием своей концепции. у них достаточно плановой (развертывания согласно проекту и архитектуре) и внеплановой (разработчики накосорезили и сломали себе стенд) работы. у всех в компании есть должностные инструкции, есть обязанности, есть зоны ответственности. или нужно чтобы девопс-инженер внедривший свою архитектуру вместо той что предложил архитектор потом отвечал за ботлнеки в огромном облачном приложении при его масштабировании? хочешь проектировать - иди в архитекторы, расти в архитекторы, кто не даёт? но зачем помимо своих основных обязанностей, которые расписаны на 2 недели вперед, еще и в архитектуру лезть? особенно если там есть кому её делать.
Здравствуйте, обращаем ваше внимание, что доклад можно обсудить со спикером на официальном канале конференции и задать в чате канала конференции свои вопросы t.me/DevOpsConfTalks
Про clickhouse, объем и тонкости не рассказал. Ведь надо вставлять большими батчами и шардируется ли кластер, есть же ещё тема по хранению логов 1 год, тоже часто в вставляют в clickhouse.
Отличная презентация, спасибо! По воле судьбы сейчас пытаюсь составить регламент по работе с инцидентами внутри компании, ранее подобного опыта не было и Ваш доклад очень помог. Вот бы Вы еще выложили сам регламент, цены бы Вам не было:D
Намного проще делать Регламент не с чистого листа, а взять за основу "рыбу" любого другого регламента (можно найти в интернете) и дополнять своими требованиями.
Здравствуйте, обращаем ваше внимание, что доклад можно обсудить со спикером на официальном канале конференции и задать в чате канала конференции свои вопросы t.me/DevOpsConfTalks
Здравствуйте, обращаем ваше внимание, что доклад можно обсудить со спикером на официальном канале конференции t.me/DevOpsConfChannel и задать в чате канала конференции свои вопросы t.me/DevOpsConfTalks
Наверное, самый банальный и неинтересный доклад. Я если честно так и не понял, какие же "смыслы" CI/CD "потерялись". Банальные проблемы, которые имеют банальные решения.
Герметичный репо это конечно красиво звучит. Но если таких репо 50+, а сотрудников не много в организации. То хранить в каждой свой ci и сопровождать его - это сомнительное удовольствие. Особенно если процесс сборки у этих репо разный. Есть решение вынести ci в репо темплейтов, но тогда уже не будет никакого герметичного репо Имхо, концепция в том виде в котором преподнес автор - жизнеспособна и может приносить пользу, только в небольших проектах
Здравствуйте, обращаем ваше внимание, что доклад можно обсудить со спикером на официальном канале конференции t.me/DevOpsConfChannel и задать в чате канала конференции свои вопросы t.me/DevOpsConfTalks
Да уже нашел, спасибо большое! Прикрепите плиз к выпускам ссылочки от авторов, а то если с телефона смотришь выпуска, приходится с бубном прыгать чтобы из QR вытащить ссылки
Видео о том, как девопс должен уметь все и даже больше, дежурить круглосуточно, а получать как буратино, типичная история найма сотрудников в Тиньков! И не забудьте каждый день благодарить!
