Рубрика "как оно у корпоратов".
Статья про то, как, зачем и почему делают интеграционное решение в Лемана Тех:
https://habr.com/ru/companies/lemana_tech/articles/887916/
Статья про то, как, зачем и почему делают интеграционное решение в Лемана Тех:
https://habr.com/ru/companies/lemana_tech/articles/887916/
Хабр
Как мы создали интеграционную платформу, которая работает
Привет! Меня зовут Александр Камчатнов, я — технический архитектор Интеграционной платформы Лемана Тех. Сегодня я расскажу, как мы ее создали и как развиваем. Не буду объяснять, что такое REST, Kafka,...
Forwarded from Технологический Болт Генона
This project simulates a Kafka-like distributed streaming system with Producers, Partitions, and Consumers. It visualizes how data flows through the system and provides real-time metrics on performance. It's useful to understand how records flow within the system and distribute across Consumers.
Kafka-like Stream Processing Simulation
https://github.com/evouraorg/kafka-traffic-visualizer
Online
https://evoura.com/kafka-traffic-visualizer/
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
"Софт надо писать без багов, сразу" — сказал мне однажды Большой Начальник.
Меня знатно подбомбило. Но он был прав.
Нет, я не ерунду несу. Дослушайте.
Можно бесконечно улучшать мониторинг, набирать людей на поддержку, устраивать бригаду скорой помощи для продакшена. Но это всё — лечение симптомов, а не причины болезни. Кроме припарок — надо делать так, чтобы софт сразу выходил качественным. И человечество уже придумало море подходов!
- Внедряйте quality gate-ы на ранних этапах, раньше — лучше. Автоматизированное тестирование, линтеры, дизайн-ревью, да хотя бы внятная постановка задач!
- Прокачивайте тех, кто ставит задачи и принимает ключевые решения. Общайтесь, учите, обеспечивайте обратную связь и развитие.
- Вместо героического решения горы техдолга — не доводите до него. Это не всегда возможно и на костылях всё IT держится, но мало кто может поспорить, что бесконтрольный техдолг — прямой путь на стол паталогоанатома. Нельзя опускать руки в стремлении обуздать эту основополагающую IT-стихию!
В любом случае, лечить гангрену подорожником — плохая стратегия. Работа над повышением качества должна начинаться сразу, с самого начала.
Меня знатно подбомбило. Но он был прав.
Нет, я не ерунду несу. Дослушайте.
Можно бесконечно улучшать мониторинг, набирать людей на поддержку, устраивать бригаду скорой помощи для продакшена. Но это всё — лечение симптомов, а не причины болезни. Кроме припарок — надо делать так, чтобы софт сразу выходил качественным. И человечество уже придумало море подходов!
- Внедряйте quality gate-ы на ранних этапах, раньше — лучше. Автоматизированное тестирование, линтеры, дизайн-ревью, да хотя бы внятная постановка задач!
- Прокачивайте тех, кто ставит задачи и принимает ключевые решения. Общайтесь, учите, обеспечивайте обратную связь и развитие.
- Вместо героического решения горы техдолга — не доводите до него. Это не всегда возможно и на костылях всё IT держится, но мало кто может поспорить, что бесконтрольный техдолг — прямой путь на стол паталогоанатома. Нельзя опускать руки в стремлении обуздать эту основополагающую IT-стихию!
В любом случае, лечить гангрену подорожником — плохая стратегия. Работа над повышением качества должна начинаться сразу, с самого начала.
Кандидаты начали проходить собеседования с помощью LLM! Караул!
— периодически раздаётся из разных щелей.
Предлагаю ультимативное решение проблемы: разрешить LLM на собеседованиях, но при соблюдении условий.
Кандидат может использовать LLM, мало того — мы даже напоминаем ему о том, что он может это делать, и отмечаем, что качественные навыки использования LLM будут бонусом — но при одном условии. Он должен делать это открыто, и шарить интервьюверу экран, чтобы было видно, какие запросы он задаёт, как интерпретирует ответы, где слепо верит, а где видит подвох.
Джин вылез из бутылки, давайте использовать себе на благо!
— периодически раздаётся из разных щелей.
Предлагаю ультимативное решение проблемы: разрешить LLM на собеседованиях, но при соблюдении условий.
Кандидат может использовать LLM, мало того — мы даже напоминаем ему о том, что он может это делать, и отмечаем, что качественные навыки использования LLM будут бонусом — но при одном условии. Он должен делать это открыто, и шарить интервьюверу экран, чтобы было видно, какие запросы он задаёт, как интерпретирует ответы, где слепо верит, а где видит подвох.
Джин вылез из бутылки, давайте использовать себе на благо!
Сегодня я узнал, что вместо того, чтобы парсить интернет — можно скачать его с архив орг:
Вот, например: 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.
Не благодарите:
🔥 Билет за боль: чей факап был самым адским? 🔥
У меня есть лишний билет на закрытое мероприятие «Очень сложные переговоры». Но просто так его не отдам😈
Хочу, чтобы он достался тому, кому пришлось сложно, у кого горело так, что можно было поджарить бекон на расстоянии.
👀 Что за билет?
3 апреля — ивент, где разберут переговорные жестища: когда ставки на миллионы, выходов нет, а ошибки больно бьют по карману и репутации. Обещают, что будет особенно интересно для тех, кто хочет стать C-level.
📢 Как заполучить билет?
1️⃣ Расскажите в комментах под этим постом про свой факап, который реально тряханул:
✍️ Что случилось?
✍️ Во что это обошлось (деньги, нервы, репутация, волосы на голове)?
✍️ Как выкарабкались (или не выкарабкались)?
2️⃣ Победителя выберем просто: чей коммент наберёт больше всего реакций — тому и билет.
🕐 Итоги подведём 1 апреля — и это не прикол.
Удивите меня. Или хотя бы напомните, что бывало и хуже 🔥
У меня есть лишний билет на закрытое мероприятие «Очень сложные переговоры». Но просто так его не отдам
Хочу, чтобы он достался тому, кому пришлось сложно, у кого горело так, что можно было поджарить бекон на расстоянии.
👀 Что за билет?
3 апреля — ивент, где разберут переговорные жестища: когда ставки на миллионы, выходов нет, а ошибки больно бьют по карману и репутации. Обещают, что будет особенно интересно для тех, кто хочет стать C-level.
📢 Как заполучить билет?
1️⃣ Расскажите в комментах под этим постом про свой факап, который реально тряханул:
✍️ Что случилось?
✍️ Во что это обошлось (деньги, нервы, репутация, волосы на голове)?
✍️ Как выкарабкались (или не выкарабкались)?
2️⃣ Победителя выберем просто: чей коммент наберёт больше всего реакций — тому и билет.
🕐 Итоги подведём 1 апреля — и это не прикол.
Удивите меня. Или хотя бы напомните, что бывало и хуже 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня последний день голосования за факап-истории в конкурсе! И в комментах народ отсыпал свежие истории, заходите почитать и отреагировать!
Сотрудники, отвечающие за ту самую зону b — наверное, вы тоже можете поделиться интересным опытом 😳
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Уютный IT адочек
🔥 Билет за боль: чей факап был самым адским? 🔥
У меня есть лишний билет на закрытое мероприятие «Очень сложные переговоры». Но просто так его не отдам 😈
Хочу, чтобы он достался тому, кому пришлось сложно, у кого горело так, что можно было поджарить бекон…
У меня есть лишний билет на закрытое мероприятие «Очень сложные переговоры». Но просто так его не отдам 😈
Хочу, чтобы он достался тому, кому пришлось сложно, у кого горело так, что можно было поджарить бекон…
Итоги конкурса
Печальная история про лягушёнка Пепе набрала максимум голосов, но её автор отказался от приза в пользу истории отгрузки дублей данных в ФНС.
Поздравляем победителя @MrKaiserLeon, желаем ему наличия огнетушителяи льда для задницы когда они так нужны. Крепких нервов и здоровья. 😳
Печальная история про лягушёнка Пепе набрала максимум голосов, но её автор отказался от приза в пользу истории отгрузки дублей данных в ФНС.
Поздравляем победителя @MrKaiserLeon, желаем ему наличия огнетушителя
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Oleg Voznesensky in Уютный IT бар
Скинул мем с лягушонком Пепе в чатег с коллегами с международного проекта. Штатовским представителям заказчика это ОЧЕНЬ НЕ ПОНРАВИЛОСЬ. Вылетел с проекта. Инициировал внеочередную поинтовку местной (ex-)фидо тусовки, где все напились и мочили разные неполиткорректные…
Как разгрести хаос в команде, если ты новый человек?
1. Разбираться. Вникать, спрашивать, копать. Не стесняться задавать вопросы, даже если кажется, что ты уже всех достал. Узнать, как тут вообще живут, какие процессы есть (или их нет), кто принимает решения, а кто просто делает вид.
Отдельный, строго необходимый скилл — выбивать себе право задавать неудобные вопросы и назначать встречи кому угодно, чтобы вытащить из них сведения.
2. Фиксировать. Записывать, рисовать схемы, собирать документы. Хаос не любит прозрачность, а твоя задача — сделать его видимым. Фиксация нужна не только тебе, но и начальству. Им нужен не просто крик «у нас тут всё плохо!», а конкретика: вот, что есть, вот, чего не хватает, вот, что нужно менять. Наличие у тебя схем того, как устроено на самом деле, документов, где понятным образом зафиксировано происходящее — это буквально то, что вселит в них уверенность, что ты на правильном пути.
3. Держать связь с реальностью. Твои представления могут не совпадать с тем, что на самом деле происходит. Проверяй гипотезы. Показывай команде свои схемы, свои записи, спрашивай, слушай. Реальность сложнее, чем твои представления о ней, но не сложнее, чем ты способен докопаться.
4. Не терпеть вредителей. В мутной воде многие отлично себя чувствуют. Кто-то сознательно саботирует, кто-то просто боится перемен. Нужно ли давать шанс встроиться в новый порядок? Всегда да. Нужно ли давать саботировать изменения? Точно нет. Придётся разговаривать прямо, давать возможность исправиться и вместе искать пространство для манёвра, но если человек не хочет меняться — расставаться с ним без сожалений.
Наведение порядка — это процесс, а не кнопка «Сделать красиво». Будет сопротивление, будут ошибки. Главное — двигаться вперёд и не бояться делать хаос видимым. Тогда он перестаёт быть хаосом.
1. Разбираться. Вникать, спрашивать, копать. Не стесняться задавать вопросы, даже если кажется, что ты уже всех достал. Узнать, как тут вообще живут, какие процессы есть (или их нет), кто принимает решения, а кто просто делает вид.
Отдельный, строго необходимый скилл — выбивать себе право задавать неудобные вопросы и назначать встречи кому угодно, чтобы вытащить из них сведения.
2. Фиксировать. Записывать, рисовать схемы, собирать документы. Хаос не любит прозрачность, а твоя задача — сделать его видимым. Фиксация нужна не только тебе, но и начальству. Им нужен не просто крик «у нас тут всё плохо!», а конкретика: вот, что есть, вот, чего не хватает, вот, что нужно менять. Наличие у тебя схем того, как устроено на самом деле, документов, где понятным образом зафиксировано происходящее — это буквально то, что вселит в них уверенность, что ты на правильном пути.
3. Держать связь с реальностью. Твои представления могут не совпадать с тем, что на самом деле происходит. Проверяй гипотезы. Показывай команде свои схемы, свои записи, спрашивай, слушай. Реальность сложнее, чем твои представления о ней, но не сложнее, чем ты способен докопаться.
4. Не терпеть вредителей. В мутной воде многие отлично себя чувствуют. Кто-то сознательно саботирует, кто-то просто боится перемен. Нужно ли давать шанс встроиться в новый порядок? Всегда да. Нужно ли давать саботировать изменения? Точно нет. Придётся разговаривать прямо, давать возможность исправиться и вместе искать пространство для манёвра, но если человек не хочет меняться — расставаться с ним без сожалений.
Наведение порядка — это процесс, а не кнопка «Сделать красиво». Будет сопротивление, будут ошибки. Главное — двигаться вперёд и не бояться делать хаос видимым. Тогда он перестаёт быть хаосом.
Ситуация до боли знакома. Кто-то предлагает новый чек-лист для контроля задач, и тут же уважаемые “эксперты” начинают дебаты:
— "Это формальность, никто не будет этим пользоваться."
— "Все эти бумажки отваливаются через полгода, зачем тратить время?"
— "Если хотите порядок — нужны автоматические линтеры и тесты, а не таблицы."
Скепсис понятен. Чек-листы и правда легко превращаются в пыльные файлы, забытые на гугл-диске. Но когда команда говорит: "Мы реально спотыкаемся тут каждый день" — это уже повод задуматься.
Почему так происходит? Люди не любят процессы, которые воспринимаются как пустая формальность, но многие проблемы рождаются из-за отсутствия системного понимания. Работа над формализацией чего-то может создать это системное понимание.
🔧 Чек-лист, который работает:
1. Простой. Понятные пункты, которые легко проверять.
2. Приносит пользу здесь и сейчас. Если чек-лист экономит время, нервы или спасает от ошибок, его начнут использовать.
3. Имеет связь с задачей. Это не просто "чтобы было", а чтобы сделать проект лучше.
Автоматизация — это здорово, это гораздо лучше чек-листов и инструкций. Но давайте признаем: не всё можно сразу закодить в линтеры (и тем более не всегда на это есть время и силы). И да, иногда проще заклеить дыру скотчем, пока не нашли сварочный аппарат. Главное, чтобы этот скотч держал, а не просто создавал видимость исправления.
Если внедряете чек-листы — делайте это так, чтобы люди захотели ими пользоваться. Начните с малого, сделайте так, чтобы было не стыдно перед клиентами, и двигайтесь к автоматизации. Не останавливайтесь и делайте прозрачным для команды этот путь и его результаты — и это вернёт вам взаимное доверие.
— "Это формальность, никто не будет этим пользоваться."
— "Все эти бумажки отваливаются через полгода, зачем тратить время?"
— "Если хотите порядок — нужны автоматические линтеры и тесты, а не таблицы."
Скепсис понятен. Чек-листы и правда легко превращаются в пыльные файлы, забытые на гугл-диске. Но когда команда говорит: "Мы реально спотыкаемся тут каждый день" — это уже повод задуматься.
Почему так происходит? Люди не любят процессы, которые воспринимаются как пустая формальность, но многие проблемы рождаются из-за отсутствия системного понимания. Работа над формализацией чего-то может создать это системное понимание.
🔧 Чек-лист, который работает:
1. Простой. Понятные пункты, которые легко проверять.
2. Приносит пользу здесь и сейчас. Если чек-лист экономит время, нервы или спасает от ошибок, его начнут использовать.
3. Имеет связь с задачей. Это не просто "чтобы было", а чтобы сделать проект лучше.
Автоматизация — это здорово, это гораздо лучше чек-листов и инструкций. Но давайте признаем: не всё можно сразу закодить в линтеры (и тем более не всегда на это есть время и силы). И да, иногда проще заклеить дыру скотчем, пока не нашли сварочный аппарат. Главное, чтобы этот скотч держал, а не просто создавал видимость исправления.
Если внедряете чек-листы — делайте это так, чтобы люди захотели ими пользоваться. Начните с малого, сделайте так, чтобы было не стыдно перед клиентами, и двигайтесь к автоматизации. Не останавливайтесь и делайте прозрачным для команды этот путь и его результаты — и это вернёт вам взаимное доверие.
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…
👑
Работал я как-то с человеком, который решил, что я "неправильный", и взялся меня лечить. Никто его об этом не просил. Но, кажется, он был уверен: если сумеет меня "вылечить", то станет ещё умнее и успешнее.
Сегодняшний пост — о локальных царьках.
Мне довелось встречать таких персонажей в самых разных ролях: от продавцов фильтров на рынке у трёх вокзалов до основателей IT-компаний. Внешний лоск, масштабы успеха и задачи могли отличаться, но суть всегда была одна.
Как распознать царька:
- Красивые сказки, которые увлекают, но не сходятся с реальностью.
- Имидж «великого» и единственно правого, который он старательно лепит вокруг себя.
- Настойчивое желание переубедить всех и каждого, что правда только за ним.
- Общение с ним часто вызывает ощущение: "Что вообще происходит?".
- Авторитет "царя" нельзя оспаривать, иначе вы — враг.
- Отказ признавать свои ошибки, даже очевидные.
- Разрыв между словами и делами, скрытый под маской харизмы.
- Деление мира на "равных" (себе) и всех остальных.
Звучит знакомо?
Чем это опасно?
В моём случае ценой ошибки были несколько месяцев психотерапии. Именно столько мне понадобилось после увольнения, чтобы перестать вздрагивать при начале рабочего общения с другими людьми. Токсичность царьков может полностью выбить из колеи и потребовать приёма замечательных колёс для восстановления психики.
Как выживать?
1. Держитесь своих интересов. Помните: никто не знает, что вам нужно, лучше вас самих.
2. Опирайтесь на факты, а не на их красивые истории.
3. Слушайте свои ощущения — если что-то не так, это повод задуматься.
4. Не бойтесь своей самостоятельности. Уход от такого "царя" — это не слабость, а победа.
Токсичные лидеры встречаются везде, и избежать их сложно. Но ваша задача — защитить себя, свои границы и своё здоровье. Никто не сделает это за вас.
Крепитесь и верьте в себя.
Работал я как-то с человеком, который решил, что я "неправильный", и взялся меня лечить. Никто его об этом не просил. Но, кажется, он был уверен: если сумеет меня "вылечить", то станет ещё умнее и успешнее.
Сегодняшний пост — о локальных царьках.
Мне довелось встречать таких персонажей в самых разных ролях: от продавцов фильтров на рынке у трёх вокзалов до основателей IT-компаний. Внешний лоск, масштабы успеха и задачи могли отличаться, но суть всегда была одна.
Как распознать царька:
- Красивые сказки, которые увлекают, но не сходятся с реальностью.
- Имидж «великого» и единственно правого, который он старательно лепит вокруг себя.
- Настойчивое желание переубедить всех и каждого, что правда только за ним.
- Общение с ним часто вызывает ощущение: "Что вообще происходит?".
- Авторитет "царя" нельзя оспаривать, иначе вы — враг.
- Отказ признавать свои ошибки, даже очевидные.
- Разрыв между словами и делами, скрытый под маской харизмы.
- Деление мира на "равных" (себе) и всех остальных.
Звучит знакомо?
Чем это опасно?
В моём случае ценой ошибки были несколько месяцев психотерапии. Именно столько мне понадобилось после увольнения, чтобы перестать вздрагивать при начале рабочего общения с другими людьми. Токсичность царьков может полностью выбить из колеи и потребовать приёма замечательных колёс для восстановления психики.
Как выживать?
1. Держитесь своих интересов. Помните: никто не знает, что вам нужно, лучше вас самих.
2. Опирайтесь на факты, а не на их красивые истории.
3. Слушайте свои ощущения — если что-то не так, это повод задуматься.
4. Не бойтесь своей самостоятельности. Уход от такого "царя" — это не слабость, а победа.
Токсичные лидеры встречаются везде, и избежать их сложно. Но ваша задача — защитить себя, свои границы и своё здоровье. Никто не сделает это за вас.
Крепитесь и верьте в себя.