DevopsTrain

Measure once, cut twice ❔Случалось ли с вами перепутать терминалы и запустить команду не там, где надо? Например, на проде вместо dev-окружения. Полбеды, когда это не деструктивная операция, а что если вы удалили базу или директорию с уверенностью, что делаете это на стейджинге? В этом случае из хороших новостей только то, что узнаете вы об этом очень скоро 🙂. Ребята из соседнего отдела техподдержки реагируют быстрее этих ваших модных мониторингов. В этот момент в голове проносятся разные мысли, и ты уже мысленно строишь планы на внеочередной отпуск, бессрочный. Как назло никакого плана быстрого восстановления под рукой нет (кто же думает о disaster recovery plan пока петух не клюнет?). Далее ты немного отходишь от шока и начинаешь исправлять свой косяк. Смотришь состояние бекапов в надежде, что они свежие и рабочие. Если нет, что ж, ты попал. Как вам такой сценарий? Когда-то давно со мной случались факапы, хотя и не сказать что много. Теперь я десять раз проверю перед выполнением деструктивной операции, более того, я даже бывает сначала просто выключу виртуальную машину или базу, перед удалением, подожду денек-другой и если никто не придет — можно удалять. Потому что, даже если ты делаешь то в чем уверен, другие могут сообщить тебе неверные данные о том на сколько критична та или иная ВМ или БД.

Виноват будешь не ты, но именно тебе потом восстанавливать.

А мы любим подстелить соломку, где только это возможно. ▶️Впрочем, подстелить не всегда получается, из-за того что удаление или изменение какого-то компонента неявным образом может повлиять на работу других, о чем ты либо не знал, либо ход твоих мыслей так далеко не зашел. Поэтому главное правило: перед удалением все проверь, и по возможности оставь себе шанс откатиться если что-то пойдет не по плану, как это бывает в больших и сложных системах. И еще совет: используй понятный нейминг объектов, чтобы они не вводили в заблуждение о том, к какой подсистеме они относятся. Более детально я рассказываю в рамках своей программы обучения.

Новый курс! — Devops Troubleshooting 😱 Рад поделиться новостью — новый курс по траблшутингу devops кейсов готов! В настоящий момент курс поделен на две большие части: ▶️ Kubernetes ▶️ Linux / Networks Каждый из них, в свою очередь, поделен на 3 части: Beginner, Intermediate и Advanced, для того чтобы по нарастающей сложности вы могли выбрать подходящий набор кейсов ✔️Уже сейчас там 28 кейсов, но их число будет расти. Каждый кейс запускается в специализированном окружении, то есть либо в выделенном кластере Kubernetes, либо в виртуальной машине.

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

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

Тесты глазами DevOps-инженера Вчера настраивал пайплайн и подумал:

а знаем ли мы, что именно тестируем?

Да, мы не пишем код, но пайплайны с тестами — наша зона ответственности. И чтобы правильно настроить CI/CD, нужно понимать суть процесса. ❔ Как мы смотрим на тесты Представьте, что тестирование — это как проверка автомобиля. Unit-тесты — это когда механик проверяет каждую деталь отдельно: работает ли двигатель, тормоза, фары. Интеграционные тесты — когда мы заводим машину и смотрим, как все системы работают вместе. А E2E тесты — это когда мы садимся за руль и едем по городу, проверяя весь путь от дома до работы. ❔Что мы проверяем Есть два больших вопроса: "Работает ли система?" и "А как хорошо она работает?". Первый вопрос решают функциональные тесты — они проверяют, что кнопка "Купить" действительно покупает товар. Второй вопрос решают нефункциональные тесты — они смотрят на безопасность, производительность, удобство использования. 🪲 Уровень "прозрачности" Интересно, что тестирование бывает разным по уровню доступа к коду. Черный ящик — тестируем как обычный пользователь, не зная, что происходит внутри. Белый ящик — видим весь код и тестируем с пониманием архитектуры. Серый ящик — золотая середина, когда знаем общую структуру, но не вдаемся в детали. 🤖 Ручное vs автоматическое Ручное тестирование — это когда человек садится за компьютер и проверяет все вручную. Классика, но медленно. Автоматизированное — это наша стихия: скрипты, CI/CD, автоматизация. Быстро, надежно, масштабируемо. ❔Почему это важно для нас Понимание типов тестов помогает нам правильно настроить пайплайны. Мы знаем, что unit-тесты должны быть быстрыми и запускаться при каждом коммите. Интеграционные тесты — при мерже в основную ветку. E2E тесты — перед релизом. А нагрузочные тесты — по расписанию или при изменениях инфраструктуры. ✔️Это помогает нам оптимизировать время сборки, правильно распараллеливать задачи и говорить с разработчиками на одном языке. На все эти детали мы обращаем пристальное внимание в моей программе менторства (🤫 мест на осень не осталось мало):

Devops как прогрессивная и консервативная тема С одной стороны девопс, как термин, еще достаточно молод по меркам многих других вещей в IT, а с другой стороны в его основе применяются технологии, которым уже много лет. И это делает его вдвойне интересным направлением для персонального развития. *️⃣Возьмем для сравнения разработку, а точнее ее довольно популярную часть — фронтенд. Выглядит так, что туда вкатиться не так уж сложно и долго, но тут кроется подвох. Да, для работы в конкретный момент времени и на определенном проекте тебе надо знать основы языка, и особенности фреймворка. Это намного проще, чем тот же devops, где нужно разбираться во многих вещах. Однако, потом выясняется, что написанный тобой код на некоторых устройствах, браузерах, юзерах (подставить свое) работает не так как планировалось. А позже на соседнем проекте ты узнаешь, что там иной фреймворк и тебе надо его изучать. А через год-два выходит очередной модный фреймворк и тебя жизнь заставляет его учить. В прочем мобильная разработка не далеко ушла в этом отношении. В devops все иначе:

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

К тому же всегда в цене фундаментальные знания: Linux, сети, контейнеры, IaC, CI/CD. Мне регулярно поступают вопросы вида: ❔"А точно, что те вещи, которые я изучу будут актуальны через год или два". У меня ответ простой и четкий: совершенно точно. В моих курсах нет мимолетных и на днях появившихся технологий, только проверенные временем вещи, которые с нами уже от 10 лет и больше. И конечно, именно они и мелькают в требованиях к вакансиям чаще всего. 🙂 Впрочем, это не значит, что все стоит на месте и не меняется годами, изменения происходят, это неизбежно и прекрасно.

Мы просто наблюдаем за ними и применяем лучшие подходы в нашей работе.

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

Рынок найма Эта картинка как нельзя лучше описывает текущий рынок найма. Да, пока мы живем в фазе, когда это рынок принадлежит работодателю, и надеемся что тренд изменится и нам не придется как ужу выкручиваться, чтобы правильно ответить на вопросы HR скрининга. 😕 Дело в том, что на некоторые позиции поток соискателей настолько большой, что кадровики легко могут себе позволить отсеивать кандидатов за любой вопрос, ответ на который не отвечает текущим политикам компании. Раньше я не задумываясь отвечал на такие вопросы как: "А почему ищете работу?", "Как относитесь к переработкам?", "На какую зарплату рассчитываете?" и тд. ➡️ Сегодня я понимаю, что в текущих реалиях я бы даже не дошел до технического интервью, отвечай я также. Это полная дичь, и многие это понимают, но почему-то ничего не меняется.

Хочется быть честным и отвечать в стиле "speak from my heart", однако это пустая трата времени, если цель устроиться на работу.

Что уж говорить про технические интервью, которые тоже бывают весьма странными. Ну на сколько это возможно назвать странными матерых сеньоров, которым навесили сверху задачу прособеседовать N людей, хотя у них, вообще то, много и другой работы 👻 Часто они задают вопросы определенным скриптом, причем даже не адаптируют беседу под человека, хотя вот видно, что некоторые вопросы ему задавать уже не надо. Стоит отметить, что бывают и вполне душевные технические беседы, но реже. ✅ На все эти детали мы обращаем пристальное внимание в моей программе менторства (🤫 мест на осень осталось мало): 🔥даю рекомендации по общению на разных уровнях найма, 🔥 оформляем резюме, 🔥проводим mock интервью, 🔥 формируем позиционирование и улучшаем самопрезентацию

Без плана никуда В своей практике время от времени сталкиваюсь с необходимостью проведения ответственных мероприятий, затрагивающих прод. Это может быть перенос на другую платформу, сервер, кластер и т.д. И не всегда есть возможность сделать плавное переключение на новую схему, что означает отсутствие права на ошибку, а время процедуры обычно очень лимитировано 🤷‍♂️🤷‍♂️🤷‍♂️ ➡️ В этом случае я поступаю следующим образом: на каком нибудь тестовом окружении провожу все шаги процедуры и записываю себе в виде плана с точностью до команды или четкой и короткой инструкции.

Сам план должен быть понятным даже спустя месяц, поэтому важно правильно его составить.

Т.к. сроки выполнения процедуры сжаты, то два тома инструкций расписывать не надо. ➡️ Далее, когда есть план, можно еще разок полностью по нему пройти, выполняя шаг за шагом, и измерить время, в которое можно уложиться. А дальше осталось запланировать мероприятие, уведомить нужных лиц и в назначенный момент сделать дело. Я обычно планирую такие вещи на раннее утро, чтобы пока все спят все завершить. Ну люблю я запах паленых серверов по утрам, что поделаешь)

Иметь план всегда полезно,

поэтому в своей менторской программе мы начинаем обучение с проработки индивидуального плана, в котором также есть некоторые ориентиры по срокам, чтобы эффективнее прошло обучение ✔️

В чем прикол моей платформы Не все сразу понимают как формат курсов devopstrain продвигает вас в обучении. Позвольте рассказать немного истории...) Давным давно у меня возникла идея создания универсальной платформы для IT курсов. Предполагалось, что там будут курсы по разным темам, в том числе и по разработке. Но надо было с чего то начинать. Первый релиз платформы случился еще в 2020 году с одним единственным курсом "Kubernetes на практике". Именно кубер на тот момент выглядел наиболее подходящим вариантом для такого формата. И это оказалось действительно так, кубер с тех пор остается бестселлером на моей платформе. Если вы еще знакомы с моей платформой, сам формат в двух словах выглядит так: вы читаете небольшую теоретическую вводную ➡️ затем следует практика (результат которой проверяется автоматически) ➡️ далее снова все повторяется. Каждый раздел связан с предыдущим, поэтому вы понимаете что откуда взялось. ❔Почему такой формат работает? Секрет в том, что курсы такого формата оптимально сбалансированы по следующим характеристикам: 💜глубина подачи теоретического материала тут можно уйти в дебри, где будет очень интересно, но ничего не понятно. А можно пробежаться по верхам, и этого будет недостаточно даже для тех. собеседования, не говоря уже о реальной работе. Истина где-то посередине. 💜 доступность практики тут тоже можно в курсе написать, мол, запусти Linux, в нем подними minikube и у тебя готовый кубер для выполнения заданий курса. Это, в целом, хороший вариант, если у вас уже есть некий опыт, но если его недостаточно, то вместо фокуса на ресурсах кубера, вы будете долгое время настраивать просто окружение, а потом уже сил, времени может не хватить на тему, изучаемую в курсе. 💜 актуальность в ежедневном использовании известно, что тема devops очень обширна, и без насмотренности трудно сказать, что важнее учить в первую очередь. Время - это наиболее ценный и ограниченный ресурс, поэтому его нужно использовать с максимальной эффективностью. Формируя план курса, я всегда исхожу из того, что требуется чаще всего в работе меня и коллег.

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

Вы, наверняка, часто сталкивались с тем, что после просмотра видео, когда дело доходит до практики, то у вас как будто все выветрилось из головы. Я уже более двух лет занимаюсь обучением, поэтому знаю о чем говорю. Подытожу: платформа devopstrain - это не всеобъемлющий справочник, а скорее продуманный roadmap со встроенной практикой, который выведет вас куда надо 😕

Собрал для вас подборку самых популярных постов: 🔵Почему стоит всерьез рассмотреть профессию devops-инженера? 🔵С чего начать изучение DevOps? 🔵Из каких профессий приходят в девопсы? 👻 🔵Страхи тех, кто хочет, но почему-то еще не идет учиться DevOps 🔵Почему Kubernetes (k8s) это "операционная система", в которой необходимо "шарить" 🔵ИИ (AI), то есть про искусственный интеллект в DevOps 🔵Поговорим про ближайшее будущее Devops 🔵Про удаленку в devops 🔵Middle или Junior? 🔵Зарплата учеников + отзыв

Я уже давно не ищу работу, но каждую неделю стабильно получаю по 2-3 предложения с хорошими зарплатами. Зачастую хожу на собеседования и получаю офферы для того, чтобы быть в курсе рынка труда и вопросов собесов. Когда работодатели пишут сами — это заведомо выгодная позиция с точки зрения трудоустройства. HR пишут не только мне, как сеньору, но и моим ученикам, которые достигли уровня middle. Конечно, у них имеется определенный опыт, но немаловажно еще оформить правильно его и подать себя в резюме. А после также правильно общаться с будущими работодателями с учетом устоявшихся законов капиталистического рынка. С этим всем помогаю разобраться, потому не одними хард скилами сыт инженер devops =) Как достичь уровня мидл или сеньор? ▶️ Постоянное обучение: Изучайте новые технологии, следите за трендами в индустрии. ▶️ Практика: Участвуйте в реальных проектах, работайте над своими навыками. В моем обучение есть отличный практический проект.

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

📌Итог: Повышение своих скилов — это не только про деньги, но и про возможности, интересные задачи и постоянное развитие. Если вы хотите узнать больше о том, как достичь этого уровня или получить обучение в DevOps, пишите. ☝️Напоминаю, что с сентября планирую повышать цены, но пока можно забронировать место по старой цене и начать обучение сейчас или позже.

NixOS спустя год ➡️ В прошлом году я уже делал цикл постов про мой переход на NixOS в качестве домашней системы. Прошел почти год с момента перевода моих ноутов на эту замечательную ОС, хотел бы поделиться впечатлениями.

Сказать, что я доволен - ничего не сказать.

После debian based дистров, да, впрочем, и не только их, этот отвечает моим требованиям на 100%. Все настройки лежат у меня в git репе, для каждой из моих машин. Конфигурация несколько отличается, но не сильно, конфиг используется общий, но, например, photoprism на младшей машинке мне не нужен, поэтому там сделано исключение. Добавление пакетов - это новая строчка в конфиге и запуск одной команды, что создает новый снепшот всей системы и я могу, если что, откатиться. Но это ни разу не потребовалось. 🔖 К слову, пакетная база настолько большая, что 99,9% пакетов я нашел в ней. И, пожалуй, буквально несколько приложений пришлось скачивать отдельно. Кстати, из-за особенностей системы (там своя иерархия файлов), ты не можешь просто так взять и запустить тот же appimage. Но как обычно есть проблема - есть решение: appimage-run 🔖 Причем, часть пакетов у меня висит на стабильной ветке, а часть в unstable, чтобы получать самый свежий софт, такой как k9s, terraform, kubectl, cursor, firefox, telegram и прочее. Это очень удобно и работает пока стабильно. Также, в своих проектах я использую shell.nix файл с конфигурацией нужных для данного приложения зависимостей причем нужной версии. Ближайший аналог в мире python - virtualenv, хоть и достаточно грубое сравнение.

В остальном это обычный Linux, но вот именно пакетный менеджер nix и конфигурация системы через код делает из него шедевр.

Однозначно рекомендую! 🙂 DevopsTrain

Middle или Junior ❔ Если вы не вчера начали свой путь в IT, и тем более если в смежной DevOps области вроде сисадминства имели опыт, то вероятно вам всерьез стоит задуматься о позиционировании себя как Middle. ➡️ Поясню почему. Допустим, вы хотите перейти в devops, но вам кажется, что ваших навыков достаточно только для джун позиции. Это нормально и вероятно вы адекватно оцениваете свой уровень. Однако, возможно что вы уже не джун, хотя еще и не мидл. Но т.к. вы не можете быть как та обезьяна в анекдоте, вам все таки придется выбрать что написать в резюме или на какую вакансию подаваться.

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

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

Startup, Mid-size, Enterprise ▶️Мне приходилось работать в компаниях разного размера, решил поделиться, в чем для себя я увидел отличия, плюсы и минусы.

Startup

⏩Работа в стартапах (до 50 человек) — весело, задорно, хаотично, иногда аврально, но сильно заметна очевидная связь между тем, что ты сделал и эффектом для компании. Возможно потому, что когда ты роняешь прод, это действительно трудно не заметить)) Или оптимизировал расходы на сервера, чтобы оставить больше бюджета на рекламу. А уж если ты еще бэкенд пишешь, то там еще больше можешь влиять на результат. Из минусов можно выделить необходимость выстраивать различные процессы, а код и инфраструктура еще не имеют жестких гайдлайнов. Как правило, даже нет infra-as-a-code. Тем не менее мне до сих пор нравится работать в таких компаниях, люблю приводить все в порядок.

Mid-size

⏩В компании среднего размера (порядка 100+ человек) от тебя зависит чуть меньше, т.к. по идее твоя роль должна быть задублирована вторым и может быть третьим человеком. Однако несмотря на большее число сотрудников, ты все еще напрямую влияешь на работоспособность продуктов компании. К плюсам можно отнести выстроенный подход к разработке и релизам, а также широкое использование инструментов вроде terraform, helm, ansible для работы с инфрой.

Enterprise

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

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

DevopsTrain

💬 Такой отзыв пришел вчера на мою программу наставничества. Максим устроился на работу в финтех с хорошей зарплатой. Меня часто спрашивают:

Смогу ли я устроиться на работу после вашей программы ❔❔

Конечно, при должном упорстве и уровне знаний можно получить работу с зарплатой от 250-300к и окупить наставничество за неделю-две. В обучении вся нужная информация и вопросы собеседований, которые часто задают работодатели ✔️ Жду вас на своем обучении, с сентября планирую повышение цены 🙃

Немного про DevSecOps Т.к. я сейчас работаю над созданием нового курса, решил и пост сделать на эту тему.  В чем, собственно, суть подхода в DevSecOps, и чем он отличается от того, как обычно решали проблемы с безопасностью?  🔵Раньше: Отдельная security-команда (если она есть, кхе-кхе) периодически проводит свои тесты на предмет известных уязвимостей тестового стенда, а иногда сразу и прода. Даже возможно смотрит в код приложения, но это не точно. Далее дает обратную связь разработчикам, если есть что исправить.  🔵Сейчас: Статические (код) и динамические (запущенное приложение) проверки встроены в CI-пайплайн, и разработчики постоянно получают обратную связь от инструментов-анализаторов. Безопасность становится общей ответственностью, а не только службы безопасности.  📎 Что касается самих инструментов, то ярким примером являются SonarQube, Checkmarx. 

Безопасность — это не только код, это еще инфраструктура, которая архитектурно должна быть безопасной. А также и организационно. 

Впрочем, далеко не везде заморачиваются с такими вещами, из-за чего сливы пользовательских данных — очень частое явление. Но понятно одно: с этим всем можно и нужно бороться, а спрос на внедрение DevSecOps будет расти.  📍Devops Roadmap 👉 Наставничество 👉 Курсы

DevOps как гавань в чудном мире ИИ В продолжение темы про то, как не пойти работать курьером, хотел поделиться соображениями почему девопсов пока ИИ не сможет заменить. Под девопсами я понимаю целый класс смежных специалистов, в том числе: devsecops, mlops, cloud engineer, platform engineer, и т.д. В среднем девопсу хорошо бы шарить хотя бы немного во всех этих областях, но речь пока не про это. Ранее я высказывал мысль, что раз

AI делает работу более эффективной, значит и меньше сотрудников требуется для ее выполнения.

👻Иногда проскакивают и другие точки зрения на этот счет. Мол, если человек работает быстрее - значит можно дать ему больше работы, при этом никого не увольнять. В теории да, но рынок не бесконечный, и выводить в еще большем количестве новых продуктов на него далеко не всегда имеет смысл. Не каждая компания может позволить себе так расширяться, зачастую работая себе в минус ради 'большей доли в будущем'. Да и прирост населения потихоньку сокращается, экономики замедляются. Выходит, что все таки сокращения это наиболее частый сценарий на сегодняшний день. Сейчас вполне очевидно, что почти весь прикладной софт будет разрабатываться с помощью ИИ. Конечно, останется небольшой процент "системников", где важна глубокая экспертиза, и они будут писать по старинке, но все равно с привлечением AI технологий. Уже сейчас идет разработка языков программирования нового поколения, созданных специально для нейронок. Синтаксис этих языков - просто английский язык, то есть порог вхождения будет еще ниже, чем сейчас. 🐶 Мы, девопсы, с интересом наблюдаем за этим всем и пользуемся, в том числе и для своих целей. Но любой код, не важно кем написанный, нужно где-то запускать и как-то поддерживать его работу, мониторить, восстанавливать в случае аварий и т.д.

Конечно, доверить такие серьезные вещи ИИ, очевидно, нельзя.

И не только потому что это подразумевает передачу паролей и ключей в небезопасный контур. Даже если вопрос с безопасностью будет решен путем запуска модели у себя, все равно действия ИИ могут сломать все случайным образом, а ответственность на ком в этом случае будет? ➡️ Еще причина по которой ИИ курит в сторонке - это очень сложная и зачастую нелогичная инфраструктура, где данные есть только в головах людей, и как решать ту или иную проблему только они и знают. Так что приходите учиться на практике тому, что будет актуально еще долгое время 😉 DevopsTrain

Опа, что это тут? Новый курс! ➡️ 12 Factor App: от теории к практике в Cloud Native мире Рад поделиться долгожданным обновлением платформы! Сегодня стартует уникальный курс, посвящённый созданию cloud native приложений на основе 12 Factor App. 💡 Почему этот курс особенный? Мы не просто разбираем теорию, а шаг за шагом реализуем микросервисное приложение, используя Go — язык, который стал незаменимым инструментом для DevOps. ❔Что будет в курсе? ✅ Понимание принципов 12 Factor App и их применение. ✅ Создание приложения с помощью вайб-кодинга — промптов для ИИ (это реально круто и будущее уже здесь!). ✅ Работа с Kubernetes и GitHub Actions, включая настройку собственных раннеров. ✅ Интеграция с БД и Telegram API для полного цикла разработки. ✅ Бонусные 2 фактора от меня 🤩 Этот курс — не просто обучение, а взгляд в будущее разработки, где ИИ и облачные технологии становятся неотъемлемой частью процесса. Если вы хотите быть на волне технологий и понимать, как создаются современные приложения, — welcome!

Помимо этого, до 15 июня действует 5% скидка на программу наставничества. И до этой же даты действует акция: 1 курс + еще 1 курс = 3 курса (самый дешевый в подарок)

Хотели прокачаться в Devops? - самое время начать (пока не поздно 🐶) 📎 И не забывайте про DevOps Roadmap

Реально последний шанс НЕ пойти работать таксистом Кажется, что вся шумиха вокруг нейросетей и AI это просто очередная веха в развитии айтишечки. Действительно, не первый же раз мы видим инновации в этой сфере. Хотя, если честно, то реально значимых открытий и изобретений можно пересчитать по пальцам одной руки: 🔵 Создание ЭВМ и сетей 🔵 Создание интернета и связанных с ним протоколов (TCP, HTTP, smtp, dns, ...) 🔵 Отдельно можно выделить протокол Bittorrent 🔵 Ладно, эти ваши смартфоны тоже существенный скачок в развитии, хотя большинство людей их использует достаточно примитивно 🔵 Создание Bitcoin (сюда же и прочие криптовалюты) 🔵 Машинное обучение и в частности генеративные модели вроде GPT Пальцев получилось 6, чтож, бывает и такое. Хотя я мог что-то и забыть, напомните в комментариях. Так вот, получается, что

не так уж часто происходят революционные события

, чтобы каждое из них не рассмотреть всерьез. Я в целом отслеживаю ситуацию и замечаю и гораздо более нишевые тренды, которые мне интересны по долгу службы. То есть еще в 16 году я сделал ставку на Kubernetes, хотя он был еще в зачатке и в облаках его не было вовсе. А в 15 году мне уже было очевидно, что Golang прочно займет свою нишу и даже потеснит прочее легаси вроде Python/Ruby/Java на многих проектах. 🤖 Конечно же и мимо гпт пройти не смог, использовать его начал еще в 22 году, и несмотря на некоторую глючность моделей тех времен, сразу стало понятно что это game changer. Но то, что мы видим сейчас в плане развития как самих моделей, так и инструментов на их основе - это нечто за гранью добра и зла. Причем я бы сказал, что инструментарий не менее важен, чем качество моделей. Я говорю сейчас про такие штуки как редакторы кода, ИИ ассистенты и прочие помощники. С каждым днем все радостнее жить. Но как бы есть еще один тренд, который можно отрицать до последнего, но умные люди уже вчера начали думать об этом.

Речь о тотальном переходе на эти инструменты и как следствие повышение эффективности интеллектуального труда.

Больше эффективность - нужно меньше людей для выполнения того же объема работ. Понятно, к чему я веду. Сокращения это не фантазии, это реальность сегодняшнего дня. Хорошая новость в том, что ручной труд пока заменить не удается и курьеры, таксисты еще пока пользуются спросом 😂 ❗️Если такие перспективы не воодушевляют, то по сути в ИТ вариантов не так уж много. Остается возглавить ИИ революцию выбрав работу инженера по машинному обучению. Но как понимаете, выбрать не достаточно, нужно уметь что-то делать, а конкуренция там будь здоров. Поэтому другой более реальный и не менее выгодный вариант - инженер Devops, который, в том числе, и модельки эти будет запускать. Приходите учиться в мою программу наставничества, пока не поздно. В следующем посте я подробнее расскажу почему у девопсов еще есть время до того, как их попросят освободить место. DevopsTrain

День глюков Я давно заметил, что схожие по своей сути события имеют тенденцию группироваться и случаться в один день, либо на одной неделе. К примеру, если встретил на дороге неадеквата, который тебя подрезал, то скорее всего он в этот день будет не единственным. Если какой-то привычный для тебя сервис сегодня "прилег", то жди еще сюрпризов. Недавно череда странных багов случилась со мной в один день. ▶️Глюк №1 Кластер Kubernetes на OVH не запускался. Я решил обновить в своих курсах версию кластера по умолчанию, ведь пора бы уже, старая скоро просто не будет поддерживаться. Увеличил версию, и проверил — выдалась ошибка. На OVH ошибки очень скудные, деталей нет вообще. Первая мысль — именно данная версия не работает, ведь пару дней назад же все было ок. Но потом оказалось, что и старая версия в этот день тоже не работала. Чтож, ок, тут только ждать пока починят. ▶️Глюк №2 Пользователь сообщил, что ИИ ассистент на моей платформе ему не отвечает. Как же так, ведь у других работает прямо в данный момент. Пришлось раскапывать причину, оказалось что именно на данном разделе курса сработал пограничный случай и преобразование в JSON отвалилось. Потребовалось время, но проблема решилась. ▶️Глюк №3 На основной работе ко мне пришли из разработки и сообщил, что нашли в инфре стейджингого окружения страшный и ужасный баг, который если повториться в проде, будет *опа. Вкратце: у нас несколько инстансов redis запущено в одной неймспейсе k8s, и каждый микросервис работает со своим. А тут по какой-то неведомой причине один микросервис подключился к redis другого микросервиса. Сначала грешили на съехавшие env переменные, хотя ничего не меняли тут, и как выяснилось дело не в них. Они установлены верно. Но по ошибкам в Sentry проблема определенно была. После долгих раскопок логов, нашли попытки самого редиса подключиться к другому, что насторожило. Выяснилось, что не так уж давно был внедрен механизм Sential для кластеризации Redis, и он умеет делать autodiscovery, и находил в качестве источника не своего мастера. ▶️Глюк №4 Он связан с попыткой решить №3, а именно запустить Managed Redis cluster в облаке. Запускаем мы сервисы через Terraform, но почему-то именно с этим ресурсом возникли проблемы, после создания ресурс не добавлялся в стейт. Тут похоже мы наткнулись на какой-то пограничный случай, т.к. воспроизводится только на нашем стейте. Если вынести его отдельно, то проблем нет. Вывод, который можно сделать: 🙄 при решении проблем включается туннельное зрение. Вы ищите причину там, где кажется она и должна быть, но все может быть совсем иначе.

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

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

Менторство: это дань моде или нечто большее? В том или ином виде менторство существовало всегда, просто с некоторых пор оно стало так называться. Впрочем, что касается devops и смежных дисциплин вроде разработки, то тут есть свои особенности. Сейчас технологии развиваются очень стремительными темпами, гораздо быстрее чем даже 20-30 лет назад. Несмотря на то, что явным образом можно выделить основополагающие вещи, существует очень много разнообразных сопутствующих направлений, которые в том или ином виде используют работодатели и их они тоже хотят видеть в вашем резюме.

И если раньше можно было натаскаться самостоятельно по фундаментальным техникам, то сейчас этого просто недостаточно.

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

Чтобы не тратить месяцы и годы на самостоятельное изучение, которое может оказаться нерелевантным к тому времени, и существует менторинг.

По чистой случайности я тоже оказался ментором, уже несколько лет. И не просто ментором, а ментором со своей практической платформой обучения и набором курсов максимально отвечающим реалиям сегодняшнего рынка. Более того, у меня есть хобби: я просматриваю вакансии, анализирую требования и вношу коррективы в программу обучения. Приходите на мою программу наставничества, буду рад помочь! ☝️На май остались последние места.