DevOps как гавань в чудном мире ИИ
В продолжение темы про то, как не пойти работать курьером, хотел поделиться соображениями почему девопсов пока ИИ не сможет заменить. Под девопсами я понимаю целый класс смежных специалистов, в том числе: devsecops, mlops, cloud engineer, platform engineer, и т.д. В среднем девопсу хорошо бы шарить хотя бы немного во всех этих областях, но речь пока не про это. Ранее я высказывал мысль, что раз
👻Иногда проскакивают и другие точки зрения на этот счет. Мол, если человек работает быстрее - значит можно дать ему больше работы, при этом никого не увольнять. В теории да, но рынок не бесконечный, и выводить в еще большем количестве новых продуктов на него далеко не всегда имеет смысл. Не каждая компания может позволить себе так расширяться, зачастую работая себе в минус ради 'большей доли в будущем'. Да и прирост населения потихоньку сокращается, экономики замедляются. Выходит, что все таки сокращения это наиболее частый сценарий на сегодняшний день.
Сейчас вполне очевидно, что почти весь прикладной софт будет разрабатываться с помощью ИИ. Конечно, останется небольшой процент "системников", где важна глубокая экспертиза, и они будут писать по старинке, но все равно с привлечением AI технологий. Уже сейчас идет разработка языков программирования нового поколения, созданных специально для нейронок. Синтаксис этих языков - просто английский язык, то есть порог вхождения будет еще ниже, чем сейчас.
🐶 Мы, девопсы, с интересом наблюдаем за этим всем и пользуемся, в том числе и для своих целей. Но любой код, не важно кем написанный, нужно где-то запускать и как-то поддерживать его работу, мониторить, восстанавливать в случае аварий и т.д.
И не только потому что это подразумевает передачу паролей и ключей в небезопасный контур. Даже если вопрос с безопасностью будет решен путем запуска модели у себя, все равно действия ИИ могут сломать все случайным образом, а ответственность на ком в этом случае будет?
➡️ Еще причина по которой ИИ курит в сторонке - это очень сложная и зачастую нелогичная инфраструктура, где данные есть только в головах людей, и как решать ту или иную проблему только они и знают.
Так что приходите учиться на практике тому, что будет актуально еще долгое время 😉
👉Devops Roadmap
👉Наставничество
👉Курсы
В продолжение темы про то, как не пойти работать курьером, хотел поделиться соображениями почему девопсов пока ИИ не сможет заменить. Под девопсами я понимаю целый класс смежных специалистов, в том числе: devsecops, mlops, cloud engineer, platform engineer, и т.д. В среднем девопсу хорошо бы шарить хотя бы немного во всех этих областях, но речь пока не про это. Ранее я высказывал мысль, что раз
AI делает работу более эффективной, значит и меньше сотрудников требуется для ее выполнения.
👻Иногда проскакивают и другие точки зрения на этот счет. Мол, если человек работает быстрее - значит можно дать ему больше работы, при этом никого не увольнять. В теории да, но рынок не бесконечный, и выводить в еще большем количестве новых продуктов на него далеко не всегда имеет смысл. Не каждая компания может позволить себе так расширяться, зачастую работая себе в минус ради 'большей доли в будущем'. Да и прирост населения потихоньку сокращается, экономики замедляются. Выходит, что все таки сокращения это наиболее частый сценарий на сегодняшний день.
Сейчас вполне очевидно, что почти весь прикладной софт будет разрабатываться с помощью ИИ. Конечно, останется небольшой процент "системников", где важна глубокая экспертиза, и они будут писать по старинке, но все равно с привлечением AI технологий. Уже сейчас идет разработка языков программирования нового поколения, созданных специально для нейронок. Синтаксис этих языков - просто английский язык, то есть порог вхождения будет еще ниже, чем сейчас.
🐶 Мы, девопсы, с интересом наблюдаем за этим всем и пользуемся, в том числе и для своих целей. Но любой код, не важно кем написанный, нужно где-то запускать и как-то поддерживать его работу, мониторить, восстанавливать в случае аварий и т.д.
Конечно, доверить такие серьезные вещи ИИ, очевидно, нельзя.
И не только потому что это подразумевает передачу паролей и ключей в небезопасный контур. Даже если вопрос с безопасностью будет решен путем запуска модели у себя, все равно действия ИИ могут сломать все случайным образом, а ответственность на ком в этом случае будет?
➡️ Еще причина по которой ИИ курит в сторонке - это очень сложная и зачастую нелогичная инфраструктура, где данные есть только в головах людей, и как решать ту или иную проблему только они и знают.
Так что приходите учиться на практике тому, что будет актуально еще долгое время 😉
👉Devops Roadmap
👉Наставничество
👉Курсы
👍8❤1
Немного про DevSecOps
Т.к. я сейчас работаю над созданием нового курса, решил и пост сделать на эту тему.
В чем, собственно, суть подхода в DevSecOps, и чем он отличается от того, как обычно решали проблемы с безопасностью?
🔵 Раньше:
Отдельная security-команда (если она есть, кхе-кхе) периодически проводит свои тесты на предмет известных уязвимостей тестового стенда, а иногда сразу и прода. Даже возможно смотрит в код приложения, но это не точно. Далее дает обратную связь разработчикам, если есть что исправить.
🔵 Сейчас:
Статические (код) и динамические (запущенное приложение) проверки встроены в CI-пайплайн, и разработчики постоянно получают обратную связь от инструментов-анализаторов. Безопасность становится общей ответственностью, а не только службы безопасности.
📎 Что касается самих инструментов, то ярким примером являются SonarQube, Checkmarx.
Впрочем, далеко не везде заморачиваются с такими вещами, из-за чего сливы пользовательских данных — очень частое явление. Но понятно одно: с этим всем можно и нужно бороться, а спрос на внедрение DevSecOps будет расти.
📍 Devops Roadmap
👉 Наставничество
👉 Курсы
Т.к. я сейчас работаю над созданием нового курса, решил и пост сделать на эту тему.
В чем, собственно, суть подхода в DevSecOps, и чем он отличается от того, как обычно решали проблемы с безопасностью?
Отдельная security-команда (если она есть, кхе-кхе) периодически проводит свои тесты на предмет известных уязвимостей тестового стенда, а иногда сразу и прода. Даже возможно смотрит в код приложения, но это не точно. Далее дает обратную связь разработчикам, если есть что исправить.
Статические (код) и динамические (запущенное приложение) проверки встроены в CI-пайплайн, и разработчики постоянно получают обратную связь от инструментов-анализаторов. Безопасность становится общей ответственностью, а не только службы безопасности.
Безопасность — это не только код, это еще инфраструктура, которая архитектурно должна быть безопасной. А также и организационно.
Впрочем, далеко не везде заморачиваются с такими вещами, из-за чего сливы пользовательских данных — очень частое явление. Но понятно одно: с этим всем можно и нужно бороться, а спрос на внедрение DevSecOps будет расти.
👉 Наставничество
👉 Курсы
Please open Telegram to view this post
VIEW IN TELEGRAM
2.48K👍6
Меня часто спрашивают:
Смогу ли я устроиться на работу после вашей программы❔ ❔
Конечно, при должном упорстве и уровне знаний можно получить работу с зарплатой от 250-300к и окупить наставничество за неделю-две. В обучении вся нужная информация и вопросы собеседований, которые часто задают работодатели
Жду вас на своем обучении, с сентября планирую повышение цены
Please open Telegram to view this post
VIEW IN TELEGRAM
2.42K🔥11❤1👍1😁1
Startup, Mid-size, Enterprise
▶️Мне приходилось работать в компаниях разного размера, решил поделиться, в чем для себя я увидел отличия, плюсы и минусы.
⏩Работа в стартапах (до 50 человек) — весело, задорно, хаотично, иногда аврально, но сильно заметна очевидная связь между тем, что ты сделал и эффектом для компании. Возможно потому, что когда ты роняешь прод, это действительно трудно не заметить)) Или оптимизировал расходы на сервера, чтобы оставить больше бюджета на рекламу. А уж если ты еще бэкенд пишешь, то там еще больше можешь влиять на результат. Из минусов можно выделить необходимость выстраивать различные процессы, а код и инфраструктура еще не имеют жестких гайдлайнов. Как правило, даже нет infra-as-a-code. Тем не менее мне до сих пор нравится работать в таких компаниях, люблю приводить все в порядок.
⏩В компании среднего размера (порядка 100+ человек) от тебя зависит чуть меньше, т.к. по идее твоя роль должна быть задублирована вторым и может быть третьим человеком.
Однако несмотря на большее число сотрудников, ты все еще напрямую влияешь на работоспособность продуктов компании. К плюсам можно отнести выстроенный подход к разработке и релизам, а также широкое использование инструментов вроде terraform, helm, ansible для работы с инфрой.
⏩В корпорациях (1000+ сотрудников) твоя роль становится более узкоспециализированной, и твое влияние на конечный результат заметно снижается. Процессы строго регламентированы, каждый шаг требует согласований, а решения принимаются на верхнем уровне. Из плюсов — стабильность, четкая структура и возможность работать с масштабными системами. Однако, бюрократия и медленное принятие решений могут раздражать. Инфраструктурные решения уже выстроены годами, и внесение изменений требует тщательного обоснования. Тем не менее это отличная возможность набраться опыта работы в крупных проектах и понять, как функционируют сложные системы.
✌️ Devops Roadmap
✅ Наставничество
✅ Курсы
▶️Мне приходилось работать в компаниях разного размера, решил поделиться, в чем для себя я увидел отличия, плюсы и минусы.
Startup
⏩Работа в стартапах (до 50 человек) — весело, задорно, хаотично, иногда аврально, но сильно заметна очевидная связь между тем, что ты сделал и эффектом для компании. Возможно потому, что когда ты роняешь прод, это действительно трудно не заметить)) Или оптимизировал расходы на сервера, чтобы оставить больше бюджета на рекламу. А уж если ты еще бэкенд пишешь, то там еще больше можешь влиять на результат. Из минусов можно выделить необходимость выстраивать различные процессы, а код и инфраструктура еще не имеют жестких гайдлайнов. Как правило, даже нет infra-as-a-code. Тем не менее мне до сих пор нравится работать в таких компаниях, люблю приводить все в порядок.
Mid-size
⏩В компании среднего размера (порядка 100+ человек) от тебя зависит чуть меньше, т.к. по идее твоя роль должна быть задублирована вторым и может быть третьим человеком.
Однако несмотря на большее число сотрудников, ты все еще напрямую влияешь на работоспособность продуктов компании. К плюсам можно отнести выстроенный подход к разработке и релизам, а также широкое использование инструментов вроде terraform, helm, ansible для работы с инфрой.
Enterprise
⏩В корпорациях (1000+ сотрудников) твоя роль становится более узкоспециализированной, и твое влияние на конечный результат заметно снижается. Процессы строго регламентированы, каждый шаг требует согласований, а решения принимаются на верхнем уровне. Из плюсов — стабильность, четкая структура и возможность работать с масштабными системами. Однако, бюрократия и медленное принятие решений могут раздражать. Инфраструктурные решения уже выстроены годами, и внесение изменений требует тщательного обоснования. Тем не менее это отличная возможность набраться опыта работы в крупных проектах и понять, как функционируют сложные системы.
По большому счету разница между среднего размера компаниями и большими только в стабильности и многообразии продуктов, но как правило ты все равно работаешь в команде такого же размера и имеешь дело с таким же набором коллег.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Middle или Junior ❔
Если вы не вчера начали свой путь в IT, и тем более если в смежной DevOps области вроде сисадминства имели опыт, то вероятно вам всерьез стоит задуматься о позиционировании себя как Middle.
➡️ Поясню почему.
Допустим, вы хотите перейти в devops, но вам кажется, что ваших навыков достаточно только для джун позиции. Это нормально и вероятно вы адекватно оцениваете свой уровень. Однако, возможно что вы уже не джун, хотя еще и не мидл.
Но т.к. вы не можете быть как та обезьяна в анекдоте, вам все таки придется выбрать что написать в резюме или на какую вакансию подаваться.
Кажется, что в таком случае действительно лучше пробовать быть мидлом, даже если вы чуток не дотягиваете. Подтянуть навыки можно в достаточно сжатые сроки, это будет полезно даже если вы пойдете джуном, позволит вам выглядеть более выгодно на фоне остальных. Конечно, кроме хард скилов нужно прокачаться и в софт скилах, а также иметь правильно оформленное резюме. Но это уже тема для отдельного разговора.
Кстати, по зарплате между джуном и мидлом тоже разница существенная.
✍️ Приходите учиться на мою программу менторства, которая не только быстро вас подтянет до нужного уровня, но и научит презентовать себя в выгодном свете.
💡 💡 На лето осталось немного свободных мест 🙂
Если вы не вчера начали свой путь в IT, и тем более если в смежной DevOps области вроде сисадминства имели опыт, то вероятно вам всерьез стоит задуматься о позиционировании себя как Middle.
Допустим, вы хотите перейти в devops, но вам кажется, что ваших навыков достаточно только для джун позиции. Это нормально и вероятно вы адекватно оцениваете свой уровень. Однако, возможно что вы уже не джун, хотя еще и не мидл.
Но т.к. вы не можете быть как та обезьяна в анекдоте, вам все таки придется выбрать что написать в резюме или на какую вакансию подаваться.
Конкуренция среди джунов будет повыше чем среди мидлов, а спрос с них не намного меньше.
Кажется, что в таком случае действительно лучше пробовать быть мидлом, даже если вы чуток не дотягиваете. Подтянуть навыки можно в достаточно сжатые сроки, это будет полезно даже если вы пойдете джуном, позволит вам выглядеть более выгодно на фоне остальных. Конечно, кроме хард скилов нужно прокачаться и в софт скилах, а также иметь правильно оформленное резюме. Но это уже тема для отдельного разговора.
Кстати, по зарплате между джуном и мидлом тоже разница существенная.
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍4❤1
NixOS спустя год
➡️ В прошлом году я уже делал цикл постов про мой переход на NixOS в качестве домашней системы. Прошел почти год с момента перевода моих ноутов на эту замечательную ОС, хотел бы поделиться впечатлениями.
После debian based дистров, да, впрочем, и не только их, этот отвечает моим требованиям на 100%. Все настройки лежат у меня в git репе, для каждой из моих машин. Конфигурация несколько отличается, но не сильно, конфиг используется общий, но, например, photoprism на младшей машинке мне не нужен, поэтому там сделано исключение. Добавление пакетов - это новая строчка в конфиге и запуск одной команды, что создает новый снепшот всей системы и я могу, если что, откатиться. Но это ни разу не потребовалось.
🔖 К слову, пакетная база настолько большая, что 99,9% пакетов я нашел в ней. И, пожалуй, буквально несколько приложений пришлось скачивать отдельно. Кстати, из-за особенностей системы (там своя иерархия файлов), ты не можешь просто так взять и запустить тот же appimage. Но как обычно есть проблема - есть решение:
🔖 Причем, часть пакетов у меня висит на стабильной ветке, а часть в unstable, чтобы получать самый свежий софт, такой как k9s, terraform, kubectl, cursor, firefox, telegram и прочее.
Это очень удобно и работает пока стабильно. Также, в своих проектах я использую shell.nix файл с конфигурацией нужных для данного приложения зависимостей причем нужной версии.
Ближайший аналог в мире python - virtualenv, хоть и достаточно грубое сравнение.
Однозначно рекомендую!🙂
🙃 Devops Roadmap
✔️ Наставничество
✔️ Курсы
Сказать, что я доволен - ничего не сказать.
После debian based дистров, да, впрочем, и не только их, этот отвечает моим требованиям на 100%. Все настройки лежат у меня в git репе, для каждой из моих машин. Конфигурация несколько отличается, но не сильно, конфиг используется общий, но, например, photoprism на младшей машинке мне не нужен, поэтому там сделано исключение. Добавление пакетов - это новая строчка в конфиге и запуск одной команды, что создает новый снепшот всей системы и я могу, если что, откатиться. Но это ни разу не потребовалось.
appimage-runЭто очень удобно и работает пока стабильно. Также, в своих проектах я использую shell.nix файл с конфигурацией нужных для данного приложения зависимостей причем нужной версии.
Ближайший аналог в мире python - virtualenv, хоть и достаточно грубое сравнение.
В остальном это обычный Linux, но вот именно пакетный менеджер nix и конфигурация системы через код делает из него шедевр.
Однозначно рекомендую!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤2
Я уже давно не ищу работу, но каждую неделю стабильно получаю по 2-3 предложения с хорошими зарплатами.
Зачастую хожу на собеседования и получаю офферы для того, чтобы быть в курсе рынка труда и вопросов собесов. Когда работодатели пишут сами — это заведомо выгодная позиция с точки зрения трудоустройства.
HR пишут не только мне, как сеньору, но и моим ученикам, которые достигли уровня middle. Конечно, у них имеется определенный опыт, но немаловажно еще оформить правильно его и подать себя в резюме. А после также правильно общаться с будущими работодателями с учетом устоявшихся законов капиталистического рынка. С этим всем помогаю разобраться, потому не одними хард скилами сыт инженер devops =)
Как достичь уровня мидл или сеньор?
▶️ Постоянное обучение: Изучайте новые технологии, следите за трендами в индустрии.
▶️ Практика: Участвуйте в реальных проектах, работайте над своими навыками. В моем обучение есть отличный практический проект.
📌 Итог: Повышение своих скилов — это не только про деньги, но и про возможности, интересные задачи и постоянное развитие. Если вы хотите узнать больше о том, как достичь этого уровня или получить обучение в DevOps, пишите.
↗️ Наставничество
➡️ Курсы
➡️ Devops Roadmap
Зачастую хожу на собеседования и получаю офферы для того, чтобы быть в курсе рынка труда и вопросов собесов. Когда работодатели пишут сами — это заведомо выгодная позиция с точки зрения трудоустройства.
HR пишут не только мне, как сеньору, но и моим ученикам, которые достигли уровня middle. Конечно, у них имеется определенный опыт, но немаловажно еще оформить правильно его и подать себя в резюме. А после также правильно общаться с будущими работодателями с учетом устоявшихся законов капиталистического рынка. С этим всем помогаю разобраться, потому не одними хард скилами сыт инженер devops =)
Как достичь уровня мидл или сеньор?
Я его разрабатывал для получения реального опыта уже на этапе обучения, что невероятно ценно для чувства уверенности в своих силах.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥2💊1
Собрал для вас подборку самых популярных постов:
🔵 Почему стоит всерьез рассмотреть профессию devops-инженера?
🔵 С чего начать изучение DevOps?
🔵 Из каких профессий приходят в девопсы? 👻
🔵 Страхи тех, кто хочет, но почему-то еще не идет учиться DevOps
🔵 Почему Kubernetes (k8s) это "операционная система", в которой необходимо "шарить"
🔵 ИИ (AI), то есть про искусственный интеллект в DevOps
🔵 Поговорим про ближайшее будущее Devops
🔵 Про удаленку в devops
🔵 Middle или Junior?
🔵 Зарплата учеников + отзыв
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥2
В чем прикол моей платформы
Не все сразу понимают как формат курсов devopstrain продвигает вас в обучении. Позвольте рассказать немного истории...)
Давным давно у меня возникла идея создания универсальной платформы для IT курсов. Предполагалось, что там будут курсы по разным темам, в том числе и по разработке. Но надо было с чего то начинать. Первый релиз платформы случился еще в 2020 году с одним единственным курсом "Kubernetes на практике". Именно кубер на тот момент выглядел наиболее подходящим вариантом для такого формата. И это оказалось действительно так, кубер с тех пор остается бестселлером на моей платформе.
Если вы еще знакомы с моей платформой, сам формат в двух словах выглядит так: вы читаете небольшую теоретическую вводную➡️ затем следует практика (результат которой проверяется автоматически) ➡️ далее снова все повторяется. Каждый раздел связан с предыдущим, поэтому вы понимаете что откуда взялось.
❔ Почему такой формат работает?
Секрет в том, что курсы такого формата оптимально сбалансированы по следующим характеристикам:
💜 глубина подачи теоретического материала
тут можно уйти в дебри, где будет очень интересно, но ничего не понятно. А можно пробежаться по верхам, и этого будет недостаточно даже для тех. собеседования, не говоря уже о реальной работе. Истина где-то посередине.
💜 доступность практики
тут тоже можно в курсе написать, мол, запусти Linux, в нем подними minikube и у тебя готовый кубер для выполнения заданий курса. Это, в целом, хороший вариант, если у вас уже есть некий опыт, но если его недостаточно, то вместо фокуса на ресурсах кубера, вы будете долгое время настраивать просто окружение, а потом уже сил, времени может не хватить на тему, изучаемую в курсе.
💜 актуальность в ежедневном использовании
известно, что тема devops очень обширна, и без насмотренности трудно сказать, что важнее учить в первую очередь. Время - это наиболее ценный и ограниченный ресурс, поэтому его нужно использовать с максимальной эффективностью. Формируя план курса, я всегда исхожу из того, что требуется чаще всего в работе у меня и коллег.
Вы, наверняка, часто сталкивались с тем, что после просмотра видео, когда дело доходит до практики, то у вас как будто все выветрилось из головы.
Я уже более двух лет занимаюсь обучением, поэтому знаю о чем говорю.
Подытожу: платформа devopstrain - это не всеобъемлющий справочник, а скорее продуманный roadmap со встроенной практикой, который выведет вас куда надо😕
Не все сразу понимают как формат курсов devopstrain продвигает вас в обучении. Позвольте рассказать немного истории...)
Давным давно у меня возникла идея создания универсальной платформы для IT курсов. Предполагалось, что там будут курсы по разным темам, в том числе и по разработке. Но надо было с чего то начинать. Первый релиз платформы случился еще в 2020 году с одним единственным курсом "Kubernetes на практике". Именно кубер на тот момент выглядел наиболее подходящим вариантом для такого формата. И это оказалось действительно так, кубер с тех пор остается бестселлером на моей платформе.
Если вы еще знакомы с моей платформой, сам формат в двух словах выглядит так: вы читаете небольшую теоретическую вводную
Секрет в том, что курсы такого формата оптимально сбалансированы по следующим характеристикам:
тут можно уйти в дебри, где будет очень интересно, но ничего не понятно. А можно пробежаться по верхам, и этого будет недостаточно даже для тех. собеседования, не говоря уже о реальной работе. Истина где-то посередине.
тут тоже можно в курсе написать, мол, запусти Linux, в нем подними minikube и у тебя готовый кубер для выполнения заданий курса. Это, в целом, хороший вариант, если у вас уже есть некий опыт, но если его недостаточно, то вместо фокуса на ресурсах кубера, вы будете долгое время настраивать просто окружение, а потом уже сил, времени может не хватить на тему, изучаемую в курсе.
известно, что тема devops очень обширна, и без насмотренности трудно сказать, что важнее учить в первую очередь. Время - это наиболее ценный и ограниченный ресурс, поэтому его нужно использовать с максимальной эффективностью. Формируя план курса, я всегда исхожу из того, что требуется чаще всего в работе у меня и коллег.
Если баланс этих параметров нарушен, то результат обучения ухудшается, причем неподготовленный человек (а ученик, естественно, не имеет обычно большой насмотренности) сразу и не определит причину.
Вы, наверняка, часто сталкивались с тем, что после просмотра видео, когда дело доходит до практики, то у вас как будто все выветрилось из головы.
Я уже более двух лет занимаюсь обучением, поэтому знаю о чем говорю.
Подытожу: платформа devopstrain - это не всеобъемлющий справочник, а скорее продуманный roadmap со встроенной практикой, который выведет вас куда надо
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥1
Без плана никуда
В своей практике время от времени сталкиваюсь с необходимостью проведения ответственных мероприятий, затрагивающих прод. Это может быть перенос на другую платформу, сервер, кластер и т.д.
И не всегда есть возможность сделать плавное переключение на новую схему, что означает отсутствие права на ошибку, а время процедуры обычно очень лимитировано🤷♂️ 🤷♂️ 🤷♂️
➡️ В этом случае я поступаю следующим образом: на каком нибудь тестовом окружении провожу все шаги процедуры и записываю себе в виде плана с точностью до команды или четкой и короткой инструкции.
Т.к. сроки выполнения процедуры сжаты, то два тома инструкций расписывать не надо.
➡️ Далее, когда есть план, можно еще разок полностью по нему пройти, выполняя шаг за шагом, и измерить время, в которое можно уложиться. А дальше осталось запланировать мероприятие, уведомить нужных лиц и в назначенный момент сделать дело. Я обычно планирую такие вещи на раннее утро, чтобы пока все спят все завершить. Ну люблю я запах паленых серверов по утрам, что поделаешь)
поэтому в своей менторской программе мы начинаем обучение с проработки индивидуального плана, в котором также есть некоторые ориентиры по срокам, чтобы эффективнее прошло обучение✔️
▶️ Наставничество
▶️ Курсы
🔥 DevOps Roadmap
В своей практике время от времени сталкиваюсь с необходимостью проведения ответственных мероприятий, затрагивающих прод. Это может быть перенос на другую платформу, сервер, кластер и т.д.
И не всегда есть возможность сделать плавное переключение на новую схему, что означает отсутствие права на ошибку, а время процедуры обычно очень лимитировано
Сам план должен быть понятным даже спустя месяц, поэтому важно правильно его составить.
Т.к. сроки выполнения процедуры сжаты, то два тома инструкций расписывать не надо.
Иметь план всегда полезно,
поэтому в своей менторской программе мы начинаем обучение с проработки индивидуального плана, в котором также есть некоторые ориентиры по срокам, чтобы эффективнее прошло обучение
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍7🔥2
Рынок найма
Эта картинка как нельзя лучше описывает текущий рынок найма. Да, пока мы живем в фазе, когда это рынок принадлежит работодателю, и надеемся что тренд изменится и нам не придется как ужу выкручиваться, чтобы правильно ответить на вопросы HR скрининга.
😕 Дело в том, что на некоторые позиции поток соискателей настолько большой, что кадровики легко могут себе позволить отсеивать кандидатов за любой вопрос, ответ на который не отвечает текущим политикам компании. Раньше я не задумываясь отвечал на такие вопросы как: "А почему ищете работу?", "Как относитесь к переработкам?", "На какую зарплату рассчитываете?" и тд.
➡️ Сегодня я понимаю, что в текущих реалиях я бы даже не дошел до технического интервью, отвечай я также. Это полная дичь, и многие это понимают, но почему-то ничего не меняется.
Что уж говорить про технические интервью, которые тоже бывают весьма странными. Ну на сколько это возможно назвать странными матерых сеньоров, которым навесили сверху задачу прособеседовать N людей, хотя у них, вообще то, много и другой работы👻
Часто они задают вопросы определенным скриптом, причем даже не адаптируют беседу под человека, хотя вот видно, что некоторые вопросы ему задавать уже не надо. Стоит отметить, что бывают и вполне душевные технические беседы, но реже.
✅ На все эти детали мы обращаем пристальное внимание в моей программе менторства (🤫 мест на осень осталось мало):
🔥 даю рекомендации по общению на разных уровнях найма,
🔥 оформляем резюме,
🔥 проводим mock интервью,
🔥 формируем позиционирование и улучшаем самопрезентацию
Эта картинка как нельзя лучше описывает текущий рынок найма. Да, пока мы живем в фазе, когда это рынок принадлежит работодателю, и надеемся что тренд изменится и нам не придется как ужу выкручиваться, чтобы правильно ответить на вопросы HR скрининга.
Хочется быть честным и отвечать в стиле "speak from my heart", однако это пустая трата времени, если цель устроиться на работу.
Что уж говорить про технические интервью, которые тоже бывают весьма странными. Ну на сколько это возможно назвать странными матерых сеньоров, которым навесили сверху задачу прособеседовать N людей, хотя у них, вообще то, много и другой работы
Часто они задают вопросы определенным скриптом, причем даже не адаптируют беседу под человека, хотя вот видно, что некоторые вопросы ему задавать уже не надо. Стоит отметить, что бывают и вполне душевные технические беседы, но реже.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍5🔥1
Devops как прогрессивная и консервативная тема
С одной стороны девопс, как термин, еще достаточно молод по меркам многих других вещей в IT, а с другой стороны в его основе применяются технологии, которым уже много лет. И это делает его вдвойне интересным направлением для персонального развития.
*️⃣ Возьмем для сравнения разработку, а точнее ее довольно популярную часть — фронтенд. Выглядит так, что туда вкатиться не так уж сложно и долго, но тут кроется подвох. Да, для работы в конкретный момент времени и на определенном проекте тебе надо знать основы языка, и особенности фреймворка.
Это намного проще, чем тот же devops, где нужно разбираться во многих вещах.
Однако, потом выясняется, что написанный тобой код на некоторых устройствах, браузерах, юзерах (подставить свое) работает не так как планировалось. А позже на соседнем проекте ты узнаешь, что там иной фреймворк и тебе надо его изучать. А через год-два выходит очередной модный фреймворк и тебя жизнь заставляет его учить. В прочем мобильная разработка не далеко ушла в этом отношении.
В devops все иначе:
К тому же всегда в цене фундаментальные знания: Linux, сети, контейнеры, IaC, CI/CD.
Мне регулярно поступают вопросы вида:
❔ "А точно, что те вещи, которые я изучу будут актуальны через год или два".
У меня ответ простой и четкий: совершенно точно.
В моих курсах нет мимолетных и на днях появившихся технологий, только проверенные временем вещи, которые с нами уже от 10 лет и больше. И конечно, именно они и мелькают в требованиях к вакансиям чаще всего.
🙂 Впрочем, это не значит, что все стоит на месте и не меняется годами, изменения происходят, это неизбежно и прекрасно.
Исходя из этих соображений и сделаны мои курсы и программа менторства. Приятно получать обратную связь в виде отзывов, один из таких прикреплен к посту💙
С одной стороны девопс, как термин, еще достаточно молод по меркам многих других вещей в IT, а с другой стороны в его основе применяются технологии, которым уже много лет. И это делает его вдвойне интересным направлением для персонального развития.
Это намного проще, чем тот же devops, где нужно разбираться во многих вещах.
Однако, потом выясняется, что написанный тобой код на некоторых устройствах, браузерах, юзерах (подставить свое) работает не так как планировалось. А позже на соседнем проекте ты узнаешь, что там иной фреймворк и тебе надо его изучать. А через год-два выходит очередной модный фреймворк и тебя жизнь заставляет его учить. В прочем мобильная разработка не далеко ушла в этом отношении.
В devops все иначе:
количество инструментов, которые необходимо знать не такое маленькое, но вполне конечное, а наиболее популярных можно посчитать по пальцам рук.
К тому же всегда в цене фундаментальные знания: Linux, сети, контейнеры, IaC, CI/CD.
Мне регулярно поступают вопросы вида:
У меня ответ простой и четкий: совершенно точно.
В моих курсах нет мимолетных и на днях появившихся технологий, только проверенные временем вещи, которые с нами уже от 10 лет и больше. И конечно, именно они и мелькают в требованиях к вакансиям чаще всего.
Мы просто наблюдаем за ними и применяем лучшие подходы в нашей работе.
Исходя из этих соображений и сделаны мои курсы и программа менторства. Приятно получать обратную связь в виде отзывов, один из таких прикреплен к посту
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥1
Тесты глазами DevOps-инженера
Вчера настраивал пайплайн и подумал:
Да, мы не пишем код, но пайплайны с тестами — наша зона ответственности. И чтобы правильно настроить CI/CD, нужно понимать суть процесса.
❔ Как мы смотрим на тесты
Представьте, что тестирование — это как проверка автомобиля. Unit-тесты — это когда механик проверяет каждую деталь отдельно: работает ли двигатель, тормоза, фары. Интеграционные тесты — когда мы заводим машину и смотрим, как все системы работают вместе. А E2E тесты — это когда мы садимся за руль и едем по городу, проверяя весь путь от дома до работы.
❔ Что мы проверяем
Есть два больших вопроса: "Работает ли система?" и "А как хорошо она работает?". Первый вопрос решают функциональные тесты — они проверяют, что кнопка "Купить" действительно покупает товар. Второй вопрос решают нефункциональные тесты — они смотрят на безопасность, производительность, удобство использования.
🪲 Уровень "прозрачности"
Интересно, что тестирование бывает разным по уровню доступа к коду. Черный ящик — тестируем как обычный пользователь, не зная, что происходит внутри. Белый ящик — видим весь код и тестируем с пониманием архитектуры. Серый ящик — золотая середина, когда знаем общую структуру, но не вдаемся в детали.
🤖 Ручное vs автоматическое
Ручное тестирование — это когда человек садится за компьютер и проверяет все вручную. Классика, но медленно. Автоматизированное — это наша стихия: скрипты, CI/CD, автоматизация. Быстро, надежно, масштабируемо.
❔ Почему это важно для нас
Понимание типов тестов помогает нам правильно настроить пайплайны. Мы знаем, что unit-тесты должны быть быстрыми и запускаться при каждом коммите. Интеграционные тесты — при мерже в основную ветку. E2E тесты — перед релизом. А нагрузочные тесты — по расписанию или при изменениях инфраструктуры.
✔️ Это помогает нам оптимизировать время сборки, правильно распараллеливать задачи и говорить с разработчиками на одном языке.
На все эти детали мы обращаем пристальное внимание в моей программе менторства (🤫 мест на осеньне осталось мало):
Вчера настраивал пайплайн и подумал:
а знаем ли мы, что именно тестируем?
Да, мы не пишем код, но пайплайны с тестами — наша зона ответственности. И чтобы правильно настроить CI/CD, нужно понимать суть процесса.
Представьте, что тестирование — это как проверка автомобиля. Unit-тесты — это когда механик проверяет каждую деталь отдельно: работает ли двигатель, тормоза, фары. Интеграционные тесты — когда мы заводим машину и смотрим, как все системы работают вместе. А E2E тесты — это когда мы садимся за руль и едем по городу, проверяя весь путь от дома до работы.
Есть два больших вопроса: "Работает ли система?" и "А как хорошо она работает?". Первый вопрос решают функциональные тесты — они проверяют, что кнопка "Купить" действительно покупает товар. Второй вопрос решают нефункциональные тесты — они смотрят на безопасность, производительность, удобство использования.
Интересно, что тестирование бывает разным по уровню доступа к коду. Черный ящик — тестируем как обычный пользователь, не зная, что происходит внутри. Белый ящик — видим весь код и тестируем с пониманием архитектуры. Серый ящик — золотая середина, когда знаем общую структуру, но не вдаемся в детали.
🤖 Ручное vs автоматическое
Ручное тестирование — это когда человек садится за компьютер и проверяет все вручную. Классика, но медленно. Автоматизированное — это наша стихия: скрипты, CI/CD, автоматизация. Быстро, надежно, масштабируемо.
Понимание типов тестов помогает нам правильно настроить пайплайны. Мы знаем, что unit-тесты должны быть быстрыми и запускаться при каждом коммите. Интеграционные тесты — при мерже в основную ветку. E2E тесты — перед релизом. А нагрузочные тесты — по расписанию или при изменениях инфраструктуры.
На все эти детали мы обращаем пристальное внимание в моей программе менторства (🤫 мест на осень
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1🔥1
Новый курс! — Devops Troubleshooting 😱
Рад поделиться новостью — новый курс по траблшутингу devops кейсов готов! В настоящий момент курс поделен на две большие части:
▶️ Kubernetes
▶️ Linux / Networks
Каждый из них, в свою очередь, поделен на 3 части: Beginner, Intermediate и Advanced,
для того чтобы по нарастающей сложности вы могли выбрать подходящий набор кейсов
✔️ Уже сейчас там 28 кейсов, но их число будет расти. Каждый кейс запускается в специализированном окружении, то есть либо в выделенном кластере Kubernetes, либо в виртуальной машине.
Данный курс доступен только в рамках программы наставничества (для студентов с уже завершенными сроками обучения — на индивидуальных условиях), отдельно он доступен только для корпоративных клиентов (компаний).
Приходите учиться!
Рад поделиться новостью — новый курс по траблшутингу devops кейсов готов! В настоящий момент курс поделен на две большие части:
Каждый из них, в свою очередь, поделен на 3 части: Beginner, Intermediate и Advanced,
для того чтобы по нарастающей сложности вы могли выбрать подходящий набор кейсов
Навыки траблшутинга не только полезны в ежедневной практике девопса, но и на технических собеседованиях, там тоже часто есть отдельная часть посвященная этому. Набор заданий подобран исходя из наиболее частых кейсов, которые могут возникнуть, либо вас могут спросить на собесах.
Данный курс доступен только в рамках программы наставничества (для студентов с уже завершенными сроками обучения — на индивидуальных условиях), отдельно он доступен только для корпоративных клиентов (компаний).
Приходите учиться!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
Measure once, cut twice
❔ Случалось ли с вами перепутать терминалы и запустить команду не там, где надо?
Например, на проде вместо dev-окружения. Полбеды, когда это не деструктивная операция, а что если вы удалили базу или директорию с уверенностью, что делаете это на стейджинге?
В этом случае из хороших новостей только то, что узнаете вы об этом очень скоро🙂 . Ребята из соседнего отдела техподдержки реагируют быстрее этих ваших модных мониторингов. В этот момент в голове проносятся разные мысли, и ты уже мысленно строишь планы на внеочередной отпуск, бессрочный. Как назло никакого плана быстрого восстановления под рукой нет (кто же думает о disaster recovery plan пока петух не клюнет?). Далее ты немного отходишь от шока и начинаешь исправлять свой косяк. Смотришь состояние бекапов в надежде, что они свежие и рабочие. Если нет, что ж, ты попал.
Как вам такой сценарий?
Когда-то давно со мной случались факапы, хотя и не сказать что много. Теперь я десять раз проверю перед выполнением деструктивной операции, более того, я даже бывает сначала просто выключу виртуальную машину или базу, перед удалением, подожду денек-другой и если никто не придет — можно удалять. Потому что, даже если ты делаешь то в чем уверен, другие могут сообщить тебе неверные данные о том на сколько критична та или иная ВМ или БД.
А мы любим подстелить соломку, где только это возможно.
▶️ Впрочем, подстелить не всегда получается, из-за того что удаление или изменение какого-то компонента неявным образом может повлиять на работу других, о чем ты либо не знал, либо ход твоих мыслей так далеко не зашел.
Поэтому главное правило: перед удалением все проверь, и по возможности оставь себе шанс откатиться если что-то пойдет не по плану, как это бывает в больших и сложных системах.
И еще совет: используй понятный нейминг объектов, чтобы они не вводили в заблуждение о том, к какой подсистеме они относятся. Более детально я рассказываю в рамках своей программы обучения.
Например, на проде вместо dev-окружения. Полбеды, когда это не деструктивная операция, а что если вы удалили базу или директорию с уверенностью, что делаете это на стейджинге?
В этом случае из хороших новостей только то, что узнаете вы об этом очень скоро
Как вам такой сценарий?
Когда-то давно со мной случались факапы, хотя и не сказать что много. Теперь я десять раз проверю перед выполнением деструктивной операции, более того, я даже бывает сначала просто выключу виртуальную машину или базу, перед удалением, подожду денек-другой и если никто не придет — можно удалять. Потому что, даже если ты делаешь то в чем уверен, другие могут сообщить тебе неверные данные о том на сколько критична та или иная ВМ или БД.
Виноват будешь не ты, но именно тебе потом восстанавливать.
А мы любим подстелить соломку, где только это возможно.
Поэтому главное правило: перед удалением все проверь, и по возможности оставь себе шанс откатиться если что-то пойдет не по плану, как это бывает в больших и сложных системах.
И еще совет: используй понятный нейминг объектов, чтобы они не вводили в заблуждение о том, к какой подсистеме они относятся. Более детально я рассказываю в рамках своей программы обучения.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9🤯1
🎉 YouTube-канал Devopstrain 🎉
Я все таки дошел уже даже до ютуба. Если еще года 3-4 назад я представить себе не мог такое в страшном сне, то сейчас это уже реальность. 🤯
➡️ Встречайте первое видео, в котором мы прямо в режиме онлайн решаем различные продовые инциденты с одним из моих учеников.
Ссылка на видео:
https://www.youtube.com/watch?v=yqBWH08cBDk
---
⚖️ Строго не судите, это всего лишь начало! Постараюсь регулярно выпускать различные видео про девопс и жизнь девопс инженера. 📹✨
А сейчас прошу подписаться и поставить лайк этому видео, это очень важно для нового канала, и поможет в его продвижении. 📈
Комментарий к видео также будет очень кстати =) 💬
Спасибо за внимание! 🙏
Я все таки дошел уже даже до ютуба. Если еще года 3-4 назад я представить себе не мог такое в страшном сне, то сейчас это уже реальность. 🤯
➡️ Встречайте первое видео, в котором мы прямо в режиме онлайн решаем различные продовые инциденты с одним из моих учеников.
Ссылка на видео:
https://www.youtube.com/watch?v=yqBWH08cBDk
---
⚖️ Строго не судите, это всего лишь начало! Постараюсь регулярно выпускать различные видео про девопс и жизнь девопс инженера. 📹✨
А сейчас прошу подписаться и поставить лайк этому видео, это очень важно для нового канала, и поможет в его продвижении. 📈
Комментарий к видео также будет очень кстати =) 💬
Спасибо за внимание! 🙏
YouTube
Учим Devops на инцидентах в продакшене!
#devops #troubleshooting #kubernetes #linux #devopstrain
В этом видео мы вместе с моим учеником Владиславом будем заниматься траблшутингом кластера Kubernetes и Linux сервера, исправлять инциденты, которые могут возникнут в проде или любом другом окружении…
В этом видео мы вместе с моим учеником Владиславом будем заниматься траблшутингом кластера Kubernetes и Linux сервера, исправлять инциденты, которые могут возникнут в проде или любом другом окружении…
🔥17❤8❤🔥1
Взял менторство у Александра и устроился в финтех с зарплатой 350К
У Александра своя платформа с заданиями, буквально с первого задания погружаешься в практику и это очень интересно. Серьезный подход к делу помогает получить хорошую базу и уверенно чувствовать себя на работе потом.
Александр всегда на связи по всем вопросам, также есть удобный ИИ бот, обученный под программу. Под руководством Александра, выполнил проектную работу, в которой отработал навыки выстраивания облачной инфраструктуры IaC с помощью Terraform.
Проходя курсы и переодически созваниваясь, разбирая вопросы как с курсов, так и с прошедших собесов, по итогу смог почувствовать себя более уверенно, пройти пару непростых технических созвонов и получить оффер.
Здорово, что курсы остаются в доступе, сейчас использую их как базу знаний, очень помогает на текущей работе
Часто получаю хорошие отзывы на свою программу, радует что даже на вялом рынке ребята находят работу, а порой и совмещают две
Также до 1 декабря действуют акции:
Выбирайте 2 курса на платформе и забирайте третий в подарок (самый низкий по стоимости).
Обращайтесь!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6😁2❤1
Решил не тянуть с подарками, и зарелизить то, о чем многие давно спрашивали: «Сообщество Devopstrain».
Это ламповое и уютное место, где вы можете поговорить, задать вопрос или помочь кому-то еще советом. Обсуждаем все на свете, от куба до трудоустройства и вопросов по работе, а также нетехнические темы. Я там, пишу о том, о чем не могу говорить публично.
Сообщество доступно всем участникам менторской программы, даже если срок обучения у вас уже прошел.
В ближайшие дни вам на почту придет приглашение, так что проверяйте время от времени.
Если не пришло — напишите мне, решим вопрос.
🤔 Почему только сейчас?
Мысль такая была и раньше, и даже была попытка запустить сообщество, но в другой концепции, которая, признаю, была не самая удачная. И тогда нас было сильно меньше. А сейчас нас много, поэтому, я верю что все получится!
Пишите, спрашивайте, отвечайте, будьте как дома!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7
Forwarded from Капитан
Привет!
Фидбек по обучению и менторству:
Я пришёл к тебе в августе этого года с целью прокачаться как в уже знакомых технологиях, так и освоить новые (будем считать кубер новым, поскольку на работе я его щупал раз в 2-3 месяца), познакомиться с новыми workflow, научиться проходить собесы и выбирать тактику поведения в зависимости от ситуации
По зарплате надеялся вырасти до 250-270к, не завалить хоть какое-нибудь ТИ, получить оценку со стороны
На поиск работы ушёл ~1 месяц, обучение заняло 3 месяца ежедневной и довольно плотной работы
Как итог:
- Оффер на 400к, позиция миддла (очевидно, что требования там, как к Синьору Помидору, но и зарплата соответствующая =))
- Наконец-то научился внятно объяснять теорию и перестал попадать в ситуации "я знаю, как это работает, но не могу объяснить"
- Занимаясь кубером ~1.5 месяца в процессе обучения, по итогам собеса я получил оценку в этой секции "сеньор+". Сюда же добавлю, что были и другие успешные ТИ на позиции с упором в куб
- Получил шпаргалку для работы в виде твоих статей и всех манифестов, которые я разработал в результате прохождения (даже на текущей работе мне проще было подглядеть, что я придумал, проходя обучение, чем заново изобретать велосипед. Уверен, что и впредь мне всё это пригодится)
Что хотелось бы отметить и за что сказать отдельное спасибо:
- Ты вдохнул в меня уверенность в себе, помог преодолеть "синдром самозванца".
"Ты явно сможешь найти варианты получше", "проси 300-350к" - те вещи, которых я не ожидал услышать, но услышал и они возымели решающее влияние на видение себя в своей профессии. Уже думал уходить в таксисты или на завод)
- Содержательные ответы на все, даже самые глупые вопросы, иногда не сильно связанные с обучением
- Курсы построены таким образом, что приходится много раз возвращаться к уже пройденным темам, что дополнительно закрепляет пройденный материал и инструменты. Таким образом набивается рука, запоминается синтаксис и особенности работы с инструментами
- Предоставление инфраструктуры и домена сильно облегчает жизнь
- Getting started по многим инструментам лучше, чем в доках от разработчиков, что даёт возможность пощупать новые инструменты и получить базовое понимание их работы
- Создание коммьюнити и поддержание связи дополнительно подкупают. Видно, что тебе не всё равно на своих учеников)
- Курс по траблшутингу (отличный экзамен/игра/шпаргалка, славно помогает набить руку)
- Курс и блог читаются не душно от слова совсем)
Итог превзошёл ожидания. Это был непростой путь (очевидно, что чтобы зарабатывать деньги - нужно что-то уметь =)) и я сильно благодарен за всю ту помощь, которую ты оказал.
Я думаю, что я ещё не раз и не 2 почувствую необходимость в твоих советах (как говорится в спорте, каждому тренеру нужен тренер - со стороны всегда виднее, да и официально Синьором Помидором я ещё не стал =))
Фидбек по обучению и менторству:
Я пришёл к тебе в августе этого года с целью прокачаться как в уже знакомых технологиях, так и освоить новые (будем считать кубер новым, поскольку на работе я его щупал раз в 2-3 месяца), познакомиться с новыми workflow, научиться проходить собесы и выбирать тактику поведения в зависимости от ситуации
По зарплате надеялся вырасти до 250-270к, не завалить хоть какое-нибудь ТИ, получить оценку со стороны
На поиск работы ушёл ~1 месяц, обучение заняло 3 месяца ежедневной и довольно плотной работы
Как итог:
- Оффер на 400к, позиция миддла (очевидно, что требования там, как к Синьору Помидору, но и зарплата соответствующая =))
- Наконец-то научился внятно объяснять теорию и перестал попадать в ситуации "я знаю, как это работает, но не могу объяснить"
- Занимаясь кубером ~1.5 месяца в процессе обучения, по итогам собеса я получил оценку в этой секции "сеньор+". Сюда же добавлю, что были и другие успешные ТИ на позиции с упором в куб
- Получил шпаргалку для работы в виде твоих статей и всех манифестов, которые я разработал в результате прохождения (даже на текущей работе мне проще было подглядеть, что я придумал, проходя обучение, чем заново изобретать велосипед. Уверен, что и впредь мне всё это пригодится)
Что хотелось бы отметить и за что сказать отдельное спасибо:
- Ты вдохнул в меня уверенность в себе, помог преодолеть "синдром самозванца".
"Ты явно сможешь найти варианты получше", "проси 300-350к" - те вещи, которых я не ожидал услышать, но услышал и они возымели решающее влияние на видение себя в своей профессии. Уже думал уходить в таксисты или на завод)
- Содержательные ответы на все, даже самые глупые вопросы, иногда не сильно связанные с обучением
- Курсы построены таким образом, что приходится много раз возвращаться к уже пройденным темам, что дополнительно закрепляет пройденный материал и инструменты. Таким образом набивается рука, запоминается синтаксис и особенности работы с инструментами
- Предоставление инфраструктуры и домена сильно облегчает жизнь
- Getting started по многим инструментам лучше, чем в доках от разработчиков, что даёт возможность пощупать новые инструменты и получить базовое понимание их работы
- Создание коммьюнити и поддержание связи дополнительно подкупают. Видно, что тебе не всё равно на своих учеников)
- Курс по траблшутингу (отличный экзамен/игра/шпаргалка, славно помогает набить руку)
- Курс и блог читаются не душно от слова совсем)
Итог превзошёл ожидания. Это был непростой путь (очевидно, что чтобы зарабатывать деньги - нужно что-то уметь =)) и я сильно благодарен за всю ту помощь, которую ты оказал.
Я думаю, что я ещё не раз и не 2 почувствую необходимость в твоих советах (как говорится в спорте, каждому тренеру нужен тренер - со стороны всегда виднее, да и официально Синьором Помидором я ещё не стал =))
🔥4❤1