Automation Craft

Как стать Девопс инженером и какие задачи решает junior DevOps.
Мы с Александром подготовили мини гайд по профессии DevOps engineer.
ССЫЛКА НА ВИДЕО

Всем привет! ССЫЛКА НА ВИДЕО
Владимир пришел к нам во второй раз!
Напомню кто не в курсе...

Наш гость Владимир Соколенко!
Site Reliability Engineer (SRE) - Software Production Resilience Engineering (SPRE)
В компании Red Hat!(Чехия)

Мы обсудили, как реально развиваться в IT, зачем нужны сертификаты вроде RHCSA, AWS СSA, CKA и др. как правильно учиться, формировать свою программу обучения, планировать карьеру и не терять мотивацию.

У меня появилось желание сделать разговорный подкаст, который бы освещал внеайтишную жизнь. Поговорить о проблемах с которыми многие сталкиваются, послушать истории из жизни, обсудить разные точки зрения..
Это первая попытка сделать подкаст без айти тематики, но пока это удалось на половину.
Без профессиональных тем не обошлось.

В гостях Глеб Быков. DevOps engineer, ментор:
Канал в телеграм - https://t.me/devopshh

ССЫЛКА НА ВИДЕО

Монтирование закончено! Очень рекомендую к просмотру!
Интервью с Владимиром Соколенко Senior SRE в RED HAT!
Полезная и интересная беседа получилась.
ССЫЛКА НА ВИДЕО



🗣 Консультации | 🏃‍♂️ YouTube | 🏭DevOps Фабрика

Последнюю неделю много про резюме говорил.
И у себя на канале постримил.
И в клубе при Фабрике тоже созвон провёл.

Меня посетила мысль объединить базовые рекомендации по Резюме/CV.

Мини-Гайд-Базовичок:

✍️Название профессии = названию вакансии
Если ты ищешь вакансии, которые называются DevOps engineer, то профессия должна иметь точно такое же название.
🔴 системный администратор, ДевОпс Инженер, Platform engineer, SRE, возьмите_хоть_на_кого-нибудь инженер
🟢 DevOps engineer.

✍️ Опыт работы – это уже выполненная работа
Не копируй описание вакансий. Обычно это абстрактные пустые строки:
🔴 "Администрирование Linux", "Настройка мониторинга".
Пиши от себя и в законченной форме:
🟢 "Администрировал Linux", "Настраивал мониторинг".

✍️ Покажи свои преимущества ещё до собеседования
"Администрировал Linux" - разными людьми может трактоваться по-своему. Выгодно опиши свой опыт, не оставляя шансов на двусмысленную трактовку:
🟢 "Администрировал парк из 100+ серверов на Ubuntu и CentOS. Полностью автоматизировал процесс с помощью Ansible: от бутстрапа под разные нужды (для БД-кластеров, для stage и prod-сред, для балансировщиков нагрузки и т. д.) до настройки и управления серверами под ML и DS".

✍️ Забудь "О себе" и Summary
Если хочешь написать там что-то большее, чем просто "в свободное время занимаюсь спортом", адаптируй это и добавь в свой опыт работы в компании. Пользы будет намного больше. Всё самое важное размещаем в самые важные места. Если ОЧЕНЬ😡 ПРЯМО ХОЧЕТСЯ ПРО СЕБЯ рассказать – сделай это в сопроводительном письме (cover letter).

✍️ Выучил новые технологии? Впиши их в свой рабочий опыт
Бывает, что на текущем месте работы не удаётся применить новые навыки – то нет времени, то нет бюджета, то просто невыгодно компании. Но ты-то наверняка уже придумал, как и что реализовать, или хотя бы попробовать. Если умеешь и научился – добавь в текущий опыт, как будто делал это на работе. Зачем добру пропадать?

✍️ Раз написал – придётся отвечать
Я не пропагандирую откровенное враньё. Если приукрашиваешь – будь готов ответить за это. Стоит подготовиться и ожидать вопросов по всему резюме. Там, где не уверен, – готовься тщательнее. Это почти что Fake it till you make it. А если будешь эти белые пятна закрывать, то ещё и прокачаешь скилл.

✍️Напиши себе огромную хвалебную Оду – потом отредактируешь
Чтобы сделать эффективное резюме, в начале опиши все свои мысли, все достижения по каждой работе широко, хвалебно, с большим количеством подробностей – прям сплошной поток текста. Там, где делал командой, пиши, что делал ты. Там, где видел, как делают, пиши, что делал сам. А потом уже убирай лишнее. Как говорят в среде актёров: не наиграешь – не сыграешь.

Вероятно, не все пункты будут полезны тем, кто начинает с нуля и без релевантного опыта. Для такого случая, думаю, нужен отдельный гайд.
На гайд для резюме "без опыта" – жду реакции.

Ну и конечно, если нужен индивидуальный разбор твоего случая – черкани!

🗣 Консультации | 🏃‍♂️ YouTube

Всем привет!
Давненько не публиковал тут видосики с канала DevOps Фабрика
Сегодня смонтировал и выложил новый мок собес.

Очень рекомендую посмотреть всем!
Не только с точки зрения новых знаний, ответов на вопросы.

Получился особенный разговор!
Виталий сильный состоявшийся специалист. Большой стаж в IT как инженер и менеджер. Мок собеседование - пример стремительно развивающихся технологий. За которыми очень важно поспевать если хочешь оставаться на плаву.

Дайджест уходящих праздников:

💬 Я предлагаю почитать мою субъективную и концентрированную серию постов "Почему DevOps тебя сожрет":
1️⃣ DevOps тебя сожрет
2️⃣ Что скрывается за DevOps-специалистом
3️⃣ Поток задач без конечного результата
4️⃣ Тебе не выучить все эти технологии
5️⃣ Дежурства - любовь моя
6️⃣ К тебе - только с проблемами. Ответственность без силы

Как ты мог заметить, минусы не катастрофические — жить можно. А для кого-то это просто издержки профессии. Честно говоря, мне бы хотелось прочитать что-то такое, прежде чем я начал бы погружаться в девопс как в профессию. Но на тот момент я видел только суперскилового спеца-хакера, многорукого-многочлена, который и сервер починит, и разраба вздрючит, и бизнес научит. И хоть понимание приходит чаще после собственных граблей, но хотя бы куда прилетит черенок приятно осознавать, даже если думаешь, что это будет не так и больно.

Пиши своё мнение, сталкивался с такими минусами? Минусы ли это для тебя? Чё вообще, как тебе девопс?

DevOps тебя сожрёт.
Часть 6

4. К тебе приходят только с проблемами, и порой неизлечимыми.
5. У тебя огромная ответственность, но обычно без огромной силы.

Говорим про среднестатистического девпопса среднестатистического грейда.

Решил объединить эти два пункта. Они обычно ходят рука об руку. Ведь если к тебе приходят с проблемами, чтобы ты их решил, — значит, наделяют (перекладывают) ответственностью. Это, конечно, оправдано, ведь одна из обязанностей, которую указывают в вакансии, — это “траблшутинг, желание докопаться до проблемы и не сдаваться, не обосраться, до сути добраться, в стельку надраться”
Однако, если ты не особо готов к постоянному НЕпланомерному потоку жалоб (без предложений) / просьб / инцидентов — от этого может начать подгорать. А также добавим повышенную ответственность без рычагов влияния,без особой возможности влиять на обстоятельства. Появляется ещё кучка причин для стресса, а ты сидишь со связанными руками, обтекая.

В компании есть спец/команда, который решает проблемы и любимые коллежки по любому чиху отправляется в чатик или ЛС этого спеца \ команды.
И вроде, что не так? Всегда и везде есть спецы, которые решают проблемы в разных командах. Пишут и разработке, и тестировщикам, и, само собой, в техническую поддержку. Сх**ли девопсы особенные?
Это очень справедливые вопросы. И когда по части инфраструктуры страждущие идут спрашивать про инфру — это зае**сь, так и надо. Но со временем происходит перевоплощение чата инфраструктуры в чат “комната грязи”. Как будто devops в глазах коллег — это слуга, который во всём за них разберётся, скажет, куда идти (на х*й), что поправить или даже сам пофиксит.

Тут никакого обмана нет. Если ты идёшь в девопс, то должен осознавать свою важную роль ассенизатора. Это просто факт, который нужно принимать и быть к нему готовым. Пишу об этом только потому, что это специфическая особенность devops инженера, и иногда это может быть реальным минусом, который приводит к выгоранию.

Насчёт ответственности без “силы” — это твоя невозможность повлиять на многие процессы, за которые отвечаешь и получаешь пи**ы. Несмотря на то, какой девопс важный и вся разработка держится на инфре, твои предложения, оптимизации, улучшения, могут быть невыгодны бизнесу. Это часто встречается в любой другой технической профессии, где “тупые фаундеры, построившие с нуля свой бизнес не понимают СЛОЖНЕЙШИХ технических решений, процессов, архитектуры, какая ОС лучше, как зае**ли дейлики, нельзя в прод деплоить в пятницу … и дохера ещё чего”, девопс не исключение.

Трафик вырос, но сервера без апгрейда. Сервис прикладывает сервера. Тебе еб*т мозги, инфра работает плохо — почини, а на запрос о необходимости увеличить косты на ресурсы кладут хер. Ты находишься в стрессе, с горящей жопой, фиксишь то одно, то другое. Начинаешь верить, что проблема в тебе, хотя на самом деле от тебя зависит очень мало, т. к. никакая самая ебе**ая оптимизация чего угодно не справится с ростом трафика в 10 или 100 раз на одних и тех же ресурсах, хотя с 10кой может и справится)))

Тут опять-таки есть пара решений на поверхности.
Первый. Если этот пункт сочетается с остальными, в постах выше — увольняться.
Второй. Принять свою беспомощность и нежелание бизнеса идти навстречу. Честно выполнять работу с тем, что есть, без разрыва жопы.

Это, кстати, важная проблема, создающая замкнутый круг.
Ты думаешь, что тебя насадят на кукан из-за проблем, на которые ты не можешь повлиять и стараешься овертаймить, оверперформить, лишь бы удержать разваливающуюся ху**ю от разрушения.
Достаточно продолжать работать в рамках нормы, и через время бизнес увидит наступление пиз**ца, прислушается к тебе, выделит бюджет. А иначе он будет видеть: “вроде и так работает, пущу-ка я лучше бабло на маркетинг, Вася-девопсер-мастер-супернаходка отлично справляется со всем, правда, сидит по 12–16 часов… накину-ка я ему 10к премии.” НЕ БУДЬ ЭТИМ ВАСЕЙ. (Васи ссори если что)

продолжение поста ниже...

ССЫЛКА НА СТРИМ - стрим через 45 мин начну
Всем привет, кому нечего делать и кто хочет послушать музычку и че нить обсудить - велкоме

DevOps тебя сожрёт.
Часть 5

3. Дежурства


Этот пункт без внимания не могу оставить. Один из самых популярных минусов инфраструктурных специальностей. На самом деле, у меня есть опыт работы devops инженером без дежурств — дежурили разработчики. Но это были отдельные Data Engineering команды.

DevOps — помимо широкого стека технологий, это также про большую ответственность, но часто без “большой силы” (но об этом в следующем посте).
И дежурство — это не только вставать среди ночи, когда прилетел алерт по упавшему сервису.
Это буквально быть на передовой почти любых проблем не только по части твоей инфраструктуры, но и сервисов разработчиков. Чаще всего тебе как будто нужно доказать в первую очередь, что это не проблема на стороне опсов, обнаружить проблему в сервисе и ткнуть разработку лицом туда.

Например, сервис отдаёт 502 на проде, ай-яй-яй, караул. Алерт прилетел.
К тебе разработчик приходит со словами: “Плз, посмотри, что-то упало”, а НЕ “Мы проверили работу сервиса, логи, потребляемые ресурсы — на стороне сервиса не увидели проблемы.” (К слову, обычно есть настроенный мониторинг, чтобы эту инфу получить.)
Идёшь смотреть ресурсы тачки, где крутится лежачий, там всё ок: CPU, сеть, диски — всё в порядке, есть стабильные всплески, как и в любой другой день, но вот memory вызывает подозрение. Проверяешь работу сервиса в контейнере, и там, например, оказалось, что превышается лимит, контейнер падает, а случилось это через пару часов после релиза, так как косячные запросы к БД завалили сервис.

Да, это не касается всех команд разработки. Иногда попадаются команды, которые используют девопс методологию как раз для того, чтобы тоже быстро локализовать проблемы и брать ответственность за инциденты.

Также к дежурству относятся покрытие любых хотелок и вопросов со стороны остальных работников компании. День ото дня эти хотелки\запросы\вопросы очень разнообразны, контексты меняются молниеносно. Такая центрифуга высасывает из тебя все силы к концу рабочего дня. Если вы работаете вдвоём-втроём, то хотя бы раз в неделю ты будешь отправляться в центрифугу. В нормальных компаниях, где не планируется через полгода выкинуть безжизненный кусок человека на улицу, основные таски из бэклога делать не требуют. Правда, не всем так везёт, и после горячей недели тебе могут на дейлике еб**ь мозг за проё***ные сроки у особо важной задачки.

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

Собственно, если ты к фанатам саппорта не относишься, то варианты тоже есть.
— Один из них — не идти туда, где есть дежурства.
— Второй — на собесах заранее спрашивать о количестве инцидентов, о количестве дежурных, о графике дежурств. С этим, конечно, можно жонглировать. Если вас будет два дежурных, неделя через неделю, но инцидентов один в месяц, а разработчиков 10 человек — вполне неплохой вариант. Если вас 5, инциденты каждую неделю, а разработчиков 500 человек — то это, конечно, пиз**ц. Даже если инцидентов один в полгода, то 100 разрабов на одного девопса — это пиз**ц.

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

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

— Забудь о тасках из бэклога. Дежурство — это всегда приоритет, так как запросы горящие, стоящие денег и требующие твоего оперативного внимания.

— Если ты действительно не выдерживаешь и отпуск не помогает — поговори со своим тимлидом о смене твоей профобласти. Если вариантов нет — вероятно, придётся искать новую компанию. Если варианты есть, но тебя кормят завтраками о том, что “скоро поменяем тебя, дежурства кончатся” и т. д., но этого не происходит — есть риск, что тебя выжимают как расходник. Вали скорее, пока не сгорел.

Есть опыт в дежурствах? Нравится саппорт? Расскажи про свой опыт.
(2 пунктика осталось)

17 декабря 2021 года я залил на ютуб свой первый видос.
И этот канал существует получается тоже года три!
2024 выпал из моей жизни .. а все потому что я стал отцом.
Год нелегкий был. Полный эмоциональных качелей от радостей до горестей , туда и обратно. Ну и понятно мне вообще было не до канала.
За это время я переосмыслил свое отношение к IT, к работе, к преподаванию ... ну и собственно к жизни.
Вообще очень круто, что у меня есть люди которые подписаны и иногда даже участвуют в чатах, постах. Я понимаю что большая часть пришла после видео-рассказов по автоматизации и девопсу, а не за моим мнением о чем либо). Но есть те кому это интересно. Круто, что есть место куда я могу высказаться. Очень большая ценность медиа-соц-пространств.

Поздравляю, тебя, с наступающим 2025 годом - годом эгоизма и любви к себе!
Уходящий год показал мне насколько важно не забывать про самого себя. Как бы нас не учили, что быть эгоистом плохо - иногда нужно им быть. Поэтому желаю себе и тебе здорового эгоизма, ЧСВ, ценить своим успехи и неудачи.

Приходи 5 января в 17 00 по МСК на стрим. Я не планирую делать его каким то узкаайтишным. Планирую сидеть и говорить. Если заскучаешь в воскресный вечер залетай ССЫЛКА НА СТРИМ

продолжение поста выше...

Это очередной источник выгорания, который на старте кажется классной возможностью для развития, а в процессе понимаешь, что это сизифов труд в постижении технологий. И тут есть всё так же несколько вариантов не ох***ь от жизни.
— Идти в девопс с пониманием этой особенности (или не идти).
— Если такая особенность — это не твой путь, то искать в сфере инфраструктуры узкую специализацию (Cloud Engineer (не факт), Cleaner Engineer, Release/Build Engineer, Infogypsy Engineer, Kubernetes Engineer (не факт), Barista Engineer и т. д.).
— Сталкиваться с реальностью и убеждаться, что всего знать не нужно, чтобы расти. Ходить на собеседования, участвовать в сообществах, задавать вопросы себе и другим: “А правда вот эта ху*ня такая востребованная и мне она нужна, чтобы работать?”
Вообще, всё, что я тут пишу, — это не отговаривание начинающих. Это, наоборот, попытка показать обратную сторону медали. Так-то я всё еще менторю в Девопс Фабрике и провожу консультации. Просто мне наёб***ть не нравится людей, а помочь с реализацией цели всегда готов!

Потерпите, осталось 3 пункта, и я закончу с этой темой💀.

DevOps тебя сожрет.
Часть 4

2. Технологий, скиллов, тулзов, путей развития, так много, что можно охренеть и не выхренеть обратно.

Тут кажется, мало кого можно удивить.
Да, в айти надо много учиться, постоянно развиваться, изучать что-то новое.
А в какой профессии это не нужно делать? Под каждой статьей/видео, где обсуждается катастрофическая сложность айтишника, обязательно есть пунктик про постоянное обучение. В комментариях тут же насрут гору профессий, где также нужно учиться, чтобы быть\оставаться\стать кем-то стоящим.
Знаешь такие профессии?
И я согласен. “Постоянное обучение” — это них*я не минус, это благодать человеческая.
Другой момент — это понимать, ЧТО учить, КАК учить, а самое главное — НАХ*Я учить? И вот в девопс-области придется знатно ох**ть, прежде чем ты сможешь ответить на эти вопросы. Но, правда, сделаю оговорку: такое чаще происходит либо когда ты только вкатываешься, либо когда меняешь компанию.
Когда ты уже сидишь в золотых наручниках у Кабан Кабаныча, ты хотя бы примерно будешь знать, что тебе надо учить, возможно даже знать как и зачем. Правда, часто это будет Евротур по технологиям, которые тебя пустят по кругу, но флюгегехаймен тебе не поможет.(мискузи)
С одной стороны, наивные фанаты технологий скажут: “Вау, это же так круто! Столько всего учишь интересного/нужного/важного.” И эти влажные фантазии разбиваются о реальность (в очередной раз). Умных слов дохера и больше, но все по верхам. Нужно быстро закрывать задачи, бегло читать документацию, внедрять решения. Никаким фундаментальным знанием тут и не пахнет. Может, повезет, и свежедоставленную новинку нужно будет внедрять и оптимизировать — тогда получится потратить время на детальное изучение. Но из огромного пула НЕОБХОДИМЕЙШИХ девопс технологий ты с трудом погружаешься в 1-2, притом что будут бесконечным потоком прилетать таски из других областей.(читай части выше)
Вскормленные сисьадминской (и не только) грудью с тяжелой судьбой мудрецы в твоей галере скажут: "кто тебе мешает развиваться и изучать эти технологии, все зависит только от твоего желания." Они не договаривают, что пресловутым развитием они занимаются во внерабочее время, отдыхают от работы, работая.
Будем честными, это путь особый, и если после 8 часов за компом тебе хочется поизучать какой-нибудь дрочёный Tarantool или как же под капотом работает RabbitMQ — отличный выбор. Тут только надо быть честным с самим собой, чтобы это не стало причиной выгорания через N-месяцев/лет.

Условная компания “РогаИКопыта” пишет в вакансии, что хочет универсального солдата, который знает от батона до гандона, а по факту нужно, чтобы он просто хорошо знал Linux и, например, Postgres. И если “РогаИКопыта” напишут по чесноку, как есть, к ней никто не придет, кроме разве что джунов (ну они на всё придут), поэтому добавляем мешок девопсовых слов и штук.
А кандидат, напротив, видит, что везде требуется знать кучу тулзов, а компания с честным описанием вызывает подозрения и страх отсутствия роста/развития как специалиста. И, зная только Linux и Docker, откликается на вакансию посочнее.

Получается замкнутый круг, где компания и девопс наеб***ют друг друга и часто оба разочарованы.

В девопсе просто невозможно расслабиться и сказать себе, что вот я достаточно знаю, чтобы оставаться на плаву и быть ценным в любой другой компании. Именно тот факт, что ты “еще не доучился”, “не всё знаешь” и т. д., приковывает к компании, где тебя приютили. Технологии растут как грибы, ты постоянно думаешь, что отстаешь, в вакансиях мелькают новые страшные слова. И если в разработке это могут быть новые фреймворки или паттерны проектирования или иные подходы, но все в рамках одного ЯПа, сервисов, то девопс — это пи***ц зыбучие пески.

продолжение поста ниже...

продолжение поста выше..

Я ни в коем случае не говорю, что прям это минус для всей девопс-индустрии. Это только моё отношение к такой особенной характеристике работы.
С другой стороны, есть фанаты «технической поддержки», кто дорастает до senior, lead, head и т. д. Но это надо любить и хотеть. Так что подумайте, это вам ок или не ок.

Если не ок, но нравится область инфры, всегда можно найти более редкие вакансии, где ты отвечаешь за узкую область, типо автоматизации ручных процессов (это можно сказать, разработчик) или Kubernetes-специалист и т. д.
Кстати, возможно, проектная работа тоже может быть решением этой проблемы, но высокий процент галер в этом случае.
Может быть накинешь еще вариантов?)

Продолжение следует... впереди ещё 4 весёлых пункта.

DevOps тебя Сожрёт
Часть 3

Дохера есть статей\видео\подкастов о том, как тяжело жить разработчику, тестировщику, разного рода менеджерам. Но про девопсов, сисадминов, SRE и прочих инфрабов — нуль. Возможно, я прип***ел для красного словца, и 1–2 видео,пару статей было, но в общем-то это надо поискать. Тогда как другие айтишные специальности пышут нытьём о нелёгкой жизни. Ну, базара нет, и там тоже говна немало. Но инфраструктура так-то бок о бок с разработкой... можно было бы и уважить.

Что банального сразу в голову лезет: сидячая работа, постоянно учиться, некуда складывать деньги, низкая социальная активность, скучно работать 1–2 часа в день, выгорание от созвонов, выгорание от ревью, выгорание от выгорания, короче, типичные проблемы, знакомые всем.

Всё сказанное выше и ниже касается девопсойдов только среднестатистического розлива и среднего порядка — тех, кто ковыряется в инфре по локоть, делает стандартные девопс/админ задачи. Именно таких ищут на сайтах знакомств компании.

Ниже я перечислю боли, которые время от времени сыпят соль на рану, мозолят глаза, устремляют к выгоранию, заставляют плакать по вечерам от счастья, а утром — от горя.

Боль 1.
Постоянный поток без конечного результата

Я вот начинал с разработки, с изучения языков программирования. В чём там прелесть? Там есть определённые рамки, структура, задача, которая приводит к выполнению поставленной цели. Причём, что важно, часто это будет законченный процесс.

Не просто так в разработке есть спринты. Ограниченный период времени (обычно от недели до 3 месяцев). По итогу этого спринта должна быть выполнена задача.
В идеальном мире она описана, в неидеальном у нас только конечная точка.
В идеальном мире никто в спринт не вмешивается, в неидеальном туда залетают хотфиксы, блокеры и т. д.

Задача — накодить в API ручку /login с использованием JWT.

Например, в первый спринт не уложились, всё улетело на следующий спринт. Но цель-то конечная сохранилась. Медленно, но верно ты пытаешься выстрадать из себя нужные методы, обработчики и прочие прелести. И как итог — х*як! Готовая ручка, которой пользуются.
В неидеальном мире вашу работу смоют в унитаз, мол, и без логина нормал работает, от логина ленивые клиенты отваливаются (п**ец примерчик, конечно).

А что по девопсу-то?
В инфраструктурно-сервисно-обслуживающем девопсе спринтов нормальных быть не может в принципе. Так же как, например, у технической поддержки.
Канбан — девопс-путь, а то и чаще бэклог-помойка.
Яркое описание любой вакансии: «у нас интересные разнообразные задачи с кучей технологий» — это значит, ты будешь каждый день еб***ть винегрет.

Ты будешь начинать задачи, оху***ть от её тупости, откладывать, брать другую, более-менее понятную, делать. Потом тебя отвлекли на траблшутинг сервиса, который ты поднимал 1–2 месяца назад, вникать, фиксить, возвращаться к предыдущей задаче, поднимать контекст... а тут уже конец рабочего дня. 

Cамое главное: пальчик на спусковой крючок крепко кладётся, и перед тобой стоит выбор — ещё чуть поработать, выстрелить в голову (ведь я почти разгадал проблему, а часто нет) или пойти отдыхать (естественно, по инерции ещё размышляя над той самой задачей в поисках гениального инсайта).

Короче, один из минусов работы в девопсе в том, что ты сразу окунаешься в реку и не можешь приплыть в порт. Тебе приходится просто выходить на другом берегу, отдышаться и снова в реку. Нет законченных проектов, есть мелкие, средние задачи, большие задачи, которые размазываются между подлетающими ОЧЕНЬ-ОЧЕНЬ важными. Потом твои проекты откладываются, ты прыгаешь между контекстами, а потом по итогу работы вопрос: «А что я сделал-то в итоге?»
Ну, так-то дох*я... Тут задеплоил, тут закрыл, там поднял, там пофиксил — в целом большая работа проделана, а итога нет.

Вот пишу и думаю, что это, наверно, я зае**н этим желанием иметь какой-то итог своей работы, нет внутреннего финиша, хотя бы какого-то маленького и короткого финиша. У тебя, может, быть иначе. Можешь и мнением поделиться — я только ЗА!

Опять не влезло. Ниже продолжение

продолжение поста выше..

Но пока останусь — ведь деньги платят, и вроде неплохие. А то, что это не то, чем я реально хотел заниматься, — ничего страшного. Сейчас еще опыта поднаберусь, тогда уже в настоящий девопс перейду.
Да вообще, честно говоря, то, чем я сейчас занимаюсь, — это база. Именно после такой работы я стану настоящим сильным специалистом. И пока эти ямлодрочеры изучают устройство K8S, разбираются в работе с облаками, крутят Terraform-ы, пишут операторы для K8S, экспортеры для мониторинга на Go/Python и прочие поверхностные девопс-штуки без понимания БАЗЫЫЫ, я буду получать сильный фундамент и потом приду к ним экспертом, покажу, как на самом деле надо строить инфру.
По крайней мере, так говорят мои сеньор-девопсы в команде. Они в компании работают уже +10 лет, все с нуля поднимали, это вам не хер собачий.


Ну, собственно, это тоже может тебя сожрать.
Ладно... Продолжение следует.

DevOps тебя сожрет.
Часть 2

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

Конечно, методологии, теории, практики придуманы не просто так. Они на самом деле могут помочь компании быть эффективнее. Однако сейчас меня волнует текущая ситуация на рынке труда, сама суть профессии, требования к ней, которые часто в реальности имеют мало общего с “Agile”-движениями.

Кто такие системные администраторы? Сисадмины? Админы?
Кажется, тут и вопроса быть не может.

Специалисты, работающие с инфраструктурой. Настраивают сервера. Выдают доступы. Иногда настраивают сети. В печальных компаниях тянут провода, подключают принтеры, занимаются эникейством. Что там еще… ну мониторинг, конечно, администрирование баз данных. Помогают разворачивать сервисы разработчиков на тачки. Веб-сервера настраивают. Скрипты на ебашике, питошке, гошке.
Что я еще забыл? Дополни, плиз.

Ох, ну нихера себе, что это я такое описал. Очень как-то похоже на то, что пишут в требованиях к DevOps инженерам. Только нужно немного девопсового сахарка добавить.

- Infrastructure as a Code: Terraform, management configuration, Ansible etc (Настраивают сервера, выдают доступы).
- NetOps: Cisco CCNA R&S, CNI, DPC etc (Монтаж сетевого оборудования, работа в ЦОД и т. д.).
- Observability: Grafana, Prometheus, VM, Loki, ELK etc (Мониторинг, логирование).
- DBA, DWH (Работа с базами данных, администрирование и т. д.).
- Scripting, Automation of routine processes (Скрипты на ебашике, питошке, гошке).
- Docker, Kubernetes, CI/CD etc. (Развертывание сервисов).

Ну вот, классическая вакансия на девопса. Чем бы хотелось заняться? Что звучит интереснее?
Прям сисадмин на стероидах.
Хочу заметить, что системные администраторы в hh это теперь чаще всего windows админы, офисные типо эникейщики или девопсы, но с очень низкой зп.

Однако чем отличаются описания?
Наличием современных технологий, современных подходов.
На самом деле, нет никаких стероидов, никакого волшебствa. Просто мир не стоит на месте и развивается, обрастает новыми инструментами, практиками, абстракциями. Хорошо это или плохо — не знаю. Не буду пи***ть, я начинал, когда уже вовсю существовало “сисадминство v 2.0”.

Так вот, многие компании хотят посочнее и повыгоднее продать пустующее место в шахте/галере/заводе/офисе (выбери подходящее). И классическую работу системного администратора оборачивают в девопсовую упаковку (их можно понять — хотят современных технологий у себя заиметь).
Если ты зеленый инфрабой/инфрагёрл и не распознал такую компанию, начинаешь через время ох***ать с вопросом: “И это девоООПС?!”
А где же пресловутая автоматизация? Почему я сервера на stage ставлю через Ansible, а на prod надо руками катить? Почему Terraform-ом виртуалки поднимались два года назад, и больше к этому коду никто не возвращался? Почему, матьегозаногу, в GitLab CI все через ебаш управляется? Логи только на тачках хранятся, разрабы билдят и пушат кривые образы, которые забивают диски до сотки раз в неделю?
Конечно, это абстрактная компания, и такой набор я, к счастью, нигде за раз не встречал — мне с компаниями везло (хотя свои приколы есть везде).

На самом деле, ничего плохого в такой компании нет. Там эффективно работает продукт. Работает инфраструктура. Клиенты счастливы, бабки текут рекой. Самим девопсам/сисадминам в кайф там работать — они там по-своему развиваются и получают удовольствие от жизни. Что еще надо?

Проблема в том, что я об****лся.
Мои ожидания разбились о реальность. Не распознал компанию, которая мне не подходит. Читал, изучал, смотрел про один девопс, а в окунулся в другой.

все не влезло, ниже продолжение...

DevOps тебя сожрет.
Часть 1

Наконец я ушел в отпуск.
Настала пора расчехлить рефлексию — пройтись по святому, по девопсу.

Что общего в профессиях: сантехник, электрик, дворник, официант, пожарный, может, даже врач, может, даже священник? (продолжи список).
Общее у этих всех профессий — некое служение/обслуживание.
То есть дело, помогающее остальной части населения сделать жизнь лучше.
Как ты думаешь, можно ли отнести к такой профессии devops инженера?
В моей реальности — да. Для меня девопс в первую очередь “помогающая” специальность. А если вспомнить про pipelines, то буквально сантехник.

Да, конечно, в devops области есть архитекторы инфраструктуры, инженеры автоматизации, управленцы — короче, те, кто “создают” (хотя с управленцами вопрос). И чаще это не то, чем обычно занимаются средние девопсы.
Но тут не о них, а о типичной работе девопса, что она из себя представляет.
Почему девопс тебя сожрет, если ты не будешь готов к реальности.

Думаю, знакомых с работой девопса этим не удивить, но вокруг профессии есть постоянный флер необычности, сложности, элитарности.
С другой стороны, от некоторой части разработки за спиной можно услышать мнение о том, что девопс — это обслуживающий персонал.
Лично мое мнение: в обслуживающем персонале нет ничего оскорбительного. Однако девелоперы закладывают именно уничижительный оттенок.
“Мы, разработка, создаем уникальный (или нет) продукт. Делаем мир лучше (или нет), а девопс только косвенно участвует в этом и еще чаще мешает/тормозит нашу эффективную (или нет) работу”.
И с каждым из этих мнений я могу согласиться, понять и простить.

Интересно, что devops — это не человек, а методология.Честно, уже зае***о слышать/читать это.
Причем методология для эффективного взаимодействия всех членов IT-команды.
Но мнение разработки о девопс звучит, как будто они говорят про системных администраторов. То есть как об отдельной команде, с которой взаимодействие происходит с трудом. (Конечно, все эти рассуждения зависят от компании и культуры в ней, однако это нередкое суждение.)
Как-то не очень вяжется с DevOps методологией, не так ли?

Тут мы подходим к интересному:
Девопс людьми понимается по-разному. 😮
Требования и обязанности от компании к компании могут разительно отличаться.
Отсюда появляются впечатлительные вайтишники, айтишники, для которых девопс — нечто магическое, потому что непонятное. Для кого-то это сисадмины на стероидах. Для кого-то швейцарский нож в команде. Для кого-то — хакер. Для кого-то ямлодрочер. Для кого-то DBA
Я сначала относился к числу “вайтишников под впечатлением”, даже когда уже проработал в IT какое-то время.
Сегодня, ожидаемо, магия растворилась, но об этом позже.
Когда вокруг такое большое изобилие разнообразных интерпретаций, мнений, требований... важные вопросы: Что же является правдой? На что ориентироваться? Туда ли я вообще двигаюсь?
В общем, очень важно понимать, как себя называть и кем себя считать. Точнее скажу — это важно мне, может, и тебе?

Пообщались с Сашей!
На разные темы начиная от пользы сообщества заканчивая Окном Джохари
ССЫЛКА НА ВИДЕО