Привет!
Я — Денис Казимиров, я руковожу backend-разработкой и devOps в Braind, а в IT я больше 15 лет, из них уже более восьми на руководящих ролях.
Я начинал как backend-разработчик, писал на PHP. Спустя время стал руководить людьми. В моем опыте меня часто сопровождали интернет-магазины, работая в разных компаниях сталкивался с ecom почти всегда. Но помимо электронной коммерции у меня большой опыт с разными веб-решениями начиная от b2b-решений и заканчивая проектированием и реализацией highload-проектов. По мере возможности изучаю архитектуру и system design.
Я верю, что главное в любой компании — люди. Без хороших надежных ребят невозможно сделать ничего стоящего.
В канале будет много моих заметок о работе, того, что оказалось для меня неожиданным или важным, моих мыслей и сомнений. Но сразу предупреждаю, не ищите здесь «серебряных пуль» и однозначных ответов, особенно на управленческие вопросы, их не существует.
Постараюсь писать почаще, это помогает структурировать мысли. Думаю, что лучшим вариантом будут короткие заметки, но уверен, что от лонгридов не спастись )
Немного обо мне: играю в футбол, строю дом и много всего делаю своими руками, об этом можно почитать в другом моем телеграм-канале.
Если вам интересно — подписывайтесь. Я уже накидал небольшой контент-план, будет кое-что про инфраструктуру и отказоустойчивость.
#знакомство
Я — Денис Казимиров, я руковожу backend-разработкой и devOps в Braind, а в IT я больше 15 лет, из них уже более восьми на руководящих ролях.
Я начинал как backend-разработчик, писал на PHP. Спустя время стал руководить людьми. В моем опыте меня часто сопровождали интернет-магазины, работая в разных компаниях сталкивался с ecom почти всегда. Но помимо электронной коммерции у меня большой опыт с разными веб-решениями начиная от b2b-решений и заканчивая проектированием и реализацией highload-проектов. По мере возможности изучаю архитектуру и system design.
Я верю, что главное в любой компании — люди. Без хороших надежных ребят невозможно сделать ничего стоящего.
В канале будет много моих заметок о работе, того, что оказалось для меня неожиданным или важным, моих мыслей и сомнений. Но сразу предупреждаю, не ищите здесь «серебряных пуль» и однозначных ответов, особенно на управленческие вопросы, их не существует.
Постараюсь писать почаще, это помогает структурировать мысли. Думаю, что лучшим вариантом будут короткие заметки, но уверен, что от лонгридов не спастись )
Немного обо мне: играю в футбол, строю дом и много всего делаю своими руками, об этом можно почитать в другом моем телеграм-канале.
Если вам интересно — подписывайтесь. Я уже накидал небольшой контент-план, будет кое-что про инфраструктуру и отказоустойчивость.
#знакомство
🔥4👍3❤2👏1🌚1💯1
Сегодня обсуждали (и еще в процессе, несмотря на поздний час) онбординг сотрудников с коллегами-руководителями. Очень много мыслей в целом и пищи для размышлений на будущее.
Впечатления двоякие. С одной стороны многое можно улучшить, есть много идей для нашего онбординга. Но с другой — приятно осознавать, сколько всего уже сделано, сколько хороших вещей мы даем ребятам в компании. Главное, что сейчас сильно не хватает системности и полноты. Уверен, что тот майндмап, который у нас коллективно получилось составить, нам сильно поможет двинуть эту тему вперед.
Несмотря на то, что прямо сейчас для нас в бэке это не самый приоритетный вопрос, надеюсь, возьмем его в проработку в следующем году. Уже накидываю планы на следующий год )
UPD. В итоге получилось 2.5 часа ) Честно говоря, было непросто, но теперь у нас есть артефакт, включающий весь опыт разных компаний от Озон и Яндекса до Volvo Trucks )
#текущее
Впечатления двоякие. С одной стороны многое можно улучшить, есть много идей для нашего онбординга. Но с другой — приятно осознавать, сколько всего уже сделано, сколько хороших вещей мы даем ребятам в компании. Главное, что сейчас сильно не хватает системности и полноты. Уверен, что тот майндмап, который у нас коллективно получилось составить, нам сильно поможет двинуть эту тему вперед.
Несмотря на то, что прямо сейчас для нас в бэке это не самый приоритетный вопрос, надеюсь, возьмем его в проработку в следующем году. Уже накидываю планы на следующий год )
UPD. В итоге получилось 2.5 часа ) Честно говоря, было непросто, но теперь у нас есть артефакт, включающий весь опыт разных компаний от Озон и Яндекса до Volvo Trucks )
#текущее
👍3🔥3❤2🌚1
Есть у нас один документ, который нам кажется естественным, но на самом деле есть не у всех. Многие компании и команды имеют что-то немного похожее, но большинство просто страдает без него.
Этот документ мы называем технический план или техническое ревью. Не путать с ADR (Architectural Decision Record), наш вариант отчасти фиксирует решения, но содержит еще кучу дополнительной полезной информации, начиная от плана решения задачи, заканчивая оценками этапов, указанием рисков и исследовательских частей.
Когда-то давно я принес идею этого документа от Алексея Катаева из SkyEng. Лет семь назад на одной из TeamLead Conf он рассказывал о том, как разбирались с оценками задач, и я зацепился за этот инструмент, адаптировал под наши реалии и с тех пор мы живем с ним. Конечно за столько лет он сильно видоизменился: дополнялся и дорабатывался, появлялись новые процессы. Например, валидация техплана: тимлид изучает задачу и техплан, валидирует техническое решение, оценки, помогает разработчику с задачей.
В какой-то момент я осознал, что этот процесс протекает по-разному у разных тимлидов и жизненно необходимо синхронизироваться. В пятницу с тимлидами собрались и накидали майндмэп этого процесса, адаптировали это под текущие требования и реалии, зафиксировали всё. Уверен, что теперь будет гораздо легче проводить валидацию, а ее результаты будут более единообразными и управляемыми. Другими словами, отлично поработали, соберу из этого еще текстовую памятку, будем становиться лучше )
Это был не совсем обычный формат встречи в рамках нашего TeamLead Club (о нем тоже как-нибудь расскажу). Мы запустили цикл воркшопов (если можно их так назвать), где будем разбирать реальные кейсы из нашей работы. Думаю, что такой подход даст максимум пользы.
P.S. Для нас это был первый опыт такого рода встреч, если и вы хотите достигать на встречах большего, а может быть вообще не знаете, как прийти к желаемому результату, то рекомендую посмотреть здесь — http://facilab.pro, очень полезный ресурс.
#текущее
Этот документ мы называем технический план или техническое ревью. Не путать с ADR (Architectural Decision Record), наш вариант отчасти фиксирует решения, но содержит еще кучу дополнительной полезной информации, начиная от плана решения задачи, заканчивая оценками этапов, указанием рисков и исследовательских частей.
Когда-то давно я принес идею этого документа от Алексея Катаева из SkyEng. Лет семь назад на одной из TeamLead Conf он рассказывал о том, как разбирались с оценками задач, и я зацепился за этот инструмент, адаптировал под наши реалии и с тех пор мы живем с ним. Конечно за столько лет он сильно видоизменился: дополнялся и дорабатывался, появлялись новые процессы. Например, валидация техплана: тимлид изучает задачу и техплан, валидирует техническое решение, оценки, помогает разработчику с задачей.
В какой-то момент я осознал, что этот процесс протекает по-разному у разных тимлидов и жизненно необходимо синхронизироваться. В пятницу с тимлидами собрались и накидали майндмэп этого процесса, адаптировали это под текущие требования и реалии, зафиксировали всё. Уверен, что теперь будет гораздо легче проводить валидацию, а ее результаты будут более единообразными и управляемыми. Другими словами, отлично поработали, соберу из этого еще текстовую памятку, будем становиться лучше )
Это был не совсем обычный формат встречи в рамках нашего TeamLead Club (о нем тоже как-нибудь расскажу). Мы запустили цикл воркшопов (если можно их так назвать), где будем разбирать реальные кейсы из нашей работы. Думаю, что такой подход даст максимум пользы.
P.S. Для нас это был первый опыт такого рода встреч, если и вы хотите достигать на встречах большего, а может быть вообще не знаете, как прийти к желаемому результату, то рекомендую посмотреть здесь — http://facilab.pro, очень полезный ресурс.
#текущее
👍3✍2🔥2🌚1
State of DevOps Russia 2025
На днях вышло большое исследование от Express42 о состоянии DevOps в России в 2025 году. Полную версию можете получить тут — https://devopsrussia.ru/
Я изучил этот документ на 90 страниц и выделил несколько интересных моментов для себя, о них и расскажу.
🧰 Инструменты
В качестве управления конфигурациями подавляющее большинство все еще использует самописные и shell-скрипты, хотя их объем снижается. При этом растет популярность инструментов автоматизации таких как Ansible и Terraform. Мы тоже пользуемся ими.
В качестве CI/CD все чаще используют GitLab CI и Jenkins. Рад, что мы угадали с этим трендом и не придется переезжать в ближайшем будущем. Предположу, что такой тренд связан с растущей популярностью on-premise-решений, всем хочется большей уверенности в завтрашнем дне на фоне ухода зарубежных сервисов и блокировок российских аккаунтов. Об этом говорит и лидерство среди систем контроля версий on-premise GitLab CE.
При этом доля компаний, использующих зарубежные коммерческие сервисы для ведения задач и документации увеличилась. Да, речь тоже о решениях на своих серверах, но, кажется, есть некоторое разочарование в отечественных SaaS-решениях, их доля сократилась. Мы продолжаем пользоваться Yandex Tracker, но для построения полноценной экосистемы требуется большой объем доработок.
Лидером среди «облаков» стал Yandex Cloud, почти половина компаний так или иначе его используют. Второй — Selectel. Оба провайдера — наши технические партнеры, активно пользуемся их услугам.
🔐 Информационная безопасность
Тема архиважная и эта важность растет очень быстро. Даже совсем маленькая компания уже не может игнорировать этот вопрос, особенно в свете новых штрафов за утечки ПД.
Метрики ИБ. Три четверти участников исследования используют метрики ИБ в своей работе, вот топ-4:
- время восстановления после инцидента (Recovery Time Objective);
- количество нарушений политик безопасности (Security Policy Violations);
- количество критических уязвимостей (Critical Vulnerability Count);
- время реагирования на инциденты (Incident Response Time).
Чаще всего инструменты ИБ интегрируются в системы CI/CD, при этом все еще остаются 22% компаний, которые совсем их не используют. Больше половины компаний используют shift left-подход и встраивают проверки безопасности в ранние стадии.
Большая часть опрошенных используют Open Source-решения для ИБ, а главным фактором выбора таких решений являются функциональные возможности инструмента.
Топ сложностей при использовании инструментов ИБ:
- недостаток технической экспертизы у команды внедрения (45,5 %);
- совместимость с существующими системами (42,3 %);
- высокая стоимость (41 %).
🤖 ИИ в работе
Более 75% респондентов так или иначе используют ML/AI-инструменты в своей работе.
Топ направления для использования ИИ в работе:
- автоматическая генерация кода;
- создание документации;
- анализ кода на наличие ошибок;
- автоматическое создание тестовых сценариев;
- аналитика и управление данными;
- анализ кода на наличие уязвимостей.
Пожалуй на этом я закончу. Цели уместить 90 страниц в один пост у меня не было. Если интересно, лучше читать полную версию. Я отметил для себя только самое актуальное. Например, я совсем ничего не написал про DevEx (Developer Experience) или IDP (Internal Development Platform), хотя это в разной степени представлено и у нас.
#TLDR #исследования #обзор
На днях вышло большое исследование от Express42 о состоянии DevOps в России в 2025 году. Полную версию можете получить тут — https://devopsrussia.ru/
Я изучил этот документ на 90 страниц и выделил несколько интересных моментов для себя, о них и расскажу.
Главные выводы коротко:
- эффективность команд выросла;
- ИБ продолжает распространяться;
- фокус на IDP растет, особенно в бигтех;
- ИИ в работе использует большинство;
- переход на российское ПО идет, но достаточно медленно;
- растёт популярность on-premise-решений;
- растет степень автоматизации.
🧰 Инструменты
В качестве управления конфигурациями подавляющее большинство все еще использует самописные и shell-скрипты, хотя их объем снижается. При этом растет популярность инструментов автоматизации таких как Ansible и Terraform. Мы тоже пользуемся ими.
В качестве CI/CD все чаще используют GitLab CI и Jenkins. Рад, что мы угадали с этим трендом и не придется переезжать в ближайшем будущем. Предположу, что такой тренд связан с растущей популярностью on-premise-решений, всем хочется большей уверенности в завтрашнем дне на фоне ухода зарубежных сервисов и блокировок российских аккаунтов. Об этом говорит и лидерство среди систем контроля версий on-premise GitLab CE.
При этом доля компаний, использующих зарубежные коммерческие сервисы для ведения задач и документации увеличилась. Да, речь тоже о решениях на своих серверах, но, кажется, есть некоторое разочарование в отечественных SaaS-решениях, их доля сократилась. Мы продолжаем пользоваться Yandex Tracker, но для построения полноценной экосистемы требуется большой объем доработок.
Лидером среди «облаков» стал Yandex Cloud, почти половина компаний так или иначе его используют. Второй — Selectel. Оба провайдера — наши технические партнеры, активно пользуемся их услугам.
🔐 Информационная безопасность
Тема архиважная и эта важность растет очень быстро. Даже совсем маленькая компания уже не может игнорировать этот вопрос, особенно в свете новых штрафов за утечки ПД.
Метрики ИБ. Три четверти участников исследования используют метрики ИБ в своей работе, вот топ-4:
- время восстановления после инцидента (Recovery Time Objective);
- количество нарушений политик безопасности (Security Policy Violations);
- количество критических уязвимостей (Critical Vulnerability Count);
- время реагирования на инциденты (Incident Response Time).
Чаще всего инструменты ИБ интегрируются в системы CI/CD, при этом все еще остаются 22% компаний, которые совсем их не используют. Больше половины компаний используют shift left-подход и встраивают проверки безопасности в ранние стадии.
Большая часть опрошенных используют Open Source-решения для ИБ, а главным фактором выбора таких решений являются функциональные возможности инструмента.
Топ сложностей при использовании инструментов ИБ:
- недостаток технической экспертизы у команды внедрения (45,5 %);
- совместимость с существующими системами (42,3 %);
- высокая стоимость (41 %).
🤖 ИИ в работе
Более 75% респондентов так или иначе используют ML/AI-инструменты в своей работе.
Топ направления для использования ИИ в работе:
- автоматическая генерация кода;
- создание документации;
- анализ кода на наличие ошибок;
- автоматическое создание тестовых сценариев;
- аналитика и управление данными;
- анализ кода на наличие уязвимостей.
Пожалуй на этом я закончу. Цели уместить 90 страниц в один пост у меня не было. Если интересно, лучше читать полную версию. Я отметил для себя только самое актуальное. Например, я совсем ничего не написал про DevEx (Developer Experience) или IDP (Internal Development Platform), хотя это в разной степени представлено и у нас.
#TLDR #исследования #обзор
🔥5✍1👍1🤯1🌚1👀1
Сегодня будет про доступность сервисов, ЦОДы и «девятки».
Когда обсуждают требования к системе, часто можно услышать от заказчика, что он хочет, чтобы система работала хорошо. Что тут скажешь, нормальное желание, только вот неизмеримое. Сразу возникает вопрос: а что значит «работает хорошо»? Здорово, что уже много всего придумано, можно просто использовать три показателя: SLA, SLO, SLI. Чуть подробнее, что это:
🔹 SLA (Service Level Agreement) — соглашение об уровне сервиса. Пример: «Сервис доступен 99,9% времени».
🔹 SLO (Service Level Objective) — цель доступности. Например: «99,9% запросов выполняются быстрее 100мс». Таких показателей может быть несколько.
🔹 SLI (Service Level Indicator) — конкретный измеряемый показатель. Например: «количество ошибок 5xx», «успешные транзакции».
Хотел поговорить об SLA и невыполнимых обещаниях, которые можно случайно дать. Есть одна приземляющая реальность, о которую разбиваются любые девятки — это доступность ЦОД (центр обработки данных, дата-центр).
🖥 Немного про tier’ы
Все ЦОДы классифицируются по уровню надежности — Tier (классификация Uptime Institute). Всего бывает четыре уровня:
🔸 Tier I — базовый уровень, доступность 99.671% или простой до 28.8 часов в год;
🔸 Tier II — с резервированием критических компонентов, доступность 99.749% или простой в год до 22 часов;
🔸 Tier III — с обеспечением непрерывности обслуживания, доступность 99.982% или простой до 1.6 часов в год;
🔸 Tier IV — максимальная отказоустойчивость, доступность 99.995% или простой максимум 26 минут в год.
Знаете, сколько ЦОД уровня Tier IV в мире есть прямо сейчас? Около 50 штук, а в России в 2024 году был открыт первый — «Москва-2» (почитать о нем можно здесь).
UPD. Спасибо коллегам за уточнение в комментах, таких влияний на доступность системы может быть огромное множество и я привел пример лишь одной из них.
#полезное
Когда обсуждают требования к системе, часто можно услышать от заказчика, что он хочет, чтобы система работала хорошо. Что тут скажешь, нормальное желание, только вот неизмеримое. Сразу возникает вопрос: а что значит «работает хорошо»? Здорово, что уже много всего придумано, можно просто использовать три показателя: SLA, SLO, SLI. Чуть подробнее, что это:
🔹 SLA (Service Level Agreement) — соглашение об уровне сервиса. Пример: «Сервис доступен 99,9% времени».
🔹 SLO (Service Level Objective) — цель доступности. Например: «99,9% запросов выполняются быстрее 100мс». Таких показателей может быть несколько.
🔹 SLI (Service Level Indicator) — конкретный измеряемый показатель. Например: «количество ошибок 5xx», «успешные транзакции».
Хотел поговорить об SLA и невыполнимых обещаниях, которые можно случайно дать. Есть одна приземляющая реальность, о которую разбиваются любые девятки — это доступность ЦОД (центр обработки данных, дата-центр).
Все ЦОДы классифицируются по уровню надежности — Tier (классификация Uptime Institute). Всего бывает четыре уровня:
🔸 Tier I — базовый уровень, доступность 99.671% или простой до 28.8 часов в год;
🔸 Tier II — с резервированием критических компонентов, доступность 99.749% или простой в год до 22 часов;
🔸 Tier III — с обеспечением непрерывности обслуживания, доступность 99.982% или простой до 1.6 часов в год;
🔸 Tier IV — максимальная отказоустойчивость, доступность 99.995% или простой максимум 26 минут в год.
Знаете, сколько ЦОД уровня Tier IV в мире есть прямо сейчас? Около 50 штук, а в России в 2024 году был открыт первый — «Москва-2» (почитать о нем можно здесь).
Мысль проста: если ваш сервис живёт в одном ЦОД, вы физически не можете честно заявлять доступность выше, чем уровень доступности этого ЦОД. Просто помните об этом, когда обещаете такие показатели.
UPD. Спасибо коллегам за уточнение в комментах, таких влияний на доступность системы может быть огромное множество и я привел пример лишь одной из них.
#полезное
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥3🤔2🤩1🌚1
Вчера с «сообщниками» обсудили стратегию. Начали с осознания того, а что вообще такое стратегия, каждый внутри компании воспринимает это понятие по своему. Кто-то представляет себе документ на 50 слайдов, кто-то — набор OKR, кто-то — просто «куда мы вообще идём». Оказалось, что сформулировать определение для этого понятия весьма непросто. Очень сильно влияет прошлый опыт: в каких компаниях ты работал, что там называли стратегией и была ли она вообще. Я для себя заметил любопытную зависимость: чем крупнее компания, тем шире и многослойнее у людей представление о стратегии.
Здорово, что получилось обсудить и усреднить наш опыт. Надеюсь, теперь будет меньше сложностей, когда я соберусь готовить стратегию. Оказалось, что нередко от руководителей среднего звена хотят в каком-то виде стратегию, при этом не дав более верхнеуровневое понимание. Правда такой запрос, как показалось, есть только в достаточно больших компаниях. Вероятно это связано с тем, что стратегия компании глобально определена (не думаю, что Яндекс живет без нее).
При подготовке к обсуждению ребята поделились интересной статьей о стратегических фокусах, а я принесу ее вам — https://agile-organizations.ru/tpost/ed4892gim1-ierarhiya-strategicheskih-fokusov-kak-vi Не важно, работаете вы в IT или производите корм для животных, это может быть интересно и полезно.
#текущее
Здорово, что получилось обсудить и усреднить наш опыт. Надеюсь, теперь будет меньше сложностей, когда я соберусь готовить стратегию. Оказалось, что нередко от руководителей среднего звена хотят в каком-то виде стратегию, при этом не дав более верхнеуровневое понимание. Правда такой запрос, как показалось, есть только в достаточно больших компаниях. Вероятно это связано с тем, что стратегия компании глобально определена (не думаю, что Яндекс живет без нее).
При подготовке к обсуждению ребята поделились интересной статьей о стратегических фокусах, а я принесу ее вам — https://agile-organizations.ru/tpost/ed4892gim1-ierarhiya-strategicheskih-fokusov-kak-vi Не важно, работаете вы в IT или производите корм для животных, это может быть интересно и полезно.
#текущее
👍2🤔2🌚1💯1
Я всегда проектировал архитектуру решений у нас в компании. Считал себя таким архитектором-любителем. На предыдущем месте работы, по воле случая мне в прямое подчинение достались архитектор и несколько DBA. Тогда работа с такими специалистами для меня была в новинку, я о таких единорогах читал только в книгах, поэтому внимательно следил за всем, что они делают и немного изучал теорию. Позже, я тоже принимал участие в проектировании архитектуры и валидации отрисованных схем. Сейчас я снова проектирую сам или помогаю лидам проектировать решения. Недавно, кстати, мы перешли на отрисовку схем по стандарту C4, но об этом в другой раз.
Так вот, я вписался принять участие в архитектурной ката. Термин необычный, архитектурные ката — это групповые упражнения, которые помогают развивать навыки проектирования систем. Слово ката из японского языка, по сути это приём, который ученики отрабатывают, повторяя его многократно. Архитектурные ката возникли из-за простого желания: архитекторам программного обеспечения нужно попрактиковаться в разработке архитектур ПО, а такое случается очень редко. Проектирование архитектуры системы относительно общего цикла производства ПО это очень маленькая часть: быстрый цикл проектирования и очень долгий цикл разработки. Поэтому практики и не хватает.
Так вот, в середине декабря соберемся с ребятами из разных компаний в команды и будем соревноваться в проектировании архитектур. Устроено все примерно так: собираемся, организатор приносит задачу, мы проектируем архитектуру, слои сервисов и инфраструктуры (делаем свои ката), потом защищаем. Далее этап оценки получившейся архитектуры экспертом.
Я все же считаю себя дилетантом в этом вопросе, но ребята сказали, что так даже лучше — большему научишься :) Что ж, посмотрим, потом расскажу, как прошло.
Так вот, я вписался принять участие в архитектурной ката. Термин необычный, архитектурные ката — это групповые упражнения, которые помогают развивать навыки проектирования систем. Слово ката из японского языка, по сути это приём, который ученики отрабатывают, повторяя его многократно. Архитектурные ката возникли из-за простого желания: архитекторам программного обеспечения нужно попрактиковаться в разработке архитектур ПО, а такое случается очень редко. Проектирование архитектуры системы относительно общего цикла производства ПО это очень маленькая часть: быстрый цикл проектирования и очень долгий цикл разработки. Поэтому практики и не хватает.
Так вот, в середине декабря соберемся с ребятами из разных компаний в команды и будем соревноваться в проектировании архитектур. Устроено все примерно так: собираемся, организатор приносит задачу, мы проектируем архитектуру, слои сервисов и инфраструктуры (делаем свои ката), потом защищаем. Далее этап оценки получившейся архитектуры экспертом.
Я все же считаю себя дилетантом в этом вопросе, но ребята сказали, что так даже лучше — большему научишься :) Что ж, посмотрим, потом расскажу, как прошло.
🔥7👍4🤩2😎1
В пятницу проходила церемония награждения Tagline Awards, где наша компания представляла несколько работ. Больше всего я конечно ждал результатов в номинации «Лучшая работа с highload». Мы уже брали серебро в highload с другим проектом, тем не менее, я был уверен, что в этом году мы должны войти в тройку.
Мы сделали очень крутой проект. Может быть по общепринятым меркам мирового highload цифры и не впечатляющие, но для интернет-магазина небольшого производства игрушек всё более чем серьезно: около 4500 RPS, до 2000 заказов за 5-7 секунд, время формирования ответа бэкенда при этом до 70мс. Учитывая особенности и ограничения проекта, это просто героические цифры. Я очень горжусь ребятами, которые работали над этим проектом.
Про сам проект и технические детали я расскажу в другой раз, сегодня про признание в отрасли. Итак, мы взяли бронзу! Это отличный результат! Я очень рад, что такую классную работу оценили по достоинству. Если кто-то из причастных читает это, знайте — вы крутые спецы и доказали это всем. Уверен, это далеко не предел!
Мы сделали очень крутой проект. Может быть по общепринятым меркам мирового highload цифры и не впечатляющие, но для интернет-магазина небольшого производства игрушек всё более чем серьезно: около 4500 RPS, до 2000 заказов за 5-7 секунд, время формирования ответа бэкенда при этом до 70мс. Учитывая особенности и ограничения проекта, это просто героические цифры. Я очень горжусь ребятами, которые работали над этим проектом.
Про сам проект и технические детали я расскажу в другой раз, сегодня про признание в отрасли. Итак, мы взяли бронзу! Это отличный результат! Я очень рад, что такую классную работу оценили по достоинству. Если кто-то из причастных читает это, знайте — вы крутые спецы и доказали это всем. Уверен, это далеко не предел!
🔥9👏8🏆6❤2
Карьерное планирование
Увы, архитектурная ката была перенесена из-за форс-мажора, но на этой неделе оставалась еще одна интересная встреча — карьерное планирование 2026. Встречу вела София Андрикова, сертифицированный Executive и Карьерный коуч ICF, эксперт по оценке Hogan, BasePro, DISC&DF.
Честно говоря, помимо полезных материалов, рабочих инструментов и подходов, которые теперь остались со мной и, уверен, помогут мне в планировании следующего года и не только, я совершенно под другим углом посмотрел на себя и свои профессиональные качества. Подробностей не будет, мне самому нужно еще подумать об этом.
Еще оказалось весьма непросто описать самого себя. Мне повезло и в практической работе в парах мне досталась сама София. Разобрали, как это делать правильно. Самое полезное конечно — взгляд со стороны, особенно, когда помогает профи.
В целом для себя отметил, что многие не задумываются о том, куда они собираются прийти в карьерном плане. Параллельно вчерашней встрече, эта тема всплыла и в книге, которую я сейчас читаю/слушаю. Но в книге эта тема раскрывается со стороны руководителя, который помогает своим сотрудникам двигаться в важном для них направлении. Есть над чем подумать и здесь.
Увы, архитектурная ката была перенесена из-за форс-мажора, но на этой неделе оставалась еще одна интересная встреча — карьерное планирование 2026. Встречу вела София Андрикова, сертифицированный Executive и Карьерный коуч ICF, эксперт по оценке Hogan, BasePro, DISC&DF.
Честно говоря, помимо полезных материалов, рабочих инструментов и подходов, которые теперь остались со мной и, уверен, помогут мне в планировании следующего года и не только, я совершенно под другим углом посмотрел на себя и свои профессиональные качества. Подробностей не будет, мне самому нужно еще подумать об этом.
Еще оказалось весьма непросто описать самого себя. Мне повезло и в практической работе в парах мне досталась сама София. Разобрали, как это делать правильно. Самое полезное конечно — взгляд со стороны, особенно, когда помогает профи.
В целом для себя отметил, что многие не задумываются о том, куда они собираются прийти в карьерном плане. Параллельно вчерашней встрече, эта тема всплыла и в книге, которую я сейчас читаю/слушаю. Но в книге эта тема раскрывается со стороны руководителя, который помогает своим сотрудникам двигаться в важном для них направлении. Есть над чем подумать и здесь.
👍3🤔3🏆2
Понемногу выходим из праздничного анабиоза.
В преддверии Нового года был на встрече с коллегами, где мы играли в «Новогодний свояк» — аналог своей игры, только вместо ответов на вопросы нужно было рассказывать истории из своей профессиональной деятельности на выбранную тему и ситуацию.
До меня наконец доехал подарок за мои истории ) Полистал, это будет интересно. Может еще расскажу об этой книге.
В преддверии Нового года был на встрече с коллегами, где мы играли в «Новогодний свояк» — аналог своей игры, только вместо ответов на вопросы нужно было рассказывать истории из своей профессиональной деятельности на выбранную тему и ситуацию.
До меня наконец доехал подарок за мои истории ) Полистал, это будет интересно. Может еще расскажу об этой книге.
👍5🔥3⚡2
Много сказано про рынок труда в IT для разработчика. Если коротко — сейчас не лучшие времена. Но пока ни разу не встречал материалов на тему рынка для руководителей. Вчера был на встрече с Верой Маневич, HRD Ozon Tech. Обсуждали ситуацию на рынке труда в IT в целом и в частности затронули тренды рынка труда для руководителей. Простите, получился лонгрид, TL;DR )
Общая обстановка
В нашей стране сфера руководителей не так хорошо развита как сфера инженеров. Индустрия не успевает готовить качественных вождей, обычно просто ставят тех, кто хотя бы «говорит не заикаясь». Если вспоминать то, что последние несколько лет происходило на рынке труда: был период, когда все нанимали, потом все сокращали. Сейчас ситуация неоднозначна и очень зависит от компании — кто-то нанимает, кто-то сокращает, кто-то набирает стажеров. Вера говорит, и я соглашусь с этим, что для руководителей стресс в такой ситуации еще выше, чем для инженеров: часто совершенно не ясно, что будет дальше. Что удивительно, такая тенденция наблюдается по всему миру, а не только у нас. Наверное у нас осложняется экономическими факторами, но все же.
Еще одно открытие: C-level руководителей на рынке сейчас переизбыток. Они обучились, купили консалтинг, платят коучам, упаковались и пытаются себя продавать. Правда обычно спецы такого уровня не ходят по рынку в поисках, они переходят из одной компании в другую.
Если говорить о мидлменеджерах, то ситуация с наймом их извне прежняя: они хуже приживаются с рынка, в отличии от инженеров, поэтому был и есть тренд растить их внутри, как следствие таких вакансий достаточно мало.
Тренды
Дисклеймер: это уже обсуждается или внедряется у зарубежных коллег, у нас тоже может быть, но это не точно. И еще — размер компании имеет значение, это нужно учитывать.
🍀 AI. Вроде бы ворвался стремительно, но никому не ясно, как все же с этим быть, эффективно это или нет. В любом случае, руководителю надо об этом думать, надо использовать и точечно внедрять. Интересная история о Netflix из первых уст. При внедрении ИИ они начали с легализации его в компании и сокращении непонимания политики компании — проговорили моменты по использованию, чтобы люди не думали, что их уволят, если они не будут использовать ИИ. Но стоить помнить, «обмазывание» ИИ без повода это булшит.
🍀 Возвраты в офис. Тренд зарубежный, но там возник из-за того, что собственники бизнеса и владельцы помещений одни и те же люди, им это просто приносит деньги. Но при этом офис определенно создает некую «магию» и бывает эффективней удаленной коммуникации. Неуправляемая (важно, именно неуправляемая) удаленка равна карантину у школьников дома, так что в этом вопросе нужны правила и контроль. При этом маленькие компании такие условия диктовать не могут (строгий возврат в офис), т.к. это их конкурентное преимущество перед бигтехами, конкурировать по финансам возможности нет.
🍀 Руководитель-технарь. Любой руководитель должен быть технарем, а уже потом руководителем. Надо разбираться в архитектуре, понимать технику и т.д. Считается, что команды под управлением таких руков быстрее двигаются вперед. Главный совет: не надо писать код, если ты сильный руководитель, такое нужно не всегда и не всем. Лучше искать компанию, где будут требоваться именно управленческие навыки.
🍀 Управление скоростью. Это самый призрачный тренд, но он существует. Скорость — это стратегическое преимущество. Скорость принятия решений часто медленнее скорости разработки. Надо убирать барьеры и бюрократию. Ситуация еще хуже, чем с ИИ, ни у кого нет понимания, как это сделать, как управлять скоростью.
🍀 Меньшие, но более профессиональные команды. Крупные компании делают ставки на более сильных спецов. Пусть их будем меньше в количестве, но они сделают тот же объем работы быстрее, чем большая по численности команда из менее квалифицированных специалистов.
Главный вывод — продолжайте учиться и развиваться и тогда у вас все будет хорошо (думаю, что если вы в ИТ, то у вас нет проблем с саморазвитием). «Любой умный образованный человек работу обязательно найдет».
Общая обстановка
В нашей стране сфера руководителей не так хорошо развита как сфера инженеров. Индустрия не успевает готовить качественных вождей, обычно просто ставят тех, кто хотя бы «говорит не заикаясь». Если вспоминать то, что последние несколько лет происходило на рынке труда: был период, когда все нанимали, потом все сокращали. Сейчас ситуация неоднозначна и очень зависит от компании — кто-то нанимает, кто-то сокращает, кто-то набирает стажеров. Вера говорит, и я соглашусь с этим, что для руководителей стресс в такой ситуации еще выше, чем для инженеров: часто совершенно не ясно, что будет дальше. Что удивительно, такая тенденция наблюдается по всему миру, а не только у нас. Наверное у нас осложняется экономическими факторами, но все же.
Еще одно открытие: C-level руководителей на рынке сейчас переизбыток. Они обучились, купили консалтинг, платят коучам, упаковались и пытаются себя продавать. Правда обычно спецы такого уровня не ходят по рынку в поисках, они переходят из одной компании в другую.
Если говорить о мидлменеджерах, то ситуация с наймом их извне прежняя: они хуже приживаются с рынка, в отличии от инженеров, поэтому был и есть тренд растить их внутри, как следствие таких вакансий достаточно мало.
Тренды
Дисклеймер: это уже обсуждается или внедряется у зарубежных коллег, у нас тоже может быть, но это не точно. И еще — размер компании имеет значение, это нужно учитывать.
Главный вывод — продолжайте учиться и развиваться и тогда у вас все будет хорошо (думаю, что если вы в ИТ, то у вас нет проблем с саморазвитием). «Любой умный образованный человек работу обязательно найдет».
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥3🤔1🌚1💯1👨💻1
Сегодня буду впервые принимать участие в книжном клубе. Обсуждать будем книгу «Эффективный конфликт. Как защищать интересы и управлять сложной коммуникацией» авторов Александры Клименко, Юрия Клименко, Михаила Ромашова.
Уверен, что не в каждом книжном клубе удается обсудить книгу вместе с автором. Сегодня как раз такой день, Александра Клименко будет вместе с нами и можно будет из первых уст получить ответы на вопросы. Обсудить известную книгу с автором, это очень круто. Честно говоря, я даже немного взволнован😛
Есть правда небольшая проблема — с момента прочтения книги я успел прочесть еще три. Впечатления и мысли немного «перемешались». Постараюсь успеть подготовиться. Ну и о самой встрече расскажу, если будет интересно.
Ссылка на аудиоверсию книги
Уверен, что не в каждом книжном клубе удается обсудить книгу вместе с автором. Сегодня как раз такой день, Александра Клименко будет вместе с нами и можно будет из первых уст получить ответы на вопросы. Обсудить известную книгу с автором, это очень круто. Честно говоря, я даже немного взволнован
Есть правда небольшая проблема — с момента прочтения книги я успел прочесть еще три. Впечатления и мысли немного «перемешались». Постараюсь успеть подготовиться. Ну и о самой встрече расскажу, если будет интересно.
Ссылка на аудиоверсию книги
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥4👏2🆒2❤1🤔1
Сегодня компании, в которой я начинал как руководитель и работаю до сих пор, 12 лет!
Все 12 лет я был ее частью, частью чего-то меняющегося и растущего, взрослеющего и строгого, доброго и веселого, невероятно профессионального, поддерживающего и всегда очень разного. И это отлично!
Открою главную тайну: в какой-то момент я ушел из компании, но спустя полгода вернулся. А вернулся я к людям, которые здесь работают! Это не для красного словца, чистая правда!
Что ж, поздравляю Braind с днем рожденья! Многая лета! Окунулся в прорубь сегодня за ваше здоровье! 🥂
Все 12 лет я был ее частью, частью чего-то меняющегося и растущего, взрослеющего и строгого, доброго и веселого, невероятно профессионального, поддерживающего и всегда очень разного. И это отлично!
Открою главную тайну: в какой-то момент я ушел из компании, но спустя полгода вернулся. А вернулся я к людям, которые здесь работают! Это не для красного словца, чистая правда!
Что ж, поздравляю Braind с днем рожденья! Многая лета! Окунулся в прорубь сегодня за ваше здоровье! 🥂
❤8👍5👏4🍾3