Как опыт Яндекса доказывает важность поиска для внедрения LLM
В статье Дима Кирпа, разработчик из команды ML Laboratory в Yandex Infrastructure, делится опытом внедрения LLM в корпоративный интранет Яндекса. Он рассказывает о процессе создания внутреннего поиска и построения на его базе генеративной Q&A‑системы AI Chat.
Автор отмечает, что без качественного инструмента поиска рушится цепочка работы со знаниями: у людей умирает мотивация писать документацию, а отсутствие хорошей документации и поиска приводит к тому, что люди тратят много времени на поиск информации. Проблемы со знаниями в компании нельзя решить только с помощью LLM, если нет качественной базы данных.
Дима Кирпа считает, что поиск должен быть основой для внедрения LLM и других генеративных технологий. Он приводит аргументы в пользу этого подхода, основанные на опыте Яндекса.
Источник
В статье Дима Кирпа, разработчик из команды ML Laboratory в Yandex Infrastructure, делится опытом внедрения LLM в корпоративный интранет Яндекса. Он рассказывает о процессе создания внутреннего поиска и построения на его базе генеративной Q&A‑системы AI Chat.
Автор отмечает, что без качественного инструмента поиска рушится цепочка работы со знаниями: у людей умирает мотивация писать документацию, а отсутствие хорошей документации и поиска приводит к тому, что люди тратят много времени на поиск информации. Проблемы со знаниями в компании нельзя решить только с помощью LLM, если нет качественной базы данных.
Дима Кирпа считает, что поиск должен быть основой для внедрения LLM и других генеративных технологий. Он приводит аргументы в пользу этого подхода, основанные на опыте Яндекса.
Источник
1) Бумага тоньше человеческого волоса, а жопу прикрывает лучше бронированного листа
2) Устные указания имеют рекомендательный характер
Не благодарите. ))))
2) Устные указания имеют рекомендательный характер
Не благодарите. ))))
💯4🔥2
Symfony
New in Symfony 8.1: Messenger Improvements (Symfony Blog)
Symfony 8.1 improves Messenger with batch fetching, AMQP priorities, smarter retries, and configurable resets.
Symfony 8.1: улучшения компонента Messenger
Статья описывает обновления компонента Messenger в новой версии Symfony 8.1. В ней рассматриваются изменения в выполнении рабочих процессов, поведении транспорта, сериализации и обработке сбоев.
Ключевые улучшения включают возможность пакетной выборки сообщений, настройку интервала сброса сервисов и определение пользовательского имени типа для сериализованных сообщений. Также добавлена поддержка приоритизации сообщений в AMQP.
Конкретные изменения:
• Добавлена опция --fetch-size для команды messenger:consume, позволяющая рабочим процессам запрашивать несколько сообщений за один вызов.
• Введен параметр --no-reset с возможностью указания интервала сброса сервисов после обработки N сообщений.
• Реализовано пользовательское имя типа для сериализованных сообщений через аргумент serializedTypeName атрибута #[AsMessage].
• Внедрена поддержка приоритизации сообщений в AMQP через новый AmqpPriorityStamp.
Источник
Статья описывает обновления компонента Messenger в новой версии Symfony 8.1. В ней рассматриваются изменения в выполнении рабочих процессов, поведении транспорта, сериализации и обработке сбоев.
Ключевые улучшения включают возможность пакетной выборки сообщений, настройку интервала сброса сервисов и определение пользовательского имени типа для сериализованных сообщений. Также добавлена поддержка приоритизации сообщений в AMQP.
Конкретные изменения:
• Добавлена опция --fetch-size для команды messenger:consume, позволяющая рабочим процессам запрашивать несколько сообщений за один вызов.
• Введен параметр --no-reset с возможностью указания интервала сброса сервисов после обработки N сообщений.
• Реализовано пользовательское имя типа для сериализованных сообщений через аргумент serializedTypeName атрибута #[AsMessage].
• Внедрена поддержка приоритизации сообщений в AMQP через новый AmqpPriorityStamp.
Источник
Статический анализ с ИИ: как LLM помогают искать уязвимости
Денис Макрушин из команды SourceCraft обсуждает применение искусственного интеллекта в области кибербезопасности. В статье рассматривается, как LLM (языковые модели) могут помочь в поиске и исправлении уязвимостей в коде, а также их ограничения.
Классические SAST-инструменты генерируют много ложных срабатываний, что приводит к потере времени на ручной разбор. Релиз Claude Code Security от Anthropic изменил ситуацию на рынке кибербезопасности. LLM могут улучшить семантический анализ и помочь в интерпретации результатов, формируя новую категорию — AI SAST.
Основные проблемы классических SAST включают сигнатурные ложные срабатывания, дубликаты, алерты без контекста и неэксплуатируемые находки. LLM могут помочь в триаже алертов, оценке реального риска эксплойта и объяснении разработчикам актуальности проблем. Однако LLM работают на вероятностях и не могут заменить формальную верификацию и классические анализаторы.
В статье упоминаются конкретные цифры: до 91% предупреждений в опенсорс-проектах на GitHub оказываются ложными, а в Python-приложениях на Flask — до 99,5%.
Источник
Денис Макрушин из команды SourceCraft обсуждает применение искусственного интеллекта в области кибербезопасности. В статье рассматривается, как LLM (языковые модели) могут помочь в поиске и исправлении уязвимостей в коде, а также их ограничения.
Классические SAST-инструменты генерируют много ложных срабатываний, что приводит к потере времени на ручной разбор. Релиз Claude Code Security от Anthropic изменил ситуацию на рынке кибербезопасности. LLM могут улучшить семантический анализ и помочь в интерпретации результатов, формируя новую категорию — AI SAST.
Основные проблемы классических SAST включают сигнатурные ложные срабатывания, дубликаты, алерты без контекста и неэксплуатируемые находки. LLM могут помочь в триаже алертов, оценке реального риска эксплойта и объяснении разработчикам актуальности проблем. Однако LLM работают на вероятностях и не могут заменить формальную верификацию и классические анализаторы.
В статье упоминаются конкретные цифры: до 91% предупреждений в опенсорс-проектах на GitHub оказываются ложными, а в Python-приложениях на Flask — до 99,5%.
Источник
Private Packagist
An update on Composer & Packagist supply chain security
The last months, and even more so the last weeks, saw an increasing amount of software supply chain attacks targeting open-source ecosystems. A handful of these have hit the PHP ecosystem too, via taken-over GitHub accounts and stolen access tokens that let…
Обновление по безопасности Composer и Packagist
Статья посвящена мерам по повышению безопасности в экосистеме PHP, особенно в контексте атак на цепочки поставок программного обеспечения. Основное внимание уделяется работе над усилением защиты в Composer и Packagist.org.
В статье описаны текущие и планируемые меры безопасности: интеграция обнаружения вредоносного ПО Aikido, введение политики управления зависимостями в Composer 2.10, обеспечение неизменности стабильных версий на Packagist.org и внедрение многофакторной аутентификации (MFA). Также обсуждаются долгосрочные направления, включая обязательное использование MFA и строгие требования на уровне организаций.
Конкретные шаги включают запуск Composer 2.10 с новой политикой зависимостей, обеспечение неизменности версий на Packagist.org и введение новых функций безопасности в Private Packagist. Подчёркивается важность включения MFA для всех, кто поддерживает пакеты на Packagist.org.
Источник
Статья посвящена мерам по повышению безопасности в экосистеме PHP, особенно в контексте атак на цепочки поставок программного обеспечения. Основное внимание уделяется работе над усилением защиты в Composer и Packagist.org.
В статье описаны текущие и планируемые меры безопасности: интеграция обнаружения вредоносного ПО Aikido, введение политики управления зависимостями в Composer 2.10, обеспечение неизменности стабильных версий на Packagist.org и внедрение многофакторной аутентификации (MFA). Также обсуждаются долгосрочные направления, включая обязательное использование MFA и строгие требования на уровне организаций.
Конкретные шаги включают запуск Composer 2.10 с новой политикой зависимостей, обеспечение неизменности версий на Packagist.org и введение новых функций безопасности в Private Packagist. Подчёркивается важность включения MFA для всех, кто поддерживает пакеты на Packagist.org.
Источник
❤1
Simon Willison’s Weblog
Claude Opus 4.8: “a modest but tangible improvement”
Anthropic shipped Claude Opus 4.8 today. My favourite thing about it is this note in the release announcement: Users will find Opus 4.8 to be a modest but tangible improvement …
Anthropic выпустила Claude Opus 4.8
Статья рассказывает о выходе новой версии модели искусственного интеллекта Claude Opus 4.8 от компании Anthropic. Автор статьи — Simon Willison — отмечает, что обновление представляет собой незначительное, но ощутимое улучшение по сравнению с предыдущей версией.
Ключевые тезисы:
• Модель стала честнее и реже делает необоснованные заявления.
• Claude Opus 4.8 лучше справляется с выявлением неопределённостей в своей работе.
• По оценкам, модель в четыре раза реже пропускает ошибки в написанном коде по сравнению с предшественником.
• Модель демонстрирует снижение количества фактических галлюцинаций.
Конкретика:
• Цена осталась прежней: $5 за миллион входных данных и $25 за миллион выходных.
• «Быстрый режим» стоит вдвое дороже обычного, что является значительным снижением по сравнению с предыдущими моделями.
• Ограничения контекста и объёма данных остались на уровне 1 000 000 токенов для контекста и 128 000 токенов для вывода.
• Новая функция: поддержка системных сообщений в середине разговора.
• Увеличено количество кэшируемых токенов до 1 024, что меньше, чем у предыдущей версии (4 096 токенов).
Источник
Статья рассказывает о выходе новой версии модели искусственного интеллекта Claude Opus 4.8 от компании Anthropic. Автор статьи — Simon Willison — отмечает, что обновление представляет собой незначительное, но ощутимое улучшение по сравнению с предыдущей версией.
Ключевые тезисы:
• Модель стала честнее и реже делает необоснованные заявления.
• Claude Opus 4.8 лучше справляется с выявлением неопределённостей в своей работе.
• По оценкам, модель в четыре раза реже пропускает ошибки в написанном коде по сравнению с предшественником.
• Модель демонстрирует снижение количества фактических галлюцинаций.
Конкретика:
• Цена осталась прежней: $5 за миллион входных данных и $25 за миллион выходных.
• «Быстрый режим» стоит вдвое дороже обычного, что является значительным снижением по сравнению с предыдущими моделями.
• Ограничения контекста и объёма данных остались на уровне 1 000 000 токенов для контекста и 128 000 токенов для вывода.
• Новая функция: поддержка системных сообщений в середине разговора.
• Увеличено количество кэшируемых токенов до 1 024, что меньше, чем у предыдущей версии (4 096 токенов).
Источник
Symfony
New in Symfony 8.1: RateLimiter Improvements (Symfony Blog)
Symfony 8.1 adds a RateLimit attribute for declarative controller rate limiting and a calendar-aligned mode for fixed-window limiters.
Symfony 8.1: улучшения RateLimiter
Статья посвящена новым функциям в Symfony 8.1, которые упрощают работу с ограничением частоты запросов. Автор рассказывает о нововведениях, которые позволяют более гибко настраивать лимиты и упрощают процесс разработки.
В Symfony 8.1 добавлено новое декларативное свойство #[RateLimit]. Оно позволяет автоматически возвращать ответ «429 Too Many Requests» при превышении лимита запросов, настроенного в framework.rate_limiter. Атрибут можно применять многократно, накладывая несколько ограничений на одно действие, а также применять ко всему классу контроллера.
Кроме того, в Symfony 8.1 появилась опция anchor_at для политики fixed_window. Она позволяет синхронизировать окна лимитирования с календарём, что полезно для циклов биллинга, финансовых годов или еженедельных перезагрузок. Параметр anchor_at принимает любую строку, которую может обработать DateTimeImmutable.
Источник
Статья посвящена новым функциям в Symfony 8.1, которые упрощают работу с ограничением частоты запросов. Автор рассказывает о нововведениях, которые позволяют более гибко настраивать лимиты и упрощают процесс разработки.
В Symfony 8.1 добавлено новое декларативное свойство #[RateLimit]. Оно позволяет автоматически возвращать ответ «429 Too Many Requests» при превышении лимита запросов, настроенного в framework.rate_limiter. Атрибут можно применять многократно, накладывая несколько ограничений на одно действие, а также применять ко всему классу контроллера.
Кроме того, в Symfony 8.1 появилась опция anchor_at для политики fixed_window. Она позволяет синхронизировать окна лимитирования с календарём, что полезно для циклов биллинга, финансовых годов или еженедельных перезагрузок. Параметр anchor_at принимает любую строку, которую может обработать DateTimeImmutable.
Источник
Symfony
New in Symfony 8.1: HttpClient Improvements (Symfony Blog)
Symfony 8.1 improves HttpClient with persistent cURL connections, a Guzzle handler, custom DNS resolution, an SSRF allow-list, and per-client mocking.
Symfony 8.1: улучшения для компонента HttpClient
Статья посвящена релизу Symfony 8.1, в котором представлены улучшения для компонента HttpClient. В обновлении затронуты такие аспекты, как производительность, совместимость, безопасность и тестирование.
Ключевые тезисы:
• В Symfony 8.1 представлены улучшения для компонента HttpClient.
• Добавлена поддержка persistent cURL соединений, что позволяет повторно использовать данные DNS, SSL сессий и соединения между запросами.
• Реализована возможность использования Symfony HttpClient в качестве обработчика для Guzzle, что позволяет использовать его в SDK, построенных на Guzzle.
• В NoPrivateNetworkHttpClient добавлена возможность исключения определённых хостов из списка запрещённых частных сетей.
• По умолчанию для кэшированных ответов используется более безопасный режим.
Конкретика:
• Для использования persistent cURL соединений в Symfony 8.1 необходимо включить опцию extra.use_persistent_connections в CurlHttpClient.
• Для использования Symfony HttpClient в качестве обработчика для Guzzle необходимо создать экземпляр GuzzleHttpHandler.
• В NoPrivateNetworkHttpClient добавлен третий аргумент $allowList, который позволяет исключить определённые хосты из списка запрещённых частных сетей.
Источник
Статья посвящена релизу Symfony 8.1, в котором представлены улучшения для компонента HttpClient. В обновлении затронуты такие аспекты, как производительность, совместимость, безопасность и тестирование.
Ключевые тезисы:
• В Symfony 8.1 представлены улучшения для компонента HttpClient.
• Добавлена поддержка persistent cURL соединений, что позволяет повторно использовать данные DNS, SSL сессий и соединения между запросами.
• Реализована возможность использования Symfony HttpClient в качестве обработчика для Guzzle, что позволяет использовать его в SDK, построенных на Guzzle.
• В NoPrivateNetworkHttpClient добавлена возможность исключения определённых хостов из списка запрещённых частных сетей.
• По умолчанию для кэшированных ответов используется более безопасный режим.
Конкретика:
• Для использования persistent cURL соединений в Symfony 8.1 необходимо включить опцию extra.use_persistent_connections в CurlHttpClient.
• Для использования Symfony HttpClient в качестве обработчика для Guzzle необходимо создать экземпляр GuzzleHttpHandler.
• В NoPrivateNetworkHttpClient добавлен третий аргумент $allowList, который позволяет исключить определённые хосты из списка запрещённых частных сетей.
Источник
Хабр
Мы попробовали Claude Code в энтерпрайз-разработке и собрали за вас восемь проблем
Привет! Меня зовут Андрей, я инженер в Циане. Примерно год назад мы начали внедрять в работу AI-помощников для разработки, а несколько месяцев назад сфокусировались на Claude Code как самом...
Проблемы внедрения Claude Code в энтерпрайз-разработке
Инженер компании Циан Андрей рассказывает о сложностях, с которыми команда столкнулась при внедрении AI-помощника Claude Code в процесс разработки.
Ключевые проблемы включают хранение артефактов AI-помощников в репозиториях, распространение конфигурации, работу с операционной системой Windows и расширение функционала субагентов. Для решения некоторых из них предлагаются различные подходы, например, использование плагинов для распространения общей конфигурации или предоставление Claude Code доступа к информации о компонентах на внутреннем портале.
Также упоминается, что поддержка Windows появилась в Claude Code сравнительно недавно, и возникают сложности с работой инструментария на этой операционной системе. В связи с этим рассматривается возможность перехода на WSL (Windows Subsystem for Linux) или отказа от Windows на машинах разработчиков.
В статье отмечается увеличение максимального контекста в моделях Claude Code с 200 тысяч до миллиона токенов, но указывается на проблемы с компакцией контекста и необходимость использования субагентов для разных задач.
Источник
Инженер компании Циан Андрей рассказывает о сложностях, с которыми команда столкнулась при внедрении AI-помощника Claude Code в процесс разработки.
Ключевые проблемы включают хранение артефактов AI-помощников в репозиториях, распространение конфигурации, работу с операционной системой Windows и расширение функционала субагентов. Для решения некоторых из них предлагаются различные подходы, например, использование плагинов для распространения общей конфигурации или предоставление Claude Code доступа к информации о компонентах на внутреннем портале.
Также упоминается, что поддержка Windows появилась в Claude Code сравнительно недавно, и возникают сложности с работой инструментария на этой операционной системе. В связи с этим рассматривается возможность перехода на WSL (Windows Subsystem for Linux) или отказа от Windows на машинах разработчиков.
В статье отмечается увеличение максимального контекста в моделях Claude Code с 200 тысяч до миллиона токенов, но указывается на проблемы с компакцией контекста и необходимость использования субагентов для разных задач.
Источник
👍1
Разграничение доступа в приложениях: как работает правильный RBAC
Статья на Habr рассказывает о том, как правильно реализовать концепцию RBAC (Role-Based Access Control) в реальных продуктах. Автор описывает проблемы, с которыми сталкиваются разработчики при использовании классической модели «роль → право», и предлагает решение в виде системы из четырёх независимых осей доступа.
В статье отмечается, что классический RBAC отвечает только на вопросы, связанные с доступом к таблице целиком. Реальные требования же живут на четырёх уровнях: таблица → строка → поле → значение. Для решения этой проблемы автор предлагает использовать четыре оси доступа: ACL (Access Control List), RAC (Record Access Control), FAC (Field Access Control) и VAC (Value Access Control). Каждая из осей решает свою задачу и ничего не знает о других.
ACL — это базовый слой, который определяет, пустят ли пользователя в здание (таблицу) вообще. RAC отвечает за доступ в комнаты (строки), FAC — за то, что в комнате разрешено трогать (поля), а VAC — за действия, которые допустимы с этими объектами.
В FARA CRM права описываются декларативно, прямо в модуле, через миксин. Это позволяет централизованно управлять доступом и избежать уязвимостей, связанных с самоназначением ролей.
Источник
Статья на Habr рассказывает о том, как правильно реализовать концепцию RBAC (Role-Based Access Control) в реальных продуктах. Автор описывает проблемы, с которыми сталкиваются разработчики при использовании классической модели «роль → право», и предлагает решение в виде системы из четырёх независимых осей доступа.
В статье отмечается, что классический RBAC отвечает только на вопросы, связанные с доступом к таблице целиком. Реальные требования же живут на четырёх уровнях: таблица → строка → поле → значение. Для решения этой проблемы автор предлагает использовать четыре оси доступа: ACL (Access Control List), RAC (Record Access Control), FAC (Field Access Control) и VAC (Value Access Control). Каждая из осей решает свою задачу и ничего не знает о других.
ACL — это базовый слой, который определяет, пустят ли пользователя в здание (таблицу) вообще. RAC отвечает за доступ в комнаты (строки), FAC — за то, что в комнате разрешено трогать (поля), а VAC — за действия, которые допустимы с этими объектами.
В FARA CRM права описываются декларативно, прямо в модуле, через миксин. Это позволяет централизованно управлять доступом и избежать уязвимостей, связанных с самоназначением ролей.
Источник
PHP 8.6: дата релиза и новые возможности
В статье обсуждается предстоящий релиз PHP 8.6, который ожидается в конце ноября 2026 года. Описываются основные нововведения и изменения, которые будут включены в эту версию.
Ключевые нововведения PHP 8.6 включают частичное применение функций (PFA, v2) и нативную функцию clamp(). Частичное применение функций позволяет использовать синтаксис на основе плейсхолдеров для частичного применения аргументов к любому вызываемому объекту. Функция clamp() удерживает значение в диапазоне min/max.
Также рассматривается RFC для функции func_get_args_by_name(), которая возвращает аргументы текущей функции, сохраняя имена параметров в качестве ключей массива.
Ожидается, что первой российской IDE, поддержавшей все нововведения PHP 8.6, станет OpenIDE.
Ссылки на RFC:
• Частичное применение функций: https://wiki.php.net/rfc/partial_function_application_v2
• Функция clamp(): https://wiki.php.net/rfc/clamp_v2
• Функция func_get_args_by_name(): https://wiki.php.net/rfc/func_get_args_by_name
Источник
В статье обсуждается предстоящий релиз PHP 8.6, который ожидается в конце ноября 2026 года. Описываются основные нововведения и изменения, которые будут включены в эту версию.
Ключевые нововведения PHP 8.6 включают частичное применение функций (PFA, v2) и нативную функцию clamp(). Частичное применение функций позволяет использовать синтаксис на основе плейсхолдеров для частичного применения аргументов к любому вызываемому объекту. Функция clamp() удерживает значение в диапазоне min/max.
Также рассматривается RFC для функции func_get_args_by_name(), которая возвращает аргументы текущей функции, сохраняя имена параметров в качестве ключей массива.
Ожидается, что первой российской IDE, поддержавшей все нововведения PHP 8.6, станет OpenIDE.
Ссылки на RFC:
• Частичное применение функций: https://wiki.php.net/rfc/partial_function_application_v2
• Функция clamp(): https://wiki.php.net/rfc/clamp_v2
• Функция func_get_args_by_name(): https://wiki.php.net/rfc/func_get_args_by_name
Источник
Forwarded from gotcha
🚀 Gotcha v0.4.10 — стабилизация линии 0.4.x
Вышел новый релиз — и он же первый официально опубликованный на GitHub. Внутри — итоги двух полных аудитов продукта (эксплуатация, безопасность, доступность, i18n) и серия патчей 0.4.5–0.4.10.
⚙️ Эксплуатация
▪️ Compose-стек с лимитами памяти и healthcheck'ами; hardened-контейнер: read-only FS, no-new-privileges
▪️ /healthz и /readyz разделены — liveness и readiness больше не смешиваются
▪️ --migrate-force восстанавливает прерванную миграцию; откат релиза больше не требует бэкапа
▪️ Ретеншн отдельно для метрик, профилей и инцидентов; 0 теперь честно значит «хранить вечно»
▪️ Для сложных сетей: свой Telegram Bot API сервер (GOTCHA_TELEGRAM_API_BASE) и настройка MTU
🎯 Точность
▪️ Квота транзакций считается по сохранённому, а не по принятому — с сэмплингом 0.1 раньше платили десятикратно
▪️ Исправлены длительности перф-регрессий (µs читались как ms) — миграция пересчитает старые данные
▪️ Алерты, ретраи и throttling считаются по часам БД — дублей из-за рассинхрона времени больше нет
🔐 Безопасность
▪️ Удаление участника из организации отзывает и доступы его команд к проектам
▪️ Регистрация по инвайту требует токен из ссылки, а не только совпадение email
▪️ Отсечка глубоко вложенного OTLP/JSON, усиленный redirect guard (по репорту CodeQL)
🔔 Уведомления и UX
▪️ Единый язык уведомлений (GOTCHA_LOCALE), человекочитаемые темы писем
▪️ Канал «внутри периметра» получает полные детали событий
▪️ Доступность: клавиатурная навигация, кастомные чекбоксы, контраст без опоры на цвет
📚 Документация обновлена до 0.4.10: getgotcha.ru/docs
🌐 getgotcha.ru
⭐️ github.com/OtezVikentiy/gotcha
💬 Чат: t.me/getgotcha
Вышел новый релиз — и он же первый официально опубликованный на GitHub. Внутри — итоги двух полных аудитов продукта (эксплуатация, безопасность, доступность, i18n) и серия патчей 0.4.5–0.4.10.
⚙️ Эксплуатация
▪️ Compose-стек с лимитами памяти и healthcheck'ами; hardened-контейнер: read-only FS, no-new-privileges
▪️ /healthz и /readyz разделены — liveness и readiness больше не смешиваются
▪️ --migrate-force восстанавливает прерванную миграцию; откат релиза больше не требует бэкапа
▪️ Ретеншн отдельно для метрик, профилей и инцидентов; 0 теперь честно значит «хранить вечно»
▪️ Для сложных сетей: свой Telegram Bot API сервер (GOTCHA_TELEGRAM_API_BASE) и настройка MTU
🎯 Точность
▪️ Квота транзакций считается по сохранённому, а не по принятому — с сэмплингом 0.1 раньше платили десятикратно
▪️ Исправлены длительности перф-регрессий (µs читались как ms) — миграция пересчитает старые данные
▪️ Алерты, ретраи и throttling считаются по часам БД — дублей из-за рассинхрона времени больше нет
🔐 Безопасность
▪️ Удаление участника из организации отзывает и доступы его команд к проектам
▪️ Регистрация по инвайту требует токен из ссылки, а не только совпадение email
▪️ Отсечка глубоко вложенного OTLP/JSON, усиленный redirect guard (по репорту CodeQL)
🔔 Уведомления и UX
▪️ Единый язык уведомлений (GOTCHA_LOCALE), человекочитаемые темы писем
▪️ Канал «внутри периметра» получает полные детали событий
▪️ Доступность: клавиатурная навигация, кастомные чекбоксы, контраст без опоры на цвет
📚 Документация обновлена до 0.4.10: getgotcha.ru/docs
🌐 getgotcha.ru
⭐️ github.com/OtezVikentiy/gotcha
💬 Чат: t.me/getgotcha
Друг рассказал историю про миграцию, от которой у меня до сих пор дёргается глаз.
Компания переезжала на новую базу 1С. Три месяца готовили тестовую базу, отлаживали документы. И вот в выходные - перенос данных в бой.
С понедельника в чате поддержки 180+ сообщений об ошибках. Норма - одно-два за несколько дней. К пятнице поток так и не иссяк.
Что было сломано? Проще сказать, что работало. Слетели статусы заказов - клиентам нельзя отгружать. Отвязался банк - оплат не видно. Лёг ЭДО - у входящих документов за месяц пропали подписи. Оторвалась почта, интеграции, заказы с сайта падали в старую базу. Часть пользователей вообще не знала о переезде и продолжала работать в старой базе - неделю жили в двух базах с ручным дублированием. Права срезали без карты "кому что нужно". Под конец недели сама база проводила документ по двадцать минут. Вишенка на торте - под вопросом оказалась регуляторная отчётность.
Разгребали всё это неделю люди, которые к переносу отношения не имели. Причём вслепую - им даже не сказали, что и как переносилось.
А теперь самое интересное. За два месяца до этого в той же компании были два переноса того же класса. Делал другой человек. Ноль инцидентов.
То есть дело не в том, что "миграции - это всегда больно". Дело в том, что в неудачном переносе не было:
- плана отката (на прямой вопрос "а откатываться как будем?" - "пока не вижу причин");
- полного перечня переносимых данных;
- уведомления пользователей;
- плана переключения интеграций;
- критериев приёмки - хоть каких-нибудь.
Ни один пункт не требует таланта. Это чеклист на семь строк, который пишется за час.
Мораль у меня такая. Когда что-то падает, первый рефлекс - искать, кто накосячил. Но "кто" - почти всегда неправильный вопрос. Правильный - "какой процесс позволил выкатить это в бой без плана отката". Потому что человека можно заменить, а дыра в процессе воспроизведёт ту же историю с любым следующим исполнителем.
Героизм тех, кто неделю тушил пожар, - это восхитительно. Но чеклист на час работы дешевле недели героизма. Всегда.
Компания переезжала на новую базу 1С. Три месяца готовили тестовую базу, отлаживали документы. И вот в выходные - перенос данных в бой.
С понедельника в чате поддержки 180+ сообщений об ошибках. Норма - одно-два за несколько дней. К пятнице поток так и не иссяк.
Что было сломано? Проще сказать, что работало. Слетели статусы заказов - клиентам нельзя отгружать. Отвязался банк - оплат не видно. Лёг ЭДО - у входящих документов за месяц пропали подписи. Оторвалась почта, интеграции, заказы с сайта падали в старую базу. Часть пользователей вообще не знала о переезде и продолжала работать в старой базе - неделю жили в двух базах с ручным дублированием. Права срезали без карты "кому что нужно". Под конец недели сама база проводила документ по двадцать минут. Вишенка на торте - под вопросом оказалась регуляторная отчётность.
Разгребали всё это неделю люди, которые к переносу отношения не имели. Причём вслепую - им даже не сказали, что и как переносилось.
А теперь самое интересное. За два месяца до этого в той же компании были два переноса того же класса. Делал другой человек. Ноль инцидентов.
То есть дело не в том, что "миграции - это всегда больно". Дело в том, что в неудачном переносе не было:
- плана отката (на прямой вопрос "а откатываться как будем?" - "пока не вижу причин");
- полного перечня переносимых данных;
- уведомления пользователей;
- плана переключения интеграций;
- критериев приёмки - хоть каких-нибудь.
Ни один пункт не требует таланта. Это чеклист на семь строк, который пишется за час.
Мораль у меня такая. Когда что-то падает, первый рефлекс - искать, кто накосячил. Но "кто" - почти всегда неправильный вопрос. Правильный - "какой процесс позволил выкатить это в бой без плана отката". Потому что человека можно заменить, а дыра в процессе воспроизведёт ту же историю с любым следующим исполнителем.
Героизм тех, кто неделю тушил пожар, - это восхитительно. Но чеклист на час работы дешевле недели героизма. Всегда.
👍4
Forwarded from gotcha
🧩 Мониторинг для CMS: 6 расширений и 7 статей
Подключить Gotcha к своему приложению всегда было просто - работают штатные Sentry SDK. А вот с готовыми сайтами на CMS было хуже: официальных расширений нет ни у кого. Теперь есть.
WordPress, Joomla, 1С-Битрикс, Drupal, OpenCart, MODX - для каждой CMS своё расширение и статья с полным разбором. Скачали архив, поставили штатным установщиком, вставили DSN - и ошибки с производительностью уже в вашем инстансе.
Что собирает каждое расширение:
🐞 ошибки PHP, включая фатальные, со стектрейсом
⏱️ время ответа по эндпойнтам (а не по URL - иначе отчёт утонет)
🌐 ошибки JavaScript и Web Vitals у реальных посетителей
🟢 аптайм и срок SSL-сертификата - вообще без единой строки кода
Самое интересное в этой работе - что "просто вызвать Sentry SDK" не работает ни в одной CMS. У каждой свой способ отдать вам ошибку:
▪️ Joomla перехватывает исключения сама, забирать их нужно из события onError
▪️ у Битрикса для этого есть штатная точка расширения - ExceptionHandlerLog в .settings.php
▪️ Drupal раздаёт ошибки всем сервисам с тегом logger, перехватывать вообще ничего не надо
▪️ OpenCart и MODX ставят свои обработчики раньше расширений - приходится встраиваться в цепочку, а не перебивать
Каждое расширение проверено на живом движке в докере: официальные образы (для Битрикса - триал-дистрибутив), установка из архива, настоящие ошибки, реальный инстанс Gotcha на другом конце. По дороге нашлось полтора десятка багов - все описаны в статьях. Например, конфликт версий psr/log, из-за которого сайт на Joomla 4 отдавал белый экран на каждой странице: composer-зависимости расширения обязательно нужно изолировать php-scoper'ом, иначе ломается не мониторинг, а весь сайт.
Отдельно - Tilda. Расширение туда поставить некуда, это SaaS. Но браузерная половина доступна и там, и статья честно разбирает, что получится собрать, а что нет.
📚 Статьи:
WordPress - getgotcha.ru/blog/wordpress-monitoring/
Joomla - getgotcha.ru/blog/joomla-monitoring/
1С-Битрикс - getgotcha.ru/blog/bitrix-monitoring/
Drupal - getgotcha.ru/blog/drupal-monitoring/
OpenCart - getgotcha.ru/blog/opencart-monitoring/
MODX - getgotcha.ru/blog/modx-monitoring/
Tilda - getgotcha.ru/blog/tilda-monitoring/
Все архивы и краткая сводка - в документации: getgotcha.ru/docs/sdk/
🌐 getgotcha.ru
⭐️ github.com/OtezVikentiy/gotcha
Подключить Gotcha к своему приложению всегда было просто - работают штатные Sentry SDK. А вот с готовыми сайтами на CMS было хуже: официальных расширений нет ни у кого. Теперь есть.
WordPress, Joomla, 1С-Битрикс, Drupal, OpenCart, MODX - для каждой CMS своё расширение и статья с полным разбором. Скачали архив, поставили штатным установщиком, вставили DSN - и ошибки с производительностью уже в вашем инстансе.
Что собирает каждое расширение:
🐞 ошибки PHP, включая фатальные, со стектрейсом
⏱️ время ответа по эндпойнтам (а не по URL - иначе отчёт утонет)
🌐 ошибки JavaScript и Web Vitals у реальных посетителей
🟢 аптайм и срок SSL-сертификата - вообще без единой строки кода
Самое интересное в этой работе - что "просто вызвать Sentry SDK" не работает ни в одной CMS. У каждой свой способ отдать вам ошибку:
▪️ Joomla перехватывает исключения сама, забирать их нужно из события onError
▪️ у Битрикса для этого есть штатная точка расширения - ExceptionHandlerLog в .settings.php
▪️ Drupal раздаёт ошибки всем сервисам с тегом logger, перехватывать вообще ничего не надо
▪️ OpenCart и MODX ставят свои обработчики раньше расширений - приходится встраиваться в цепочку, а не перебивать
Каждое расширение проверено на живом движке в докере: официальные образы (для Битрикса - триал-дистрибутив), установка из архива, настоящие ошибки, реальный инстанс Gotcha на другом конце. По дороге нашлось полтора десятка багов - все описаны в статьях. Например, конфликт версий psr/log, из-за которого сайт на Joomla 4 отдавал белый экран на каждой странице: composer-зависимости расширения обязательно нужно изолировать php-scoper'ом, иначе ломается не мониторинг, а весь сайт.
Отдельно - Tilda. Расширение туда поставить некуда, это SaaS. Но браузерная половина доступна и там, и статья честно разбирает, что получится собрать, а что нет.
📚 Статьи:
WordPress - getgotcha.ru/blog/wordpress-monitoring/
Joomla - getgotcha.ru/blog/joomla-monitoring/
1С-Битрикс - getgotcha.ru/blog/bitrix-monitoring/
Drupal - getgotcha.ru/blog/drupal-monitoring/
OpenCart - getgotcha.ru/blog/opencart-monitoring/
MODX - getgotcha.ru/blog/modx-monitoring/
Tilda - getgotcha.ru/blog/tilda-monitoring/
Все архивы и краткая сводка - в документации: getgotcha.ru/docs/sdk/
🌐 getgotcha.ru
⭐️ github.com/OtezVikentiy/gotcha
Forwarded from gotcha
📊 Вторая статья на Хабре
"Стоковый ClickHouse занял 12 ГБ диска при 543 КБ данных: сколько на самом деле ест self-hosted observability"
В комментариях к первой статье больше всего реакции собрали цифры потребления с боевого стенда. Эта статья - развёрнутый ответ, с замерами: 2 ядра, 2 ГБ RAM, 20 ГБ SSD, боевой инстанс.
Внутри:
▪️ 543 КБ полезных данных против 579 МБ собственной телеметрии ClickHouse - 98.8% вставок база делала сама себе
▪️ мерж-амплификация 1:678 - на каждую новую строку движок перезаписывал 678 уже лежащих
▪️ гипотеза про CPU, которая не подтвердилась, и ловушка docker stats (проценты от ядра, а не от машины)
▪️ ошибка в конфиге, которая уронила прод на несколько минут, и правильный порядок действий
▪️ итог тюнинга: память ClickHouse 880 → 256 МБ (-66%), диск 12 → 9.2 ГБ, load average 1.15 → 0.79
▪️ почему из 11 настроек универсальны только 3, а остальные вредят мощному серверу - и как это разложилось на базовый compose и оверлей для слабого железа
Замеры воспроизводимы: конфиги в репозитории, стенд описан в начале статьи.
📖 habr.com/ru/articles/1070270/
🌐 getgotcha.ru
💬 Чат: t.me/getgotcha
"Стоковый ClickHouse занял 12 ГБ диска при 543 КБ данных: сколько на самом деле ест self-hosted observability"
В комментариях к первой статье больше всего реакции собрали цифры потребления с боевого стенда. Эта статья - развёрнутый ответ, с замерами: 2 ядра, 2 ГБ RAM, 20 ГБ SSD, боевой инстанс.
Внутри:
▪️ 543 КБ полезных данных против 579 МБ собственной телеметрии ClickHouse - 98.8% вставок база делала сама себе
▪️ мерж-амплификация 1:678 - на каждую новую строку движок перезаписывал 678 уже лежащих
▪️ гипотеза про CPU, которая не подтвердилась, и ловушка docker stats (проценты от ядра, а не от машины)
▪️ ошибка в конфиге, которая уронила прод на несколько минут, и правильный порядок действий
▪️ итог тюнинга: память ClickHouse 880 → 256 МБ (-66%), диск 12 → 9.2 ГБ, load average 1.15 → 0.79
▪️ почему из 11 настроек универсальны только 3, а остальные вредят мощному серверу - и как это разложилось на базовый compose и оверлей для слабого железа
Замеры воспроизводимы: конфиги в репозитории, стенд описан в начале статьи.
📖 habr.com/ru/articles/1070270/
🌐 getgotcha.ru
💬 Чат: t.me/getgotcha
Forwarded from gotcha
🎉 Gotcha 1.0.0 - первый стабильный релиз
Первый тег, 0.1.0, датирован 22 июля. Сегодня выходит 1.0. Важно в этом номере не то, сколько всего приехало за два месяца, а то, чего у 0.x не было вовсе: обещание.
🔒 Что заморожено
▪️ имена переменных окружения
▪️ адреса приёма и форматы тел запросов
▪️ схема миграций и формат бэкапов
▪️ имена self-метрик без пометки "временная"
▪️ тело исходящего вебхука и контракт GOTCHA_AGENT_*
▪️ адреса уже опубликованных статус-страниц
Всё перечисленное с этого релиза меняется только назад совместимо. Что это нарушает - ждёт 2.0.
До 1.0 контракт мог меняться между релизами, и об этом говорилось прямо. С 1.0 обновление перестаёт быть событием, к которому готовятся: прочитать страницу "Обновление", подтянуть образ, поехали.
Что в обещание не входит, сказано так же прямо: внутренние пакеты, внешний вид интерфейса, имена счётчиков с пометкой "временный". Полный текст - на странице политики версионирования.
🧪 Чем занимались перед заморозкой
▪️ 31 переменная окружения переименована в 0.34 - до заморозки, а не после. Старое имя больше не читается: старт останавливается и называет новое, вместо тихой подмены дефолтом
▪️ Репетиция обновления на копии продовых данных: апгрейд и откат проехали руками до релиза, а не после. Нашлось и закрыто пять блокеров, включая цикл падений при откате бинаря на базу с более новой схемой
▪️ Сплошной аудит девятью независимыми линзами: архитектура, безопасность, ревью кода, QA, интерфейс вживую и по исходникам, юзабилити, документация, эксплуатация. Всё найденное закрыто тремя волнами до релиза
1.0 выходит не потому, что кончились идеи, а потому что кончились известные долги.
⚠️ Старые адреса приёма /logs, /profiles/pprof и /api/{project}/deployments/ работают в 1.0 и удаляются только в 2.0. Устаревшими их объявили 31 августа - слишком короткий срок предупреждения, чтобы ломать чужие интеграции релизом, который называется "обещание стабильности".
⭐️ github.com/OtezVikentiy/gotcha/releases/tag/v1.0.0
🌐 getgotcha.ru/changelog/
💬 Чат: t.me/getgotcha
Первый тег, 0.1.0, датирован 22 июля. Сегодня выходит 1.0. Важно в этом номере не то, сколько всего приехало за два месяца, а то, чего у 0.x не было вовсе: обещание.
🔒 Что заморожено
▪️ имена переменных окружения
▪️ адреса приёма и форматы тел запросов
▪️ схема миграций и формат бэкапов
▪️ имена self-метрик без пометки "временная"
▪️ тело исходящего вебхука и контракт GOTCHA_AGENT_*
▪️ адреса уже опубликованных статус-страниц
Всё перечисленное с этого релиза меняется только назад совместимо. Что это нарушает - ждёт 2.0.
До 1.0 контракт мог меняться между релизами, и об этом говорилось прямо. С 1.0 обновление перестаёт быть событием, к которому готовятся: прочитать страницу "Обновление", подтянуть образ, поехали.
Что в обещание не входит, сказано так же прямо: внутренние пакеты, внешний вид интерфейса, имена счётчиков с пометкой "временный". Полный текст - на странице политики версионирования.
🧪 Чем занимались перед заморозкой
▪️ 31 переменная окружения переименована в 0.34 - до заморозки, а не после. Старое имя больше не читается: старт останавливается и называет новое, вместо тихой подмены дефолтом
▪️ Репетиция обновления на копии продовых данных: апгрейд и откат проехали руками до релиза, а не после. Нашлось и закрыто пять блокеров, включая цикл падений при откате бинаря на базу с более новой схемой
▪️ Сплошной аудит девятью независимыми линзами: архитектура, безопасность, ревью кода, QA, интерфейс вживую и по исходникам, юзабилити, документация, эксплуатация. Всё найденное закрыто тремя волнами до релиза
1.0 выходит не потому, что кончились идеи, а потому что кончились известные долги.
⚠️ Старые адреса приёма /logs, /profiles/pprof и /api/{project}/deployments/ работают в 1.0 и удаляются только в 2.0. Устаревшими их объявили 31 августа - слишком короткий срок предупреждения, чтобы ломать чужие интеграции релизом, который называется "обещание стабильности".
⭐️ github.com/OtezVikentiy/gotcha/releases/tag/v1.0.0
🌐 getgotcha.ru/changelog/
💬 Чат: t.me/getgotcha
👍1
Forwarded from gotcha
🔧 Gotcha 1.0 -> 1.3.1: первая проверка обещания
1.0 вышла 6 сентября и заморозила контракт совместимости. С тех пор вышло четыре релиза - и это первая проверка обещания на практике. Проверку оно прошло: ни одна переменная окружения не переименована, адреса приёма и форматы тел запросов не менялись, обе новые миграции идут только вперёд. Обновление с 1.0 остаётся прежним: прочитать "Обновление", подтянуть образ, поехали.
Три релиза из четырёх существуют потому, что читатели завели issue и оказались правы.
📥 Приём перестал отвечать "принято" на то, что мог потерять (1.2.0, 1.3.0)
▪️ Раньше приём отвечал 200 безусловно, а положить данные в очередь мог и не успеть: закрытый конвейер, полная очередь, переполненный буфер перед ClickHouse, который при нехватке места вытесняет самое старое. Клиент видел успех, прекращал ретраи, данных не было
▪️ Теперь перед постановкой в очередь проверяется каждый буфер на пути сигнала. Заполнен на 95% и выше - весь запрос отклоняется с 503 и Retry-After: 5, не приняв из него ничего. Повтор безопасен и не создаёт дублей
▪️ Запрос, из которого в очередь не встало ни одного элемента, тоже отвечает 503 - закрыта гонка, которую оставила первая заплатка
▪️ Воркер теперь ждёт место в насыщенном буфере до двух секунд вместо того, чтобы вытеснять данные, на которые клиенту уже ответили 200. Ожидание видно двумя новыми self-метриками
▪️ Ретраи больше не списывают месячную квоту заново: организация платит за то, что реально встало в очередь, а списанное за отклонённое по нехватке ёмкости возвращается
▪️ Профили получили собственное решение по квоте и больше не теряются молча под исчерпанной квотой событий: конверт из одних профилей отвечает 429, а не 200
🔎 Логи можно вычитать, а не только сужать (1.1.0)
▪️ У каждого значения фасета - уровня, сервиса, окружения, атрибута - появился чип исключения, у текста записи своё исключение подстроки. Знакомую шумную строку теперь можно убрать из выдачи
▪️ Фильтры сохраняются лично или на весь проект, один сохранённый можно назначить умолчанием. Ссылка "показать всё" снимает его на текущий просмотр, так что умолчание не прячет данные от того, кто его не ставил
🛡 Установка (1.3.1)
▪️ GOTCHA_COMPOSE_NO_NEW_PRIVS - для хостов, где Docker поставлен из snap. Там dockerd сам работает под профилем AppArmor, ядро отказывает контейнеру в переходе в свой профиль, и контейнер падает на exec с operation not permitted, не напечатав ни строки лога. Симптом, проверка в одну строку без Gotcha и настоящее лечение теперь описаны в разделе устранения неполадок
⚠️ Что осталось незакрытым: потеря при жёстком убийстве процесса до флаша. Штатное выключение буферы дренирует, но настоящий крах требует журнала на диске, и в ветке 1.x его не будет. Поэтому контракт приёма записан в документации словами: 2xx означает "принято в память, записано асинхронно после этого", а не "сохранено".
⭐️ github.com/OtezVikentiy/gotcha/releases/tag/v1.3.0
🌐 getgotcha.ru/changelog/
💬 Чат: t.me/getgotcha
1.0 вышла 6 сентября и заморозила контракт совместимости. С тех пор вышло четыре релиза - и это первая проверка обещания на практике. Проверку оно прошло: ни одна переменная окружения не переименована, адреса приёма и форматы тел запросов не менялись, обе новые миграции идут только вперёд. Обновление с 1.0 остаётся прежним: прочитать "Обновление", подтянуть образ, поехали.
Три релиза из четырёх существуют потому, что читатели завели issue и оказались правы.
📥 Приём перестал отвечать "принято" на то, что мог потерять (1.2.0, 1.3.0)
▪️ Раньше приём отвечал 200 безусловно, а положить данные в очередь мог и не успеть: закрытый конвейер, полная очередь, переполненный буфер перед ClickHouse, который при нехватке места вытесняет самое старое. Клиент видел успех, прекращал ретраи, данных не было
▪️ Теперь перед постановкой в очередь проверяется каждый буфер на пути сигнала. Заполнен на 95% и выше - весь запрос отклоняется с 503 и Retry-After: 5, не приняв из него ничего. Повтор безопасен и не создаёт дублей
▪️ Запрос, из которого в очередь не встало ни одного элемента, тоже отвечает 503 - закрыта гонка, которую оставила первая заплатка
▪️ Воркер теперь ждёт место в насыщенном буфере до двух секунд вместо того, чтобы вытеснять данные, на которые клиенту уже ответили 200. Ожидание видно двумя новыми self-метриками
▪️ Ретраи больше не списывают месячную квоту заново: организация платит за то, что реально встало в очередь, а списанное за отклонённое по нехватке ёмкости возвращается
▪️ Профили получили собственное решение по квоте и больше не теряются молча под исчерпанной квотой событий: конверт из одних профилей отвечает 429, а не 200
🔎 Логи можно вычитать, а не только сужать (1.1.0)
▪️ У каждого значения фасета - уровня, сервиса, окружения, атрибута - появился чип исключения, у текста записи своё исключение подстроки. Знакомую шумную строку теперь можно убрать из выдачи
▪️ Фильтры сохраняются лично или на весь проект, один сохранённый можно назначить умолчанием. Ссылка "показать всё" снимает его на текущий просмотр, так что умолчание не прячет данные от того, кто его не ставил
🛡 Установка (1.3.1)
▪️ GOTCHA_COMPOSE_NO_NEW_PRIVS - для хостов, где Docker поставлен из snap. Там dockerd сам работает под профилем AppArmor, ядро отказывает контейнеру в переходе в свой профиль, и контейнер падает на exec с operation not permitted, не напечатав ни строки лога. Симптом, проверка в одну строку без Gotcha и настоящее лечение теперь описаны в разделе устранения неполадок
⚠️ Что осталось незакрытым: потеря при жёстком убийстве процесса до флаша. Штатное выключение буферы дренирует, но настоящий крах требует журнала на диске, и в ветке 1.x его не будет. Поэтому контракт приёма записан в документации словами: 2xx означает "принято в память, записано асинхронно после этого", а не "сохранено".
⭐️ github.com/OtezVikentiy/gotcha/releases/tag/v1.3.0
🌐 getgotcha.ru/changelog/
💬 Чат: t.me/getgotcha
❤1
Forwarded from gotcha
🛡 Gotcha 1.5.1: волна корректности и безопасности
Четыре релиза за двое суток, собранные в одну запись: полный аудит кодовой базы 1.x и его устранение (1.4.0), починка ошибки, которую привезла сама эта волна (1.4.1), ещё две закрытые находки (1.5.0) и редкий отказ приёма, доведённый до корня (1.5.1). Контракт 1.0 держится: ни одна переменная окружения не переименована, адреса приёма и форматы тел запросов не менялись.
⚠️ Если вы на любой 1.x - обновляйтесь сразу на 1.5.1. На 1.4.0 останавливаться не нужно: сутки он отдавал каждую страницу больше килобайта как файл на скачивание. Сжатие уехало с неверным типом содержимого, 1.4.1 починил.
🔒 Безопасность
▪️ Разбор профилей ограничен по памяти: подготовленный профиль мог раздуть несколько килобайт входа в гигабайты кучи
▪️ Приём ограничивает частоту по адресу клиента до проверки ключа. Раньше поток запросов со случайными ключами доходил до кэша ключей и до базы с её небольшим общим пулом соединений, прежде чем быть отвергнутым
▪️ Значение метрики на краю диапазона float64 могло навсегда завесить обработчик, рисующий её график, сжигая ядро на каждую открытую страницу до перезапуска
▪️ Если инстанс когда-нибудь работал без GOTCHA_SECRET_KEY, всё зашифрованное с тех пор записано под ключом разработки. Перешифровать недостаточно - открытый текст уже попал в журнал упреждающей записи и в бэкапы, такие секреты нужно отозвать и выпустить заново. Теперь это видно метрикой gotcha_secret_key_insecure, а не только строкой в логе старта
⏱️ Вычислители под нагрузкой молча делали часть работы
▪️ Вычислители хостов, правил и SLO и планировщик эскалаций начинали свой список заново каждый тик: всё, что не влезало в бюджет, не проверялось вообще никогда, а в шторме планировщик снова и снова эскалировал одни и те же самые старые, пока новые ждали бесконечно. Теперь продолжают с места обрыва, а пропуск виден метрикой
📥 Приём и честность данных
▪️ Квота больше не списывается до разбора тела: битый или слишком большой запрос стоил квоты, не приняв ничего
▪️ Редкий отказ ClickHouse "use of closed network connection" доведён до корня: на отмене контекста батча клиент рвал сокет напрямую, минуя пул, - а соединение к этому моменту уже вернулось в пул и могло принадлежать постороннему запросу, который и падал
⚡️ Вычислитель хостов спрашивает один сгруппированный запрос на проект вместо запроса на хост. По живому журналу на пятистах хостах: 500 запросов и 750 000 прочитанных строк стали 1 запросом и 1 500 строк.
📚 Руководства сверены с кодом, а не с памятью. Справочник событий вебхука описывал 8 видов из 23 - теперь описаны все 23, и сторож не даёт списку снова разойтись с кодом. Пример SMTP использовал порт 465, на котором этот клиент не умеет говорить вовсе, так что почта просто висела до таймаута.
🔁 Отзыв одного диагноза: 1.3.1 объяснял "exec /usr/local/bin/gotcha: operation not permitted" докером из snap. Объяснение уехало на косвенных уликах, прямая контрпроба его не подтвердила. Раздел устранения неполадок больше не называет причину - он даёт две проверки, разделяющие "ограничения контейнера отвергнуты" и "сломан образ или бинарь".
⚠️ Два места требуют внимания при обновлении, оба про вход
▪️ Вход через единый вход организации больше не привязывается автоматически к существующему парольному аккаунту по совпадению адреса почты. Кто раньше входил одним нажатием, один раз войдёт паролем и привяжет единый вход руками
▪️ У провайдера через GOTCHA_OIDC_ENABLED саморегистрация и привязка по адресу теперь включаются отдельной переменной GOTCHA_OIDC_TRUST_EMAIL=true. Яндекс ID и VK ID не затронуты
⭐️ github.com/OtezVikentiy/gotcha/releases/tag/v1.5.1
🌐 getgotcha.ru/changelog/
💬 Чат: t.me/getgotcha
Четыре релиза за двое суток, собранные в одну запись: полный аудит кодовой базы 1.x и его устранение (1.4.0), починка ошибки, которую привезла сама эта волна (1.4.1), ещё две закрытые находки (1.5.0) и редкий отказ приёма, доведённый до корня (1.5.1). Контракт 1.0 держится: ни одна переменная окружения не переименована, адреса приёма и форматы тел запросов не менялись.
⚠️ Если вы на любой 1.x - обновляйтесь сразу на 1.5.1. На 1.4.0 останавливаться не нужно: сутки он отдавал каждую страницу больше килобайта как файл на скачивание. Сжатие уехало с неверным типом содержимого, 1.4.1 починил.
🔒 Безопасность
▪️ Разбор профилей ограничен по памяти: подготовленный профиль мог раздуть несколько килобайт входа в гигабайты кучи
▪️ Приём ограничивает частоту по адресу клиента до проверки ключа. Раньше поток запросов со случайными ключами доходил до кэша ключей и до базы с её небольшим общим пулом соединений, прежде чем быть отвергнутым
▪️ Значение метрики на краю диапазона float64 могло навсегда завесить обработчик, рисующий её график, сжигая ядро на каждую открытую страницу до перезапуска
▪️ Если инстанс когда-нибудь работал без GOTCHA_SECRET_KEY, всё зашифрованное с тех пор записано под ключом разработки. Перешифровать недостаточно - открытый текст уже попал в журнал упреждающей записи и в бэкапы, такие секреты нужно отозвать и выпустить заново. Теперь это видно метрикой gotcha_secret_key_insecure, а не только строкой в логе старта
⏱️ Вычислители под нагрузкой молча делали часть работы
▪️ Вычислители хостов, правил и SLO и планировщик эскалаций начинали свой список заново каждый тик: всё, что не влезало в бюджет, не проверялось вообще никогда, а в шторме планировщик снова и снова эскалировал одни и те же самые старые, пока новые ждали бесконечно. Теперь продолжают с места обрыва, а пропуск виден метрикой
📥 Приём и честность данных
▪️ Квота больше не списывается до разбора тела: битый или слишком большой запрос стоил квоты, не приняв ничего
▪️ Редкий отказ ClickHouse "use of closed network connection" доведён до корня: на отмене контекста батча клиент рвал сокет напрямую, минуя пул, - а соединение к этому моменту уже вернулось в пул и могло принадлежать постороннему запросу, который и падал
⚡️ Вычислитель хостов спрашивает один сгруппированный запрос на проект вместо запроса на хост. По живому журналу на пятистах хостах: 500 запросов и 750 000 прочитанных строк стали 1 запросом и 1 500 строк.
📚 Руководства сверены с кодом, а не с памятью. Справочник событий вебхука описывал 8 видов из 23 - теперь описаны все 23, и сторож не даёт списку снова разойтись с кодом. Пример SMTP использовал порт 465, на котором этот клиент не умеет говорить вовсе, так что почта просто висела до таймаута.
🔁 Отзыв одного диагноза: 1.3.1 объяснял "exec /usr/local/bin/gotcha: operation not permitted" докером из snap. Объяснение уехало на косвенных уликах, прямая контрпроба его не подтвердила. Раздел устранения неполадок больше не называет причину - он даёт две проверки, разделяющие "ограничения контейнера отвергнуты" и "сломан образ или бинарь".
⚠️ Два места требуют внимания при обновлении, оба про вход
▪️ Вход через единый вход организации больше не привязывается автоматически к существующему парольному аккаунту по совпадению адреса почты. Кто раньше входил одним нажатием, один раз войдёт паролем и привяжет единый вход руками
▪️ У провайдера через GOTCHA_OIDC_ENABLED саморегистрация и привязка по адресу теперь включаются отдельной переменной GOTCHA_OIDC_TRUST_EMAIL=true. Яндекс ID и VK ID не затронуты
⭐️ github.com/OtezVikentiy/gotcha/releases/tag/v1.5.1
🌐 getgotcha.ru/changelog/
💬 Чат: t.me/getgotcha