Очень наглядная демонстрация, почему integrity_check не равен проверке полноты: копия без файла WAL формально целая, но в ней нет всего, что ещё не попало в основной файл через checkpoint. Для расписания мне кажется самым надёжным VACUUM INTO или Backup API плюс сверка количества строк в ключевых таблицах после восстановления. Интересно, замеряли ли вы, насколько VACUUM INTO блокирует писателей на базе побольше?
Очень знакомо, что ценные решения живут в пересменках и чатах, а официальная база состоит из мануалов, которые никто не открывает. Мне кажется, главный вопрос тут даже не в создании, а в поддержке актуальности: инструкция, которая устарела на полгода, вредит больше, чем её отсутствие. Как вы решаете, кто отвечает за пересмотр статей, и есть ли у вас срок, после которого статья помечается как требующая проверки?
Хороший пример того, как рост accuracy на общем наборе маскирует провал на новом источнике: 8 из 20 вместо 16 на фиде партнёра в среднем просто растворяются. На практике проблема ещё и в том, что срез с 20 примерами слишком мал для уверенных выводов, поэтому полезно смотреть на доверительные интервалы recall по сегментам. Интересно, предлагаете ли вы фиксировать минимальный размер среза, ниже которого решение о релизе требует отдельной разметки?
Отличный пример того, как аккуратная обработка ошибок превращается в тихий отказ: каждый метод вежливо ловит исключение, и деградация становится нормой. Мне кажется, здесь помогла бы не только явная заглушка, но и метрика hit rate кэша с алертом, ведь ноль попаданий за восемь недель был бы виден сразу. А health check на зависимости при старте вы в итоге добавили, или решили, что сервис должен уметь жить без Redis?
Знакомая история, когда предрелизное тестирование превращается в главный этап поиска багов, а 10 человек проверяют одно и то же. Похоже, ключевой сдвиг в том, чтобы находить дефекты до Code Freeze, а не после. Интересно, как вы решили вопрос с полным ретестом после каждого исправления: перешли на ретест только затронутых областей или опираетесь на автотесты?
Интересная схема, когда газопоршневые установки работают как основной источник, а дизели остаются резервом. Насколько я понимаю, ГПУ довольно чувствительны к резким набросам нагрузки, поэтому интересно, как вы решаете переходные процессы: через ИБП и плавный прием нагрузки или параллельную работу с сетью? Будет здорово, если в следующих частях покажете схему переключений.
Падение числа вакансий младших сисадминов с 240 до 25 за пару лет выглядит очень показательно. Похоже, часть этих задач ушла в аутсорс и первую линию поддержки, а часть просто растворилась в обязанностях DevOps. Было бы интересно увидеть, насколько за тот же период выросло число вакансий с требованиями к автоматизации и IaC, чтобы понять, куда перетекает спрос.
Спасибо, что начали с авторизации, без неё все остальные примеры автоматизации обычно и упираются в документацию, которой уже нет. Для регулярных скриптов, наверное, разумнее сразу переходить на reference-токен отдельной сервисной учётки с минимальными правами, чем хранить пароль локальной УЗ. Как вы обрабатываете истечение Bearer-токена в долгих выгрузках: обновляете по ответу 401 или заранее по времени жизни?
Хорошо, что подняли тему прозрачности для сотрудников, на практике именно непонимание того, что собирает система, вызывает больше всего сопротивления. Мне кажется, многое решает понятный внутренний регламент: какие каналы контролируются, кто имеет доступ к инцидентам и сколько хранятся данные. Интересно, рекомендуете ли вы заранее показывать сотрудникам, как выглядит карточка инцидента, или это скорее вредит?
ViewTransition в стабильном API выглядит удобно, раньше приходилось вручную оборачивать обновления в document.startViewTransition и следить за синхронизацией с рендером. Интересно, как он ведёт себя в браузерах без поддержки View Transitions: просто молча применяет изменения без анимации? И не мешает ли он, если на странице уже есть анимации через CSS или сторонние библиотеки.
Полезный обзор, особенно для тех, кто дальше MergeTree обычно не заходит. Я бы добавил к рекомендациям предупреждение про ReplacingMergeTree: дедупликация происходит только при слияниях, поэтому без FINAL или агрегации в запросе дубликаты вполне могут попасть в отчёт. Интересно, используете ли вы на практике движки вроде Join или Set, или их обычно заменяют словарями?
OAuth 2.0 для SMTP действительно давно напрашивался, многие провайдеры корпоративной почты уже отключают обычную авторизацию по паролю. Интересно, как Joomla ведёт себя, если refresh token отзовут или он истечёт: администратор получает явное уведомление, или письма просто молча перестают уходить? Для форм и заказов второй вариант был бы довольно неприятным.
Очень узнаваемая картина, особенно про сети, которые растут сами собой, а растянутые VLAN потом становятся главным источником неизвестного юникаста. На практике самое сложное даже не спроектировать границу L2/L3 правильно, а убедить команду перенести её в существующей сети без простоя. Было бы интересно почитать, как вы рекомендуете поэтапно сужать домены L2, если сервисы уже завязаны на общий сегмент.
Понравилось, что вы аккуратно разобрали проблему одинаковых отметок времени, обычно на этом месте в оценке незаметно появляется утечка из будущего. Интересно, какой вклад в итоговое качество дают кандидаты из описаний и изображений по сравнению с переходами других посетителей. Для товаров с холодным стартом, наверное, именно они и вытаскивают выдачу, если не сравнивали отдельно на таком срезе?
Хороший разбор, особенно вопрос о том, куда на самом деле делся пароль после переноса в JCEKS. Ведь если пароль от самого хранилища остаётся дефолтным или лежит в переменной окружения рядом, то выигрыш скорее в том, что секрет не светится в выводе конфигов и в git. Интересно, как вы решаете ротацию: пересоздаёте JCEKS и раскатываете на все узлы, или сервисы умеют подхватывать новый файл без рестарта?
Хорошая тема, этот промежуточный слой действительно часто нужен небольшим командам. Интересно, как там решается сетевое взаимодействие между узлами и что происходит с сервисами, если один из узлов надолго пропадает из сети. Буду ждать продолжения с примерами обновления без простоя.
Спасибо за честную проверку на своем стенде, таких сравнений не хватает. Было бы интересно увидеть, как меняется потребление памяти при высокой кардинальности меток и частой ротации подов, потому что именно этот сценарий обычно сильнее всего бьет по Prometheus. И как ведет себя время выполнения тяжелых запросов за длинный период?
Сильный результат по времени обнаружения. Интересно, как вы решали вопрос с поздно приходящими событиями во Flink: какой водяной знак выбрали и не появилось ли из за него ложных срабатываний при всплесках задержки в Kafka? На практике именно этот баланс между скоростью и точностью обычно съедает выигрыш.
Интересный взгляд. Мне кажется, одна из главных проблем текущей стандартной библиотеки в том, что ее нельзя ломать ради улучшений, и неудачные решения живут десятилетиями. Как вы видите версионирование такой библиотеки, чтобы со временем можно было исправлять ошибки дизайна и при этом не разрывать экосистему?
Приятно видеть нативный заметочник без тяжелой обертки. Интересно, на чем сделан рендеринг текста и как обстоят дела с вводом через системные методы ввода, особенно для языков с составными символами. Обычно именно здесь у нативных интерфейсов на Rust больше всего сложностей, и это сильно влияет на ежедневное удобство.
Очень наглядная демонстрация, почему integrity_check не равен проверке полноты: копия без файла WAL формально целая, но в ней нет всего, что ещё не попало в основной файл через checkpoint. Для расписания мне кажется самым надёжным VACUUM INTO или Backup API плюс сверка количества строк в ключевых таблицах после восстановления. Интересно, замеряли ли вы, насколько VACUUM INTO блокирует писателей на базе побольше?
Очень знакомо, что ценные решения живут в пересменках и чатах, а официальная база состоит из мануалов, которые никто не открывает. Мне кажется, главный вопрос тут даже не в создании, а в поддержке актуальности: инструкция, которая устарела на полгода, вредит больше, чем её отсутствие. Как вы решаете, кто отвечает за пересмотр статей, и есть ли у вас срок, после которого статья помечается как требующая проверки?
Хороший пример того, как рост accuracy на общем наборе маскирует провал на новом источнике: 8 из 20 вместо 16 на фиде партнёра в среднем просто растворяются. На практике проблема ещё и в том, что срез с 20 примерами слишком мал для уверенных выводов, поэтому полезно смотреть на доверительные интервалы recall по сегментам. Интересно, предлагаете ли вы фиксировать минимальный размер среза, ниже которого решение о релизе требует отдельной разметки?
Отличный пример того, как аккуратная обработка ошибок превращается в тихий отказ: каждый метод вежливо ловит исключение, и деградация становится нормой. Мне кажется, здесь помогла бы не только явная заглушка, но и метрика hit rate кэша с алертом, ведь ноль попаданий за восемь недель был бы виден сразу. А health check на зависимости при старте вы в итоге добавили, или решили, что сервис должен уметь жить без Redis?
Знакомая история, когда предрелизное тестирование превращается в главный этап поиска багов, а 10 человек проверяют одно и то же. Похоже, ключевой сдвиг в том, чтобы находить дефекты до Code Freeze, а не после. Интересно, как вы решили вопрос с полным ретестом после каждого исправления: перешли на ретест только затронутых областей или опираетесь на автотесты?
Интересная схема, когда газопоршневые установки работают как основной источник, а дизели остаются резервом. Насколько я понимаю, ГПУ довольно чувствительны к резким набросам нагрузки, поэтому интересно, как вы решаете переходные процессы: через ИБП и плавный прием нагрузки или параллельную работу с сетью? Будет здорово, если в следующих частях покажете схему переключений.
Падение числа вакансий младших сисадминов с 240 до 25 за пару лет выглядит очень показательно. Похоже, часть этих задач ушла в аутсорс и первую линию поддержки, а часть просто растворилась в обязанностях DevOps. Было бы интересно увидеть, насколько за тот же период выросло число вакансий с требованиями к автоматизации и IaC, чтобы понять, куда перетекает спрос.
Спасибо, что начали с авторизации, без неё все остальные примеры автоматизации обычно и упираются в документацию, которой уже нет. Для регулярных скриптов, наверное, разумнее сразу переходить на reference-токен отдельной сервисной учётки с минимальными правами, чем хранить пароль локальной УЗ. Как вы обрабатываете истечение Bearer-токена в долгих выгрузках: обновляете по ответу 401 или заранее по времени жизни?
Хорошо, что подняли тему прозрачности для сотрудников, на практике именно непонимание того, что собирает система, вызывает больше всего сопротивления. Мне кажется, многое решает понятный внутренний регламент: какие каналы контролируются, кто имеет доступ к инцидентам и сколько хранятся данные. Интересно, рекомендуете ли вы заранее показывать сотрудникам, как выглядит карточка инцидента, или это скорее вредит?
ViewTransition в стабильном API выглядит удобно, раньше приходилось вручную оборачивать обновления в document.startViewTransition и следить за синхронизацией с рендером. Интересно, как он ведёт себя в браузерах без поддержки View Transitions: просто молча применяет изменения без анимации? И не мешает ли он, если на странице уже есть анимации через CSS или сторонние библиотеки.
Полезный обзор, особенно для тех, кто дальше MergeTree обычно не заходит. Я бы добавил к рекомендациям предупреждение про ReplacingMergeTree: дедупликация происходит только при слияниях, поэтому без FINAL или агрегации в запросе дубликаты вполне могут попасть в отчёт. Интересно, используете ли вы на практике движки вроде Join или Set, или их обычно заменяют словарями?
OAuth 2.0 для SMTP действительно давно напрашивался, многие провайдеры корпоративной почты уже отключают обычную авторизацию по паролю. Интересно, как Joomla ведёт себя, если refresh token отзовут или он истечёт: администратор получает явное уведомление, или письма просто молча перестают уходить? Для форм и заказов второй вариант был бы довольно неприятным.
Очень узнаваемая картина, особенно про сети, которые растут сами собой, а растянутые VLAN потом становятся главным источником неизвестного юникаста. На практике самое сложное даже не спроектировать границу L2/L3 правильно, а убедить команду перенести её в существующей сети без простоя. Было бы интересно почитать, как вы рекомендуете поэтапно сужать домены L2, если сервисы уже завязаны на общий сегмент.
Понравилось, что вы аккуратно разобрали проблему одинаковых отметок времени, обычно на этом месте в оценке незаметно появляется утечка из будущего. Интересно, какой вклад в итоговое качество дают кандидаты из описаний и изображений по сравнению с переходами других посетителей. Для товаров с холодным стартом, наверное, именно они и вытаскивают выдачу, если не сравнивали отдельно на таком срезе?
Хороший разбор, особенно вопрос о том, куда на самом деле делся пароль после переноса в JCEKS. Ведь если пароль от самого хранилища остаётся дефолтным или лежит в переменной окружения рядом, то выигрыш скорее в том, что секрет не светится в выводе конфигов и в git. Интересно, как вы решаете ротацию: пересоздаёте JCEKS и раскатываете на все узлы, или сервисы умеют подхватывать новый файл без рестарта?
Хорошая тема, этот промежуточный слой действительно часто нужен небольшим командам. Интересно, как там решается сетевое взаимодействие между узлами и что происходит с сервисами, если один из узлов надолго пропадает из сети. Буду ждать продолжения с примерами обновления без простоя.
Спасибо за честную проверку на своем стенде, таких сравнений не хватает. Было бы интересно увидеть, как меняется потребление памяти при высокой кардинальности меток и частой ротации подов, потому что именно этот сценарий обычно сильнее всего бьет по Prometheus. И как ведет себя время выполнения тяжелых запросов за длинный период?
Сильный результат по времени обнаружения. Интересно, как вы решали вопрос с поздно приходящими событиями во Flink: какой водяной знак выбрали и не появилось ли из за него ложных срабатываний при всплесках задержки в Kafka? На практике именно этот баланс между скоростью и точностью обычно съедает выигрыш.
Интересный взгляд. Мне кажется, одна из главных проблем текущей стандартной библиотеки в том, что ее нельзя ломать ради улучшений, и неудачные решения живут десятилетиями. Как вы видите версионирование такой библиотеки, чтобы со временем можно было исправлять ошибки дизайна и при этом не разрывать экосистему?
Приятно видеть нативный заметочник без тяжелой обертки. Интересно, на чем сделан рендеринг текста и как обстоят дела с вводом через системные методы ввода, особенно для языков с составными символами. Обычно именно здесь у нативных интерфейсов на Rust больше всего сложностей, и это сильно влияет на ежедневное удобство.