Это лонг рид для b2b продактов о том, что делать для успешной работы sales driven в продукте. Собрала все используемые материалы в самый полный гайд по теме. И даже ничего не продаю.

Про Gherkin слышали в основном те, кто связан с тестированием. Среди аналитиков он встречается крайне редко. Но если отбросить всё связанное с BDD и тестами, то Gherkin это формат описания поведения системы, где сценарий это обычный текст, написанный в структурированном виде “Given‑When‑Then”. Не код, не диаграмма, а короткое текстовое описание того, что происходит в системе в определённых условиях.

Не потому что модно, не потому что “так надо”, а потому что это удобно. Можно описать фактически всё: контекст, событие, результат - в трёх строках. Удивительно, что это не стало стандартом. Но как это работает на практике? Чтож… Щас выскажусь!

С ростом популярности Kubernetes все больше компаний стремятся использовать его для облегчения управления контейнеризованными приложениями. Вместе с этой тенденцией наблюдается рост числа незащищенных (или неправильно сконфигурированных) кластеров, имеющих прямой доступ в интернет. Это создает большие риски для безопасности, поскольку такие кластеры могут быть обнаружены с использованием поисковых сайтов и атакованы злоумышленниками.

В статье рассмотрим базовые концепции мониторинга и обеспечения безопасности кластера Kubernetes, поговорим о распространенных векторах атак, а также разберем способы их обнаружения и метрики, которые в этом помогут.

Мы начинали с обычного ELK-стека, логи приходили на logstash, записывались в Elasticsearch, а пользователи смотрели их в Kibana. Потом в эту схему добавилась Kafka, так как мы понимали, что на пиках нагрузок не успеваем записать все логи в Elasticsearch. Всё это располагалось в одном ЦОДе, а в Kafka была единая очередь. В результате горизонтального масштабирования Elasticsearch разросся до 30+ нод. Данная схема справлялась с нагрузкой в 100 тысяч документов в секунду.

Как вы понимаете, эта схема нас устраивала только до определённого периода. В какой-то момент нагрузка начала расти как на дрожжах.

Привет, Хабр! На связи Филипп Бочаров, руководитель платформы наблюдаемости и мониторинга для более 400 продуктов экосистемы МТС, и Юлия Тальцкова, ведущий инженер сервиса логирования и кластеров Open Search с более 400 терабайтами логов клиентов. Этот материал написан на основе нашего доклада для конференции Highload++

Расскажем, как нам удалось переписать критичный и высоконагруженный сервис логирования, перестать просыпаться от ночных звонков и даже иногда уходить в отпуск.

Управление Kubernetes в продакшене требует внимательности и соблюдения лучших инженерных практик, особенно в масштабных средах. В этой статье мы собрали основные принципы эксплуатации, которые помогут избежать распространённых проблем, повысить стабильность и минимизировать сложность работы с Kubernetes. Вы узнаете о важнейших аспектах, таких как управление ресурсами, настройка высокой доступности, мониторинг, автоматизация через GitOps и оптимизация затрат — всё это позволяет эффективно управлять инфраструктурой, снижая риски и улучшая производительность.

Привет! Меня зовут Егор Стремоусов, я тимлид команды продуктовых дизайнеров платформы TWork Обслуживания в Т-Банке. Расскажу, как моя команда повысила предсказуемость поставки дизайн-задач, какие методы и инструменты мы для этого использовали.

Про информационную безопасность Kubernetes-кластеров много пишут с позиции специалистов ИБ. Но полезно взглянуть на эту тему глазами обычных пользователей K8s — инженеров и разработчиков. Тех, кто много работает со своими приложениями в подах, но не управляет служебными частями кластера.

Большинство стандартов безопасности описывает лучшие практики настройки управляющих компонентов — control plane. Нечасто встречаются рекомендации по грамотной настройке рабочих единиц — подов. В статье попробуем восполнить этот пробел. Выполним обзор источников, рассмотрим хорошие практики работы с образами. Изучим, как ограничить привилегии контейнера и почему это важно. Поговорим о инструментах автоматической проверки манифестов и разберем примеры GItlab CI пайпланов.

Мы начинаем цикл статей про настройку правил WAF (Web application firewall): поделимся хитростями и неочевидными способами настройки WAF для борьбы с некоторыми веб-атаками. И наша первая тема: манипуляция с заголовками ответа. Сразу стоит заметить, что управлять заголовками ответа чаще всего приходится через конфиг веб-сервера и очень многие DevOps инженеры сочтут странным использование для этого WAF, ведь конфигурация как бы «размазывается» между несколькими сущностями... Но через WAF делать настройку может оказаться даже удобнее - давайте проверим это вместе.

Ситуация, знакомая многим: разрабатываем сервис, пилим в нём фичи, развиваем продукт… но постепенно всё выходит из под контроля. Кодовая база разрастается, зависимости становятся сложнее. Команда разработчиков тратит больше времени на распутывание существующих проблем, чем на создание новой функциональности.

Хорошая новость: распутать спагетти-код можно по-разному, и иногда срабатывают не самые очевидные способы. В нашем случае помогла комбинация действий: не просто выделение части кода в отдельные микросервисы, но и параллельная реализация архитектурного подхода DDD Lite (в связке с принципами чистой архитектуры).

О том, как в рамках кейса мы избавились от спагетти-зависимостей, поделили сервис на чёткие слои, упростили поддержку и масштабирование кода, — рассказываем под катом. Плюс делимся рекомендациями: кому и при каких сценариях связка «DDD Lite + микросервисы» может пригодиться.

На нодах доступа где наши клиенты создают туннели, для терминации HTTP трафика сейчас мы используем Traefik. Недавно мы столкнулись с проблемой, когда на 1 из доменов приходили тысячи запросов в секунду, и web server уходил в полку по CPU, страдал весь клиентский трафик на ноде в данном регионе, а пользователи жаловались на зависания и таймауты. Это история как мы внедрили fail2ban для блокировки ddos флуда по access логам.

В последние 1-1,5 месяца я просматриваю вакансии, оставляю отклики, посещаю собеседования (да, я решил найти новое дело) и заметил неприятную закономерность — примерно 7 из 10 вакансий с названием “Менеджер проекта в … сфере” по факту ищут SM или универсального солдата с функциями SM + PO + PdM. В одном случае нужен человек, который будет настраивать автоматизацию в Jira и писать JQL-запросы — по сути, Scrum Master с технической прожаркой. В другом — Product Owner уже есть, бэклог он ведёт сам, внешние коммуникации на нём, а от кандидата хотят фасилитации и контроля спринтов. Вакансия — PM, реальность — совсем другое. В итоге обе стороны теряют по паре часов на собеседование, не получая ничего, кроме вежливого «мы подумаем».

Почему же важно чётко разграничивать роли менеджеров проектов, скрам-мастеров, владельцев продукта и менеджеров продукта? Как смешение этих ролей бьёт по команде и проекту? И что делать, чтобы навести порядок? Давайте разбираться на инженерном уровне — без воды, но с иронией. Куда ж без неё, когда и в резюме у кандидатов честно написано «Scrum Master / Product Manager, 5 лет опыта».

В сети интернет достаточно информации на русском языке по поводу SOP и CORS, но введение в такие технологии как CORP, COEP и COOP показалось недостаточным (а кто-то может видеть эти аббревиатуры впервые). Поэтому решил написать статью по знакомству с cross-origin политиками.

Структура кода — это не просто способ организации файлов и папок в проекте, это фундаментальный аспект разработки, который влияет на её эффективность, качество, и долгосрочную поддержку. Красиво организованный код облегчает понимание, упрощает внедрение новых функций и снижает вероятность ошибок. Независимо от масштаба проекта, будь то небольшое приложение или сложная система, структурированный подход к организации кода способствует снижению рисков, связанных с техническим долгом, и повышает продуктивность команды разработчиков. Однако не все разработчики осознают, насколько велика разница между проектами с хорошо продуманной структурой и хаотично организованной.

В этой статье мы разберём, что значит «понятная структура кода», и почему её наличие столь важно для успешной разработки.

Привет! Меня зовут Павел Лукьянов, я заместитель CTO в AGIMA. На одной из прошлых работ мы с ребятами попробовали внедрить так называемую чистую архитектуру на монолитном проекте. И это был интригующий опыт. Во-первых, мы начали намного рациональнее подходить к оценке задач. Во-вторых, заметно сократили time-to-market. А в-третьих, сильно разозлили наших аналитиков. Считаю, такими впечатляющими результатами стоит делиться.

Как определить, насколько глубоко на старте проекта надо продумывать его архитектуру? И на чем стоит сфокусироваться сразу, чтобы ее пришлось переделывать в процессе? В своё время, вдохновленный книгой «Принципы» Рэя Далио, я попробовал вывести основные подходы к IT-архитектуре, которые теперь сам активно применяю в работе на старте проектов. О них сегодня и расскажу, чтобы помочь начинающим архитекторам ПО.

Это в какой-то степени продолжение моей статьи — История создания идеального Docker для Laravel. В ней я рассказывал о том, как собрал идеальный Docker-образ для Laravel с Nginx Unit. Это был один из первых шагов по оптимизации моей инфраструктуры. Как я уже упоминал, у меня есть несколько pet-проектов, запущенных на VPS в docker-compose, и я хотел не только отслеживать их состояние, но и прокачать навыки в области Observability.

В любой продуктовой команде существует огромное количество метрик: от DAU/MAU и Retention до NPS, LTV, CAC и Conversion Rate. Без четкой структуры работа с ними превращается в хаос: команда следит за десятками показателей, но не понимает, какие из них действительно влияют на бизнес‑цели.

Дерево метрик помогает решить эту проблему, превращая разрозненные данные в логичную систему, где каждая метрика связана с конечной целью компании. Это инструмент, который делает управление метриками осмысленным, помогает продакту ставить приоритеты и находить точки роста продукта. В этой статье разберем:

- Что такое дерево метрик и как его построить?
- Когда оно необходимо?
- Как построить дерево метрик: пошаговое руководство
- Как правильно использовать дерево метрик в работе?

Представьте ситуацию: вы исследуете клиентский опыт, никого не трогаете и тут вас просят оценить, насколько участники IT-команды довольны инструментами Data Platform. Метрик вам, кстати, не дают — их вы должны выделить сами.

Случалось в вами такое? Со мной — да. Меня зовут Рамиля, я — лидер маркетинговых исследований в Додо. Сегодня расскажу, как оценить удовлетворённость сотрудников дата-инфраструктурой. Ну и гайдом обязательно поделюсь!