IT-стандарты *

Недавно довелось послушать лекцию по ИИ, которая оказалась бы очередным стратегическим / плановым / программным / базовым (нужное подчеркнуть) мероприятием, если бы лектор не упомянул, что в части понимания того, что такое ИИ, они используют термин из ГОСТа (какого именно – не успел увидеть (да, там было все как полагается: презентация на большом экране, трибуна, грамотная речь лектора и т.п.), но где-то рядом прозвучало «критическая информационная инфраструктура»). Вот тут стало по-юридически интересно: почему ГОСТ, ведь есть же у нас уже закон № 243-ФЗ от 26.07.2026, а до этого – Национальная стратегия развития ИИ до 2030 года, утвержденная еще в 2019 году; и там, и там есть определение термина «искусственный интеллект»? Может мне что-то неизвестно?

Внимание, спойлер: да, неизвестно! И весьма много чего…

Вместо введения

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

В распределённой системе всё меняется.

Один пользовательский запрос может пройти через API Gateway, несколько микросервисов, очередь сообщений, базу данных и внешний API. При этом каждый компонент может находиться на отдельном сервере или контейнере.

Если такой запрос выполняется 4 секунды, возникает вполне практический вопрос:

Где именно были потрачены эти 4 секунды?

На сети? На базе данных? На блокировке потока? На выполнении конкретного метода? На внешнем сервисе?

Именно для ответа на этот вопрос в APM используются трассировка (distributed tracing) и инструментация приложений.

Один из наиболее интересных подходов — автоматическая инструментация, при которой разработчику не требуется вручную добавлять tracing‑код в каждый сервис.

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

Привет, Хабр! Меня зовут Илья. Долгое время я работал в финтехах и у облачного провайдера. Занимался сопровождением информационных систем, причём не как инфраструктурщик, а как специалист по поддержке целых автоматизированных систем. То есть смотрел на ИТ не с уровня отдельного сервера, а с уровня «работает ли сервис для бизнеса и клиента».

И сразу, пока вы не пролистали до конца, вопрос к вам.

Друзья айтишники, вспомните момент, когда DRP действительно понадобился. Что пошло не так? Бэкап, который не восстановился? Резервная площадка, на которой «забыли» один сервис? Регламент, который лежал на той самой упавшей файловой шаре? Напишите в комментариях свои фэйлы. Чужие ошибки учат лучше любых методичек, а для кого‑то ваш комментарий станет поводом проверить свой план до аварии, а не после.

А теперь поговорим о том, как строятся планы DRP и почему наличие документа ещё не означает, что вы восстановитесь.

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

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

Всем привет. С вами Авдей Мартынович, руководитель подразделения по работе с СМБ в ALP ITSM. До ALP я был ИТ-директором региональной компании и сам нанимал подрядчиков, а последние семь лет работаю на стороне аутсорсинга. Так что на выбор подрядчика смотрю с обеих сторон стола.

Ниже — десять вопросов, которые я задавал бы аутсорсеру сам, на месте клиента. Не все вопросы будут удобными, и это правильно: по реакции подрядчик виден лучше, чем по презентации. Скопируйте список в заметки перед первой встречей.

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

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

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

Эксперт в области защиты данных ГК «Солар» Виталий Петросян разбирает три расследования, в которых использовался Solar Dozor.

Дело первое. Чужая учетная запись

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

Действия совершает один человек, а в системах они фиксируются за другим пользователем.

Первый сигнал Solar Dozor был связан с попыткой записать служебный документ на USB-носитель. Документ относился к чувствительным материалам и содержал пометку ДСП. Перед записью цвет пометки изменили так, чтобы она почти сливалась с фоном.

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

Спор о русском в коде обычно ведут идеологи. Одни требуют «программировать на родном», другие крутят пальцем у виска. Но если убрать эмоции, остаётся инженерная задача: где локализация снимает трение, а где создаёт новое?

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

Пора это признать. И посмотреть, во что это обходится на практике.

На примере сервиса мультифакторной аутентификации MULTIFACTOR: от лицензирования компании и подготовки продукта до испытаний, аттестации облачной части и нескольких десятков неудобных вопросов к архитектуре

ИИ тебя заменит! Слышали? Я часто, и мне захотелось разобраться в теме и понять для себя, как разработка будет жить в условиях всеобщего ИИ, когда любой встречный-поперечный может с помощью AI сделать генерацию сайта, бота или использовать нейросеть для генерации приложений. И вроде бы, действительно, программист больше не нужен, но ведь мы интуитивно понимаем, что не всё так просто.

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

Предположим, вам нужно заселиться в один из двух небоскребов на 99 этаж. Оба небоскреба имеют 100 этажей, основание, у них одинаковая площадь квартир и общедомового пространства, у каждого встроена противопожарная безопасность, но в обоих случаях она еще ни разу не запускалась. Но есть и различия: первое здание прошло полную приемку в органах гос-пожар-тех-потреб надзора, его проектировали и строили люди по всем современным нормам. Второе здание было построено ИИ без привлечения специалистов-людей. Для второго здания гос-пожар-тех-потреб надзор НЕ участвовал во вводе строения в эксплуатацию.

Какое здание вы бы предпочли на ближайшие 5–10 лет? Почему-то мне кажется, что первое.

Подобный эксперимент можно привести и с врачами. К кому на лечение пойдете, если съели не тот гриб? К человеку или к ИИ? Почему-то мне кажется, что за финальным лечением все пойдут к врачу-человеку. И это понятно. Мы еще не настолько сильно доверяем ИИ, и уж тем более в таких вопросах, как здоровье.

С 2022 года большинство российских компаний прошли первую волну импортозамещения, перешли на отечественные офисные пакеты, почту и мессенджеры и перевели часть серверов на российские ОС. К концу 2026-го у многих проект замедлился, и проблем становится больше. В отчёте для руководства доля замещения выглядит высокой, но администраторы продолжают находить иностранные системы, которых в плане не было. Бывает и так, что новая российская система отказывается работать после отключения старой зарубежной. 

Зачем вообще нанимать команду разработки, если нейросеть соберёт систему сама?

Я задаю его себе сам. Нейросети сейчас участвуют почти во всём, что мы делаем: пишут код и помогают разбирать требования. Чёрт! Да я с Claude Code общаюсь чаще, чем с матерью.

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

За последние месяцев двенадцать у нас поменялось многое: как пишется код, как готовится аналитика, что присылают заказчики и с чем они вообще приходят. Часть процессов пришлось перестраивать на ходу. Дальше — что из этого вышло, на примерах проектов, которые сейчас в работе. Это заметки по итогам года, и выводы у меня пока не окончательные.

Привет, Хабр! На связи Алёна, аналитик по информационной безопасности в Selectel. В последние пять лет вышло множество нормативно‑правовых актов от ФСТЭК России, которые кардинально изменили как подход к защите государственных информационных систем (далее — ГИС), так и порядок их аттестации и последующей эксплуатации. 

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

Мы уже прошли этот путь и готовы к размещению у нас клиентских ИС, к которым предъявляются требования по соответствию приказу ФСТЭК России № 117. 

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

Больше тридцати лет я строю процессы в бизнесах разного масштаба — от компаний на два человека до компаний на несколько тысяч. Последние полтора года мы с @skazkin  строим компанию, в которой код на сто процентов пишут ИИ-агенты, а не люди. Мой участок в этой работе — не код, а процесс: как устроена система, гарантирующая, что результат работы агента действительно соответствует поставленной задаче и отвечает всем требованиям по качеству.

Этот текст — систематизация моего понимания особенностей работы агента по в рамках процесса разработки.

Задача. Разработка ПО с помощью ИИ-агентов, результат которой должен соответствовать замыслу доказано соответствовать требованиям — а не просто быть написанным и запущенным.

Основная идея. Чтобы получить код, соответствующий требованиям, не нужно изобретать новую методологию. Управление требованиями и их изменением, независимая верификация, контроль кода, статистический контроль процесса — всё это давно разработано, формализовано в стандартах и опробовано на людях; в своих принципах эта дисциплина переносится на агентов целиком. Систему агентской разработки следует строить из тех же контуров. Но агент как исполнитель обладает свойствами, отличными от свойств человека-исполнителя, и эти свойства смещают акценты внутри знакомых контуров: значительная часть того, что в человеческой разработке получалась «сама собой» — за счёт памяти исполнителей, их вопросов, неловкости перед коллегами, выученных привычек, — для агента не существует, и соответствующая функция должна исполняться системой явно, как механически закреплённый элемент.

SAML больше двадцати лет обеспечивает единый вход (SSO) в корпоративной и академической среде. Но протокол прогибается под тяжестью собственной сложности, и ему пора на пенсию. Разбираемся, как SAML появился, почему его раз за разом ломают исследователи безопасности и почему на смену ему должен прийти OpenID Connect (OIDC).

С приходом ИИ в поисковую выдачу, на смену Search Engine Optimization приходит GEO — Generative Engine Optimization (не путать с геосервисами вроде Яндекс/Гугл-карт и прочих Foursquare — это было гео для миллениалов). Для зумеров и молодящихся миллениалов ГЕО — это оптимизация под ИИ-выдачу, попадание в ИИ-рекомендации, в особенности (для Рунета) — в «Алису». «Попасть в рекомендации Алисы» — это уже реальный востребованный спрос, предложение на который только находится на этапе формирования.

С GEO-предложением сейчас происходит примерно то же, что происходило с рынком мобильной разработки после презентации айфона и AppStore: инструменты уже появились, названия у них есть, набор основных функций тоже более-менее сформировался, но общего понимания того, что именно они измеряют и чем один подход отличается от другого, пока ещё нет. Если попытаться систематизировать предложения по GEO, получится своего рода «облако тегов» — ChatGPT, Perplexity, Gemini, «видимость», «упоминания», Share of Voice, «конкуренты» — при ближайшем рассмотрении оказывающимся, скорее, туманом, в котором скрыты довольно разные методологии.

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

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

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

Привет, Хабр! По первому образованию я юрист. Успел поработать в прокуратуре и арбитражном суде, потом ушёл в ИТ и последние 13 лет занимаюсь инфраструктурой, разработкой и DevOps. Сейчас строю MLOps-платформу.

Эта биография мешает мне спокойно читать споры об авторском праве и генеративном ИИ. Юрист видит копирование чужих книг. Инженер — цепочку операций: crawler, raw storage, очистку, дедупликацию, training mix, веса, API. Между «скачали страницу» и «модель ответила пользователю» слишком много разных действий, чтобы обсуждать их одним словом «обучение».

Отправной точкой для этого разбора стала колонка Мэтта Столлера о внутренних материалах OpenAI и Microsoft. Столлер пишет прежде всего о политике и неравном применении закона. Меня зацепил другой вопрос: как тот же конфликт выглядит на уровне движения данных по ML-pipeline — и что с этим вообще может сделать инженерная команда.

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

Спойлер: ничего. Сертифицируют вообще не ЦОД. Привет! На связи Андрей, инженер в дата-центре Selectel. Работа на этой позиции подразумевает множество зон ответственности, одна из них — надежная эксплуатация инфраструктуры в рамках услуги А-ЦОД. В этой статье разберемся, что же это вообще такое и чем отличается от остальной части дата-центра. А начнем с основ.

Когда мы слышим «защищенный дата-центр», легко представить себе серверную с толстыми стенами, камерами, охраной и десятками стоек. Но дело в том, что все это есть и в нашем обычном сегменте ЦОД — те же системы охлаждения, резервные генераторы, СКУД. Защищенная часть может состоять всего из пары стоек, которые будут стоять среди сотен обычных и на первый взгляд практически не отличаться. Но отличия все же есть, и они очень существенны.

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

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

Меня зовут Миша Соколов, я старший специалист по тестированию в Контуре. Расскажу, как у нас трансформировалась система оценки QA-инженеров. Спойлер: это был путь от плоской Excel-таблички со скиллами из актуальных вакансий на рынке до разветвлённой структуры из пяти треков развития и распределённого матричного управления для 270+ QA-инженеров.

«Ну понятно, до нормального результата ещё года два». Так можно было сказать про нейронки… примерно полгода назад. И вот мы здесь. ИИ уже делает кучу вещей сильно быстрее и проще.

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

Привет! Это Денис Румянцев, руководитель продуктовой разработки в Профи.ру. Я не сторонник ни полного восторга от ИИ, ни идеи «давайте всё запретим, пока не поздно».