А в догонку к предыдущему вот ещё один: https://softwaremill.com/kafka-visualisation/
Softwaremill
SoftwareMill Kafka Visualization
Using the Kafka Visualization tool you can simulate how data flows through a replicated Kafka topic, to gain a better understanding of the message processing model.
🔥7👍2
CD и Фаулер: что на самом деле означает “Continuous Delivery”
Когда говорят “CI/CD”, обычно имеют в виду: “я запушил код — он магически оказался в проде”. Но это не Continuous Delivery. Настоящий CD — это не про кнопки “Deploy” и не про джобы в GitLab CI. Это про то, как код попадает к пользователям быстро, безопасно и непрерывно.
❓ Что такое CD по Фаулеру ❓
Continuous Delivery (CD) — это подход, при котором каждое изменение кода потенциально готово к продакшену. Это не значит, что код выкатывается мгновенно, но если понадобится — он может быть развернут в любой момент.
Фаулер выделяет три ключевых аспекта CD:
1. Код готов к деплою в любой момент, а значит:
- Каждая фича или фикс проходят полный цикл тестирования.
- Код хранится в рабочем состоянии в любой момент времени.
- Нет отделения “стабильного кода в main” и “свалки разного в develop” — код в принципе можно катнуть всегда (хотя фича и не всегда в нём будет доступна пользователям).
2. У вас есть автоматизация доставки
- Тесты, сборки, деплой — всё автоматизировано. Если нет — вы не сможете дешёво принимать решение о стабильности кода каждый раз, когда это вам надо.
- Минимум ручного труда: нажал кнопку — код улетел в прод.
3. Вы не боитесь деплоить
- Можно катить обновления хоть десять раз в день, потому что всё контролируемо.
- Есть откаты, фичетогглы, канареечные релизы.
Прийти к такому идеальному состоянию не просто, он требует экстремальной технологической диктатуры. Однако, у Фаулера можно многому вдохновиться, особенно если:
💩 Ваш код накапливается в develop или — ещё хуже — в feature-ветках и неделями ждёт релиза.
🧎 Деплой идёт вручную, с “ночным окном” и мантрами “ну давай, родимый”, или требует сложных приседаний в том, в какой очерёдности что катить.
🤣 Миграций схемы базы данных или автоотката релиза у вас нет, а если что-то сломалось — специально обученные эксперты чинят на горячую.
😳 Релизить по пятницам нельзя — ведь тогда ой-ой-ой — придётся работать в выходные
Когда говорят “CI/CD”, обычно имеют в виду: “я запушил код — он магически оказался в проде”. Но это не Continuous Delivery. Настоящий CD — это не про кнопки “Deploy” и не про джобы в GitLab CI. Это про то, как код попадает к пользователям быстро, безопасно и непрерывно.
Continuous Delivery (CD) — это подход, при котором каждое изменение кода потенциально готово к продакшену. Это не значит, что код выкатывается мгновенно, но если понадобится — он может быть развернут в любой момент.
Фаулер выделяет три ключевых аспекта CD:
1. Код готов к деплою в любой момент, а значит:
- Каждая фича или фикс проходят полный цикл тестирования.
- Код хранится в рабочем состоянии в любой момент времени.
- Нет отделения “стабильного кода в main” и “свалки разного в develop” — код в принципе можно катнуть всегда (хотя фича и не всегда в нём будет доступна пользователям).
2. У вас есть автоматизация доставки
- Тесты, сборки, деплой — всё автоматизировано. Если нет — вы не сможете дешёво принимать решение о стабильности кода каждый раз, когда это вам надо.
- Минимум ручного труда: нажал кнопку — код улетел в прод.
3. Вы не боитесь деплоить
- Можно катить обновления хоть десять раз в день, потому что всё контролируемо.
- Есть откаты, фичетогглы, канареечные релизы.
Прийти к такому идеальному состоянию не просто, он требует экстремальной технологической диктатуры. Однако, у Фаулера можно многому вдохновиться, особенно если:
💩 Ваш код накапливается в develop или — ещё хуже — в feature-ветках и неделями ждёт релиза.
🧎 Деплой идёт вручную, с “ночным окном” и мантрами “ну давай, родимый”, или требует сложных приседаний в том, в какой очерёдности что катить.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥4
А накидайте boost-ов каналу, чтобы добавить весёлые реакции для постов? 😳
https://t.me/lovely_it_hell?boost
https://t.me/lovely_it_hell?boost
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Уютный IT адочек
Проголосуйте за канал, чтобы он получил больше возможностей.
👍2💩2🎉1
"Софт надо писать без багов, сразу" — сказал мне однажды Большой Начальник.
Меня знатно подбомбило. Но он был прав.
Нет, я не ерунду несу. Дослушайте.
Можно бесконечно улучшать мониторинг, набирать людей на поддержку, устраивать бригаду скорой помощи для продакшена. Но это всё — лечение симптомов, а не причины болезни. Кроме припарок — надо делать так, чтобы софт сразу выходил качественным. И человечество уже придумало море подходов!
- Внедряйте quality gate-ы на ранних этапах, раньше — лучше. Автоматизированное тестирование, линтеры, дизайн-ревью, да хотя бы внятная постановка задач!
- Прокачивайте тех, кто ставит задачи и принимает ключевые решения. Общайтесь, учите, обеспечивайте обратную связь и развитие.
- Вместо героического решения горы техдолга — не доводите до него. Это не всегда возможно и на костылях всё IT держится, но мало кто может поспорить, что бесконтрольный техдолг — прямой путь на стол паталогоанатома. Нельзя опускать руки в стремлении обуздать эту основополагающую IT-стихию!
В любом случае, лечить гангрену подорожником — плохая стратегия. Работа над повышением качества должна начинаться сразу, с самого начала.
Меня знатно подбомбило. Но он был прав.
Нет, я не ерунду несу. Дослушайте.
Можно бесконечно улучшать мониторинг, набирать людей на поддержку, устраивать бригаду скорой помощи для продакшена. Но это всё — лечение симптомов, а не причины болезни. Кроме припарок — надо делать так, чтобы софт сразу выходил качественным. И человечество уже придумало море подходов!
- Внедряйте quality gate-ы на ранних этапах, раньше — лучше. Автоматизированное тестирование, линтеры, дизайн-ревью, да хотя бы внятная постановка задач!
- Прокачивайте тех, кто ставит задачи и принимает ключевые решения. Общайтесь, учите, обеспечивайте обратную связь и развитие.
- Вместо героического решения горы техдолга — не доводите до него. Это не всегда возможно и на костылях всё IT держится, но мало кто может поспорить, что бесконтрольный техдолг — прямой путь на стол паталогоанатома. Нельзя опускать руки в стремлении обуздать эту основополагающую IT-стихию!
В любом случае, лечить гангрену подорожником — плохая стратегия. Работа над повышением качества должна начинаться сразу, с самого начала.
🔥28🤣4
Кандидаты начали проходить собеседования с помощью LLM! Караул!
— периодически раздаётся из разных щелей.
Предлагаю ультимативное решение проблемы: разрешить LLM на собеседованиях, но при соблюдении условий.
Кандидат может использовать LLM, мало того — мы даже напоминаем ему о том, что он может это делать, и отмечаем, что качественные навыки использования LLM будут бонусом — но при одном условии. Он должен делать это открыто, и шарить интервьюверу экран, чтобы было видно, какие запросы он задаёт, как интерпретирует ответы, где слепо верит, а где видит подвох.
Джин вылез из бутылки, давайте использовать себе на благо!
— периодически раздаётся из разных щелей.
Предлагаю ультимативное решение проблемы: разрешить LLM на собеседованиях, но при соблюдении условий.
Кандидат может использовать LLM, мало того — мы даже напоминаем ему о том, что он может это делать, и отмечаем, что качественные навыки использования LLM будут бонусом — но при одном условии. Он должен делать это открыто, и шарить интервьюверу экран, чтобы было видно, какие запросы он задаёт, как интерпретирует ответы, где слепо верит, а где видит подвох.
Джин вылез из бутылки, давайте использовать себе на благо!
👍51🔥17💩4🎉1
Сегодня я узнал, что вместо того, чтобы парсить интернет — можно скачать его с архив орг:
Вот, например: https://archive.org/details/alexacrawls — всего 211 терабайт - и индекс alexa_2007 будет у тебя!
Что на самом деле очень круто и гораздо лучше, чем очередным пауком обходить интернет.
p.s.
Internet Arhive Web — 18,5 петабайт.
Не благодарите: https://archive.org/details/web
Вот, например: https://archive.org/details/alexacrawls — всего 211 терабайт - и индекс alexa_2007 будет у тебя!
Что на самом деле очень круто и гораздо лучше, чем очередным пауком обходить интернет.
p.s.
Не благодарите:
🔥12
Как разгрести хаос в команде, если ты новый человек?
1. Разбираться. Вникать, спрашивать, копать. Не стесняться задавать вопросы, даже если кажется, что ты уже всех достал. Узнать, как тут вообще живут, какие процессы есть (или их нет), кто принимает решения, а кто просто делает вид.
Отдельный, строго необходимый скилл — выбивать себе право задавать неудобные вопросы и назначать встречи кому угодно, чтобы вытащить из них сведения.
2. Фиксировать. Записывать, рисовать схемы, собирать документы. Хаос не любит прозрачность, а твоя задача — сделать его видимым. Фиксация нужна не только тебе, но и начальству. Им нужен не просто крик «у нас тут всё плохо!», а конкретика: вот, что есть, вот, чего не хватает, вот, что нужно менять. Наличие у тебя схем того, как устроено на самом деле, документов, где понятным образом зафиксировано происходящее — это буквально то, что вселит в них уверенность, что ты на правильном пути.
3. Держать связь с реальностью. Твои представления могут не совпадать с тем, что на самом деле происходит. Проверяй гипотезы. Показывай команде свои схемы, свои записи, спрашивай, слушай. Реальность сложнее, чем твои представления о ней, но не сложнее, чем ты способен докопаться.
4. Не терпеть вредителей. В мутной воде многие отлично себя чувствуют. Кто-то сознательно саботирует, кто-то просто боится перемен. Нужно ли давать шанс встроиться в новый порядок? Всегда да. Нужно ли давать саботировать изменения? Точно нет. Придётся разговаривать прямо, давать возможность исправиться и вместе искать пространство для манёвра, но если человек не хочет меняться — расставаться с ним без сожалений.
Наведение порядка — это процесс, а не кнопка «Сделать красиво». Будет сопротивление, будут ошибки. Главное — двигаться вперёд и не бояться делать хаос видимым. Тогда он перестаёт быть хаосом.
1. Разбираться. Вникать, спрашивать, копать. Не стесняться задавать вопросы, даже если кажется, что ты уже всех достал. Узнать, как тут вообще живут, какие процессы есть (или их нет), кто принимает решения, а кто просто делает вид.
Отдельный, строго необходимый скилл — выбивать себе право задавать неудобные вопросы и назначать встречи кому угодно, чтобы вытащить из них сведения.
2. Фиксировать. Записывать, рисовать схемы, собирать документы. Хаос не любит прозрачность, а твоя задача — сделать его видимым. Фиксация нужна не только тебе, но и начальству. Им нужен не просто крик «у нас тут всё плохо!», а конкретика: вот, что есть, вот, чего не хватает, вот, что нужно менять. Наличие у тебя схем того, как устроено на самом деле, документов, где понятным образом зафиксировано происходящее — это буквально то, что вселит в них уверенность, что ты на правильном пути.
3. Держать связь с реальностью. Твои представления могут не совпадать с тем, что на самом деле происходит. Проверяй гипотезы. Показывай команде свои схемы, свои записи, спрашивай, слушай. Реальность сложнее, чем твои представления о ней, но не сложнее, чем ты способен докопаться.
4. Не терпеть вредителей. В мутной воде многие отлично себя чувствуют. Кто-то сознательно саботирует, кто-то просто боится перемен. Нужно ли давать шанс встроиться в новый порядок? Всегда да. Нужно ли давать саботировать изменения? Точно нет. Придётся разговаривать прямо, давать возможность исправиться и вместе искать пространство для манёвра, но если человек не хочет меняться — расставаться с ним без сожалений.
Наведение порядка — это процесс, а не кнопка «Сделать красиво». Будет сопротивление, будут ошибки. Главное — двигаться вперёд и не бояться делать хаос видимым. Тогда он перестаёт быть хаосом.
👍23🔥12💩5🤔1
Ситуация до боли знакома. Кто-то предлагает новый чек-лист для контроля задач, и тут же уважаемые “эксперты” начинают дебаты:
— "Это формальность, никто не будет этим пользоваться."
— "Все эти бумажки отваливаются через полгода, зачем тратить время?"
— "Если хотите порядок — нужны автоматические линтеры и тесты, а не таблицы."
Скепсис понятен. Чек-листы и правда легко превращаются в пыльные файлы, забытые на гугл-диске. Но когда команда говорит: "Мы реально спотыкаемся тут каждый день" — это уже повод задуматься.
Почему так происходит? Люди не любят процессы, которые воспринимаются как пустая формальность, но многие проблемы рождаются из-за отсутствия системного понимания. Работа над формализацией чего-то может создать это системное понимание.
🔧 Чек-лист, который работает:
1. Простой. Понятные пункты, которые легко проверять.
2. Приносит пользу здесь и сейчас. Если чек-лист экономит время, нервы или спасает от ошибок, его начнут использовать.
3. Имеет связь с задачей. Это не просто "чтобы было", а чтобы сделать проект лучше.
Автоматизация — это здорово, это гораздо лучше чек-листов и инструкций. Но давайте признаем: не всё можно сразу закодить в линтеры (и тем более не всегда на это есть время и силы). И да, иногда проще заклеить дыру скотчем, пока не нашли сварочный аппарат. Главное, чтобы этот скотч держал, а не просто создавал видимость исправления.
Если внедряете чек-листы — делайте это так, чтобы люди захотели ими пользоваться. Начните с малого, сделайте так, чтобы было не стыдно перед клиентами, и двигайтесь к автоматизации. Не останавливайтесь и делайте прозрачным для команды этот путь и его результаты — и это вернёт вам взаимное доверие.
— "Это формальность, никто не будет этим пользоваться."
— "Все эти бумажки отваливаются через полгода, зачем тратить время?"
— "Если хотите порядок — нужны автоматические линтеры и тесты, а не таблицы."
Скепсис понятен. Чек-листы и правда легко превращаются в пыльные файлы, забытые на гугл-диске. Но когда команда говорит: "Мы реально спотыкаемся тут каждый день" — это уже повод задуматься.
Почему так происходит? Люди не любят процессы, которые воспринимаются как пустая формальность, но многие проблемы рождаются из-за отсутствия системного понимания. Работа над формализацией чего-то может создать это системное понимание.
🔧 Чек-лист, который работает:
1. Простой. Понятные пункты, которые легко проверять.
2. Приносит пользу здесь и сейчас. Если чек-лист экономит время, нервы или спасает от ошибок, его начнут использовать.
3. Имеет связь с задачей. Это не просто "чтобы было", а чтобы сделать проект лучше.
Автоматизация — это здорово, это гораздо лучше чек-листов и инструкций. Но давайте признаем: не всё можно сразу закодить в линтеры (и тем более не всегда на это есть время и силы). И да, иногда проще заклеить дыру скотчем, пока не нашли сварочный аппарат. Главное, чтобы этот скотч держал, а не просто создавал видимость исправления.
Если внедряете чек-листы — делайте это так, чтобы люди захотели ими пользоваться. Начните с малого, сделайте так, чтобы было не стыдно перед клиентами, и двигайтесь к автоматизации. Не останавливайтесь и делайте прозрачным для команды этот путь и его результаты — и это вернёт вам взаимное доверие.
👍16🔥4
🤣32👍4🤔3🔥2
SLA и снижение потерь от инцидентов
Рассказываю про то, как построить SLA для платформенных продуктов, в чём тут отличие от обычных, "продуктовых" продуктов, как с этим связаны SLI, SRE и другие страшные трёхбуквенные слова.
Пройдёмся по инфраструктуре, по управлению ожиданиями и заветным девяточкам.
Бонусом — пачка лулзов из реальной жизни.
https://youtu.be/hIvWnxdBtR8
Рассказываю про то, как построить SLA для платформенных продуктов, в чём тут отличие от обычных, "продуктовых" продуктов, как с этим связаны SLI, SRE и другие страшные трёхбуквенные слова.
Пройдёмся по инфраструктуре, по управлению ожиданиями и заветным девяточкам.
Бонусом — пачка лулзов из реальной жизни.
https://youtu.be/hIvWnxdBtR8
YouTube
Как не потерять миллионы на SLA: архитектурный подход к управлению ожиданиями / Игорь Цупко
Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2025
Презентация и тезисы:
https://devopsconf.io/moscow/2025/abstracts/14107
В мире высоких требований к надёжности платформ часто бывает так, что SLA…
Презентация и тезисы:
https://devopsconf.io/moscow/2025/abstracts/14107
В мире высоких требований к надёжности платформ часто бывает так, что SLA…
👍6🔥5
👑
Работал я как-то с человеком, который решил, что я "неправильный", и взялся меня лечить. Никто его об этом не просил. Но, кажется, он был уверен: если сумеет меня "вылечить", то станет ещё умнее и успешнее.
Сегодняшний пост — о локальных царьках.
Мне довелось встречать таких персонажей в самых разных ролях: от продавцов фильтров на рынке у трёх вокзалов до основателей IT-компаний. Внешний лоск, масштабы успеха и задачи могли отличаться, но суть всегда была одна.
Как распознать царька:
- Красивые сказки, которые увлекают, но не сходятся с реальностью.
- Имидж «великого» и единственно правого, который он старательно лепит вокруг себя.
- Настойчивое желание переубедить всех и каждого, что правда только за ним.
- Общение с ним часто вызывает ощущение: "Что вообще происходит?".
- Авторитет "царя" нельзя оспаривать, иначе вы — враг.
- Отказ признавать свои ошибки, даже очевидные.
- Разрыв между словами и делами, скрытый под маской харизмы.
- Деление мира на "равных" (себе) и всех остальных.
Звучит знакомо?
Чем это опасно?
В моём случае ценой ошибки были несколько месяцев психотерапии. Именно столько мне понадобилось после увольнения, чтобы перестать вздрагивать при начале рабочего общения с другими людьми. Токсичность царьков может полностью выбить из колеи и потребовать приёма замечательных колёс для восстановления психики.
Как выживать?
1. Держитесь своих интересов. Помните: никто не знает, что вам нужно, лучше вас самих.
2. Опирайтесь на факты, а не на их красивые истории.
3. Слушайте свои ощущения — если что-то не так, это повод задуматься.
4. Не бойтесь своей самостоятельности. Уход от такого "царя" — это не слабость, а победа.
Токсичные лидеры встречаются везде, и избежать их сложно. Но ваша задача — защитить себя, свои границы и своё здоровье. Никто не сделает это за вас.
Крепитесь и верьте в себя.
Работал я как-то с человеком, который решил, что я "неправильный", и взялся меня лечить. Никто его об этом не просил. Но, кажется, он был уверен: если сумеет меня "вылечить", то станет ещё умнее и успешнее.
Сегодняшний пост — о локальных царьках.
Мне довелось встречать таких персонажей в самых разных ролях: от продавцов фильтров на рынке у трёх вокзалов до основателей IT-компаний. Внешний лоск, масштабы успеха и задачи могли отличаться, но суть всегда была одна.
Как распознать царька:
- Красивые сказки, которые увлекают, но не сходятся с реальностью.
- Имидж «великого» и единственно правого, который он старательно лепит вокруг себя.
- Настойчивое желание переубедить всех и каждого, что правда только за ним.
- Общение с ним часто вызывает ощущение: "Что вообще происходит?".
- Авторитет "царя" нельзя оспаривать, иначе вы — враг.
- Отказ признавать свои ошибки, даже очевидные.
- Разрыв между словами и делами, скрытый под маской харизмы.
- Деление мира на "равных" (себе) и всех остальных.
Звучит знакомо?
Чем это опасно?
В моём случае ценой ошибки были несколько месяцев психотерапии. Именно столько мне понадобилось после увольнения, чтобы перестать вздрагивать при начале рабочего общения с другими людьми. Токсичность царьков может полностью выбить из колеи и потребовать приёма замечательных колёс для восстановления психики.
Как выживать?
1. Держитесь своих интересов. Помните: никто не знает, что вам нужно, лучше вас самих.
2. Опирайтесь на факты, а не на их красивые истории.
3. Слушайте свои ощущения — если что-то не так, это повод задуматься.
4. Не бойтесь своей самостоятельности. Уход от такого "царя" — это не слабость, а победа.
Токсичные лидеры встречаются везде, и избежать их сложно. Но ваша задача — защитить себя, свои границы и своё здоровье. Никто не сделает это за вас.
Крепитесь и верьте в себя.
👍24
Pet project ДО того, как разобрался в теме:
Так, короче, там будет LLM, телеграм-бот или кастомный телеграм-клиент, база данных и пачка интерфейсов для работы с ней. Ещё нужен будет какой-то хитрый парсер данных с LLM. Придётся попотеть, но должно завестись.🚬
Pet project ПОСЛЕ того, как разобрался в теме:
Пять сниппетов текста, гугл табличка.
Фиг знает, что получится, но начинаю пользоваться уже сегодня.😜
Так, короче, там будет LLM, телеграм-бот или кастомный телеграм-клиент, база данных и пачка интерфейсов для работы с ней. Ещё нужен будет какой-то хитрый парсер данных с LLM. Придётся попотеть, но должно завестись.
Pet project ПОСЛЕ того, как разобрался в теме:
Пять сниппетов текста, гугл табличка.
Фиг знает, что получится, но начинаю пользоваться уже сегодня.
Please open Telegram to view this post
VIEW IN TELEGRAM
Наконец-то полезный сервис (жалко, что не мой)
No-as-a-service — удобное API, которое возвращает разные варианты формулировок отказа. Внимание⚠️ максимум 120 запросов в минуту с одного IP.
Но зато есть возможность self-hosting-а.
https://github.com/hotheadhacker/no-as-a-service
Сервис, который мы всегда хотели🙂
No-as-a-service — удобное API, которое возвращает разные варианты формулировок отказа. Внимание
Но зато есть возможность self-hosting-а.
https://github.com/hotheadhacker/no-as-a-service
Сервис, который мы всегда хотели
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8🤣8👍5
Вписался я тут на курс «Руководитель отдела» от Стратоплана.
И сразу — опа, здравствуйте, вот вам домашка. Эссе, тест, кейс, собеседование. Всё серьёзно, как будто не учиться идёшь, а контракт на десятки миллионов заключаешь. И знаете — это охренительно. Потому что учёба, где берут всех подряд — не учёба, а платный досуг: поиграли в айтишку и хорош.
Я давно в управлении. Команды, бюджеты, запуск продуктов, тушение пожаров — уже много лет за плечами. Но опыт без формализации — это песня без слов, музыка без нот. Со временем лезут привычки, которые уже не работают — а ты всё тащишь их за собой. Нужна глубокая база без буллшита, без “ставьте задачки по SMART, пнятненько?” и "увольняя - увольняй".
У Стратоплана — высоко поднятая планка. Основатели — Орлов и Панкратов — умные люди, которым я обязан частью управленческих озарений.
А программа курса — вкусняшка:
— директивное управление, но без тоталитарного мракобесия;
— фундаментальные работающие подходы к управлению командами и структурой, здоровые отношения с командами и их лидерами;
— отношения с бизнесом — как выстроить зрелое партнёрство, а не имитировать отчётами бурную деятельность;
— работа с бюджетами (моя прелесть!);
— погружение в бизнесовую часть и как ее понимать и с ней работать;
— построение карьеры, осознанное и последовательное (ой как актуально в нашем подсдувающемся айти рынке).
Весь в предвкушении. Буду делиться своими открытиями в ближайшие месяцы ☺️
И сразу — опа, здравствуйте, вот вам домашка. Эссе, тест, кейс, собеседование. Всё серьёзно, как будто не учиться идёшь, а контракт на десятки миллионов заключаешь. И знаете — это охренительно. Потому что учёба, где берут всех подряд — не учёба, а платный досуг: поиграли в айтишку и хорош.
Я давно в управлении. Команды, бюджеты, запуск продуктов, тушение пожаров — уже много лет за плечами. Но опыт без формализации — это песня без слов, музыка без нот. Со временем лезут привычки, которые уже не работают — а ты всё тащишь их за собой. Нужна глубокая база без буллшита, без “ставьте задачки по SMART, пнятненько?” и "увольняя - увольняй".
У Стратоплана — высоко поднятая планка. Основатели — Орлов и Панкратов — умные люди, которым я обязан частью управленческих озарений.
А программа курса — вкусняшка:
— директивное управление, но без тоталитарного мракобесия;
— фундаментальные работающие подходы к управлению командами и структурой, здоровые отношения с командами и их лидерами;
— отношения с бизнесом — как выстроить зрелое партнёрство, а не имитировать отчётами бурную деятельность;
— работа с бюджетами (моя прелесть!);
— погружение в бизнесовую часть и как ее понимать и с ней работать;
— построение карьеры, осознанное и последовательное (ой как актуально в нашем подсдувающемся айти рынке).
Весь в предвкушении. Буду делиться своими открытиями в ближайшие месяцы ☺️
👍42🔥19🎉7💩2
Фу, опять какие-то новые модные слова на хайпе. Опять кто-то придумал очередной "мета-фреймворк системной сингулярности". Достали уже, честно.
Или нет?
Я утверждаю: нам всем нужна мода и хайп в IT. Сейчас объясню.
Рынок труда не любит уникальных снежинок. Он любит чёткие ярлыки. Никто не ищет себе в команду "разностороннего энтузиаста по всему и сразу". Ищут мобильного разработчика с опытом в Swift и Kotlin. Или DevOps-инженера с Kubernetes и Terraform. Никому не нужен разработчик-железячник-аналитик-сомелье. Даже если он классный.
Чем проще вы описываете себя и свою зону ответственности — тем проще вас поймут. Чем конкретнее ваша роль — тем проще вас найти и взять в работу вот прям сейчас.
Уникальность — это прекрасно для самовыражения. А на рынке труда — это головная боль для рекрутера и менеджера.
И тут наступает самый неприятный момент. Чтобы всем было проще договариваться о ролях, нужны эти самые новые слова, термины и ярлыки.
Их придумывают на конференциях, в статьях, в постах в телеграмчиках. Они раздражают, выглядят как маркетинговая муть, но именно они формируют общее поле понятий, через которое люди начинают понимать друг друга без многостраничных объяснений.
Например, никто уже не объясняет, что такое DevOps — хотя лет 10 назад это слово вызывало столько же ненависти, как сейчас "Platform Engineering". Или "SRE". Сначала смеялись, теперь нанимают пачками.
Это неприятно признавать, но без этих "хайповых" слов отрасль бы не смогла сама себя описать. А без общего языка у нас не будет общих рамок, понятных рынку.
И придётся снова объяснять на пальцах, что вы умеете делать и зачем вам платить зарплату.
Так что да, новые термины бесят. Но они — наш инструмент.
Или нет?
Я утверждаю: нам всем нужна мода и хайп в IT. Сейчас объясню.
Рынок труда не любит уникальных снежинок. Он любит чёткие ярлыки. Никто не ищет себе в команду "разностороннего энтузиаста по всему и сразу". Ищут мобильного разработчика с опытом в Swift и Kotlin. Или DevOps-инженера с Kubernetes и Terraform. Никому не нужен разработчик-железячник-аналитик-сомелье. Даже если он классный.
Чем проще вы описываете себя и свою зону ответственности — тем проще вас поймут. Чем конкретнее ваша роль — тем проще вас найти и взять в работу вот прям сейчас.
Уникальность — это прекрасно для самовыражения. А на рынке труда — это головная боль для рекрутера и менеджера.
И тут наступает самый неприятный момент. Чтобы всем было проще договариваться о ролях, нужны эти самые новые слова, термины и ярлыки.
Их придумывают на конференциях, в статьях, в постах в телеграмчиках. Они раздражают, выглядят как маркетинговая муть, но именно они формируют общее поле понятий, через которое люди начинают понимать друг друга без многостраничных объяснений.
Например, никто уже не объясняет, что такое DevOps — хотя лет 10 назад это слово вызывало столько же ненависти, как сейчас "Platform Engineering". Или "SRE". Сначала смеялись, теперь нанимают пачками.
Это неприятно признавать, но без этих "хайповых" слов отрасль бы не смогла сама себя описать. А без общего языка у нас не будет общих рамок, понятных рынку.
И придётся снова объяснять на пальцах, что вы умеете делать и зачем вам платить зарплату.
Так что да, новые термины бесят. Но они — наш инструмент.
👍35🤔2💩2
Для серьёзного продукта, его инфраструктура — это не тулза. Это тоже продукт. А девопсы — не просто люди с доступом к кластеру, а овнеры этой самой инфры.
Смотрите:
— у инфры есть код (надеюсь, всё-таки в 2025 не надо обсуждать необходимость IaC?), и у этого кода есть овнеры. Те, кто не просто накатывают, а проектируют, развивают и реагирует, если что-то не так;
— у инфры есть product owner. Тот, кто формулирует, куда мы вообще движемся, какую боль лечим, какие косты срезаем, управляет бэклогом, обладает пониманием что перспективно, а что не очень;
— у инфры есть метрики. Доставка изменений, стабильность, скорость развёртывания, NPS среди команд — всё, как у людей. Иногда их даже считают и даже(!) оптимизируют;
— у инфры есть поддержка. Ну вы понимаете, кто чинит, когда всё упало?
— у инфры есть регламенты и может быть даже дока, потому что инфра — часть общего ландшафта, и без договорённостей с остальными командами будет боль и страдания.
И если при этом "тимлид девопсов" говорит: "Ну я тут задачки раскидываю, да, и дежурства составляю", — хочется спросить:
А кто овнит твой продукт?
Кто рулит развитием? Кто отвечает за ценность? Кто следит, чтобы не просто работало, а работало хорошо и стабильно?
А часто никто. Потому что "девопс-инженеры" у нас не про овнерство, да? Они про "мы сделали — а дальше как-нибудь сами". Документации нет, роадмапа нет, техдолг "ну вы чо, у нас тут всё сложно".
DevOps — это development и operations, а не “я тут ямлики поправил, подик вроде поднялся”.
Хочешь, чтобы инфраструктура была надёжной, предсказуемой и удобной?
Начни относиться к ней как к продукту. И овнить её так же.
Смотрите:
— у инфры есть код (надеюсь, всё-таки в 2025 не надо обсуждать необходимость IaC?), и у этого кода есть овнеры. Те, кто не просто накатывают, а проектируют, развивают и реагирует, если что-то не так;
— у инфры есть product owner. Тот, кто формулирует, куда мы вообще движемся, какую боль лечим, какие косты срезаем, управляет бэклогом, обладает пониманием что перспективно, а что не очень;
— у инфры есть метрики. Доставка изменений, стабильность, скорость развёртывания, NPS среди команд — всё, как у людей. Иногда их даже считают и даже(!) оптимизируют;
— у инфры есть поддержка. Ну вы понимаете, кто чинит, когда всё упало?
— у инфры есть регламенты и может быть даже дока, потому что инфра — часть общего ландшафта, и без договорённостей с остальными командами будет боль и страдания.
И если при этом "тимлид девопсов" говорит: "Ну я тут задачки раскидываю, да, и дежурства составляю", — хочется спросить:
А кто овнит твой продукт?
Кто рулит развитием? Кто отвечает за ценность? Кто следит, чтобы не просто работало, а работало хорошо и стабильно?
А часто никто. Потому что "девопс-инженеры" у нас не про овнерство, да? Они про "мы сделали — а дальше как-нибудь сами". Документации нет, роадмапа нет, техдолг "ну вы чо, у нас тут всё сложно".
DevOps — это development и operations, а не “я тут ямлики поправил, подик вроде поднялся”.
Хочешь, чтобы инфраструктура была надёжной, предсказуемой и удобной?
Начни относиться к ней как к продукту. И овнить её так же.
👍29
Forwarded from Михаил SinTeZoiD
Если кто-то в айти говорит, что знает как правильно делать, то он или хайпожор или не квалифицированный.