Привет, Хабр. Расскажу, как за 10 часов написал self-hosted аналог ngrok на Go.
Проблема
Нужно протестировать вебхук от Т-Банк/Telegram/любого внешнего сервиса. Запускаешь ngrok — не работает. Россия заблокирована. Каждый раз VPN, а с ним становится недоступна часть внутренних ресурсов. В какой-то момент решил написать своё.
Разворачивать приложения в облаке должно быть просто. Но на деле - всё наоборот. Вместо “вжух-вжух и в продакшн” получаем вечер с документацией, пляски с параметрами Terraform и постоянную проверку, правильно ли связались ресурсы.
В статье разберемся, как от использования UI консоли приходят к Terraform, и как OpenIDE позволяет вернуть легкость UI консоли при работе с Terraform.
Привет, Хабр! Я Даниил Салман, техлид по контейнеризации. Эта статья написана по мотивам моего доклада для конференции DevOops. Разберёмся, как сделать такую ML-«песочницу», где Data Scientist пишет код, а всё остальное (установка драйверов, выделение ресурсов, деплой и тренировка модели, сбор метрик) уже настроено на бэкенде. Написали максимально просто и доступно, чтобы понять смог даже человек с минимальным погружением в тему. Идеи из этой статьи можно применять в любой инфраструктуре — важно лишь понимать основы: как работает k8s-кластер, Docker и python-фреймворки. Итак, поехали!
Разработка сервисов с интеграцией в AWS быстро упирается в компромиссы: либо работать с реальным облаком и платить за каждый эксперимент, либо замокать инфраструктуру и надеяться, что в продакшене всё «взлетит». В статье показано, как с помощью .NET Aspire и LocalStack выстроить полноценное локальное AWS-окружение — с S3, CDK и реальной оркестрацией — так, чтобы один и тот же код без условностей работал и локально, и в проде.
Когда мы впервые увидели AI-чаты, это выглядело впечатляюще. Они писали код, помогали с документацией, объясняли архитектурные решения.
Это было хорошо. Но довольно быстро стало понятно главное:
Всем привет!
Так вышло, что в месте, где я преподаю и занимаюсь менторством стажёров, начался переход с GitHub-репозиториев на GitLab, развёрнутый на собственных серверах. Пока что перенесли не все проекты, но даже этого оказалось достаточно, чтобы у стажёров возникло немало вопросов — особенно в части настройки CI/CD-процессов.
Формально CI/CD в GitHub и GitLab решают одну и ту же задачу, но на практике подходы, терминология и детали конфигурации отличаются. Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.
У меня уже есть статья про CI/CD и workflow, но она целиком посвящена GitHub Actions. Чтобы сократить количество вопросов, разночтений и бессонных ночей у стажёров, я решил написать отдельную статью про CI/CD именно в GitLab — с учётом его особенностей и типичных подводных камней.
Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.
Юнит-тесты дают чувство контроля — ровно до первого странного падения «только у одного клиента», под нагрузкой, на другой версии ядра, с неожиданными сетевыми ретраями и капризами аллокатора. В Quasar, распределённой системе хранения данных в реальном времени, эту реальность приняли как исходную: предугадать всё невозможно, поэтому уверенность строится не на одном виде тестов и не на «серебряных пулях», а на процессе, который ловит ошибки как можно раньше и системно закрывает зоны риска.
Согласитесь, что встретить Новый год рядом с семьёй и друзьями - намного приятнее, чем сидеть за ноутбуком в 02:40 и с квадратными глазами разбираться, почему “что-то там легло”, а доступ к нужным секретам остался только у одного человека… который как раз в этот момент режет оливье и не слышит телефон.
Ниже я делюсь своим чеклистом из 8 пунктов. Он помогает спокойно уйти в праздники и не проводить их в обнимку с ноутом. А после прочтения, в комментах, обязательно поделитесь что бы вы еще добавили.
В статье подробно разбираем, как устроен CSI (Container Storage Interface), как проходит жизненный цикл тома от PVC до удаления и что на самом деле делают sidecar-контейнеры и драйверы.
Мы ожидали увидеть очередную «легкую» модель для телефонов, а нашли hidden gem, который генерирует учебные материалы лучше, чем модели в 100 раз больше. Подробный разбор с JSON‑ами, промптами и сравнением.
В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».
Однако спустя полтора десятилетия крупные облачные и корпоративные платформы по-прежнему говорят языком транзакций, изолированных операций и строгой согласованности.
Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени?
В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.
Привет! С вами Максим Бурцев, руководитель отдела мониторинга в Купере. Пусть название отдела не вводит вас в заблуждение: мы занимаемся не только мониторингом, но и остальными процессами, которые связаны с инцидентами. До, во время и даже после того, как проблемы решены. Сегодня хочу поделиться опытом внедрения нетривиальных инструментов и методов, которые сделали наши процессы удобными, понятными и эффективными.
Мы доверили ИИ первым реагировать на критические инциденты в продакшене. Это сократило время реакции, но одна его галлюцинация едва не отправила весь кластер в ребут...
История о том, как мы получили мощного, но странного стажёра, с которым нельзя оставаться наедине.
Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. В этот раз я решил помочь вам посмотреть на свою работу в отношении надежности. Особенно полезно будет тем, у кого официально нет SR-инженеров в штате.
"У нас нет SRE" – не значит "у нас нет надёжности". Даже без SRE-инженера ваша команда уже что-то делает для надёжности.
Покажу, как увидеть уже существующие у вас практики и понять, куда двигаться дальше.
Коллеги, всем привет!
Долгое время в нашей внутренней сети для обработки DNS-трафика мы использовали только BIND, и нам с ним было хорошо. Но в какой-то момент его возможностей перестало хватать. В статье расскажу, что именно с BIND не так и почему теперь весь DNS-трафик у нас проходит через DNSdist. И что это вообще такое...
Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить.
Одна команда — и Claude Code сам анализирует коммиты, определяет тип релиза, генерирует changelog, обновляет версии и пушит в GitHub. Разбираем внутрянку 1000-строчного bash-скрипта.
DevOps давно перестал быть просто набором инструментов или должностью, в которой достаточно знать только Docker. DevOps стал целой культурой, интегрирующей разработку и эксплуатацию, автоматизацию, мониторинг, качество и скорость поставки изменений. К 2026 году DevOps глубже сливается с платформенной инженерией, SRE-подходами и архитектурой облаков. Соответственно, требования к инженерам растут.
Что ожидают от DevOps-специалистов в 2026 году, какие навыки становятся важными и как построить карьеру от начинающего инженера к платформенному, — объясняем в статье.
Привет, Хабр! Меня зовут Андрей Басов, я руководитель команды технической поддержки стрима корпоративных продуктов и сервисов в MWS. Вместе со своими коллегами — Тимуром Хабибулиным (data scientist) и Рафисом Ганеевым (senior devops engineer) — занимаюсь технической поддержкой и сопровождением продуктов линейки Partner Experience Platform.
Чтобы улучшить качество наших сервисов, через которые МТС взаимодействует с партнерами, мы вынуждены постоянно внедрять новые решения, растить продукты и развивать их архитектуру, при этом нам важно обеспечивать надежность и стабильность работы ИТ-систем. Это не всегда дается легко, ведь объемы данных растут, и их нужно эффективно обрабатывать. Одной из основных проблем становится анализ логов — текстовых записей. В нашем случае они фиксируют события в работе систем, которые созданы за 25+ лет работы компании, а еще у них различные стеки и архитектурные подходы.
Объемы данных настолько велики, что проанализировать вручную (например, в OpenSearch/Kibana) даже один продукт практически невозможно, иначе нам пришлось бы просматривать миллионы строк логов каждый день. Поэтому мы решили разработать систему, которая позволила бы автоматически выявлять в логах аномалии — события, не свойственные нормальному функционированию системы. Например, это могут быть следы багов, вызванных новыми релизами, или другие непредвиденные происшествия. Что из этого вышло — расскажу дальше.
Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. Мы в своей компании давно используем vector.dev для обработки логов, о чем я рассказывал в предыдущих статьях (раз, два). Мне попалась интересная статья на английском языке о vector.dev и как можно сломать по-тихому незаметно для себя конвейер "правильными" данными и настройками. Представляю свое виденье этого материала.
