MiddlePerformance Marketer > Google Ads > Аудитории и ретаргетинг
Короткий ответ Сначала нужно проверить качество и размер seed-аудитории (сколько реальных покупателей, а не всех посетителей, попало в список, и насколько они однородны по ценности), затем — не находится ли сам ad set ещё в фазе обучения, и только потом пересматривать проценты similarity или объединять источники для лучшего сигнала. Как это работает подробнее Качество look-alike прямо зависит от качества seed: если в исходный список попали случайные посетители или разовые промо-покупатели наряду с постоянными клиентами, алгоритм обучается на смешанном и менее информативном сигнале, что снижает точность похожей аудитории. Что использовать на практике На практике. Полезно пересобрать seed только из покупателей с высокой ценностью за репрезентативный период (например, 90-180 дней), проверить его размер (не менее нескольких сотен-тысяч), сравнить результат look-alike 1% против более широкого 3-5% для понимания, не является ли аудитория 1% слишком узкой и уже частично исчерпанной. Пример. Текущий seed — все посети
ad-platformsaudience-targeting
SeniorData Analyst > SQL и данные > Продуктовые и бизнес-метрики Короткий ответ Единого рецепта против закона Гудхарта ("метрика, ставшая целью, перестаёт быть хорошей метрикой") нет — обычно нужна комбинация guardrail-метрик, периодического пересмотра определения NSM, качественной проверки (например, пользовательских интервью) и явного культурного сигнала от руководства, что "игра с метрикой" недопустима даже при формальном выполнении цели. Как это работает подробнее локальная оптимизация NSM возникает, когда команда находит способ формально увеличить метрику без создания реальной ценности (например, рассылка push-уведомлений ради краткосрочного роста "активных сессий" в счёт NSM); чем конкретнее и легче манипулируемой является метрика, тем выше риск такого поведения. Команда роста добилась увеличения NSM "число активных сессий в неделю" через агрессивные авто-воспроизведения контента, не требующие осознанного действия пользователя. После добавления guardrail "доля сессий с осознанным взаимодействием (клик/лайк/ответ) от общего числа сессий" стало видно, что эта доля упал
goodharts-lawguardrails
MiddleDevOps Engineer > Контейнеры и доставка > Infrastructure as Code и управление конфигурацией Короткий ответ Strategic merge patch (patches с фрагментом YAML того же вида, что целевой ресурс) объединяется с базовым манифестом по известным Kubernetes-правилам слияния полей, и если в патче допущена ошибка — неверный kind/name/apiVersion для таргетинга ресурса, или патч описан как часть списка без совпадающего селектора, — Kustomize может просто не найти, к какому ресурсу применить патч, и тихо его пропустить; JSON6902 patch (patches с target + списком операций op/path/value) применяется по точному JSON-пути, и ошибка в path (например, неверный индекс массива контейнеров) приведёт либо к явной ошибке, либо к применению не туда, куда ожидалось — для диагностики нужно запускать kustomize build локально и явно сверять итоговый YAML, а не полагаться только на применение в кластер. Как это работает подробнее strategic merge patch требует, чтобы верхнеуровневые поля-идентификаторы (apiVersion, kind, metadata.name) в файле патча точно совпадали с таргетируемым ресурсом — Kustomize ищет ресурс по этим полям и сл
configuration-managementenvironment-management
MiddleDevOps Engineer > Контейнеры и доставка > Infrastructure as Code и управление конфигурацией Короткий ответ gather_facts: true (по умолчанию) заставляет Ansible перед выполнением задач подключиться к каждому хосту и собрать факты через модуль setup (информация об ОС, сети, дисках и т.п.), что при сотнях хостов создаёт заметную задержку на каждый прогон; ускорить повторные запуски можно включив fact caching (например, backend jsonfile или redis в ansible.cfg) с разумным fact_caching_timeout, либо собирая факты один раз в отдельном playbook и переиспользуя кэш в последующих прогонах, не опрашивая все хосты заново при каждом плейбуке. Как это работает подробнее модуль setup выполняется на каждом целевом хосте при первом обращении к play, если gather_facts не выключен, и результат живёт в памяти текущего процесса ansible-playbook; при включённом fact caching Ansible дополнительно сохраняет собранные факты во внешнее хранилище (файл/Redis/Memcached) с TTL, и при следующих запусках (если TTL не истёк) не переопрашивает хост заново, а берёт факты из кэша, экономя время на сетевое подключение и выполнение мо
ansibleconfiguration-management
MiddleDevOps Engineer > Контейнеры и доставка > Infrastructure as Code и управление конфигурацией Короткий ответ Нужно смотреть вывод ansible-playbook с -v: для каждой итерации цикла Ansible печатает результат с ключом item, что сразу показывает, на каком элементе списка и на каком хосте произошёл сбой; чтобы ошибка на одном хосте не останавливала выполнение задачи на остальных хостах, используется ignore_errors: true в сочетании с явной проверкой результата (register + последующий when: result is failed) или стратегия free вместо linear, а для одного «плохого» элемента внутри списка — loop_control: { label: "{{ item }}" } для читаемости и, при необходимости, отдельная задача-обработчик неудачных элементов. Как это работает подробнее при linear strategy (дефолтной) Ansible выполняет задачу на всех хостах пакетного батча параллельно, но следующая задача не начнётся, пока предыдущая не завершится на всех хостах; при ошибке без ignore_errors хост, на котором она произошла, исключается из дальнейшего выполнения плейбука (хотя другие хосты батча продолжают текущую задачу), а loop внутри задачи выполняется посл
ansibleconfiguration-management
MiddleDevOps Engineer > Контейнеры и доставка > Infrastructure as Code и управление конфигурацией Короткий ответ Ключевые параметры — forks (сколько хостов обрабатывается параллельно за раз, по умолчанию всего 5, что при 400 хостах означает 80 последовательных батчей), pipelining (отключает отдельную передачу модуля файлом по SSH, уменьшая число SSH-подключений на задачу) и strategy (дефолтная linear ждёт завершения задачи на всех хостах батча перед следующей задачей, тогда как free позволяет каждому хосту идти по плейбуку в своём темпе); диагностировать узкое место помогает профилирование через ANSIBLE_CALLBACKS_ENABLED=timer,profile_tasks или встроенный плагин profile_tasks, который показывает время каждой задачи и помогает понять, SSH-overhead это или реально долгая задача. Как это работает подробнее при forks = 5 Ansible делит 400 хостов на 80 последовательных групп по 5, и каждая задача внутри плейбука выполняется этими батчами, так что даже быстрая задача (1 секунда на хосте) на 400 хостах с такими forks растягивается на значимое время просто из-за количества батчей; pipelining убирает лишний шаг ко
ansibleconfiguration-management
MiddleDevOps Engineer > Контейнеры и доставка > Kubernetes и оркестрация Короткий ответ Кроме явной нехватки CPU/памяти, нужно проверить: taints на узлах без соответствующих tolerations у Pod, несовместимые nodeAffinity/nodeSelector требования, превышение ResourceQuota в namespace, нехватку доступных IP-адресов в сети подов, и недоступность запрошенного PersistentVolume/StorageClass — всё это видно в kubectl describe pod в секции Events, но формулировки сообщений нужно уметь различать. Как это работает подробнее планировщик перебирает все узлы и отфильтровывает неподходящие по множеству предикатов (ресурсы, taints, affinity, топология); если ни один узел не прошёл фильтрацию, Pod остаётся Pending, а причина агрегируется в одном сообщении FailedScheduling, которое может скрывать сразу несколько факторов (например, "insufficient cpu" на одних узлах и "node(s) had taint" на других). Пример кода Что использовать на практике Практика. при сложном сообщении об ошибке стоит проверять по отдельности каждое условие: kubectl get nodes -o json | jq '.items[].spec.taints' для taints, kubectl
kubernetesscheduling
SeniorPython Developer > Основы Python > Наблюдаемость Короткий ответ Восстановление начинают с метрик (когда начался рост latency/error rate и что предшествовало), сужают через логи ошибок за этот период и трассировки конкретных запросов, затем формулируют точную последовательность событий, корневую причину и конкретные action items с владельцами и сроками. Как это работает подробнее метрики дают общую картину «что» и «когда»; логи дают «что конкретно пошло не так» на уровне исключений; трассировки показывают «где в цепочке вызовов» возникла задержка — вместе они восстанавливают причинно-следственную цепочку, а не только симптом. Пример кода Что использовать на практике Рекомендация. полезно сопоставить timeline с историей деплоев; 504 часто коррелируют с насыщенностью пула соединений к БД/внешнему сервису; самовосстановление за 20 минут может указывать на временную перегрузку, рассосавшуюся после снижения трафика. Компромисс. глубокое расследование с привлечением нескольких команд даёт точную корневую причину, но занимает больше времени; быстрый поверхностный р
distributed-systemsincident-response
JuniorDevOps Engineer > Контейнеры и доставка > CI/CD и управление релизами Короткий ответ Required status checks не дают смёржить pull request, пока указанные проверки (тесты, линтер, сборка) не завершатся успешно; это защищает основную ветку от попадания заведомо сломанного кода. Отключение таких проверок позволит мёрджить код даже при падающих тестах, повышая риск сломать main и, как следствие, пайплайны и деплои для всей команды. Как это работает подробнее в настройках защиты ветки (branch protection rules) указывается список статус-чеков, которые GitHub/GitLab должны получить от CI как «success», прежде чем кнопка мерджа станет активной. Это работает независимо от решения ревьюера — даже одобренный PR нельзя слить, если чек не прошёл. Пример кода Что использовать на практике На практике. required checks — один из самых дешёвых и эффективных способов поддерживать `main` в рабочем состоянии, особенно в командах с частыми мерджами от разных разработчиков. Их обычно дополняют требованием хотя бы одного одобрения код-ревью. Пример. Ожидаемое поведение: кнопка merge в интерфейсе остаё
artifactscicd-and-release-management
MiddleDevOps Engineer > Контейнеры и доставка > Kubernetes и оркестрация Короткий ответ Чаще всего причина — несуществующий или неверно указанный storageClassName, отсутствие provisioner'а для динамического создания томов в этом классе, недоступность запрошенного объёма/режима доступа у облачного хранилища, либо WaitForFirstConsumer binding mode, при котором PVC намеренно остаётся Pending до тех пор, пока соответствующий Pod не будет запланирован на конкретный узел/зону. Как это работает подробнее при создании PVC контроллер admission и provisioning смотрит на storageClassName; если такого StorageClass не существует в кластере, PVC останется Pending без автоматического создания PV. Если класс существует, но использует volumeBindingMode: WaitForFirstConsumer (распространено для облачных дисков, привязанных к зоне), PVC нормально остаётся в Pending до момента, когда планировщик определит зону для использующего его Pod — это не ошибка, а штатное поведение, которое легко спутать с проблемой. Пример кода Что использовать на практике Практика. диагностику начинают с kubectl describe pvc
kubernetespersistent-storage