Давайте разберем популярный вопрос из собеседования на вакансию DevОps-инженера и как на него стоит ответить:
Ответ:виртуальная память - это механизм, который создает иллюзию у пользователей и процессов, что у них есть больше физической памяти (RAM), чем реально есть на компьютере.
Дополнить ответ можно ее возможностями и преимуществами:
1️⃣ Управление памятью: виртуальная память позволяет системе эффективно использовать доступную физическую память, предоставляя пространство для каждого процесса.
2️⃣ Выполнение больших программ: при использовании виртуальной памяти программы могут быть больше, чем доступная физическая память.
3️⃣ Изоляция: каждому процессу присваивается свое виртуальное адресное пространство, что повышает безопасность, так как процессы не могут вмешиваться в память друг друга.
4️⃣ Базовая возможность сваппинга: вычислительные процессы, которые не требуются в данный момент, могут быть перемещены (или "вытеснены") из основной памяти и сохранены в специальной области на жестком диске, известной как "swap space" или "paging file". Процессы могут быть восстановлены обратно в память, когда они снова требуется.
5️⃣ Упрощение программирования: программистам не нужно управлять реальной памятью компьютера в своих программах. Они просто оперируют с виртуальной памятью, и операционная система обеспечивает корректное отображение в физическую память.
🤓 А подробный список вопросов-ответов на частые вопросы с собесов доступен в программе наставничества.
DevopsTrain
Вопрос: Что такое виртуальная память?
Ответ:
Дополнить ответ можно ее возможностями и преимуществами:
1️⃣ Управление памятью: виртуальная память позволяет системе эффективно использовать доступную физическую память, предоставляя пространство для каждого процесса.
2️⃣ Выполнение больших программ: при использовании виртуальной памяти программы могут быть больше, чем доступная физическая память.
3️⃣ Изоляция: каждому процессу присваивается свое виртуальное адресное пространство, что повышает безопасность, так как процессы не могут вмешиваться в память друг друга.
4️⃣ Базовая возможность сваппинга: вычислительные процессы, которые не требуются в данный момент, могут быть перемещены (или "вытеснены") из основной памяти и сохранены в специальной области на жестком диске, известной как "swap space" или "paging file". Процессы могут быть восстановлены обратно в память, когда они снова требуется.
5️⃣ Упрощение программирования: программистам не нужно управлять реальной памятью компьютера в своих программах. Они просто оперируют с виртуальной памятью, и операционная система обеспечивает корректное отображение в физическую память.
DevopsTrain
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
Продолжение истории про миграцию на NixOS
Часть 3. Собственно сам переезд.
Интересно, что USB флешки я использую только для установки новой ОС, в остальное время они мне не нужны. Поэтому второй раз за 5 пять лет я сдул пыль с нее и накатил образ NixOS через
Загрузился, потыкал next, next, next ... и дело пошло. Минут через 20 перегрузился в свежую ОС и начал приводить в рабочий вид на основе созданного ранее кода конфигурации. Кстати, для себя я нашел удобным положить файлы
☝️Важный момент: несмотря на то, что в случае проблем вы можете загрузиться с более старой конфигурации системы, выбрав пункт в загрузчике, вам все равно нужно думать о том, чтобы иметь возможность откатить сам конфигурационный файл, чтобы вы могли иметь рабочий конфиг в любой момент. И для этого как раз отлично подходит
Далее следует достаточно заурядный процесс мелкого тюнинга и проверки работоспособности всех важных утилит, после чего получаем идеальную для работы систему 🤌.
Кстати из наблюдений: время автономной работы ноутбука даже немного выросло. Но я бы это связал с более новым ядром, нежели с настройками системы как таковой. Хотя отсутствие попыток что-либо обновить, чем грешила убунта, не может не радовать.
Через пару недель я повторил операцию на втором ноутбуке и на этом основную часть работы можно считать завершенной 👌
Как вам серия про NixOs?
DevopsTrain
Часть 3. Собственно сам переезд.
Интересно, что USB флешки я использую только для установки новой ОС, в остальное время они мне не нужны. Поэтому второй раз за 5 пять лет я сдул пыль с нее и накатил образ NixOS через
dd. Спасибо, что не на CD болванку как это приходилось делать лет 15 назад 👽Загрузился, потыкал next, next, next ... и дело пошло. Минут через 20 перегрузился в свежую ОС и начал приводить в рабочий вид на основе созданного ранее кода конфигурации. Кстати, для себя я нашел удобным положить файлы
configuration.nix и home.nix в свой git репозиторий. А чтобы автоматически накатывать внесенные изменения я создал Makefile с правилом make install-switch, которое копирует исходники конфигов из локальной репы в нужное место, а именно в /etc/nixos/, после чего вызывает команду пересборки системы. ☝️Важный момент: несмотря на то, что в случае проблем вы можете загрузиться с более старой конфигурации системы, выбрав пункт в загрузчике, вам все равно нужно думать о том, чтобы иметь возможность откатить сам конфигурационный файл, чтобы вы могли иметь рабочий конфиг в любой момент. И для этого как раз отлично подходит
git.Далее следует достаточно заурядный процесс мелкого тюнинга и проверки работоспособности всех важных утилит, после чего получаем идеальную для работы систему 🤌.
Кстати из наблюдений: время автономной работы ноутбука даже немного выросло. Но я бы это связал с более новым ядром, нежели с настройками системы как таковой. Хотя отсутствие попыток что-либо обновить, чем грешила убунта, не может не радовать.
Через пару недель я повторил операцию на втором ноутбуке и на этом основную часть работы можно считать завершенной 👌
Как вам серия про NixOs?
DevopsTrain
👍7🔥4🤷1
Как я создаю курсы в devopstrain?
Чтобы донести до учащихся материал доступным образом и сопроводить достаточным объемом практики, мною был отработан метод, о котором я хотел бы рассказать.
1️⃣ Формирование списка разделов:
После принятия решения о создании того или иного курса, создается список разделов. На этом этапе прорабатывается как полнота раскрытия темы, так и порядок следования разделов, чтобы изучение было от простого к сложному и разделы были связанные друг с другом логически (где это возможно).
🗓 Занимает около недели.
2️⃣ Разработка раздела:
Далее по каждому из разделов начинается работа. Все пункты ниже нужно повторить для каждого раздела. А их бывает от 10 до 25 в моих курсах, суммарно уже более 100 по всем курсам.
А. Формирование списка тем (в случайном порядке), которые нужно обязательно осветить в данном разделе. На этом этапе я изучаю документацию, статьи, куски кода и прочие источники, чтобы получился максимально полный набор того, что я считаю важным рассказать в данном разделе.
🗓 Может занять от 1 дня до недели, в зависимости от сложности раздела.
B. Составление плана раздела. Тут уже список тем превращается в структуру, каждый из элементов которого логически связан с соседними. И тут уже важен порядок, т.к. именно по этому плану и будет создаваться материал раздела. Это еще осложняется тем, что нужно придумать практику которая идет по ходу прохождения, а также понять как бекенд будет производить проверку заданий.
🗓 Занимает несколько дней.
C. Написание текста самого курса. Следовать плану уже проще, особенно если он получился подробным, однако оформительская часть отнимает достаточно много времени. Я использую собственную платформу, которая позволяет делать курсы максимально гибкими. И если не хватает каких либо элементов, то дизайнер и фронтендер сделают свою работу и платформа будет доработана. Сам код раздела пишется на YAML, в которых есть кастомные типы для отображения блоков различного функционала. Например: выделение важного, кнопка, faq, ссылки, отображение серверного вывода и многое другое. Также на этом этапе происходит создание схем и диаграмм, чтобы материал был более понятным.
🗓 Этап может занять до 3 недель в некоторых случаях.
D. Создание бекенд части. Бекенд требуется для сохранения состояния прохождения разделов, отображения серверных выводов и, самое главное, проверки ваших заданий. В зависимости от курса, логика сильно отличается, поэтому единого решения тут не придумаешь. Однако, у меня, конечно, есть ряд своих лайфхаков и скриптов для генерации кода.
🗓 Занимает 1-2 дня.
E. Тестирование работы связки курса с бекенд частью, чтобы убедиться, что все работает как задумано.
🗓 Занимает примерно 1 день.
✅ После этих шагов можно переходить к следующему разделу =)
Хотел показать с какой заботой создается каждый курс, и насколько все материалы на моей платформе качественные и эффективные 🙂
Чтобы донести до учащихся материал доступным образом и сопроводить достаточным объемом практики, мною был отработан метод, о котором я хотел бы рассказать.
1️⃣ Формирование списка разделов:
После принятия решения о создании того или иного курса, создается список разделов. На этом этапе прорабатывается как полнота раскрытия темы, так и порядок следования разделов, чтобы изучение было от простого к сложному и разделы были связанные друг с другом логически (где это возможно).
🗓 Занимает около недели.
2️⃣ Разработка раздела:
Далее по каждому из разделов начинается работа. Все пункты ниже нужно повторить для каждого раздела. А их бывает от 10 до 25 в моих курсах, суммарно уже более 100 по всем курсам.
А. Формирование списка тем (в случайном порядке), которые нужно обязательно осветить в данном разделе. На этом этапе я изучаю документацию, статьи, куски кода и прочие источники, чтобы получился максимально полный набор того, что я считаю важным рассказать в данном разделе.
🗓 Может занять от 1 дня до недели, в зависимости от сложности раздела.
B. Составление плана раздела. Тут уже список тем превращается в структуру, каждый из элементов которого логически связан с соседними. И тут уже важен порядок, т.к. именно по этому плану и будет создаваться материал раздела. Это еще осложняется тем, что нужно придумать практику которая идет по ходу прохождения, а также понять как бекенд будет производить проверку заданий.
🗓 Занимает несколько дней.
C. Написание текста самого курса. Следовать плану уже проще, особенно если он получился подробным, однако оформительская часть отнимает достаточно много времени. Я использую собственную платформу, которая позволяет делать курсы максимально гибкими. И если не хватает каких либо элементов, то дизайнер и фронтендер сделают свою работу и платформа будет доработана. Сам код раздела пишется на YAML, в которых есть кастомные типы для отображения блоков различного функционала. Например: выделение важного, кнопка, faq, ссылки, отображение серверного вывода и многое другое. Также на этом этапе происходит создание схем и диаграмм, чтобы материал был более понятным.
🗓 Этап может занять до 3 недель в некоторых случаях.
D. Создание бекенд части. Бекенд требуется для сохранения состояния прохождения разделов, отображения серверных выводов и, самое главное, проверки ваших заданий. В зависимости от курса, логика сильно отличается, поэтому единого решения тут не придумаешь. Однако, у меня, конечно, есть ряд своих лайфхаков и скриптов для генерации кода.
🗓 Занимает 1-2 дня.
E. Тестирование работы связки курса с бекенд частью, чтобы убедиться, что все работает как задумано.
🗓 Занимает примерно 1 день.
✅ После этих шагов можно переходить к следующему разделу =)
Хотел показать с какой заботой создается каждый курс, и насколько все материалы на моей платформе качественные и эффективные 🙂
👍6❤🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Сбои в облачной инфре. На кого валить?
Недавний (очередной) сбой в Яндекс.Облаке намекнул мне на тему поста, в котором попробуем определить зоны ответственности и способы обезопасить себя.
🧨 Аварии случаются, не важно, облако это или сервер в датацентре. Произойти может что угодно: пожар, наводнение, прилет БПЛА, противоправные действия и т.д. Как говорит народная мудрость: There is no cloud, it is just someone's else computer.
Но, выбирая облачные решения, мы хотим делегировать ответственность за неполадки на поставщика облачных услуг. Иначе зачем нам переплачивать за ресурсы, которые мы могли бы развернуть своими силами на физических серверах, пусть также арендованных. Да, есть еще и другие причины использовать облака, но все же когда эти все удобные вещи перестают работать в самый неподходящий момент, на первый план выходит как раз надежность.
Именно по этой причине многие компании используют свои решения и не подсаживаются на облачные. Конечно, свои сервера также могут выйти из чата в любой момент, но хотя бы у вас будут варианты кроме как сидеть и ждать когда все придет в норму. И вот тут как раз начинается самое интересное.
Если ты целиком сидишь в облаке, то у тебя просто нет вариантов в случае аварии, кроме как ждать 👽. Прошу заметить, что тут имеется в виду, что внутри облака у вас построена отказоустойчивая архитектура с множеством зон доступности и прочими атрибутами высокой доступности. Печаль в том, что это может не помочь. В этом случае вы говорите своим клиентам: извините, мое облако лежит и остается только ждать. Клиентам конечно, пофигу, они просто хотят, чтобы все работало. Но, у вас есть кого обвинить в этом, хотя по факту облажались вы, т.к. полностью доверились одному облаку.
Но у большинства компаний нет других вариантов, и им окей пойти на возможные и не такие уж большие риски ради экономии. Ну упадет раз-два в год, не так страшно. А вот кому страшно, тот изначально выстроит инфру так, чтобы у него были варианты переключения на резерв.
📎 Еще важно понимать, что сбой бывает глобальный, например прилегла вся сеть, а может быть локальный в виде упавшего сервиса или одной зоны доступности. Во втором случае у вас в теории могут быть варианты действий, которые помогут пережить данную проблему и быстрее восстановить сервис.
☝️Взвешивайте риски и обозначайте для себя SLO, так чтобы обещанный SLA для ваших клиентов был в рамках допустимого. Также имейте ввиду, что зона ответственности облачного провайдера заканчивается определенным периметром, в котором работает ваше приложение, и дальше начинается уже ваша ответственность. К примеру, если после сбоя на виртуальной машине у вас упала БД, но при этом машина запущена и работает, то это уже ваша забота, как восстановить БД.
Недавний (очередной) сбой в Яндекс.Облаке намекнул мне на тему поста, в котором попробуем определить зоны ответственности и способы обезопасить себя.
🧨 Аварии случаются, не важно, облако это или сервер в датацентре. Произойти может что угодно: пожар, наводнение, прилет БПЛА, противоправные действия и т.д. Как говорит народная мудрость: There is no cloud, it is just someone's else computer.
Но, выбирая облачные решения, мы хотим делегировать ответственность за неполадки на поставщика облачных услуг. Иначе зачем нам переплачивать за ресурсы, которые мы могли бы развернуть своими силами на физических серверах, пусть также арендованных. Да, есть еще и другие причины использовать облака, но все же когда эти все удобные вещи перестают работать в самый неподходящий момент, на первый план выходит как раз надежность.
Именно по этой причине многие компании используют свои решения и не подсаживаются на облачные. Конечно, свои сервера также могут выйти из чата в любой момент, но хотя бы у вас будут варианты кроме как сидеть и ждать когда все придет в норму. И вот тут как раз начинается самое интересное.
Если ты целиком сидишь в облаке, то у тебя просто нет вариантов в случае аварии, кроме как ждать 👽. Прошу заметить, что тут имеется в виду, что внутри облака у вас построена отказоустойчивая архитектура с множеством зон доступности и прочими атрибутами высокой доступности. Печаль в том, что это может не помочь. В этом случае вы говорите своим клиентам: извините, мое облако лежит и остается только ждать. Клиентам конечно, пофигу, они просто хотят, чтобы все работало. Но, у вас есть кого обвинить в этом, хотя по факту облажались вы, т.к. полностью доверились одному облаку.
Но у большинства компаний нет других вариантов, и им окей пойти на возможные и не такие уж большие риски ради экономии. Ну упадет раз-два в год, не так страшно. А вот кому страшно, тот изначально выстроит инфру так, чтобы у него были варианты переключения на резерв.
📎 Еще важно понимать, что сбой бывает глобальный, например прилегла вся сеть, а может быть локальный в виде упавшего сервиса или одной зоны доступности. Во втором случае у вас в теории могут быть варианты действий, которые помогут пережить данную проблему и быстрее восстановить сервис.
☝️Взвешивайте риски и обозначайте для себя SLO, так чтобы обещанный SLA для ваших клиентов был в рамках допустимого. Также имейте ввиду, что зона ответственности облачного провайдера заканчивается определенным периметром, в котором работает ваше приложение, и дальше начинается уже ваша ответственность. К примеру, если после сбоя на виртуальной машине у вас упала БД, но при этом машина запущена и работает, то это уже ваша забота, как восстановить БД.
👍5
Про ядро Linux и разработчиков из РФ
Обычно я политики не касаюсь в своих постах, но тут просто не мог пройти мимо. Вы, наверное, уже слышали о том, что дюжину российских разработчиков выпилили из списка мейнтейнеров ядра.
Все это дело оправдывается какими-то комплаенсами и прочим подобным бредом, якобы это были люди из подсанкционных компаний. Но ядро линукс - это некоммерческий проект и не принадлежит какой-то определенной компании и не относится к какой-либо стране. А то, что мы видим похоже на то, что США так не считают. Они нашли способ надавить на Линуса и других приближенных, так, чтобы испоганить саму идею open source и GPL в частности. Но кажется, что самого Линуса тут не пришлось сильно уговаривать, если посмотреть его реакцию и высказывания. Разочаровал меня Линус, конкретно. Мировое сообщество уже бурлит и негодует из-за данного очень неприятного прецедента.
☝️ На минуточку, разработчики - физ. лица, которые бесплатно добавляли в ядро новый функционал, полезный, в общем-то, всем. Ну, то есть может им и платили за это, но точно не Linux сообщество. Кому в итоге сделали хуже, кто больше потеряет от этого? Правильно, рядовые пользователи линукса со всего мира. Потому что компании, если им это будет нужно, просто форкнут ядро и будут добавлять нужные им патчи в свою ветку, периодически подтягивая из мейнстрима обновления. А вот обратно в мейнстрим их патчи уже не попадут. Гениально 🤯!
📎 Кстати, это не первое нападение на open source за последнее время. Вот тут даже сайт про изъяны Столлмана запилили. Кто это все спонсирует? Думаю понятно.
⌨️ В любом случае, Линукс остается самым большим open source проектом с огромным комьюнити, и альтернатив ему нет. Будем надеяться, что горячка отпустит и все будет хорошо. Пользуясь случаем, напомню, что в devopstrain есть отличный курс по Linux и сетям.
DevopsTrain
Обычно я политики не касаюсь в своих постах, но тут просто не мог пройти мимо. Вы, наверное, уже слышали о том, что дюжину российских разработчиков выпилили из списка мейнтейнеров ядра.
Все это дело оправдывается какими-то комплаенсами и прочим подобным бредом, якобы это были люди из подсанкционных компаний. Но ядро линукс - это некоммерческий проект и не принадлежит какой-то определенной компании и не относится к какой-либо стране. А то, что мы видим похоже на то, что США так не считают. Они нашли способ надавить на Линуса и других приближенных, так, чтобы испоганить саму идею open source и GPL в частности. Но кажется, что самого Линуса тут не пришлось сильно уговаривать, если посмотреть его реакцию и высказывания. Разочаровал меня Линус, конкретно. Мировое сообщество уже бурлит и негодует из-за данного очень неприятного прецедента.
☝️ На минуточку, разработчики - физ. лица, которые бесплатно добавляли в ядро новый функционал, полезный, в общем-то, всем. Ну, то есть может им и платили за это, но точно не Linux сообщество. Кому в итоге сделали хуже, кто больше потеряет от этого? Правильно, рядовые пользователи линукса со всего мира. Потому что компании, если им это будет нужно, просто форкнут ядро и будут добавлять нужные им патчи в свою ветку, периодически подтягивая из мейнстрима обновления. А вот обратно в мейнстрим их патчи уже не попадут. Гениально 🤯!
📎 Кстати, это не первое нападение на open source за последнее время. Вот тут даже сайт про изъяны Столлмана запилили. Кто это все спонсирует? Думаю понятно.
⌨️ В любом случае, Линукс остается самым большим open source проектом с огромным комьюнити, и альтернатив ему нет. Будем надеяться, что горячка отпустит и все будет хорошо. Пользуясь случаем, напомню, что в devopstrain есть отличный курс по Linux и сетям.
DevopsTrain
👍12
Разбираем метрики SLO, SLA, SLI
👉 SLO (Service Level Objective) — это показатель, который определяет целевой уровень доступности или производительности сервиса, предоставляемого пользователю. Это часть соглашения о качестве обслуживания (SLA), где SLO выступает в качестве конкретной метрики, которую нужно достичь. Например, SLO может указывать, что веб-сервис должен быть доступен 99.9% времени в течение месяца. SLO помогает командам разработки и эксплуатации ориентироваться на поддержание определенного уровня качества сервиса.
👉 SLA (Service Level Agreement) — это соглашение между поставщиком услуги и клиентом, которое определяет ожидаемый уровень качества и доступности сервиса. В SLA описываются конкретные метрики, такие как время отклика, доступность, производительность, а также действия в случае несоответствия этим требованиям. К примеру, если какой-то сервис упал и его доступность не вписывается в оговоренный SLO, то наступает момент, когда поставщику сервиса надо компенсировать простой согласно договоренности в SLA.
👉 SLI (Service Level Indicator) — это конкретная метрика, используемая для измерения уровня качества или производительности услуги. SLI показывает, насколько хорошо сервис выполняет свои функции в отношении определённого аспекта, например, времени отклика или доступности. Это фактическое измерение, которое помогает определить, соответствует ли услуга установленным целям (SLO) и условиям (SLA).
📎 Примеры для лучшего понимания:
Представьте, что у вас есть веб-сервис.
1️⃣ SLI (Service Level Indicator):
— Это фактическая метрика, например, среднее время отклика сервера, которое составляет 200 миллисекунд.
2️⃣ SLO (Service Level Objective):
— Это цель, которую вы хотите достичь, например, чтобы 95% запросов обрабатывались за 300 миллисекунд или быстрее.
3️⃣ SLA (Service Level Agreement):
— Это договор с клиентом, который включает SLO и другие условия. Например, вы обязуетесь поддерживать среднее время отклика в 95% случаев не более 300 миллисекунд и гарантируете компенсацию в случае нарушения этого условия.
📎 Таким образом, SLI — это то, что вы измеряете, SLO — это ваша цель, а SLA — это ваше обязательство перед клиентом. Эти параметры являются ключевыми в работе SRE.
✅ Жду вас на наших курсах и программе наставничества, с Нового года планируется повышение цен.
👉 SLO (Service Level Objective) — это показатель, который определяет целевой уровень доступности или производительности сервиса, предоставляемого пользователю. Это часть соглашения о качестве обслуживания (SLA), где SLO выступает в качестве конкретной метрики, которую нужно достичь. Например, SLO может указывать, что веб-сервис должен быть доступен 99.9% времени в течение месяца. SLO помогает командам разработки и эксплуатации ориентироваться на поддержание определенного уровня качества сервиса.
👉 SLA (Service Level Agreement) — это соглашение между поставщиком услуги и клиентом, которое определяет ожидаемый уровень качества и доступности сервиса. В SLA описываются конкретные метрики, такие как время отклика, доступность, производительность, а также действия в случае несоответствия этим требованиям. К примеру, если какой-то сервис упал и его доступность не вписывается в оговоренный SLO, то наступает момент, когда поставщику сервиса надо компенсировать простой согласно договоренности в SLA.
👉 SLI (Service Level Indicator) — это конкретная метрика, используемая для измерения уровня качества или производительности услуги. SLI показывает, насколько хорошо сервис выполняет свои функции в отношении определённого аспекта, например, времени отклика или доступности. Это фактическое измерение, которое помогает определить, соответствует ли услуга установленным целям (SLO) и условиям (SLA).
📎 Примеры для лучшего понимания:
Представьте, что у вас есть веб-сервис.
1️⃣ SLI (Service Level Indicator):
— Это фактическая метрика, например, среднее время отклика сервера, которое составляет 200 миллисекунд.
2️⃣ SLO (Service Level Objective):
— Это цель, которую вы хотите достичь, например, чтобы 95% запросов обрабатывались за 300 миллисекунд или быстрее.
3️⃣ SLA (Service Level Agreement):
— Это договор с клиентом, который включает SLO и другие условия. Например, вы обязуетесь поддерживать среднее время отклика в 95% случаев не более 300 миллисекунд и гарантируете компенсацию в случае нарушения этого условия.
📎 Таким образом, SLI — это то, что вы измеряете, SLO — это ваша цель, а SLA — это ваше обязательство перед клиентом. Эти параметры являются ключевыми в работе SRE.
👏 Кстати, этому каналу исполнился год! Ух, такое количество контента я наверное за всю жизнь до этого не сделал. Спасибо всем кто читает, реактит и комментит.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👏3👍1
А у вас так же?
Ну а если запустить кластер не получилось, то почувствовать силу помогут Kubernetes на практике и Kubernetes advanced😎
Ну а если запустить кластер не получилось, то почувствовать силу помогут Kubernetes на практике и Kubernetes advanced
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤1👍1
Импортозамещение или переезд с Google Suite на Yandex 360
К слову сказать, мы еще в процессе, но веселья уже столько, что захотелось рассказать.
Все прекрасно понимают, что по качеству и функционалу яндексу до гугла как до луны пешком. Тем не менее это лучшее из того что есть на отечественном рынке, поэтому мы сейчас неспешно переезжаем со всеми почтами, доками и прочим корпоративным барахлом. Ну как, мы переезжаем примерно также как Райффайзенбанк уходит из РФ, то есть все таки надеемся, что, так и не придется переключаться с гугла. Но план Б должен быть.
А учитывая сколько проблем вылезло, за день другой это сделать будет не возможно, а значит может случитьсяжопа и работа некоторых сотрудников будет сильно нарушена.
Изначально у нас был план интегрировать Keycloak с яндексом, чтобы каталог пользователей был у нас, а яндекс ходил бы к нам и использовал Keycloak в качестве IDP. У них отличная инструкция, к слову, но выполнив все шаги, мы обнаружили что авторизация не работает. Суппорт нам помочь не смог🚽 , к сожалению.
Еще одна проблема, которая вылезла на ровном месте - подтверждение домена. Да это ж проще простого, надо лишь создать TXT запись в DNS и нажать кнопку. Но нет, запись есть, а яндекс не хочет подтверждать домен. Как только мы не пытались это решить, но опять же суппорт помочь нам до сих пор не смог⛔️ . Я допускаю, что это мы такие невезучие и у остальных все прекрасно завелось, но все таки не должно быть в простых вещах таких сложностей.
🚬 Пока делаю следующий вывод:
Google, пожалуйста, не уходи...
DevopsTrain
К слову сказать, мы еще в процессе, но веселья уже столько, что захотелось рассказать.
Все прекрасно понимают, что по качеству и функционалу яндексу до гугла как до луны пешком. Тем не менее это лучшее из того что есть на отечественном рынке, поэтому мы сейчас неспешно переезжаем со всеми почтами, доками и прочим корпоративным барахлом. Ну как, мы переезжаем примерно также как Райффайзенбанк уходит из РФ, то есть все таки надеемся, что, так и не придется переключаться с гугла. Но план Б должен быть.
А учитывая сколько проблем вылезло, за день другой это сделать будет не возможно, а значит может случиться
Изначально у нас был план интегрировать Keycloak с яндексом, чтобы каталог пользователей был у нас, а яндекс ходил бы к нам и использовал Keycloak в качестве IDP. У них отличная инструкция, к слову, но выполнив все шаги, мы обнаружили что авторизация не работает. Суппорт нам помочь не смог
Еще одна проблема, которая вылезла на ровном месте - подтверждение домена. Да это ж проще простого, надо лишь создать TXT запись в DNS и нажать кнопку. Но нет, запись есть, а яндекс не хочет подтверждать домен. Как только мы не пытались это решить, но опять же суппорт помочь нам до сих пор не смог
🚬 Пока делаю следующий вывод:
DevopsTrain
Please open Telegram to view this post
VIEW IN TELEGRAM
😁13👍3🤔2
Golang исполнилось 15 лет
Не смог пройти мимо этого события, ведь golang играет значимую роль в мире DevOps. Посудите сами, такие продукты как Kubernetes, Terraform, Docker написаны с использованием этого замечательного языка. Да и обычная девопс рутина очень часто связана с написанием go кода. Например, создание операторов или автоматизация процедур.
🚀 Golang довольно быстро набрал популярность благодаря таким ключевым особенностям как компиляция в исполняемый файл, высокая производительность, легкая работа с асинхронными функциями, простой C-подобный синтаксис, богатая стандартная библиотека и многое другое.
📈 Все это позволило увеличить пользовательскую базу в 3 раза за последние 5 лет, что сделало его одним из самых быстрорастущих языков. Он стабильно входит в топ-10 языков программирования.
📎 В своей работе и своих проектах Golang - язык номер один, даже чаще использую, чем bash. Бекенд сервисы пишу на нем с 2015 года. К примеру бекенд платформы devopstrain и функционала проверки заданий, а также инструмент Kurator написаны на гошечке.
🤌 Кстати и проектная работа в рамках программы наставничества подразумевает работу с golang сервисами — отличная практика.
В целом я рекомендую обратить внимание на этот язык если вы еще его не используете, точно будет полезно. Он отлично подходит в качестве первого языка, в этом смысле он лучше, чем python, после которого приходится переучиваться. Ну а что вы хотели от языка, где отступы решают? ))
DevopsTrain
Не смог пройти мимо этого события, ведь golang играет значимую роль в мире DevOps. Посудите сами, такие продукты как Kubernetes, Terraform, Docker написаны с использованием этого замечательного языка. Да и обычная девопс рутина очень часто связана с написанием go кода. Например, создание операторов или автоматизация процедур.
🚀 Golang довольно быстро набрал популярность благодаря таким ключевым особенностям как компиляция в исполняемый файл, высокая производительность, легкая работа с асинхронными функциями, простой C-подобный синтаксис, богатая стандартная библиотека и многое другое.
📈 Все это позволило увеличить пользовательскую базу в 3 раза за последние 5 лет, что сделало его одним из самых быстрорастущих языков. Он стабильно входит в топ-10 языков программирования.
📎 В своей работе и своих проектах Golang - язык номер один, даже чаще использую, чем bash. Бекенд сервисы пишу на нем с 2015 года. К примеру бекенд платформы devopstrain и функционала проверки заданий, а также инструмент Kurator написаны на гошечке.
🤌 Кстати и проектная работа в рамках программы наставничества подразумевает работу с golang сервисами — отличная практика.
В целом я рекомендую обратить внимание на этот язык если вы еще его не используете, точно будет полезно. Он отлично подходит в качестве первого языка, в этом смысле он лучше, чем python, после которого приходится переучиваться. Ну а что вы хотели от языка, где отступы решают? ))
DevopsTrain
🔥10🤓1🦄1
Давайте порассуждаем на тему: а стоит ли становиться тимлидом?
👾 Нередкий случай, когда специалист меняет свою позицию с тимлида обратно на линейного инженера. И этому есть причины. Но начнем с плюсов.
➕Плюсы тимлидства:
1. Руководящая роль подразумевает меньше ручной работы, и больше орг. работы. Кому-то это ближе и нравится больше
2. Выигрыш по деньгам, пусть и незначительный
3. Иногда есть возможность набрать команду по своим предпочтениям, но опять же не всегда, иногда ты приходишь в команду, которая уже существует
4. У тебя больше рычагов давления и можно выстроить инфру по своим предпочтениям
➖Минусы тимлидства:
1. Очень часто приходится совмещать лидерскую работу и непосредственно работу руками, что требует определенного навыка
2. Выигрыш по деньгам может не покрывать возросшую нагрузку и ответственность, как правило, это именно так
3. Если работа руками полностью переложена на участников команды, то неминуема потеря хард-скиллов
4. Из пункта 3 следует, что позиция тимлида может стать тупиковой: с одной стороны ты растерял (пусть и в моменте) свои навыки работы руками, но при этом пробраться на позицию выше (например, CTO) далеко не всегда представляется возможным
5. Из пункта 4 следует, что ты можешь оказаться в ситуации vendor-lock, то есть в зависимости от работы в одной компании, что очень плохо
Именно поэтому переходы в тимлидерство и обратно - это хорошая практика для тех, кому просто быть сеньoром скучно =)
P.S: cо следующего года планируется повышение цен на индивидуальное наставничество. Успейте забронировать по старой цене 😎
DevopsTrain
👾 Нередкий случай, когда специалист меняет свою позицию с тимлида обратно на линейного инженера. И этому есть причины. Но начнем с плюсов.
➕Плюсы тимлидства:
1. Руководящая роль подразумевает меньше ручной работы, и больше орг. работы. Кому-то это ближе и нравится больше
2. Выигрыш по деньгам, пусть и незначительный
3. Иногда есть возможность набрать команду по своим предпочтениям, но опять же не всегда, иногда ты приходишь в команду, которая уже существует
4. У тебя больше рычагов давления и можно выстроить инфру по своим предпочтениям
➖Минусы тимлидства:
1. Очень часто приходится совмещать лидерскую работу и непосредственно работу руками, что требует определенного навыка
2. Выигрыш по деньгам может не покрывать возросшую нагрузку и ответственность, как правило, это именно так
3. Если работа руками полностью переложена на участников команды, то неминуема потеря хард-скиллов
4. Из пункта 3 следует, что позиция тимлида может стать тупиковой: с одной стороны ты растерял (пусть и в моменте) свои навыки работы руками, но при этом пробраться на позицию выше (например, CTO) далеко не всегда представляется возможным
5. Из пункта 4 следует, что ты можешь оказаться в ситуации vendor-lock, то есть в зависимости от работы в одной компании, что очень плохо
Именно поэтому переходы в тимлидерство и обратно - это хорошая практика для тех, кому просто быть сеньoром скучно =)
DevopsTrain
👍4
Когда я начинал свой путь в DevOps никаких системных обучений не было. Да и девопса тогда тоже еще не было 😅. Приходилось набивать шишки самостоятельно.
Сейчас вроде как стало проще, множество образовательных курсов, платформ, обучений. Но системные ли они и дадут ли тот выхлоп, на который надеется ученик?
Проблема в том, что большинство обучающих платформ коммерческие, и помимо DevOps программ у них зачастую можно встретить курсы по вязанию зеленого енота или "психолог за 2 недели". Ну сами понимаете качество подобных обучений.
Так вот, возвращаемся к системности, что мы обычно ждем от программы:
👉 Волшебный пинок (зачастую)
👉 Поддержание мотивации
👉 Релевантные и актуальные знания
👉 Перспективы в дальнейшем
☝️ Так что важно найти продукт, который будет удовлетворять этим потребностям. Ну и тут появляюсь я со своей Программой Наставничества.
Так вот, про программу: это по сути уникальное предложение, которое может ДЕЙСТВИТЕЛЬНО вывести вас на новый уровень (были джуном, стали мидлом, были мидлом - прокачались до синьера) за полгода.
Нет, я не волшебник, сыворотку лучшей версии себя не дам, но сделаю все возможное чтобы вы не сбились с пути и покорили этот devops.
Это индивидуальное наставничество для максимально эффективного обучения профессии DevOps инженера и достижения ваших конечных целей: повышения зарплаты, грейда, устройства на желаемую работу.
Во первых, никаких привычных "потоков" и видео-уроков. Начинаете когда захотите, проходите курсы на тренажере, берете консультации (4 штуки включены), полируете реальным рабочим проектом. И с улыбочкой идете искать работу, ну или на мои стажировки (за вами уже очередь 😎).
Перед началом мы конечно проходим все этапы, куда же без них:
❔А оно мне надо? Подойдет/не подойдет?
Если не уверены в скиллах - пишите мне, если не уверены в себе - пишите психологу
❔ А хватит ли у меня времени?
Программа рассчитана на busy buddies, так что за полгода уделяя от 7 часов в неделю вы справитесь. Да и доступ к курсам останется у вас навсегда.
❔ А что я потом получу?
Актуальные знания, НАВЫКИ, сертификат и кейс, который можно добавить в резюме
⚡️ Ну и напоминаю, цены с 2025 повышаются :)
Сейчас вроде как стало проще, множество образовательных курсов, платформ, обучений. Но системные ли они и дадут ли тот выхлоп, на который надеется ученик?
Проблема в том, что большинство обучающих платформ коммерческие, и помимо DevOps программ у них зачастую можно встретить курсы по вязанию зеленого енота или "психолог за 2 недели". Ну сами понимаете качество подобных обучений.
Так вот, возвращаемся к системности, что мы обычно ждем от программы:
👉 Волшебный пинок (зачастую)
👉 Поддержание мотивации
👉 Релевантные и актуальные знания
👉 Перспективы в дальнейшем
☝️ Так что важно найти продукт, который будет удовлетворять этим потребностям. Ну и тут появляюсь я со своей Программой Наставничества.
Так вот, про программу: это по сути уникальное предложение, которое может ДЕЙСТВИТЕЛЬНО вывести вас на новый уровень (были джуном, стали мидлом, были мидлом - прокачались до синьера) за полгода.
Нет, я не волшебник, сыворотку лучшей версии себя не дам, но сделаю все возможное чтобы вы не сбились с пути и покорили этот devops.
Что такое?
Это индивидуальное наставничество для максимально эффективного обучения профессии DevOps инженера и достижения ваших конечных целей: повышения зарплаты, грейда, устройства на желаемую работу.
А как выглядит?
Во первых, никаких привычных "потоков" и видео-уроков. Начинаете когда захотите, проходите курсы на тренажере, берете консультации (4 штуки включены), полируете реальным рабочим проектом. И с улыбочкой идете искать работу, ну или на мои стажировки (за вами уже очередь 😎).
Перед началом мы конечно проходим все этапы, куда же без них:
❔А оно мне надо? Подойдет/не подойдет?
Если не уверены в скиллах - пишите мне, если не уверены в себе - пишите психологу
❔ А хватит ли у меня времени?
Программа рассчитана на busy buddies, так что за полгода уделяя от 7 часов в неделю вы справитесь. Да и доступ к курсам останется у вас навсегда.
❔ А что я потом получу?
Актуальные знания, НАВЫКИ, сертификат и кейс, который можно добавить в резюме
Для меня давно не новость, что многие по 3-12 месяцев думают над покупкой программы наставничества. И даже потом не всегда решаются. Зачастую важно сделать этот первый шаг. Как зайти в воду по щиколотку, чтобы начать привыкать к температуре.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6💊1
Недавно вышел очередной Kubernetes под версией 1.32.
Давайте разберем основные изменения и улучшения в данной версии:
👉 возможность отдельно вывести stderr поток в kubectl logs. Ранее выводился комбинированный лог из stdout & stderr
👉 возможность задать ресурсы на уровне пода. Ранее можно было только на уровне каждого из контейнеров внутри пода
👉 теперь можно снимать согласованные снепшоты сразу с нескольких волумов через указание общего лейбла
👉 PersistentVolumeClaims (PVC), создаваемые StatefulSet, теперь автоматически удаляются, когда больше не нужны, при этом обеспечивается сохранность данных во время обновлений StatefulSet и обслуживания узлов. Эта функция упрощает управление хранилищем для StatefulSets и снижает риск появления брошенных PVC
👉 cелектор полей пользовательских ресурсов (CRD) позволяет разработчикам добавлять селекторы полей к пользовательским ресурсам, отражая функциональность, доступную для встроенных объектов Kubernetes.
👉 множество других мелких и не очень изменений на более низких уровнях k8s
📎 Напомню, что новые версии выходят примерно 3 раза в год.
📌 И несмотря на то, что база будет актуальна всегда, я постоянно обновляю свои кубер-курсы "Kubernetes на практике" и "Kubernetes Advanced" 💪
DevopsTrain
Давайте разберем основные изменения и улучшения в данной версии:
👉 возможность отдельно вывести stderr поток в kubectl logs. Ранее выводился комбинированный лог из stdout & stderr
👉 возможность задать ресурсы на уровне пода. Ранее можно было только на уровне каждого из контейнеров внутри пода
👉 теперь можно снимать согласованные снепшоты сразу с нескольких волумов через указание общего лейбла
👉 PersistentVolumeClaims (PVC), создаваемые StatefulSet, теперь автоматически удаляются, когда больше не нужны, при этом обеспечивается сохранность данных во время обновлений StatefulSet и обслуживания узлов. Эта функция упрощает управление хранилищем для StatefulSets и снижает риск появления брошенных PVC
👉 cелектор полей пользовательских ресурсов (CRD) позволяет разработчикам добавлять селекторы полей к пользовательским ресурсам, отражая функциональность, доступную для встроенных объектов Kubernetes.
👉 множество других мелких и не очень изменений на более низких уровнях k8s
📎 Напомню, что новые версии выходят примерно 3 раза в год.
DevopsTrain
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍1
Итоги года в DevopsTrain 🚄
💫 Хотел бы поздравить вас с наступающими праздниками и подвести итоги года на нашей платформе Devopstrain.
Я рад каждому вопросу, который вы задаете в рамках освоения курсов, они помогают определить слабые места и улучшить, доработать курс 💪
Итак, итоги года 2024:
👉 В январе произошло знаменательное событие - запуск программы наставничества
👉 С марта началось создание курса Linux & Networks, которое длилось оставшуюся часть года
👉 За год было 4 релиза платформы с исправлениями и добавлениями новых функций. О последнем в этом году релизе рассказываю подробнее ниже.
👉 Договоренность о возможности стажировки (после программы обучения) с двумя компаниями
👉 Добавлен вариант курса по Terraform для AWS
👉 Devops Roadmap дополнен новыми разделами
👉 Отрефакторена логика работы с k8s, вынесена в отдельный сервис, что улучшило взаимодействие с вашими кластерами
👉 Множественные обновления всех курсов, включая фирменные диаграммы для наглядности
🚀 Платформа для практического обучения продолжает активно улучшаться. Сегодня я рад сообщить вам, что доступен новый релиз 0.4.0, который включает следующие функции:
▪️Тема (светлая/темная) теперь следует за системной темой, если вы не переключали ее вручную
▪️Функционал заметок: вы можете оставлять приватные и публичные заметки в новой вкладке Заметки. Заметки могут быть в виде текста или ссылок. Делая заметку публичной, вы включаете возможность отображения публичных заметок от других участников. Делитесь полезной информацией!
1️⃣ 1 курс + еще 1 курс = 3 курса
Выбирайте 2 курса на платформе и забирайте третий в подарок
2️⃣ Последняя возможность записаться на Индивидуальное наставничество по старой цене!
Ну и конечно мне будет приятно получить комментарии о канале и платформе :)
💫 Хотел бы поздравить вас с наступающими праздниками и подвести итоги года на нашей платформе Devopstrain.
Я рад каждому вопросу, который вы задаете в рамках освоения курсов, они помогают определить слабые места и улучшить, доработать курс 💪
Итак, итоги года 2024:
👉 В январе произошло знаменательное событие - запуск программы наставничества
👉 С марта началось создание курса Linux & Networks, которое длилось оставшуюся часть года
👉 За год было 4 релиза платформы с исправлениями и добавлениями новых функций. О последнем в этом году релизе рассказываю подробнее ниже.
👉 Договоренность о возможности стажировки (после программы обучения) с двумя компаниями
👉 Добавлен вариант курса по Terraform для AWS
👉 Devops Roadmap дополнен новыми разделами
👉 Отрефакторена логика работы с k8s, вынесена в отдельный сервис, что улучшило взаимодействие с вашими кластерами
👉 Множественные обновления всех курсов, включая фирменные диаграммы для наглядности
🚀 Платформа для практического обучения продолжает активно улучшаться. Сегодня я рад сообщить вам, что доступен новый релиз 0.4.0, который включает следующие функции:
▪️Тема (светлая/темная) теперь следует за системной темой, если вы не переключали ее вручную
▪️Функционал заметок: вы можете оставлять приватные и публичные заметки в новой вкладке Заметки. Заметки могут быть в виде текста или ссылок. Делая заметку публичной, вы включаете возможность отображения публичных заметок от других участников. Делитесь полезной информацией!
🚆Кроме этого до 15 января действуют всеми любимые акции:
1️⃣ 1 курс + еще 1 курс = 3 курса
Выбирайте 2 курса на платформе и забирайте третий в подарок
2️⃣ Последняя возможность записаться на Индивидуальное наставничество по старой цене!
Ну и конечно мне будет приятно получить комментарии о канале и платформе :)
👍9
Захотелось поделиться отзывами по моей программе наставничества, которой скоро исполняется 1 год с момента запуска 👏
За это время произошло множество событий, а сама программа была адаптирована и дополнена. Теперь все процессы отточены и обучение идет полным ходом 🤌
✅ Также стоит отметить, что у меня есть договоренность с двумя компаниями, которые могут взять на стажировку выпускников данной программы с последующим устройством на реальный проект в крупные организации (банки, маркетплейсы и т.д.). Тем самым мы с вами решаем проблему курицы и яйца: когда людей не берут на работу без опыта, а опыт они не могут получить без работы.
Присоединяйтесь! Места ограничены.
За это время произошло множество событий, а сама программа была адаптирована и дополнена. Теперь все процессы отточены и обучение идет полным ходом 🤌
✅ Также стоит отметить, что у меня есть договоренность с двумя компаниями, которые могут взять на стажировку выпускников данной программы с последующим устройством на реальный проект в крупные организации (банки, маркетплейсы и т.д.). Тем самым мы с вами решаем проблему курицы и яйца: когда людей не берут на работу без опыта, а опыт они не могут получить без работы.
Присоединяйтесь! Места ограничены.
🔥7👍3⚡1
Мифы о Devops
👻 Devops - это сисадмин с большой зарплатой
Нет, devops обладает навыками сисадмина, но обычно сисадмину есть что подтянуть в своих навыках, чтобы стать девопс-инженером.
👻 Девопс - это про инструменты.
Нет, девопс это даже не человек, это подход. Хотя Devops-инженер вполне себе человек, которые применяет на практике парадигму и помогает остальным участникам команды следовать этой методике.
👻 Devops инженеру обязательно уметь программировать
Нет, для уровня junior это не обязательно, но будет большим плюсом, а для сеньора да, обязательно.
👻 Если подходы devops сработали в одной компании, то они будут работать и в любой другой
Нет, это не так, подстраивать процессы нужно в каждой отдельной компании или команде.
👻 Devops - это ci/cd
Конечно же нет, это куда сложнее и глобальнее.
👻 Без devops инженеров компания не сможет работать
Сможет, но до определенного момента. Хотя у некоторых компаний, даже известных, этот момент еще не наступил =)
👻 Devops - это ответ на все проблемы в компании
Нет, он не поможет если в компании не принято что-то менять в целях улучшения эффективности или если есть другие, несовместимые с ним подходы.
👻 Devops только для больших компаний
Нет, даже в малых компаниях практики devops могут сделать процессы релизов и разработки более простыми, частыми и прозрачными, что уменьшает время доставки обновлений конечным пользователям.
А с какими мифами сталкивались вы? 👀
👻 Devops - это сисадмин с большой зарплатой
Нет, devops обладает навыками сисадмина, но обычно сисадмину есть что подтянуть в своих навыках, чтобы стать девопс-инженером.
👻 Девопс - это про инструменты.
Нет, девопс это даже не человек, это подход. Хотя Devops-инженер вполне себе человек, которые применяет на практике парадигму и помогает остальным участникам команды следовать этой методике.
👻 Devops инженеру обязательно уметь программировать
Нет, для уровня junior это не обязательно, но будет большим плюсом, а для сеньора да, обязательно.
👻 Если подходы devops сработали в одной компании, то они будут работать и в любой другой
Нет, это не так, подстраивать процессы нужно в каждой отдельной компании или команде.
👻 Devops - это ci/cd
Конечно же нет, это куда сложнее и глобальнее.
👻 Без devops инженеров компания не сможет работать
Сможет, но до определенного момента. Хотя у некоторых компаний, даже известных, этот момент еще не наступил =)
👻 Devops - это ответ на все проблемы в компании
Нет, он не поможет если в компании не принято что-то менять в целях улучшения эффективности или если есть другие, несовместимые с ним подходы.
👻 Devops только для больших компаний
Нет, даже в малых компаниях практики devops могут сделать процессы релизов и разработки более простыми, частыми и прозрачными, что уменьшает время доставки обновлений конечным пользователям.
А с какими мифами сталкивались вы? 👀
👍9
Программе Менторства исполнился ровно 1 год! 🫣
🗓 22 января прошлого года я, в качестве эксперимента, стартовал программу наставничества, о которой сообщил в рассылке. Честно сказать, не ожидал получить столько откликов в первые же дни. У меня даже не все было готово на тот момент, но первые студенты начали обучение уже 23 января! 😄
За последний год было много сделано для улучшения программы: улучшена сама интерактивная платформа, добавлены новые курсы и обновлены разделы старых, дополнены доступные в программе материалы (devops кейсы, ответы на вопросы технических интервью).
Но главное - это получен бесценный опыт работы с учащимися. Никогда не думал, что я стану преподавателем или ментором, но куда нас жизнь только не забрасывает. Самое интересное, что мне это оказалось по душе, и я очень рад такому повороту.
За год несколько десятков человек начали или прошли программу и это очень мотивирует двигаться дальше. Спасибо всем за обратную связь и за ваше усердие в обучении 🤝❤️🔥.
А я, тем временем, буду рад познакомиться с новыми людьми, которые также хотели бы улучшить свои навыки в весьма востребованной сфере. Приходите!
🗓 22 января прошлого года я, в качестве эксперимента, стартовал программу наставничества, о которой сообщил в рассылке. Честно сказать, не ожидал получить столько откликов в первые же дни. У меня даже не все было готово на тот момент, но первые студенты начали обучение уже 23 января! 😄
За последний год было много сделано для улучшения программы: улучшена сама интерактивная платформа, добавлены новые курсы и обновлены разделы старых, дополнены доступные в программе материалы (devops кейсы, ответы на вопросы технических интервью).
Но главное - это получен бесценный опыт работы с учащимися. Никогда не думал, что я стану преподавателем или ментором, но куда нас жизнь только не забрасывает. Самое интересное, что мне это оказалось по душе, и я очень рад такому повороту.
За год несколько десятков человек начали или прошли программу и это очень мотивирует двигаться дальше. Спасибо всем за обратную связь и за ваше усердие в обучении 🤝❤️🔥.
А я, тем временем, буду рад познакомиться с новыми людьми, которые также хотели бы улучшить свои навыки в весьма востребованной сфере. Приходите!
❤9👍7
Как проходит типичный рабочий день девопса ❓
Конечно у всех он отличается, но я расскажу про свой.
Итак, просыпаюсь, понятное дело без будильника. По будильнику - только в аэропорт =) Дольше 8-9 утра обычно не сплю, могу и в 5-6 встать, как повезет. Далее незатейливый завтрак за проверкой почты, сообщений и алертов, накопившихся за ночь. День как правило уже распланирован накануне, и вот эти сообщения могут внести коррективы в планы, но это абсолютно нормально. Отвечаю на ваши вопросы и провожу консультации.
До обеда, как правило, получается все разрулить и даже вместить небольшую физактивность🏋️♀️ , а иногда и утреннюю прогулку (если, конечно, на улице хорошая погода). Далее обед дома или в кафе, который переходит в хорошую прогулку часа на полтора-два. Да, 15 тыс шагов сами себя не пройдут. Остаюсь на связи все это время и даже иногда беру с собой дорожный ноут для решения срочных проблем, которые случаются, впрочем, не часто.
👨💻 По возращении домой разгребаю, если что-то накопилось с обеда, и продолжаю запланированную работу до ужина. А после основного дня бывают созвоны с учениками.
💡 Вот примерно так и проходит мой рабочий день.
Делитесь своим в комментариях 👇
DevopsTrain
Конечно у всех он отличается, но я расскажу про свой.
Итак, просыпаюсь, понятное дело без будильника. По будильнику - только в аэропорт =) Дольше 8-9 утра обычно не сплю, могу и в 5-6 встать, как повезет. Далее незатейливый завтрак за проверкой почты, сообщений и алертов, накопившихся за ночь. День как правило уже распланирован накануне, и вот эти сообщения могут внести коррективы в планы, но это абсолютно нормально. Отвечаю на ваши вопросы и провожу консультации.
До обеда, как правило, получается все разрулить и даже вместить небольшую физактивность
Делитесь своим в комментариях 👇
DevopsTrain
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥5