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

С приходом ИИ в поисковую выдачу, на смену 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-инженеров.

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

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

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

Просто вы его так не назвали. Открытый стандарт EnvSpec Naming 1.0 — о том, что имя ресурса это модель доверия, а не удобство админа.

Стенд UAT с боевой выгрузкой — это prod по определению. Хост srv-msk-prod-db-tier1-old-02 не говорит машине ничего. Открытый стандарт EnvSpec Naming предлагает считать имя ресурса системой координат для ИБ, DevOps и инвентаризации.

Бэкап запускается каждую ночь, отчеты приходят со статусом «успешно», а восстановиться после сбоя все равно может не получиться. Потому что резервная копия — это еще не готовность бизнеса к аварии.

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

Всем привет! Меня зовут Олеся, я руковожу отделом процессов и технологических стандартов ИТ на Московской Бирже.

Сегодня хочу поделиться опытом, который мы накопили при построении единой производственной системы SDLC (Software Development Life Cycle), включающей три компании Группы MOEX.

Это была не просто бюрократическая задача по написанию инструкций, а сложный инженерный и организационный вызов для нас!

Материал будет полезен CIO, руководителям ИТ-подразделений и архитекторам, которые сталкиваются с проблемой разрозненности в подходах к разработке внутри одной экосистемы.

Что полезного вас ждет в этой статье?

Для описания архитектуры важно выбрать подход, который будет понятен всей команде. Одним из них является нотация C4, разработанная Саймоном Брауном.

Данная статья — это продолжение и значительное дополнение моей предыдущей статьи по C4, опубликованной в 2023 году. Здесь я детально разобрала для вас каждый уровень и элемент нотации, распространённые ошибки и спорные вопросы, а также инструменты для создания диаграмм, в частности графический редактор Draw.io и Structurizr для создания C4 через код.

Внутри — много схем, картинок и практических примеров для монолитной и микросервисной архитектуры, готовый код Structurizr и промпт для ИИ. Статья организована таким образом, чтобы вы могли открыть её, последовательно пройти все разделы и самостоятельно разобраться с C4.

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

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

Но разработчики нет‑нет да и задаются вопросом: а что, если сделать email лучше? Так рождаются RFC — от крошечных правок до попыток заново изобрести почту на JSON. По этим документам можно заглянуть на десятилетие вперёд и понять, какие идеи получат массовое распространение, а какие останутся красивой мечтой.

Я сделал для одного из своих проектов API управления контентом и skill для Codex, который знает структуру сущностей, правила заполнения и ограничения. В результате значительную часть работы с админкой оказалось проще заменить обычными текстовыми командами агенту.

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

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

Последнее время, наверное, ни один более‑менее адекватный специалист в области ИИ не проходит мимо разговоров о том, насколько всё это опасно. То одна модель «сошла с ума», то другая начала убеждать живого человека в чём‑ то странном, то кто‑то всерьёз заговорил про экзистенциальную угрозу человечеству. Я тоже как‑то подустал от этого информационного шума, но одна мысль не давала покоя: а что, собственно, мы предлагаем взамен? Красивые лозунги «сделайте ИИ добрым» явно недостаточно, а на практике что?

Когда заходит речь о «безопасном искусственном интеллекте», первое, что вспоминают — это три закона робототехники Азимова. Красиво, правильно, звучит убедительно. Но на практике они однозначно неприменимы, и дело даже не в том, что они «устарели» — они просто не работают как алгоритм. Закон «не причиняй вреда человеку» в реальности упирается в неразрешимые противоречия. А если спасти одного человека можно только ценой гибели другого? А если «вред» наступит через десять шагов логического вывода, который робот ещё даже не сделал? Сам Азимов сто раз на этом играл в своих рассказах — законы постоянно конфликтуют друг с другом, и это не баг, а фича сюжета. Но нам‑то нужна не фича сюжета, а рабочая система принятия решений. И вот тут начинаешь понимать, что декларации не спасают.

Так и родилась идея, которую я в итоге оформил в виде скилла DOF‑Core (Degrees of Freedom — степени свободы). Базовый принцип даже не мой — я о нем читал лет 10 назад и он меня впечатлил. Ниже расскажу, как устроена эта идея и почему мне кажется, что математика тут важнее хороших намерений.

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

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

Раз в неделю падает один и тот же сервис. Админ его перезапускает, пользователи возвращаются к работе, инцидент закрывают. Через несколько месяцев авария превращается рутину, и так продолжается годами. Управление проблемами — problem management — начинается в тот момент, когда кто-то все-таки спрашивает: «Почему это повторяется?». Для сервисного провайдера это логичное продолжение управления инцидентами. Обычно мы сами инициируем разбор, как только серия однотипных происшествий перестает выглядеть случайностью.  Но если ты аутсорсер, то найти root cause — это только полдела. Дальше нужно понять, что с ней делать. Причина может оказаться в продукте вендора, легаси заказчика или системе другого подрядчика — то есть там, где инженер внешней техподдержки не может просто взять и исправить ее. Но и тогда можно попробовать договориться и исправить ее. Об этом сегодня и пойдет речь. 

Меня зовут Наталия Сляднева и я руковожу Центром экспертизы по комплексному сервису К2Тех. Под катом — два расследования с разными финалами и третий случай, в котором проблему осознанно не стали решать. Иногда это самый рациональный вариант.

Скан сети находит 320 устройств, бухгалтерия — 280 на балансе. Кто подключил лишние 40 и на каком складе они лежат не знает никто, потому что информация в пяти разных системах. Разбираем, что каждая из них видит, а что упускает, и как свести их в одну карточку актива.

Cursor — день прощания

До прошлой пятницы проблемы с доступом к Cursor у российского пользователя были привычными. Редактор открывался, ИИ-агенты работали без проволочек. Нужны были только прокси и, если её не имелось, зарубежная карта — Stripe (кассовый сервис Cursor) с РФ-банками не работает.

3 сентября, вероятно с подачи Шуфутинского, Cursor обновил Terms of Service, включая раздел об экспортном контроле. 4 сентября российские пользователи начали массово получать от API not available in your region; одновременно появились сообщения о переставших работать агентах и автодополнении. Часть Pro-подписчиков получили письма об отмене подписки.

Официального сообщения Cursor в духе «мы прекращаем работу в России» на момент выхода этой статьи ещё нет. Тем не менее, сухой остаток для разработчика от этого меняется слабо.

Не всё так однозначно (с)

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

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