Привет!
Вот ты и добрался до канала, который посвящён обучению, развитию и аналитике DevOps и TeamLead в IT. Здесь не будет материалов по мемам, здесь не будет смешного контента. Что же здесь будет?
📌 Авторский материал с обучающими роликами и текстами
📌 Сообщество людей, которые хотят получить консультацию или поделиться своим опытом
📌 Небольшие статьи с размышлениями на тему новостей внутри IT
📌 Внутренние новости NotCourse
Да, контент не будет выкладываться часто, а самые его большие куски, как лекции, будут выкладываться только на платной основе. Но и мы с вами не спешим, мы стремимся к качеству, а не к количеству.
Поэтому, если тебе хочется моего гранулированного мнения только про IT, если тебе хочется избавиться от остального инфошума, в общем, если ты хочешь оставаться на связи, но не хочешь участвовать в более развлекательном NotOps - этот канал именно для тебя!
Вот ты и добрался до канала, который посвящён обучению, развитию и аналитике DevOps и TeamLead в IT. Здесь не будет материалов по мемам, здесь не будет смешного контента. Что же здесь будет?
Да, контент не будет выкладываться часто, а самые его большие куски, как лекции, будут выкладываться только на платной основе. Но и мы с вами не спешим, мы стремимся к качеству, а не к количеству.
Поэтому, если тебе хочется моего гранулированного мнения только про IT, если тебе хочется избавиться от остального инфошума, в общем, если ты хочешь оставаться на связи, но не хочешь участвовать в более развлекательном NotOps - этот канал именно для тебя!
Please open Telegram to view this post
VIEW IN TELEGRAM
DevOps-трансформации или кто мы теперь?
С момента, как DevOps появился, он постоянно воспринимался всеми по-разному. Кто-то считал, что это помощь разрабам, кто-то, что это автоматизаторы сопровождения, большие компании из FAANG предлагали свои концепции, которые тоже переживали постоянные трансформации.
И вот ты, DevOps инженер, по крайней мере, так тебя называют в компании, но что ты делаешь?
До сих пор многие люди не понимают чем мы занимаемся, как глобально, на уровне рынка труда, так и локально, внутри моей компании. Каждый раз, когда я говорю, что мы DevOps, на меня смотрят как на новые ворота. И ты снова рассказываешь про пайплайны, про деплой, про всё, чему я сам всегда вас учил и буду учить.
И вот, благодаря этой дроби у нас теперь и Platform Engineer для создания набора интеграционных сервисов для разработчиков и SRE (к которым некоторые совсем глупенькие приписывают engineer ещё раз), которых используют в автоматизации сопровождения, но для ребят попроще есть Infrastructure Engineer. Для облаков у нас Cloud Engineer, для сборок у нас Build Engineer.
А я-то тогда кто?
Мы вот и сборки огранизуем и сервисы поднимаем и в облаках инфраструктуру поддерживаем, и виртуалки присутствуют. Роли энсибл - пожалуйста, плейбуки поддержать? Конечно. В кубы придумать как расскатывать все наши продукты клиентам - сейчас сделаем. И я понимаю, что разделение неизбежно, но у вас нет ощущения, что мы всё дальше от изначальной цели? Я напомню, идеологически DevOps должен был объединить, пардоньте, mindset разработчиков и сопровождения, чтобы все начали думать о том, как лучше сделать продукт, а не как перекинуть быстрее баг через забор.
Видимо, концепция не выдержала проверки временем, закидывание говном в энтерпрайзах продолжится, а нам лишь остаётся автоматизировать то, что нам заказывают. Или нет? Что вы думаете по этому поводу? Ощутили ли вы за эти годы, что DevOps воплотил в вашей компании свою изначальную идею?
С момента, как DevOps появился, он постоянно воспринимался всеми по-разному. Кто-то считал, что это помощь разрабам, кто-то, что это автоматизаторы сопровождения, большие компании из FAANG предлагали свои концепции, которые тоже переживали постоянные трансформации.
И вот ты, DevOps инженер, по крайней мере, так тебя называют в компании, но что ты делаешь?
До сих пор многие люди не понимают чем мы занимаемся, как глобально, на уровне рынка труда, так и локально, внутри моей компании. Каждый раз, когда я говорю, что мы DevOps, на меня смотрят как на новые ворота. И ты снова рассказываешь про пайплайны, про деплой, про всё, чему я сам всегда вас учил и буду учить.
И вот, благодаря этой дроби у нас теперь и Platform Engineer для создания набора интеграционных сервисов для разработчиков и SRE (к которым некоторые совсем глупенькие приписывают engineer ещё раз), которых используют в автоматизации сопровождения, но для ребят попроще есть Infrastructure Engineer. Для облаков у нас Cloud Engineer, для сборок у нас Build Engineer.
А я-то тогда кто?
Мы вот и сборки огранизуем и сервисы поднимаем и в облаках инфраструктуру поддерживаем, и виртуалки присутствуют. Роли энсибл - пожалуйста, плейбуки поддержать? Конечно. В кубы придумать как расскатывать все наши продукты клиентам - сейчас сделаем. И я понимаю, что разделение неизбежно, но у вас нет ощущения, что мы всё дальше от изначальной цели? Я напомню, идеологически DevOps должен был объединить, пардоньте, mindset разработчиков и сопровождения, чтобы все начали думать о том, как лучше сделать продукт, а не как перекинуть быстрее баг через забор.
Видимо, концепция не выдержала проверки временем, закидывание говном в энтерпрайзах продолжится, а нам лишь остаётся автоматизировать то, что нам заказывают. Или нет? Что вы думаете по этому поводу? Ощутили ли вы за эти годы, что DevOps воплотил в вашей компании свою изначальную идею?
Менеджерские книги практически бесполезны
На сегодня я прочитал/прослушал четыре книги и не могу сказать, что нашёл хоть какую-то практически полезную информацию. Да, есть несколько способов сгруппировать управленцев по стилю, есть книжки с советами, мол, не поддавайся на провокации и не продавливайся, если продавливают, есть и совсем труха из разряда "делай хорошо, плохо не делай, особенно, если если команде плохо, то сделай чтобы им стало хорошо". Но кажется, будто вся эта информация находится на поверхности. Серьёзно, самое полезное это только классификации типов команд и типов управления, причём, выбрать можете абсолютно любую из них, которые нравятся лично вам и вполне себе спокойно жить, управлять и не переживать по поводу.
Я в своё время думал, что в методологиях управления проектами много воды, как же я ошибался. С другой стороны, я себе очень слабо представляю как тебе вообще книжка может помочь решить конкретную проблему в конкретной команде. Тем страшнее, конечно же, понимать, что есть менеджеры, которые читают эти книги, как инструкции к применению и пихают все методики в свою работу, лишь бы сделать всё эффективно и позитивно. И абсолютно наплевать что там думает сама команда по этому поводу.
Самое интересное, что я не вижу чтобы кто-то особо делился негативным опытом, своими факапами, а ведь по ним проще всего понять, как делать точно не надо. И вот я думаю, не запустить ли мне небольшой цикл записок о том, с чем таким сталкивался я за свой опыт? И как "менеджер" и как рядовой исполнитель? Есть потребность такого контента?
Этот контент не будет попадать в NotOps, так что если хотите его прочитать - подписывайтесь на канал
На сегодня я прочитал/прослушал четыре книги и не могу сказать, что нашёл хоть какую-то практически полезную информацию. Да, есть несколько способов сгруппировать управленцев по стилю, есть книжки с советами, мол, не поддавайся на провокации и не продавливайся, если продавливают, есть и совсем труха из разряда "делай хорошо, плохо не делай, особенно, если если команде плохо, то сделай чтобы им стало хорошо". Но кажется, будто вся эта информация находится на поверхности. Серьёзно, самое полезное это только классификации типов команд и типов управления, причём, выбрать можете абсолютно любую из них, которые нравятся лично вам и вполне себе спокойно жить, управлять и не переживать по поводу.
Я в своё время думал, что в методологиях управления проектами много воды, как же я ошибался. С другой стороны, я себе очень слабо представляю как тебе вообще книжка может помочь решить конкретную проблему в конкретной команде. Тем страшнее, конечно же, понимать, что есть менеджеры, которые читают эти книги, как инструкции к применению и пихают все методики в свою работу, лишь бы сделать всё эффективно и позитивно. И абсолютно наплевать что там думает сама команда по этому поводу.
Самое интересное, что я не вижу чтобы кто-то особо делился негативным опытом, своими факапами, а ведь по ним проще всего понять, как делать точно не надо. И вот я думаю, не запустить ли мне небольшой цикл записок о том, с чем таким сталкивался я за свой опыт? И как "менеджер" и как рядовой исполнитель? Есть потребность такого контента?
Этот контент не будет попадать в NotOps, так что если хотите его прочитать - подписывайтесь на канал
Буря в стакане
Вообрази, сидишь ты такой, никого не трогаешь, работу свою работаешь. Стабильно так, работа команды продвигается, результаты достигаются. И тут, откуда ни возьмись, менеджер вдруг появись. Ошарашенный, глаза горят, руки летают, срочное собрание. Сидите, на нём вам рассказывают новую идею, которую срочно, желательно уже вчера, нужно внедрить в работу для всех. Комментарии осуждаются, предложения не рассматриваются. Менеджер улетает на своём локомотиве куда-то вдаль, а вы всей командой остаётесь наедине с его мыслями.
Вот и у меня однажды был такой персонаж в жизни, но самое страшное было даже не это. Было время, когда я чуть ли не жил на работе, а он прибежал к вечеру, позвал меня на разговор и сказал, что он стал слишком редко меня видеть на рабочем месте. Он. Тот человек, который был на работе раз в неделю часа на три в лучшем случае. Но у него всегда были идеи, он всегда находил новые методики в новых книжках, которые ему советовал один из моих коллег. Коллега тот, кстати, был из моих любимых, позитивно-токсичных. Но сейчас не о нём.
С тем менеджером всё скатилось к тому, что нам перевели ещё одного менеджера, с абсолютно другим стилем и другим поведением, там был самый настоящий лидер, про которого я вам тоже однажды расскажу. А старый менеджер стал просто где-то быть и коммуницировал с нами только в крайних случаях.
Это я всё к чему. Всегда слушайте свою команду, даже если они говорят глупости, на ваш взгляд. Не обязательно незамедлительно применять их решение, но позволить им быть услышанными - безумно важно, а ещё лучше, если позволят вступить в диалог и из этого получить какое-то общее решение, которое понравится всем. Ну и не надо требовать от сотрудников того, что вы не делаете сами.
Вообрази, сидишь ты такой, никого не трогаешь, работу свою работаешь. Стабильно так, работа команды продвигается, результаты достигаются. И тут, откуда ни возьмись, менеджер вдруг появись. Ошарашенный, глаза горят, руки летают, срочное собрание. Сидите, на нём вам рассказывают новую идею, которую срочно, желательно уже вчера, нужно внедрить в работу для всех. Комментарии осуждаются, предложения не рассматриваются. Менеджер улетает на своём локомотиве куда-то вдаль, а вы всей командой остаётесь наедине с его мыслями.
Вот и у меня однажды был такой персонаж в жизни, но самое страшное было даже не это. Было время, когда я чуть ли не жил на работе, а он прибежал к вечеру, позвал меня на разговор и сказал, что он стал слишком редко меня видеть на рабочем месте. Он. Тот человек, который был на работе раз в неделю часа на три в лучшем случае. Но у него всегда были идеи, он всегда находил новые методики в новых книжках, которые ему советовал один из моих коллег. Коллега тот, кстати, был из моих любимых, позитивно-токсичных. Но сейчас не о нём.
С тем менеджером всё скатилось к тому, что нам перевели ещё одного менеджера, с абсолютно другим стилем и другим поведением, там был самый настоящий лидер, про которого я вам тоже однажды расскажу. А старый менеджер стал просто где-то быть и коммуницировал с нами только в крайних случаях.
Это я всё к чему. Всегда слушайте свою команду, даже если они говорят глупости, на ваш взгляд. Не обязательно незамедлительно применять их решение, но позволить им быть услышанными - безумно важно, а ещё лучше, если позволят вступить в диалог и из этого получить какое-то общее решение, которое понравится всем. Ну и не надо требовать от сотрудников того, что вы не делаете сами.
❤1
С 18 октября 2025 года пользователи в России столкнулись с проблемами голосовых звонков через FaceTime, что стало неожиданным «отпуском» для технологий Apple[1]. В то же время Amazon решил подкормить свои дата-центры атомной энергией, приобретя АЭС с 12 маломодульными реакторами Xe-100 мощностью 960 МВт — теперь ИИ питается не только электричеством, но и ядерной мощью[2]. Между тем, сотрудник OpenAI извинился за ошибочное приписывание GPT-5 решения нерешённых задач Эрдёша, уточнив, что модель лишь сопоставила старые публикации, а не сделала новые открытия[3]. В мире технологий даже ошибки и сбои порой выглядят как маленькие приключения.
#AIHabrDigest
#AIHabrDigest
👍1
Осенний митап в офисе HFLabs обещает разобраться, почему больше данных не всегда значит лучше для бизнеса — полезно для тех, кто устал от бесконечных таблиц и графиков[1]. Тем временем ГК «Солар» выходит на рынок SIEM с продуктом, объединяющим SIEM и SOAR, и обещает до 40% экономии на внедрении, что особенно порадует банки, ритейл и металлургию на фоне растущего рынка в России[2]. А «Яндекс» задумался о выпуске умного кольца — видимо, чтобы доказать, что гаджеты могут быть ещё компактнее, хотя сделать это будет не так просто[3]. В общем, технологии не стоят на месте, а мы продолжаем наблюдать с лёгкой иронией.
#AIHabrDigest
#AIHabrDigest
👨💻1
Мёртвый пень
Их можно найти и в топ-менеджменте и в среднем и даже на уровне простых исполнителей, но ты легко сможешь безошибочно опознать пень.
Приглядись, сидит такой, невзрачный, прикидывается ветошью и внимательно слушает остальных. Это пень, да. Такие стараются не спорить, готовы пообещать выполнить что-угодно, но делать это не будут. Ну или будут до последнего тянуть с решением.
Стать мёртвым пнём это постепенный процесс, по наблюдениям это связано с отсутствием желания меняться, изучать новое, когда человек уже измотал сам себя и ему хочется “доработать до пенсии”. Никто из нас не застрахован от такого и пока процесс двигается, человек всё сильнее врастает корнями в свою почву неизменчивости и всё меньше хочет перемен.
С пнём на исполнителе ещё можно смириться, он “работает” над своей зоной, задачи настолько не критичные, насколько это возможно, но вот с руководителем… С ним тоже можно жить, но тогда и ты сам превратишься в такой же пень. Будет команда пней, кайф.
Есть и хорошая новость, этого можно избежать, но придётся над собой работать. Постоянно пробовать что-то новое, сомневаться в догматах и пытаться найти другие способы решения задач. В быту тоже придётся над собой работать.
Не будьте пнями.
Их можно найти и в топ-менеджменте и в среднем и даже на уровне простых исполнителей, но ты легко сможешь безошибочно опознать пень.
Приглядись, сидит такой, невзрачный, прикидывается ветошью и внимательно слушает остальных. Это пень, да. Такие стараются не спорить, готовы пообещать выполнить что-угодно, но делать это не будут. Ну или будут до последнего тянуть с решением.
Стать мёртвым пнём это постепенный процесс, по наблюдениям это связано с отсутствием желания меняться, изучать новое, когда человек уже измотал сам себя и ему хочется “доработать до пенсии”. Никто из нас не застрахован от такого и пока процесс двигается, человек всё сильнее врастает корнями в свою почву неизменчивости и всё меньше хочет перемен.
С пнём на исполнителе ещё можно смириться, он “работает” над своей зоной, задачи настолько не критичные, насколько это возможно, но вот с руководителем… С ним тоже можно жить, но тогда и ты сам превратишься в такой же пень. Будет команда пней, кайф.
Есть и хорошая новость, этого можно избежать, но придётся над собой работать. Постоянно пробовать что-то новое, сомневаться в догматах и пытаться найти другие способы решения задач. В быту тоже придётся над собой работать.
Не будьте пнями.
🦄2👌1
Инструментальная перегрузка
Все сталкивались с ней, даже если не задумывались об этом. Типичный пример: сидишь на очередном совещании и думаешь «а на черта это всё мне нужно?». Или даже лучше, количество технологий видели? А как там думскроллинг поживает?
Мы поглощаем так много информации за один день, что это приводит к перенасыщению информацией и перегрузу когнитивных способностей. Это, кстати, одна из причин почему я пытаюсь сокращать свои тексты и не заваливать вас постами.
Но стоп, а инструментальная-то тут причём? Дело в том, что я последнее время много читаю про управление и разные фреймворки, методики, подходы к тому, как надо правильно строить процессы внутри команды и в управлении продуктом. И я заметил одну особенность, в “менеджерском” словаре инструментов ни чуть не меньше, чем у разработчиков, но только неопытные управленцы внедряют в свою работу первый же инструмент, который им предложили. Хороший менеджер не станет использовать то, что вот только стало популярным. Но у технических разработчиков и сопровождения этот паттерн ещё не развился.
Например, во фронте, там прям чёрт ногу сломит и всем будто плевать, будем браться за задачу с тем, что у всех на слуху. “Оптимизация? Не, не слышали, фреймворк сам всё решит”. Спойлер, не решил. Думаете, так только там? Но нет же, пихают энсибл во все места, куда дотягиваются. Кубер используем везде, где его хоть как-то можно разместить, даже если кластер по швам трещит, а приложение - монолит с БД. “У нас всё scalable”. Тьфу.
Это я к чему, не пихайте везде и всюду новое, лишь бы потрогать технологию. Но и сидеть на попе ровно с башем тоже не надо. Инструмент создают под конкретную задачу, поэтому и вы под свою задачу выбирайте инструменты. И думскроллить переставайте. Не поможет.
Все сталкивались с ней, даже если не задумывались об этом. Типичный пример: сидишь на очередном совещании и думаешь «а на черта это всё мне нужно?». Или даже лучше, количество технологий видели? А как там думскроллинг поживает?
Мы поглощаем так много информации за один день, что это приводит к перенасыщению информацией и перегрузу когнитивных способностей. Это, кстати, одна из причин почему я пытаюсь сокращать свои тексты и не заваливать вас постами.
Но стоп, а инструментальная-то тут причём? Дело в том, что я последнее время много читаю про управление и разные фреймворки, методики, подходы к тому, как надо правильно строить процессы внутри команды и в управлении продуктом. И я заметил одну особенность, в “менеджерском” словаре инструментов ни чуть не меньше, чем у разработчиков, но только неопытные управленцы внедряют в свою работу первый же инструмент, который им предложили. Хороший менеджер не станет использовать то, что вот только стало популярным. Но у технических разработчиков и сопровождения этот паттерн ещё не развился.
Например, во фронте, там прям чёрт ногу сломит и всем будто плевать, будем браться за задачу с тем, что у всех на слуху. “Оптимизация? Не, не слышали, фреймворк сам всё решит”. Спойлер, не решил. Думаете, так только там? Но нет же, пихают энсибл во все места, куда дотягиваются. Кубер используем везде, где его хоть как-то можно разместить, даже если кластер по швам трещит, а приложение - монолит с БД. “У нас всё scalable”. Тьфу.
Это я к чему, не пихайте везде и всюду новое, лишь бы потрогать технологию. Но и сидеть на попе ровно с башем тоже не надо. Инструмент создают под конкретную задачу, поэтому и вы под свою задачу выбирайте инструменты. И думскроллить переставайте. Не поможет.
👍2
Настольная книга project-менеджера от Завертайлова только что дослушана.
Хорошая книга, иногда опускается до совсем примитивов, но мне, как инженеру по сути, подошла идеально. Стоит читать когда вы уже работаете менеджером, чтобы сразу пробовать подходы. Много перечислений методов работы, много референсов в сторону других книг.
Плюсы: всё понятно, по полочкам, от управления командой и жизненным циклом, до технического стека(если вы вдруг не из инженеров).
Минусы: из-за большого количество перечислений по пунктам, на слух бывает тяжело воспринимать. Плюс, много апелляций к pdf приложению, которое я посмотреть не смог. И чтец очень часто криво читает технический английский и наши REST API превращается в ЭрИЭсТи ЭйПиАй.
Хорошая книга, иногда опускается до совсем примитивов, но мне, как инженеру по сути, подошла идеально. Стоит читать когда вы уже работаете менеджером, чтобы сразу пробовать подходы. Много перечислений методов работы, много референсов в сторону других книг.
Плюсы: всё понятно, по полочкам, от управления командой и жизненным циклом, до технического стека(если вы вдруг не из инженеров).
Минусы: из-за большого количество перечислений по пунктам, на слух бывает тяжело воспринимать. Плюс, много апелляций к pdf приложению, которое я посмотреть не смог. И чтец очень часто криво читает технический английский и наши REST API превращается в ЭрИЭсТи ЭйПиАй.
Media is too big
VIEW IN TELEGRAM
Так, пора дать немного информации.
Ролики для NotCourse всё ещё на монтаже, я об этом не забыл, всё идёт планомерно. Один для ютуба нарезан, туда нужно нарисовать графику, второй для boosty/patreon(он там будет бесплатными) режется, как только появляется свободное время.
По пути, я начал прорабатывать архитектуру проекта, чтобы к теории можно было дать и практику, да ещё и чтобы проверки были и ждать никому не приходилось. Дизайн фронта уже размечен, сейчас самая большая головная боль это набор сервисов на бэке, которые придётся тщательно продумывать и писать.
По плану, без сайта первые ролики везде я хочу выложить к концу февраля. Полный набор по Ansible ещё даже не снят, но думаю, что в фефрале же досниму и поделюсь с вами.
На Ansible я останавливаться не буду, как минимум, есть CI/CD и kubernetes в планах.
Сайт запустится, скорее-всего, только к концу года, работы много как с ним, так и на основной работе. О том, как оно всё будет взаимодействовать, как всё устроено и сколько нужно будет заносить - всё расскажу чуть позже, целый ролик запишу. Могу только сказать, что по итогу всем должно стать приятно.
Ролики для NotCourse всё ещё на монтаже, я об этом не забыл, всё идёт планомерно. Один для ютуба нарезан, туда нужно нарисовать графику, второй для boosty/patreon(он там будет бесплатными) режется, как только появляется свободное время.
По пути, я начал прорабатывать архитектуру проекта, чтобы к теории можно было дать и практику, да ещё и чтобы проверки были и ждать никому не приходилось. Дизайн фронта уже размечен, сейчас самая большая головная боль это набор сервисов на бэке, которые придётся тщательно продумывать и писать.
По плану, без сайта первые ролики везде я хочу выложить к концу февраля. Полный набор по Ansible ещё даже не снят, но думаю, что в фефрале же досниму и поделюсь с вами.
На Ansible я останавливаться не буду, как минимум, есть CI/CD и kubernetes в планах.
Сайт запустится, скорее-всего, только к концу года, работы много как с ним, так и на основной работе. О том, как оно всё будет взаимодействовать, как всё устроено и сколько нужно будет заносить - всё расскажу чуть позже, целый ролик запишу. Могу только сказать, что по итогу всем должно стать приятно.
❤1👏1