Администрирование

Продолжаем цикл статей о протоколе HTTP: расскажем, что нового привнесла версия HTTP/1.1 и какие у нее принципиальные отличия с версией HTTP/2.

Из-за того, что наша компания занимается аутсорсом разработки, в работе одновременно много проектов. На разработку и поддержку каждого требуется много времени и ресурсов. 

Мы уделяем большое внимание инфраструктуре и различным способам повышения эффективности разработки. В общем, по сути это и есть DevOps — Development & Operations. Только отдельных специалистов для этого у нас не было, и задачи закрывали хаотично и силами лидов.

В какой-то момент основатели KTS поняли, что услуга может быть актуальна на рынке: если у нас есть такая проблема, значит и другие компании с ней сталкиваются.

В статье рассказываю, как запустить новую услугу в компании по уму, а не как это обычно бывает.

Привет! Мы в МТС Digital умеем и любим создавать высоконагруженные IT-решения. Для вывода таких продуктов в промышленную эксплуатацию необходимо научиться решать задачи постоянного самоанализа работоспособности, мониторинга, проверки соответствия заявленным SLA.

Меня зовут Глеб Тильтиков, я технический руководитель омниканальной платформы MTC OmniChannel, и о внедрении самодиагностики в IT-продукте большой цифровой экосистемы и пойдёт речь в этой статье.

У нас есть прокатный Стан-2000. 2 000 — это не год создания, а длина бочки рабочего валка в миллиметрах, а значит, ширина стальной полосы. Стан раскатывает металлический слиток под названием сляб (примерно 25 тонн, толщиной 25 см и длиной — 10–12 м) в стальную полосу длиной до 1,5 км.

Всё, что входит в стан с одной стороны, проедет целых 1 500 метров до самых моталок, будет раскатано и смотано в готовый рулон. На выходе толщина полосы — минимум 1,45 мм, а в среднем — около 3 мм. Поскольку стан длиннющий, на нём едет сразу несколько слябов/полос: пока одна полоса в конце стана сматывается в рулон, другая катается, и ещё пара слябов уже выходит на стан из печи.

Это ключевое звено всего производства. Производительность цеха во многом определяется тем, насколько хорошо мы загружаем прокатный стан.

Естественно, что мы хотим загрузить на стан как можно больше слябов, но при этом точно вовремя, чтобы они не помешали друг другу. Поэтому важно:

1) Чтобы слябы не догоняли друг друга, потому что тогда будет пробка и всё остановится.

2) Чтобы разрыв между слябами был минимальным, то есть подаваться они должны почти впритык.

Задача сводится к пониманию того идеального момента, когда надо подавать на стан следующий сляб.

До появления ИТ-системы, о которой и хотим рассказать, люди в общем неплохо справлялись, но они всегда перестраховывались и закладывали несколько дополнительных секунд паузы между слябами (такой пессимистичный прогноз вместо оптимального).

Ведь сложность ещё и в том, что в зависимости от того, какой типоразмер полосы нужно получить, прокатывать нужно с разной скоростью. А ещё есть совершенно неалгоритмизируемые факторы типа «как-то не так дрожит полоса» и «что-то мне звук не нравится» — их мы пока не можем выделить для полной автоматизации.

То есть нам нужна система, которая работает в паре с человеком (точнее, командой из четырёх человек): модель принимает решение, а люди могут вносить корректировки, если их опыт подсказывает, что нужно поступить иначе.

Транскрипт доклада Wiren Board с конференции и выставки WBCE 2023.

Мы расскажем о быстром Modbus, который значительно ускоряет хорошо знакомый всем протокол, о новых устройствах и планах разработки.

Допустим, вам нужно перенести хранилище данных из одного кластера в другой. А выключать его нельзя, потому что это может вызвать незначительный (или значительный) коллапс сервисов, которые с ним работают. В статье мы расскажем о не самом очевидном и популярном способе переноса etcd из одного облачного кластера Kubernetes в другой. Такой способ поможет избежать простоя и связанных с ним последствий. Согласно стартовым условиям, оба кластера находятся в облаке, а потому нам предстоит столкнуться с некоторыми ограничениями и трудностями — им мы уделим особое внимание.

Ранее мы рассказывали об иностранных госкорпорациях, которые начали давать рекомендации по миграции на протокол нового поколения. Сегодня продолжим тему и посмотрим, какие дискуссии ведут на законодательном уровне.

В этой статье я постараюсь достаточно полно и популярно объяснить, что из себя представляют современные радиорелейные станции, исходя из десятилетнего опыта эксплуатации. Исторический очерк о становлении будет в следующей статье.

Ранее мне попадались фрагменты лекций, которые читаются в ряде профильных ВУЗов. И должен заявить, что они имеют мало общего с реальностью и скорее напоминают не всегда качественный перевод европейских стандартов связи. Это является очередным свидетельством отсутствия взаимодействия между научными учреждениями и отраслевыми предприятиями в нашей стране.

Так как отраслевые предприятия до последнего момента были ориентированы на импорт, то в этом нет ничего удивительного. Не удивительно и то, что в свою очередь, на предприятиях сформировалось немало пагубных заблуждений технического характера, которые до сих пор имеют негативные последствия.

Предлагаю вам вместе пройтись по основам и разложить все по полочкам.

Привет! На связи Максим Рязанцев, DevOps-специалист в AGIMA. В начале недели GitLab выпустил новую версию — версию 16.0. Всего в ней более 55 новых фич и доработок. Мы с коллегами изучили этот список, разобрались, как нововведения повлияют на работу с Git. И теперь делимся коротким обзором. Как водится, большая часть изменений в облачной Ultimate-версии, но рано или поздно доступны они будут всем.

Всем привет! Меня зовут Максим Еремин, я занимаюсь развитием платформенных продуктов в beeline cloud. В этой статье поговорим про контейнерную разработку в облаках, рассмотрим, в каких реалиях живут облачные провайдеры, включая российских игроков и гигантов зарубежного рынка. 

Отдельно расскажу про особенности serverless-подхода. А если вы хотите узнать о serverless больше, погрузиться в DevOps-практику и посмотреть демо по управлению контейнерами — жду вас на вебинаре «Easy to use: управление контейнерами в облаке», который пройдет 30 мая в 11:00 мск. Приходите — пообщаемся в онлайне 🙂

Введение

Информационное моделирование различных объектов все больше и больше внедряется в нашу жизнь, а методологии и инструменты для проектирования постоянно совершенствуются, появляется больше возможностей для повышения эффективности процессов проектирования, строительства и эксплуатации. Как и за счет чего при внедрении цифровой информационной модели (ЦИМ) происходит улучшение показателей работы технологических систем?

Цель данной статьи – рассмотреть решение проблем, связанных с проектированием, строительством и эксплуатацией электроэнергетического оборудования при внедрении ЦИМ.

Немного о ЦИМ…

Цифровая информационная модель (ЦИМ) – объектно-ориентированная параметрическая 3D-модель, представляющая в цифровом виде физические, функциональные и прочие характеристики объекта (или его отдельных частей) в виде совокупности информационно насыщенных элементов.

Привет, Хабр!

Технология eBPF становится все более популярной и используются во многих приложениях для Linux. В нашей статье Анализ и обнаружение Dirty Pipe мы коснулись темы eBPF и как он может помочь при обнаружении эксплуатации уязвимостей ядра. Но инструмент с такими возможностями непременно заинтересует и злоумышленников. В этой статье мы рассмотрим, каким образом атакующие могут использовать eBPF и как можно их обнаружить.

Для загрузки eBPF модуля необходимы права root или привилегии CAP_BPF. Поэтому в основном злоумышленники используют данные программы для закрепления или сокрытия вредоносного ПО в системе. Для этого используются различные наборы инструментов, основанных на eBPF. В данной статье мы рассмотрим известные вредоносные eBPF инструменты и возможные способы детектирования.

В открытом доступе есть различное вредоносное ПО, основанное на eBPF, мы выбрали наиболее многофункциональные:

https://github.com/Gui774ume/ebpfkit
https://github.com/pathtofile/bad-bpf
https://github.com/krisnova/boopkit
https://github.com/h3xduck/TripleCross

Данные инструменты имеют множество различных функций, которые вы бы вряд ли хотели увидеть у себя в инфраструктуре. Их возможности могут вас удивить, так как они могут:

Всем привет! Меня зовут Антон Брехов. Я инженер в Yandex Cloud. Сегодня хочу рассказать о том, как дешевле всего задеплоить своего телеграм-бота. Возможно, этот опыт пригодится и для других решений.

Готовых фреймворков для телеграм-ботов уже достаточно много на любых языках. Однако после написания кода встает вопрос: а как теперь заставить бота работать постоянно, сделать доступным 24/7?

Новички оставляют персональный компьютер работающим и опрашивают сервер телеграма с некоторой частотой. У опытных, скорее всего, есть свой VPS-сервер с reverse proxy для деплоя приложений. Первое решение не является высокодоступным, а отдельный сервер, даже в облаке, — это слишком дорого для деплоя одного бота. В статье расскажу об альтернативном решении.

WARNING: длинная вступительная часть. Если хотите перейти сразу к делу - листайте до Getting Started.

Большинство из нас думают о машинном обучении как о "черном ящике", который принимает некоторые данные и выдает отличные результаты. В последние годы этот черный ящик работает как имитация человека в соответствующих областях, где он используется, и достигает выдающихся результатов.

Не смог найти нормальную актуальную инструкцию по мониторингу линуксовых логов заббиксом - сделал свою, под 6.4.

И отвлекусь на установку агента - не зря же писал скрипт...

Наверное, многим знакомо ощущение, когда приходит время переделывать хорошо отлаженный продукт. Он работает, стабилен, предсказуем и знаком, но что-то изменилось в воздухе, выросла сложность решаемых задач, разрослась инфраструктура, появились новые вызовы, и вот приходится решительно садиться и все переделывать. В этой статье мы расскажем про эволюцию нашей системы генерации отчетов aka Отчетницы, которая прошла долгий путь за последние 15 лет. Хочется похвастаться тем, что, невзирая на соблазн взять и переделать все с нуля, вопреки эпиграфу и благодаря ряду удачных решений, развитие системы оставалось эволюционным. Участки системы, ответственные за бизнес-логику работы нашей промышленной системы, сохранялись, и это спасало человеко-месяцы и годы тестирования для другой полезной работы.

Разберемся с тем, что из себя представляют отчеты для участников рынка. Ежедневно на Московскую Биржу отправляются десятки миллионов торговых заявок, совершается несколько миллионов сделок. По результатам торговых и клиринговых сессий наши участники получают больше двух сотен отчетов об итогах торгов, оценке обеспечения, выполнении обязательств маркет-мейкеров и др. Отчеты бывают в основном торговые и клиринговые, и, соответственно, несут информацию о торгах или клиринге. На каждом из наших рынков они отличаются, хотя структурно могут хранить информацию одного типа. Отчеты рассылаются отдельно каждому участнику торгов\клиринга (включая самого главного из них – Банк России). На заре времен отчеты представляли из себя текстовые файлы с таблицами, нарисованными в псевдографике. Сейчас это XML файлы со схемами и стилями на нескольких языках. Кстати, забавный факт –  по историческим причинам один из наших отчетов до сих пор отправляется в псевдографике. Ради привычки наших клиентов, которым данный формат наиболее удобен – функционал отрисовки таблиц пришлось заботливо пронести сквозь все метаморфозы системы подготовки отчетов. Впрочем, не будем забегать вперед.

Привет, Хабр! Меня зовут Сева, я работаю backend-разработчиком в Doubletapp, а также занимаюсь некоторыми devops-задачами. В этой статье я расскажу о мониторинге наших backend-приложений: сборе метрик, их визуализации и отправке уведомлений. Покажу примеры конфигов с подробными комментами и дам ссылки на гитхаб.

Содержание:
• Конфигурация Prometheus
• Сбор метрик
• Дашборды для визуализации метрик в реальном времени
• Настройка уведомлений