Привет!
Я — Денис Казимиров, я руковожу 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