Всех с пятницей!
На этой неделе было как-то многовато сбоев и проблем, причем все они были довольно простые, и можно было их избежать. Наверное, когда пишешь постмортем, всегда все кажется логичным, но что с этим делать, и можно ли как-то с этим бороться?
Мне кажется, очень важно как можно лучше представлять, что может пойти не так, еще когда только начинаешь что-то менять. Хорошая идея — заранее прописать план работы. Как у вас с этим обстоит, практикуете?
На этой неделе было как-то многовато сбоев и проблем, причем все они были довольно простые, и можно было их избежать. Наверное, когда пишешь постмортем, всегда все кажется логичным, но что с этим делать, и можно ли как-то с этим бороться?
Мне кажется, очень важно как можно лучше представлять, что может пойти не так, еще когда только начинаешь что-то менять. Хорошая идея — заранее прописать план работы. Как у вас с этим обстоит, практикуете?
Как встроить безопасность в свои процессы?
➡️ В продолжение темы DevSecOps — бесплатный вебинар с экспертами Kaspersky и Positive Technologies.
🪩 Dev vs Sec: всё ещё не разговаривают — почему?
🪩 Что DevSecOps может, а что не может?
🪩 Где DevSecOps реально помогает бизнесу, а где мешает?
🪩 Time to market — вечная басня, которая не про DevSecOps
🪩 Где в DevSecOps сейчас Ops, если DevSecOps это AppSec?
Когда: 4 июня в 19:00 мск
➡️ Ссылка на трансляцию придёт в бота в день вебинара. Занимайте места в первом ряду!
Когда: 4 июня в 19:00 мск
Please open Telegram to view this post
VIEW IN TELEGRAM
Где вы храните Terraform state?
Anonymous Poll
14%
Локально на сервере
39%
Gitlab
4%
Postgres
3%
Consul
43%
S3
9%
Свой вариант
DevOps Upgrade: что изменится в 11 потоке
На прошлой неделе мы запустили набор на новый поток. И чтобы лето, солнце и жара не испортили вам весь процесс обучения, мы решили откорректировать программу. Вот, что изменилось:
➡️ Длительность потока — 9 месяцев, вместо привычных 6.
Мы добавили вводный модуль для плавного погружения в процесс обучения. Посмотрим путь развития DevOps-инженера, подтянем базу Docker, Git и Linux, научимся совмещать жизнь, работу и обучение.
➡️ Неделя 1. Знакомство и вводная встреча с ментором и куратором, входное тестирование, roadmap DevOps.
Открываем вводные курсы на выбор: большой видеокурс по Linux, введение в Ansible и Docker, подготовительный курс по Git. Для тех, кому не надо ничего подтягивать — пробный проект на стенде.
➡️ Неделя 2. Изучение вводных курсов, тренинг по тайм-менеджменту и самообучению.
➡️ Неделя 3-4. Прохождение вводных курсов Самостоятельный трек + поддержка от куратора и ментора.
➡️ Неделя 5. Плавный вход в модуль Ansible с увеличенным временем прохождения.
Старт потока — 30 июня.
Цену мы тоже снизили — до 31 мая присоединиться к потоку можно за 135 000 ₽ (вместо привычных 150-160).
⭐️ Узнать подробности и забронировать раннюю цену — на странице курса.
#devops_upgrade
На прошлой неделе мы запустили набор на новый поток. И чтобы лето, солнце и жара не испортили вам весь процесс обучения, мы решили откорректировать программу. Вот, что изменилось:
Мы добавили вводный модуль для плавного погружения в процесс обучения. Посмотрим путь развития DevOps-инженера, подтянем базу Docker, Git и Linux, научимся совмещать жизнь, работу и обучение.
Открываем вводные курсы на выбор: большой видеокурс по Linux, введение в Ansible и Docker, подготовительный курс по Git. Для тех, кому не надо ничего подтягивать — пробный проект на стенде.
Старт потока — 30 июня.
Цену мы тоже снизили — до 31 мая присоединиться к потоку можно за 135 000 ₽ (вместо привычных 150-160).
#devops_upgrade
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Коллеги, приветствую!
На этой неделе, вместо привычного теста с выбором варианта ответа у нас было обсуждение, где лучше хранить Terraform state.
Я, как и большинство из вас, чаще использую S3 или Gitlab. На видео подробно рассказал, почему, и в каком случае предпочтителен тот или иной вариант⬆️
Вижу, что много кто выбрал хранение локально — интересно, почему? Вопрос в недостатке автоматизации, или вы какую-то конкретную задачу решаете таким способом? И как вы выполняете бэкапирование этого стейта?
Поделитесь в комментариях⬇️
На этой неделе, вместо привычного теста с выбором варианта ответа у нас было обсуждение, где лучше хранить Terraform state.
Я, как и большинство из вас, чаще использую S3 или Gitlab. На видео подробно рассказал, почему, и в каком случае предпочтителен тот или иной вариант
Вижу, что много кто выбрал хранение локально — интересно, почему? Вопрос в недостатке автоматизации, или вы какую-то конкретную задачу решаете таким способом? И как вы выполняете бэкапирование этого стейта?
Поделитесь в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Blameless ≠ Безответственность: почему это ключ к надежности ваших систем
Blameless culture — это не просто модный термин. Это фундаментальный принцип построения устойчивых, надежных и постоянно улучшающихся систем.
Почему Blameless — это критически важно:
➡️ Фокус на проблеме, а не на людях
Когда случается инцидент, наша главная цель — понять, что пошло не так и почему система позволила этому случиться, а не кто нажал «ту самую кнопку». Поиск виноватых мгновенно создает атмосферу страха.
➡️ Честность и прозрачность
Люди боятся сообщать об ошибках или неочевидных рисках, если знают, что их накажут. Blameless поощряет открытое обсуждение факторов, приведших к сбою (включая дизайн системы, процессы, документацию, давление сроков), что абсолютно необходимо для настоящего постмортема.
➡️ Учимся на реальности
Самые ценные уроки извлекаются из провалов. Если люди скрывают детали из-за страха, мы теряем возможность по-настоящему понять слабые места и исправить системные причины.
➡️ Скорость восстановления и улучшения
Энергия, потраченная на поиск виноватого — это энергия, отнятая у анализа первопричин и внедрения исправлений. Blameless ускоряет процесс реального устранения проблем.
➡️ Психологическая безопасность
Команда, где можно ошибаться и обсуждать ошибки без страха унижения, — это команда, которая смело экспериментирует, быстрее учится и эффективнее сотрудничает.
Но есть важный нюанс, который обязательно нужно понимать: Blameless — это НЕ отсутствие ответственности!
Ответственность присутствует, но она смещается от наказания инженера за конкретное действие/ошибку к ответственности команды в целом за:
➡️ Активное и открытое участие в разборе инцидентов
➡️ Усердный поиск корневых причин, глубже «человеческой ошибки» (почему процесс не предотвратил ее? почему мониторинг не сработал? почему документация была неясной?)
➡️ Внедрение улучшений, выявленных в постмортеме, чтобы предотвратить повтор инцидента
➡️ Совершенствование систем и процессов
➡️ Понимание, что люди — часть системы, и наша задача — строить системы, устойчивые к неизбежным человеческим ошибкам (через автоматизацию, проверки, четкие процедуры, улучшенный мониторинг и алертинг).
Проще говоря:
🍀 Blameless
Эта ошибка произошла. Давайте поймем причины, включая то, как система/процесс не защитили нас от нее, и исправим это так, чтобы это больше не повторилось.
🍀 Безответственность
Человеский фактор, ну ошибся человек, бывает. Ничего страшного, ничего делать не будем.
Blameless культура — это мощный инструмент инженерной зрелости. Она позволяет нам превращать неизбежные инциденты в рычаги для реального улучшения надежности. Она требует высокой ответственности команды за глубокий анализ, честность и активные действия по исправлению системных недостатков.
Blameless culture — это не просто модный термин. Это фундаментальный принцип построения устойчивых, надежных и постоянно улучшающихся систем.
Почему Blameless — это критически важно:
Когда случается инцидент, наша главная цель — понять, что пошло не так и почему система позволила этому случиться, а не кто нажал «ту самую кнопку». Поиск виноватых мгновенно создает атмосферу страха.
Люди боятся сообщать об ошибках или неочевидных рисках, если знают, что их накажут. Blameless поощряет открытое обсуждение факторов, приведших к сбою (включая дизайн системы, процессы, документацию, давление сроков), что абсолютно необходимо для настоящего постмортема.
Самые ценные уроки извлекаются из провалов. Если люди скрывают детали из-за страха, мы теряем возможность по-настоящему понять слабые места и исправить системные причины.
Энергия, потраченная на поиск виноватого — это энергия, отнятая у анализа первопричин и внедрения исправлений. Blameless ускоряет процесс реального устранения проблем.
Команда, где можно ошибаться и обсуждать ошибки без страха унижения, — это команда, которая смело экспериментирует, быстрее учится и эффективнее сотрудничает.
Но есть важный нюанс, который обязательно нужно понимать: Blameless — это НЕ отсутствие ответственности!
Ответственность присутствует, но она смещается от наказания инженера за конкретное действие/ошибку к ответственности команды в целом за:
Проще говоря:
Эта ошибка произошла. Давайте поймем причины, включая то, как система/процесс не защитили нас от нее, и исправим это так, чтобы это больше не повторилось.
Человеский фактор, ну ошибся человек, бывает. Ничего страшного, ничего делать не будем.
Blameless культура — это мощный инструмент инженерной зрелости. Она позволяет нам превращать неизбежные инциденты в рычаги для реального улучшения надежности. Она требует высокой ответственности команды за глубокий анализ, честность и активные действия по исправлению системных недостатков.
Please open Telegram to view this post
VIEW IN TELEGRAM
DevOps Upgrade: рассказываю про помодульную оплату (на самом деле все просто)
В 11 потоке мы решили иначе подойти к формату рассрочки и сделали возможность оплаты равными частями перед началом каждого модуля.
Как это работает:
➡️ финальная стоимость делится на 6 равных платежей, которые вносятся перед началом каждого нового модуля, кроме финального задания
➡️ выйти из процесса обучения можно после любого модуля — оплачивать непройденные модули не нужно
➡️ программа курса построена в формате сквозного проекта, поэтому пропустить модуль и вернуться на следующий нельзя
➡️ если вы не успеваете учиться, можно бесплатно перевестись на следующий поток
Присоединиться к 11 потоку можно до конца июля, пока идет вводная часть, но цена к тому моменту будет выше.
Сейчас занять место можно за195 000 ₽ 155 000 ₽, или 25 833 ₽/модуль.
⭐️ Узнать подробности и забронировать цену — на странице курса.
#devops_upgrade
В 11 потоке мы решили иначе подойти к формату рассрочки и сделали возможность оплаты равными частями перед началом каждого модуля.
Как это работает:
Присоединиться к 11 потоку можно до конца июля, пока идет вводная часть, но цена к тому моменту будет выше.
Сейчас занять место можно за
#devops_upgrade
Please open Telegram to view this post
VIEW IN TELEGRAM
Вторник — день, когда мы традиционно решаем простые (или не очень) задачи ⭐️
#задача
Выберите правильный ответ в опросе ниже⬇️
#задача
Выберите правильный ответ в опросе ниже
Please open Telegram to view this post
VIEW IN TELEGRAM
Какой этап (stage) присутствует по умолчанию при создании пайплайна?
Anonymous Quiz
20%
run
9%
script
25%
job
22%
stage
23%
test
2%
prod
Сказки DevSecOps: вебинар уже через час ⌛️
🪩 Как перестать тушить пожары и встроить безопасность в процессы без потери скорости
🪩 Time-to-market и безопасность: можно ли совместить?
🪩 Где безопасность реально помогает бизнесу, а где — тормозит?
🪩 Как избежать простоя на миллионы?
🪩 Почему компании с системным DevSecOps теряют в 5 раз меньше данных?
🪩 Как перестать «докупать сканеры» и начать действовать?
Спикеры:
➡️ Андрей Сухоруков, Team Lead DevOps/SRE/DevSecOps (нужное подчеркнуть), Лаборатория Касперского
➡️ Артем Кармазин, ведущий эксперт внедрения процессов
безопасной разработки, Positive Technologies
➡️ Мария Шеховцова, руководитель направления архитектуры и анализа направления безопасной разработки, Positive Technologies
Ссылка на вебинар придет в бота перед началом трансляции. Подключайтесь!
Спикеры:
безопасной разработки, Positive Technologies
Ссылка на вебинар придет в бота перед началом трансляции. Подключайтесь!
Please open Telegram to view this post
VIEW IN TELEGRAM
Признайтесь, кто закрывает время в календаре на «пообедать»?
Уверен, что каждый из вас хотя бы раз так делал. А что, если я скажу, что такие «защищенные часы» могут помочь вам расти в карьере?
Когда операционка съедает все ваше время, вы не успеваете думать и, как следствие, расти. Загвоздка в том, что операционка съест время в любом случае — на то она и операционка. У вас всегда будут незавершенные задачи, проекты, созвоны и т.д. Чтобы у вас было время на рост, его нужно выделить.
➡️ Что такое «защищенные часы»?
Это слоты в вашем расписании, которые забиты как реальные встречи, никогда не отменяются (но в самом крайнем случае могут быть перенесены или сокращены) и имеют четкую структуру и цель.
➡️ Как внедрить?
Выделите час в неделю и создайте встречу с самим собой в рабочем календаре. Пропишите повестку, поставьте напоминалку и предупредите команду, что в этот час вы недоступны. Не двигайте, чтобы «доделать еще одну задачу» или «помочь, а то как же они без меня». Отменить или перенести «защищенный час» можно только в крайнем, критическом случае (уровень «апокалипсис», не меньше).
➡️ Чем заполнить защищенный час?
Читать. Апдейтить карьерный план. Разбирать итоги (что сработало, а что нет).
Важно! Это не час для отдыха. Это час для осознанного планирования и рефлексии.
➡️ Зачем это нужно?
Ну, во-первых, для повышения осознанности (знаю, это слово у многих вызывает зубную боль, но что уж тут поделать). Вы начнете видеть, какие задачи реально двигают вас к цели, а какие тормозят.
Кроме того, у вас появятся темы для разговоров с руководством — когда вы понимаете ценность своей работы, «продать» ее становится проще.
И третье — отсутствие стагнации. Если регулярно анализировать свою работу, застоя не будет.
Ну что, кто будет пробовать? А кто уже пробовал? Делитесь в комментариях
🔥, если нужно больше подобных постов
Уверен, что каждый из вас хотя бы раз так делал. А что, если я скажу, что такие «защищенные часы» могут помочь вам расти в карьере?
Когда операционка съедает все ваше время, вы не успеваете думать и, как следствие, расти. Загвоздка в том, что операционка съест время в любом случае — на то она и операционка. У вас всегда будут незавершенные задачи, проекты, созвоны и т.д. Чтобы у вас было время на рост, его нужно выделить.
Это слоты в вашем расписании, которые забиты как реальные встречи, никогда не отменяются (но в самом крайнем случае могут быть перенесены или сокращены) и имеют четкую структуру и цель.
Выделите час в неделю и создайте встречу с самим собой в рабочем календаре. Пропишите повестку, поставьте напоминалку и предупредите команду, что в этот час вы недоступны. Не двигайте, чтобы «доделать еще одну задачу» или «помочь, а то как же они без меня». Отменить или перенести «защищенный час» можно только в крайнем, критическом случае (уровень «апокалипсис», не меньше).
Читать. Апдейтить карьерный план. Разбирать итоги (что сработало, а что нет).
Важно! Это не час для отдыха. Это час для осознанного планирования и рефлексии.
Ну, во-первых, для повышения осознанности (знаю, это слово у многих вызывает зубную боль, но что уж тут поделать). Вы начнете видеть, какие задачи реально двигают вас к цели, а какие тормозят.
Кроме того, у вас появятся темы для разговоров с руководством — когда вы понимаете ценность своей работы, «продать» ее становится проще.
И третье — отсутствие стагнации. Если регулярно анализировать свою работу, застоя не будет.
Ну что, кто будет пробовать? А кто уже пробовал? Делитесь в комментариях
🔥, если нужно больше подобных постов
Please open Telegram to view this post
VIEW IN TELEGRAM
Вы точно знаете, сколько денег съедают ваши облачные сервисы?
Слёрм запускает серию бесплатных встреч, на которых будут разбирать решения в области FinOps:
🪩 неверное использование облачных ресурсов из-за непонимания их специфики;
🪩 избыточную надёжность (SRE);
🪩 оverengineering — избыточное усложнение инструментов, пайплайнов, процессов.
➡️ Первый вебинар «Облачные решения: как снизить затраты и повысить эффективность?» — уже на следующей неделе.
Программа вебинара:
➡️ Типичные ошибки при работе с облачными сервисами и их влияние на бизнес.
➡️ Настройка сетевых сервисов и контроль доступа.
➡️ Как неправильный выбор ресурсов может привести к сбоям.
➡️ Почему резервное копирование — обязательная часть стратегии.
Когда: 11 июня в 17:00 мск
Занять место на вебинаре — через бота.
Слёрм запускает серию бесплатных встреч, на которых будут разбирать решения в области FinOps:
Программа вебинара:
Когда: 11 июня в 17:00 мск
Занять место на вебинаре — через бота.
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Коллеги, приветствую!
Сегодня пятница, а значит, можно поделиться тем, что произошло за неделю. Так что ловите сказ о том, что меня сильнее всего выбесило⬆️
Почему в документациях никто не пишет, как на самом деле все должно работать? А ошибки в документациях — это вообще отдельная боль.
А что вас бесило на этой неделе? Поделитесь, чтобы уйти на выходные с легким сердцем⬇️
Сегодня пятница, а значит, можно поделиться тем, что произошло за неделю. Так что ловите сказ о том, что меня сильнее всего выбесило
Почему в документациях никто не пишет, как на самом деле все должно работать? А ошибки в документациях — это вообще отдельная боль.
А что вас бесило на этой неделе? Поделитесь, чтобы уйти на выходные с легким сердцем
Please open Telegram to view this post
VIEW IN TELEGRAM
Как насчет обстоятельного разговора про управление кластерами?🤔
Мы с Виталием Лихачевым, спикером курсов Слёрма по k8s, решили провести совместный вебинар. Будем обсуждать Rancher в продакшене, а именно:
⭐️ централизованное управление кластерами через единый интерфейс;
⭐️ автоматизированные бэкапы и восстановление;
⭐️ настройку доступа для команд и интеграцию внешней аутентификации;
⭐️ встроенные мониторинг и использование магазина приложений.
Подробно покажем и расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, поделимся собственным опытом и best practices.
Когда: 16 июня в 19:00 мск
Занять место на вебинаре➡️ через бота.
Мы с Виталием Лихачевым, спикером курсов Слёрма по k8s, решили провести совместный вебинар. Будем обсуждать Rancher в продакшене, а именно:
Подробно покажем и расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, поделимся собственным опытом и best practices.
Когда: 16 июня в 19:00 мск
Занять место на вебинаре
Please open Telegram to view this post
VIEW IN TELEGRAM
Коллеги, ссылку на бота исправил, сейчас все должно работать.
Жду вас на вебе 😎
Жду вас на вебе 😎
Коллеги, кто сталкивался?
В пятницу рассказывал вам про свое отношение к неправильной документации, пришло время поделиться тем, что произошло. Я решил создать кластер k8s в облаке через terraform. Взял готовый список ресурсов из примера и, конечно, дополнил их по-своему.
Кластер создался, но возникла проблема: под приложения ругается на то, что не соединяется с другим сервисом в интернете. Для диагностики создаю под:
И вижу, что резолва имен вообще нет. После скейла core-dns с 2 до 1 проверка начинает проходить, но иногда проблема еще 1 раз из 10 воспроизводится.
Вопрос: как дальше диагностировать проблему, что это вообще может быть, и при чем тут документация? Поделитесь в комментах, может, кому-то знакомо?
В пятницу рассказывал вам про свое отношение к неправильной документации, пришло время поделиться тем, что произошло. Я решил создать кластер k8s в облаке через terraform. Взял готовый список ресурсов из примера и, конечно, дополнил их по-своему.
Кластер создался, но возникла проблема: под приложения ругается на то, что не соединяется с другим сервисом в интернете. Для диагностики создаю под:
apiVersion: v1
kind: Pod
metadata:
name: dns-checker
spec:
containers:
- name: dns-checker
image: busybox:latest
command: ["/bin/sh", "-c"]
args:
- while true; do
echo "=== DNS Test START ===";
nslookup kubernetes.default.svc.cluster.local;
nslookup google.com;
echo "=== DNS Test END ===";
sleep 30;
done
restartPolicy: Never
И вижу, что резолва имен вообще нет. После скейла core-dns с 2 до 1 проверка начинает проходить, но иногда проблема еще 1 раз из 10 воспроизводится.
Вопрос: как дальше диагностировать проблему, что это вообще может быть, и при чем тут документация? Поделитесь в комментах, может, кому-то знакомо?
DevOps Upgrade: летние гранты на обучение! 🍉
Коллеги, всем привет. Я к вам с большой новостью: мы с командой решили возродить гранты на обучение.
На летнем потоке их будет 10 для тарифа «Комфорт»:
⭐️ 2 места — скидка 100%
⭐️ 3 места — скидка 50%
⭐️ 5 мест — скидка 35%
Как получить грант:
➡️ Заполнить входную анкету
➡️ Пройти тестирование до 20 июня 2025 года
➡️ Дождаться результатов — их я объявлю на канале 23 июня
Тест состоит из 42 вопросов и помогает проверить вашу готовность к обучению — от знания Linux и Docker до мотивации. На прохождение дается 45 минут. Удачи!
#devops_upgrade
Коллеги, всем привет. Я к вам с большой новостью: мы с командой решили возродить гранты на обучение.
На летнем потоке их будет 10 для тарифа «Комфорт»:
Как получить грант:
Тест состоит из 42 вопросов и помогает проверить вашу готовность к обучению — от знания Linux и Docker до мотивации. На прохождение дается 45 минут. Удачи!
#devops_upgrade
Please open Telegram to view this post
VIEW IN TELEGRAM