IT-инфраструктура *

Привет, Хабр! Эту статью пишет авторский коллектив Центра экспертизы по комплексному сервису К2Тех: я, Пётр Михнюк, руководитель группы инженеров по поддержке системного ПО, и мои коллеги Александр Овчинников, старший инженер по поддержке вычислительного оборудования, и Алексей Яковлев, руководитель практики ИТ‑мониторинга. У нас на поддержке около 550 клиентов из сегмента enterprise, многие с географически распределенной инфраструктурой, и практически все они так или иначе опираются на Zabbix или его наследников.​

По нашему опыту, главная угроза для эффективного мониторинга — иллюзия контроля. Часто бывает так, что система развернута, графики рисуются, алерты шлются, но команда тонет в сотнях уведомлений и не успевает ловить действительно важные события: вместо одного «критического инцидента» получаются десятки разрозненных тикетов. При этом проблемы с лавиной оповещений, тарированием порогов и общей логикой мониторинга почти не зависят от того, используете ли вы «голый» Zabbix или его форки вроде «Пульс», Glaber или UDV ITM. Учитывая, что в большинстве случаев «наследием» наших клиентов является именно Zabbix, мы будем опираться на конкретные примеры из работы с ним. Под катом — не теория, а наши подходы и примеры: как перестать тонуть в алертах и превратить Zabbix в инструмент, которому можно доверять.

Привет, Хабр! Меня зовут Павел Степуро, я исполнительный директор ДИТа «Занять и Сберегать» в Сбере.

Вы по-прежнему работаете в ИТ, сопровождаете автоматизированные системы и уже ознакомились с моей первой статьёй про путь от создания базовой системы мониторинга к системе автоматизации и принятия решений

Именно поэтому вы находитесь здесь… И это продолжение пути.

Итак, вы создали систему мониторинга мечты! У вас уже есть посекундный сбор критичных метрик: инфраструктурных, прикладных и бизнес-метрик, и вы думаете о дальнейшем развитии.

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

И сделать это можно с помощью ML predict-модели, которая будет предсказывать поведение метрик на 15 минут вперёд.

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

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

На этом фоне технология Single Sign-On (SSO) из удобной опции превратилась в базовый элемент современной инфраструктуры доступа. Она позволяет централизовать аутентификацию и убрать избыточные проверки, не снижая (а при правильной реализации — повышая) уровень безопасности.

Разберёмся, как SSO устроен на уровне протоколов и архитектуры, и как эта технология реализована в системе для многофакторной аутентификации и контроля доступа MULTIFACTOR.

Меня зовут Дмитрий Деев, я руководитель отдела IT-инфраструктуры в Ви.Tech - IT-дочке ВсеИнструменты.ру. В рамках нашего подкаста я поговорил с Ильей Кочневым, директором сопровождения информационных технологий в Lamoda Tech. Илья - более 20 лет в эксплуатации, начинал юникс-инженером, строил инфраструктуры в банках, нефтянке, e-commerce, открывал дата-центры в нескольких странах, мигрировал в облака, из облаков и между облаками.

Говорили про FinOps. Не про «культуру осознанного потребления» и не про «надо экономить», а про то, как это реально работает и когда вообще стоит этим заниматься.

Если вы работаете с мониторингом в Prometheus или VictoriaMetrics, то наверняка знаете, и Alertmanager для удобного конфигурирования алертов. А если вы ещё и используйте EvaTeam (российский аналог Jira) и хотите автоматизировать полностью цикл создания, работы над алертами в этих систмах, то это решение очень вероятно вам поможет осуществить такую связку!

Alertmanager-evateam это Alertmanager (webhook) плагин, который создаёт и управляет задачами в EvaTeam на основе алертов, с акцентом на гибкость.

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

Написать эту статью меня сподвигнул услышанный недавно краем уха разговор:

Мы уже говорили о том, как повсеместное распространение искусственного интеллекта связано с ростом цен на оперативную память. Кажется, пришло время обсудить еще один момент. Инфраструктура для ИИ — это дата-центры по всему миру и тысячи серверов в них, работающих 24/7. Они потребляют огромное количество энергии, и спрос только увеличивается. Поэтому крупные компании активно ищут перспективные источники электричества. В том числе смотрят в сторону термоядерного синтеза. Можно подумать, что тут мы говорим больше про эксперименты, чем про готовые решения. Но нет, речь идет о вполне реальных переговорах OpenAI с Helion. Давайте разберемся.

Restoring Internet Freedom (Правила восстановления свободы интернета) были приняты 14 декабря 2017 года во время первого президентского срока Дональда Трампа. Утвердив их, Федеральная комиссия по связи (FCC) отменила Open Internet Order (Правила открытого интернета) 2015 года и вернулась к схеме мягкого регулирования. Этот документ стал символом дерегулирования и «возвращения свободы интернету», хотя критики называли его капитуляцией перед крупными провайдерами.

Меня зовут Ольга Макарова, я директор департамента коммерческого управления ресурсами технического блока МТС. Вы читаете пятый материал из цикла «Сетевой нейтралитет: не совсем то, что так называют». В нем я покажу, как технические детали (DNS, кэширование, pole attachments) стали точкой преткновения между Вашингтоном, штатами, судами и провайдерами.

Представьте себе автоспортивное конструкторское бюро, которое тридцать пять лет чертило безупречные двигатели для всего пелотона Формулы-1, но никогда не выставляло на трассу собственный болид. Британская Arm Holdings десятилетиями была такой абсолютной «Швейцарией» Кремниевой долины. Она была невидимым фундаментом вычислений, продавая интеллектуальную собственность и лицензии на архитектуру всем: от Apple до Qualcomm и Nvidia. Никакого физического производства, только идеальные чертежи.

Но эволюция технологий сломала эти правила. Пока нейросети были относительно простыми, их задача сводилась к генерации: выдать текст, написать код в окне чата, нарисовать картинку. Для этой математики идеально подходили графические ускорители (ГПУ), где ИИ фактически и обитает. Однако по мере взросления модели становятся умнее. Им уже мало просто отвечать на вопросы — они начинают активно использовать внешние инструменты для выполнения десятков задач пользователей.

Чтобы искать данные в реальном времени, запускать тяжелые скрипты в изолированных средах и управлять сторонними программами, ИИ нужен быстрый исполнитель. Этим исполнителем выступает центральный процессор (ЦПУ). И чем сложнее становятся ИИ-агенты, тем острее им требуется сверхмощная процессорная логика для работы их инструментов.

Видя взрывной спрос на классическую логику, руководство осознало, что продавать концепты больше недостаточно. Во вторник, на конференции «Arm Everywhere» в Сан-Франциско, архитекторы отложили циркуль и взялись за кремний.

Разбираем Приказ ФСТЭК России № 117, который вступил в силу с 1 марта 2026 года и заменил действовавший более десяти лет Приказ № 17. В статье подробно рассматриваются новые требования к защите информации в государственных информационных системах, включая введение показателей Кзи и Пзи, переход к процессной модели управления безопасностью, ужесточение требований к кадровому составу и обязательность внедрения современных средств защиты.

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

Всегда хотел развернуть шару SMB с хранилищем на ZFS, но есть нюансы…

Совершенно не приемлю, чтобы пользователи каким либо образом взаимодействовали с сервером, где расположен pool\ZFS. В моем понимании, СХД может включать в себя только служебные компоненты без прямого пользовательского доступа к его сети.

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

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

Но если посмотреть на это как на систему, становится заметно: вокруг кандидата уже сформировалась целая экономика.

В процессе поиска работы возникает экосистема сервисов, каждый из которых решает свою задачу — и при этом зарабатывает по-своему.

Попробуем разобраться, как это устроено.

Привет всем, кто заглянул на Хабр за чем-нибудь полезным под кофе

Устраивайтесь поудобнее — сегодня поговорим про ту самую работу, где в тикете пишут «Не работает принтер», без логов и деталей, а со стороны бизнеса уже «горит» и нужно «ещё вчера». Но вместо забегов по магазину — открываешь Kyocera NetViewer, подключаешься к устройствам и начинаешь разбираться, не вставая со стула.

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

Разберём:

• что проверять в NetViewer в первую очередь (онлайн/оффлайн, ошибки, счётчики, состояние расходников);

• как по статусам понять, проблема на стороне устройства, сети или клиента;

• в каких случаях достаточно удалённых действий (перезапуск очереди, проверка подключения, базовая диагностика);

• и где проходит та самая граница, когда уже пора идти к принтеру, который жуёт бумагу и подозрительно пахнет гарью. Без занудной теории — только живой кейс, практические шаги диагностики через Kyocera NetViewer, немного самоиронии и мысли о том, как сделать так, чтобы уставал не ты, а только spooler

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

Мы – команда Инфобеза Inline Telecom Solutions и мы точно знаем, насколько это сложно, ведь мы разобрались. Теперь поможем тебе, поехали.

Привет, Хабр! Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для zVirt. В первой части мы определились с терминологией, обсудили основные концептуальные подходы автоматизации и сформировали образ «светлого будущего» — программно-определяемая инфраструктура серверной виртуализации на основе Terraform. Теперь пришло время обсудить проектирование самого решения. 

Начнем с определения — что, собственно, нужно делать?  Поговорим подробнее, что из себя представляет Terraform и где проходит граница ответственности между HashiCorp как изначальным разработчиком ПО и теми, который пишет собственный провайдер.

Эта статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера (или кто об этом задумывается). Мы попытаемся разложить задачу на конкретные модули и получим примерное понимание интерфейса. 

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

Меня зовут Елизавета Колесникова, и вот уже 4 года я работаю системным аналитиком СПАО «Ингосстрах»

Этой статьёй я бы хотела начать серию материалов для аналитиков и разработчиков, которые только начинают свой путь в ИТ.

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

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

В прошлой статье я рассказывал, как мы в «Первой Форме» пришли к навигации по корпоративным данным и почему одной языковой модели недостаточно, чтобы получать полезные ответы внутри компании. Тогда речь шла о самой идее картографирования данных — о слое, который связывает разрозненные системы, знает смысл терминов и помогает находить путь от вопроса к проверяемому ответу.

Но довольно быстро выяснилось, что построить карту один раз недостаточно.

Компания меняется постоянно. Меняются процессы, документы, код, настройки, роли, рабочие привычки. То, что ещё недавно было правильным маршрутом к ответу, через некоторое время начинает вести только к части ответа или вовсе в неправильную сторону. Это уже опасно: если у компании нет карты, она честно признаёт, что ответа быстро не получить, но если карта устарела, она начинает отвечать уверенно — и именно поэтому ей легче поверить.

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы». В этой статье я расскажу, как работать с картой дальше, чтобы она не превращалась в красивый, но мёртвый артефакт. 

Чтобы автоматизированно проверять и централизованно обрабатывать огромное количество событий о происходящем в инфраструктуре, используется SIEM –– класс решений информационной безопасности, призванный анализировать события ИБ, собираемые c устройств инфраструктуры, выявлять подозрения на инциденты.

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

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

В статье я расскажу, какие процессы следует наладить для работы с SIEM, почему это важно, и какие последствия могут быть и, скорее всего, будут, если этого не сделать.

В статье расскажем, как мы командой Yandex Infrastructure внедрили QoS в сетях InfiniBand при ограниченной вендорской поддержке и скудной практической документации. Обсудим мотивацию: рост смешанных нагрузок во внутреннем облаке и необходимость предсказуемых SLO для различных обучений. Отдельно рассмотрим как могут быть связаны QoS и топология сети DragonFly+.

Статья о том, с какими сложностями могут столкнуться пользователи, установившие ИИ-агента OpenClaw, построенная на личном опыте. Спойлер: монстр под капотом, 81 млн токенов за три дня, конфликты с сервером и почему он не просто бот, а ниндзя-одиночка.