За что платят SRE и DevOps?

➡️ Совместный эфир с Кириллом Борисовым завтра в 19:00.

– Разберем вакансии SRE и DevOps-инженеров
– Рассмотрим, что могут спрашивать по требованиям, которые заявлены в вакансии
– Расскажем, какие навыки ценятся и сколько за них платят
– Проанализируем, какие требования на самом деле критичные, а какие — лишь «хотелки» HR

А еще расскажем про собственный опыт (в том числе опыт найма) и попытаемся наконец ответить на вечный вопрос — в чем смысл жизни разница между SRE и DevOps (вдруг кто-то ещё не разобрался).

Встречаемся завтра в 19:00 на канале Кирилла «Путь SRE». Предварительная регистрация не нужна, но лучше подписаться и включить уведомления, чтобы не пропустить начало 😎

Коллеги, приветствую!

По техническим причинам сегодняшний лайв в канале Кирилла переносится на вторник, 20 мая в 19:00 мск. Просим прощения, случился форс-мажор!

Подписывайтесь на канал Кирилла, чтобы не пропустить трансляцию ➡️ Путь SRE

Как у вас в команде с безопасностью?

В июне Слёрм запускает интенсив по DevSecOps, подробности — в посте ⬇️

Спойлер: одним из спикеров будет человек, которого вы хорошо знаете — он частенько приходит на наши эфиры 😎

Как отвечать на ТЕ САМЫЕ вопросы на интервью?

Девопс миддл закончился, а тема карьеры вечна — будем к ней периодически возвращаться. Тем более, что завтра на лайве мы с Кириллом тоже будем касаться найма.

Какие вопросы рекрутера бесят вас больше всего?

🔥 Кем вы видите себя через 5 лет?
🔥 Почему вы хотите у нас работать?
🔥 Опишите свои слабые стороны
(список можно продолжить)

И если с первыми двумя вопросами все более-менее понятно, то вопрос про слабые стороны — это вопрос со звездочкой.

Интернет советует отвечать что-то вроде «я слишком много работаю, не умею отдыхать», чтобы рекрутер понял, что вы очень трудолюбивые. Не надо так 😅

Лучше внимательно изучите перед интервью текст вакансии и определите, какие навыки для нее критичны — они точно не должны быть вашим слабым местом. Затем подумайте о некритичных навыках: например, на линейной позиции навык управления командой не особо актуален.

Поздравляю, у вас есть готовый ответ на этот вопрос — гораздо более взвешенный, зрелый и честный 🔥

Продолжаем тему DevSecOps

Как думаете, насколько безопасны ваши проекты? Коллеги из Слёрма создали короткий тест из пяти вопросов для самодиагностики, который поможет найти слабые места раньше, чем это сделают другие.

Тест лежит в боте. А ещё там есть бесплатный чек-лист по DevSecOps и карта зрелости и приоритетов.

↘️ Забрать — по ссылке.

🔤🔤🔤🔤🔤🔤🔤🔤 🔤🔤🔤🔤

Слёрм открывает набор на одиннадцатый поток DevOps Upgrade!

Поток стартует 30 июня и продлится 9 месяцев вместо привычных 6.

Особенности 11 потока:
🟢 вводный модуль для плавного погружения в процесс обучения
🟢 возможность добавлять попытки при сдаче практических заданий
🟢 бесплатный перенос на следующий поток
🟢 больше работы с куратором, помощь в разборе сложных вопросов и задач
🟢 возможность оплаты равными долями перед началом каждого модуля

До 31 мая действуют ранние цены на обучение:
➡️ 135 000 ₽ для тарифа Комфорт
➡️ 170 000 ₽ для тарифа Комфорт карьера
➡️ 315 000 ₽ для тарифа VIP

⭐️ Забронировать раннюю цену и занять место на потоке — на странице курса.

#devops_upgrade

Как встроить безопасность в свои процессы?

➡️ В продолжение темы DevSecOps — бесплатный вебинар с экспертами Kaspersky и Positive Technologies.

🪩 Dev vs Sec: всё ещё не разговаривают — почему?
🪩 Что DevSecOps может, а что не может?
🪩 Где DevSecOps реально помогает бизнесу, а где мешает?
🪩 Time to market — вечная басня, которая не про DevSecOps
🪩 Где в DevSecOps сейчас Ops, если DevSecOps это AppSec?

Когда: 4 июня в 19:00 мск

➡️ Ссылка на трансляцию придёт в бота в день вебинара. Занимайте места в первом ряду!

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

Коллеги, приветствую!

На этой неделе, вместо привычного теста с выбором варианта ответа у нас было обсуждение, где лучше хранить Terraform state.

Я, как и большинство из вас, чаще использую S3 или Gitlab. На видео подробно рассказал, почему, и в каком случае предпочтителен тот или иной вариант ⬆️

Вижу, что много кто выбрал хранение локально — интересно, почему? Вопрос в недостатке автоматизации, или вы какую-то конкретную задачу решаете таким способом? И как вы выполняете бэкапирование этого стейта?

Поделитесь в комментариях ⬇️

Blameless ≠ Безответственность: почему это ключ к надежности ваших систем

Blameless culture — это не просто модный термин. Это фундаментальный принцип построения устойчивых, надежных и постоянно улучшающихся систем.

Почему Blameless — это критически важно:

➡️ Фокус на проблеме, а не на людях
Когда случается инцидент, наша главная цель — понять, что пошло не так и почему система позволила этому случиться, а не кто нажал «ту самую кнопку». Поиск виноватых мгновенно создает атмосферу страха.

➡️ Честность и прозрачность
Люди боятся сообщать об ошибках или неочевидных рисках, если знают, что их накажут. Blameless поощряет открытое обсуждение факторов, приведших к сбою (включая дизайн системы, процессы, документацию, давление сроков), что абсолютно необходимо для настоящего постмортема.

➡️ Учимся на реальности
Самые ценные уроки извлекаются из провалов. Если люди скрывают детали из-за страха, мы теряем возможность по-настоящему понять слабые места и исправить системные причины.

➡️ Скорость восстановления и улучшения
Энергия, потраченная на поиск виноватого — это энергия, отнятая у анализа первопричин и внедрения исправлений. Blameless ускоряет процесс реального устранения проблем.

➡️ Психологическая безопасность
Команда, где можно ошибаться и обсуждать ошибки без страха унижения, — это команда, которая смело экспериментирует, быстрее учится и эффективнее сотрудничает.

Но есть важный нюанс, который обязательно нужно понимать: Blameless — это НЕ отсутствие ответственности!

Ответственность присутствует, но она смещается от наказания инженера за конкретное действие/ошибку к ответственности команды в целом за:

➡️ Активное и открытое участие в разборе инцидентов
➡️ Усердный поиск корневых причин, глубже «человеческой ошибки» (почему процесс не предотвратил ее? почему мониторинг не сработал? почему документация была неясной?)
➡️ Внедрение улучшений, выявленных в постмортеме, чтобы предотвратить повтор инцидента
➡️ Совершенствование систем и процессов
➡️ Понимание, что люди — часть системы, и наша задача — строить системы, устойчивые к неизбежным человеческим ошибкам (через автоматизацию, проверки, четкие процедуры, улучшенный мониторинг и алертинг).

Проще говоря:

🍀 Blameless
Эта ошибка произошла. Давайте поймем причины, включая то, как система/процесс не защитили нас от нее, и исправим это так, чтобы это больше не повторилось.
🍀 Безответственность
Человеский фактор, ну ошибся человек, бывает. Ничего страшного, ничего делать не будем.

Blameless культура — это мощный инструмент инженерной зрелости. Она позволяет нам превращать неизбежные инциденты в рычаги для реального улучшения надежности. Она требует высокой ответственности команды за глубокий анализ, честность и активные действия по исправлению системных недостатков.