Лишь бы юзер был доволен
Если у вас больше одного аккаунта Codex, начинается классическая путаница: какой auth.json сейчас активен, где закончился лимит и что вообще происходит. Я написал небольшой CLI на bash, который решает эту проблему: переключение профилей, просмотр usage через API, кеш и поддержка прокси. Показываю, как это устроено и как использовать.
В Kafka данные могут пропадать, даже если в конфигах стоит хранение 7 дней. В этом коротком кейсе — как я решил проблему потери данных, внедрив мониторинг «окна безопасности».
Проблема: Байты сильнее времени
Решение: Метрика «Data Safety Window»
Конфигурация — это лишь декларация о намерениях. Реальное окно жизни данных диктует нагрузка в моменте.
Чтобы не гадать по конфигам, я внедрил расчет фактического запаса времени в Grafana.
Разбор HTTP/HTTPS‑трафика, потерянных заголовков и умирающих сессий съедает время, особенно когда всё это приходится делать консольными утилитами или через логи. Под катом я собрал 10 инструментов, которые помогут в дебаге запросов и сэкономят нервы.
Разбираем Common Vulnerability Scoring System – что скрывается за цифрой от 0 до 10, как читать базовые, временные и контекстные метрики, и где искать актуальную информацию об уязвимостях.
Идея этого проекта пришла мне в голову около семи лет назад, но до реализации я добрался только сейчас, т.к. есть некоторое время на это, пока ищу новую работу. Ну, и важно упомянуть, что я уже более 10 лет занимаюсь русской локализацией продуктов и сервисов Mozilla.
Мы привыкли говорить о защите серверов, рабочих станций, сетевого периметра, удостоверяющих систем, средств контроля доступа и ещё десятка важных вещей. Но браузер в организациях при этом слишком часто остаётся где-то в серой зоне. Он как будто есть сам по себе: установлен, как-то настроен, где-то применяются политики — и на этом разговор обычно заканчивается.
Хотя на практике браузер давно уже не просто программа для просмотра сайтов. Это рабочий шлюз ко всему: внутренним системам, облачным службам, корпоративной почте, документообороту, административным панелям, порталам, личным кабинетам и множеству других сервисов, через которые в компании реально проходят данные и процессы. Именно об этом я недавно писал в BIS Journal, где попытался показать браузер как важное, но часто недооценённое звено корпоративной кибербезопасности.
Для меня эта тема не случайна. Раньше я занимался развитием продукта X-Config в Spacebit — решения, связанного с безопасностью конфигураций программного обеспечения. Тогда мне пришлось довольно глубоко погрузиться в саму логику безопасной настройки: как появляются профили, как они согласуются, где заканчивается методология и начинается ручная рутина, почему даже хорошие требования без нормального инструментария быстро превращаются в набор разрозненных действий. В интервью для «Банковского обозрения» мы как раз обсуждали профили безопасного конфигурирования, роли специалистов по ИБ и администраторов, а также то, что такие профили должны жить не как памятка в PDF, а как часть управляемого процесса.
В этой статье мыпопробуем провести небольшое расследование, посвященное тому, как найти и обезвредить «тихого убийцу». В частности, мы на конкретных примерах разберём утечки памяти, фрагментацию дисков, проблему 95-го перцентиля и «зловещую тишину» в логах. А также, рассмотрим инструменты, которые не дадут производительности умереть незаметно.
Docker Swarm предоставляет встроенный механизм управления секретами: пароли, ключи API и сертификаты передаются в контейнеры через зашифрованный канал и монтируются в /run/secrets/. Звучит безопасно — пока вы не осознаете, что любой пользователь с доступом к docker exec может прочитать эти секреты в любой момент жизни контейнера.
В этой статье я разберу, почему стандартные способы защиты не работают, и покажу решение на основе именованных каналов (FIFO), которое позволяет секрету быть прочитанным ровно один раз — при старте приложения.
Во многих командах сегодня все выглядит «как положено»: Kubernetes, CI/CD, Terraform, DevOps-команда на месте.
Но по мере роста системы появляется другой эффект: разработка тормозит не из-за кода, а из-за инфраструктуры. Любое изменение проходит через одну точку — DevOps.
И дело не в том, что команда работает плохо. Просто через нее проходит все: задача уходит в очередь, возвращается на доработку и снова ждет. Бизнес давит на скорость, но инфраструктура не успевает.
Привет, Хабр! Меня зовут Павел Лавров, я owner нового продукта в экосистеме Orion soft — GitOps-платформы HyperDrive. И в этой статье я расскажу, почему проблема не в людях и не в инструментах — она в самой модели работы с инфраструктурой. Давайте разберемся, как возникает это узкое место и что меняется, если его убрать.
Меня зовут Григорий Орлов, я руководитель команды разработки сетевых сервисов гибридных облаков в Yandex Cloud. В статье расскажу про детали работы наших сервисов на уровне Config Plane — это уровень, на котором пользователь может задавать целевое состояние системы. А именно речь пойдёт про CIC‑API — сервисе управления железом, которое стоит на наших точках присутствия и участвует в работе Cloud Interconnect, необходимого для создания приватных выделенных сетевых соединений.
Всем привет, на проводе снова я и опять буду донимать всех своей синхронизацией. В этом цикле статей предлагаю хорошенечко разобраться в фазовой синхронизации на основе протокола PTPv2 G.8275.1 и его верном спутнике технологии частотной синхронизации Synchronous Ethernet. Изучать будем от и до: физический уровень, для интереса заглянем в осциллограммки, посмотрим на сигнальный обмен, расковыряем дампы, посчитаем параметры, проведем пару сеансов разоблачения, узнаем почему QoS’ы стали нафиг не нужны, как линчевание негров и повесточка изменили PTP, поиграемся в хроматическую дисперсию, увидим какие данные можно выжать с Huawei и Juniper, а также узнаем особенности их работы и где можно неудачненько влететь. К концу пьесы выясним, почему PTP без SyncE пиво без водки деньги на ветер. Информации миллиард и на удивление почти вся по делу. Наберитесь терпения, постепенно все станет ясно.
Я не особо люблю освещать «текущие события», но правительство США на днях заявило о введении реально шокирующего запрета на импорт роутеров потребительского сегмента. Это идиотский запрет по целому ряду причин, но если он действительно вступит в силу, то навык сборки «самопального» роутера может оказаться весьма кстати.
К счастью, вы можете собрать его из практически всего, что можно хоть в какой-то степени назвать компьютером.
Реализация стандарта 6G находится на ранних этапах — Международный союз электросвязи, консорциум 3GPP и коммерческие компании все еще занимаются разработкой спецификации. Но регуляторы и телекомы уже готовятся к запуску, не желая повторять ошибки, допущенные при реализации сетей пятого поколения. При этом ожидается, что сети и устройства 6G будут плотно интегрированы с системами ИИ.
Недавно позвонил мне знакомый — у них в организации возникла потребность в файловом сервере. Первым делом я, конечно, предложил что-то проверенное, вроде готового решения от Synology. У меня уже был опыт настройки таких NAS — всё понятно, удобно и стабильно работает.
Правда, был ещё опыт с файловыми помойками на Windows Server — и, честно говоря, удовольствия от них немного. Всё как-то через одно место, да и смысла в этом особо не вижу, особенно для небольших задач.
Но тут всплыла старая добрая классика — «а можно подешевле?». Бюджет у организации ограничен, поэтому от идеи покупки NAS пришлось отказаться. Вместо этого предложил использовать уже имеющийся в офисе компьютер и собрать на нём свой файловый сервер.
Начал искать self-hosted решения. Наткнулся на TrueNAS — слышал о нём раньше, но не пробовал вживую. Решил развернуть тестовый вариант у себя в Proxmox: один виртуальный диск для системы, два других — под зеркалирование (RAID1). Немного покопался — и понял: вот оно.
Для себя я определил три обязательных условия:
В медиаполе снова пошла знакомая волна предупреждений: пользоваться VPN и другими средствами обхода блокировок не только нежелательно, но еще и опасно. Мошенники крадут данные, учетные записи и деньги, а доверчивый пользователь, разумеется, остается крайним.
Рациональное зерно в этом, конечно, есть. Случайные VPN-сервисы - особенно бесплатные, непрозрачные и обещающие «полную анонимность в один клик» - действительно могут оказаться сомнительным выбором. Когда весь ваш трафик идет через неизвестно чью инфраструктуру, вопрос доверия перестает быть теоретическим.
Но дальше обычно начинается привычная подмена. Из тезиса «не стоит пользоваться чем попало» очень быстро пытаются перейти к тезису «не стоит пользоваться ничем вообще». И вот это уже больше похоже не на заботу о безопасности, а на очередную попытку объяснить, что ограниченный интернет - это и есть нормальный интернет.
На практике все работает ровно наоборот. Чем больше ограничений, тем выше спрос на инструменты обхода. И если уж выбирать между случайным коммерческим VPN, бесплатным приложением с мутной моделью монетизации и собственным сервером, то self-hosted-вариант выглядит как минимум достойным внимания.
Поэтому дальше речь пойдет не о том, почему VPN - это страшно, а о том, как сделать его своим: развернуть self-hosted AmneziaWG с помощью install-скрипта и дополнить его веб-интерфейсом для управления пользователями.
Когда мы запускаем контейнер, в большинстве случаев предварительно нужно указать настройки: порт, пароль, режим работы, адрес базы и т. д. Зачастую такие параметры жестко прописывают в самом коде, но это плохой стиль и вообще идея так себе. В будущем вы можете «затроить» и все это слить в git-репозиторий. А как мы знаем, хранить чувствительные данные в там нельзя.
Удобнее и гибче использовать переменные окружения. Те самые, которые environment variables. С помощью переменных можно настраивать поведение контейнера, использовать разные конфигурации (dev/stage/prod), безопасно передавать чувствительные данные. Как видите, одни плюсы.
Работа с переменными в Podman строится практически так же, как в Docker. Есть некоторые нюансы, но о них расскажу чуть позже. Сейчас давайте потыкаем на практике и посмотрим, что же происходит.
Один AI-агент на базе Claude Sonnet закрывает 100% моих DevSecOps-задач. Без фреймворков, без оркестраторов, без векторных баз. Только LLM, операционная система и markdown-файлы. Рассказываю архитектуру, которая за этим стоит.
Логическая репликация в Postgres редко ломает прод внезапно — чаще она долго и методично копит проблему, пока replication slot удерживает всё больше WAL, потребитель отстаёт, а свободное место на диске начинает таять. В этой статье разбирается именно такая зона риска: как устроена работа replication slots, почему одних базовых настроек здесь недостаточно и какие практики реально помогают держать под контролем WAL, публикации, heartbeats, failover и мониторинг. Материал особенно полезен тем, кто работает с CDC, Debezium и production-инстансами Postgres, где цена ошибки измеряется уже не теорией, а стабильностью системы.
Я не собирался делать этот проект.
Просто однажды сломал систему — и понял, что rollback на ext4 не такая простая вещь, как кажется.
В итоге собрал своё решение на rsync: быстрый и предсказуемый откат без смены файловой системы.
Кода тут минимум — он на GitHub. В статье — про сам подход: проблему, попытки решения и итог.
После ухода с рынка исторических лидеров в области складского оборудования выбор терминала сбора данных (ТСД) стал сложной практической задачей. Появилось множество новых брендов и моделей, и оценивать их только по техническим характеристикам из каталогов оказалось недостаточно. Потребовалась система оценки, основанная на понимании реальных складских процессов.
Мы, INTEKEY, с 2017 года автоматизируем склады. Наш опыт работы с лидерами рынка позволил сформировать чёткий стандарт требований к оборудованию. Когда привычные решения стали недоступны, мы последовательно применили этот стандарт для поиска и тестирования новых партнёров.
В этой статье разберем:
- наш метод оценки ТСД, основанный на анализе поведения устройства в реальных рабочих условиях
- какие, на первый взгляд, незначительные параметры на самом деле определяют скорость операций, количество ошибок и простоев
- какой путь мы прошли, выбирая партнеров после ухода с рынка исторических лидеров, и на каких брендах остановились
- примеры моделей под разные роли на складе;
- практические аспекты интеграции: какие особые требования появляются при работе с маркировкой «Честный знак»
Представьте: у компании 300 подразделений по всей стране или пять производственных площадок от Москвы до Дальнего Востока. Как узнать, сколько реально ноутбуков в омском филиале, где они находятся и в каком статусе принтер, купленный два года назад: используется, неисправен, в ремонте или уже подлежит списанию? Если данные приходят через мессенджеры или эксельные файлы, присланные раз в квартал — вы уже в зоне риска.