Стандарты в информационных технологиях
Работая в IT и общаясь с разными специалистами, я заметил интересную вещь: собеседования часто воспринимаются как объективная проверка знаний, хотя на практике ими управляет множество человеческих факторов.
Эта статья - попытка показать другую сторону процесса найма и объяснить, почему результат собеседования не всегда является показателем уровня разработчика.
Интеллектуальные агенты плотно вошли в нашу жизнь и работу. Но с ними есть проблема: до сих пор нет единого понимания, кто или, вернее, что имеется в виду под этим термином. Между тем вопрос не праздный — если понятие вошло в нормативные акты, значит, нужно понимать, какие системы оно охватывает, чем они отличаются от просто «агентов» или других ИИ-решений и где вообще проходят границы регулирования.
Ведущий специалист Отдел исследований и разработки АО «Гринатом» Валерий Поздняков провёл не один час за ГОСТами, законами и другими документами, чтобы разобраться — кто же всё-таки он, наш искусственно интеллектуальный коллега?
Несколько лет назад в закон «Об информации...» (149-ФЗ) добавили требования к способам авторизации пользователей.
Многие тогда обратили внимание на новость, но практических последствий почти не было — ответственности за нарушение не существовало. Если не штрафуют, значит скорость +19,9 км/ч разрешена ;)
Теперь ситуация изменилась - с июля 2026 года появилась административная ответственность, а штраф для юридических лиц 700 000 рублей.
Почитал новости, комментарии, пообщался с коллегами - оказалось, что не все до сих пор разобрались.
Например мы обсуждали:
Я дизайнер и продакт, но как и многие из вас — последний год самостоятельно разрабатываю проекты с Claude Code. И, как многие, была уверена, что соблюдаю базовые правила безопасности.
API‑ключи никогда не лежали локально.
Не попадали в Git.
Не отправлялись в облако.
Были один раз сгенерированы и вручную прописаны непосредственно на сервере.
Именно поэтому произошедшее стало для меня полной неожиданностью.
За один час злоумышленники смогли потратить около $200, воспользовававшись моими API‑ключами Anthropic и Open AI.
Пишу это в первую очередь для тех, кто, как и я, собирает продукты быстро, с ИИ‑ассистентом, и не считает себя security‑инженером. Если вы вайбкодер — пусть эта статья станет вашим бесплатным экспресс‑курсом по безопасности.
Сервер числится сразу за несколькими отделами. Каждый уверен, что у него всё в порядке. А когда железка ломается, выясняется, что она ничья. Опросили сотню компаний — картина одинаковая. Показываем, что с этим делать.
Когда в длинной сессии вы поручаете модели писать код, основная модель (исполняющая модель / executor) постепенно теряет из виду, «что в этом проекте изначально было самым важным». Например, она самовольно добавляет слой кеширования в инструмент, который не предполагает масштабирования, или подключает библиотеку, хотя вы не хотели увеличивать число зависимостей. Многие наверняка сталкивались с тем, что чем дальше идет контекст, тем сильнее модель тянет к ближайшей задаче и тем больше она отклоняется от общей линии проекта.
Именно здесь полезен советник (advisor) в Claude Code. Советник автоматически вызывается в важных точках и, более того, читает всю историю беседы. А значит, если заранее обратиться прямо к советнику и написать: «Суть этого проекта вот в чем», то каждый раз при вызове он будет сверять работу исполняющей модели с этой сутью. Иными словами, его можно использовать как «регулярное напоминание» для забывчивой исполняющей модели.
У такого подхода — «писать напрямую для советника» — есть основание в официальной документации. В этой статье я буду на нее ссылаться и доведу идею до практического примера CLAUDE.md, который можно использовать в реальной работе.
В учёте три ноутбука, и все записаны по-разному: «леново», «Lenovo Inc.», «ThinkPad». Для отчёта это три разные железки, а по деньгам — разброс в сотни тысяч на балансе. Показываем, как навести порядок в справочниках, чтобы наконец знать, чем ты вообще владеешь.
Есть одно предложение, которое за последние месяцы перепечатали, кажется, все. Вот оно, в переводе с блога TypeScript:
📣 Заявка. «Проверка типов проекта VS Code (около 1,5 млн строк) ускорилась с 77.8 с до 7.5 с». Итог, который команда вынесла в заголовок, — «примерно в 10 раз быстрее».
Это не обзор релиза. Это попытка воспроизвести один график — не на кодовой базе Microsoft, а на монорепо, которое я собрал специально под замер, двумя компиляторами на одной машине, с показом каждой цифры и с репозиторием, где любую из них можно получить командой pnpm bench.
Сразу спойлер: да, TS7 быстрее, и заметно. Но „в десять раз“ живёт в одном конкретном месте, испаряется в другом, а кое-что важное в 7.0 пока не вошло — и это „кое-что“ важнее скорости.
Главная мысль:
«10×» — это про чекер на большом проекте, а не про весь ваш день. TS7 радикально ускоряет проверку типов и режет память, и замеры это подтверждают. Но в 7.0 отсутствует стабильный программный API — а с ним из сборки выпадают кастомные трансформеры, tsserver-плагины и типизированный линтинг. Поэтому вопрос миграции — не «стало ли быстрее», а «завязана ли ваша сборка на этот API».
В 2026 году ретейл одновременно внедряет кассы самообслуживания, программы лояльности, видеоаналитику и ИИ для прогноза спроса — и при этом каждая третья сеть в России работает на инфраструктуре, которая не выдержит серьезного сбоя. У 30% компаний устаревшее оборудование, еще у 20% — хронический дефицит ИТ-специалистов, способных поддерживать эту инфраструктуру.
Получается нестыковка: сложные цифровые проекты запускают на инфраструктуре, которая не справляется даже с рутиной. Первой страдает техподдержка магазинов. Не потому что в ней работают плохие специалисты, а потому что система, которую они поддерживают, давно перестала помещаться в модель «свой айтишник в офисе».
Разберем, как устроена зрелая модель ИТ-поддержки распределенной сети, что входит в сопровождение и какие SLA (Service Level Agreement, соглашение об уровне сервиса) имеет смысл закладывать.
Привет, Хабр! Меня зовут Лера, я технический писатель в Авито. Сегодня в статье хочу рассказать о книге, которая около 40 лет остаётся настольной для руководителей, предпринимателей и менеджеров по всему миру. Речь пойдет о книге «Цель» Элияху Голдратта.
Голдратт рассказывает о менеджменте через историю главного героя Алекса Рого — директора завода, который оказывается в настоящем управленческом кризисе. Вместе с главным героем мы решаем типичные проблемы процессов. На всякий случай подсвечу, что это вымышленная история.
И хотя действие книги происходит на производстве в 1980-х годах, её проблемы удивительно актуальны для современной IT-индустрии: перегруженные команды, бесконечные очереди задач, локальная оптимизация метрик, зависимости между командами и попытки ускорить всё одновременно. Как со всем справиться? Надеюсь, статья приблизит вас к ответу на этот вопрос.
Элияху Голдратт — израильский физик, бизнес-консультант и один из самых влиятельных теоретиков менеджмента XX века. Он разработал теорию ограничений — подход к управлению сложными системами, основанный на поиске и последовательном устранении их главных ограничений. Сегодня принципы теории ограничений применяют не только в производстве, но и в логистике, управлении проектами, разработке программного обеспечения и продуктовых командах.
Мир сильно изменился с начала 21 века. В том числе, что касается систем авторизации. Мы продвинулись от авторизации через обычный логин и пароль к использованию централизованных сервисов вроде Google и Apple. Но так ли хорошо это для пользователя? И можно ли сказать, что его данные принадлежат ему?
Полгода-год использования — и уже пора жалеть, что купили не тот хелп деск. Такое может произойти, если пасть жертвой маркетинга не проанализировать свои процессы и не подобрать систему именно под них.
В этом обзоре поможем разобраться, на что обратить внимание в первую очередь при выборе решения, а в какие детали стоит углубиться после первичного отсева. И да, скажем сразу: мы — команда ITSM 365. Свой продукт тоже включили в топ help desk систем, при этом для сравнения использовали единые критерии и открытые данные.
ИИ-ассистент в корпоративной среде довольно быстро упирается в одно ограничение: он отвечает на вопросы, но ничего не делает. Спросить можно, но создать задачу, собрать данные по инцидентам, отправить дайджест, найти связанные объекты — уже нет.
В то же время в бизнесе только и разговоров, что об ИИ-агентах — эта сущность, в отличие от чат-бота или ассистента, может действовать самостоятельно. Получив запрос, ИИ-агент оценивает доступные инструменты и сам решает, в какой последовательности их вызвать. Жёсткого сценария нет, есть набор методов и инструкция, что этот агент умеет делать.
В этом материале команда SimpleOne разбирает, как агенты устроены внутри GenAI платформы: из каких компонентов состоят, как встраиваются в процессы, и что они реально могут.
На счету команды Бастиона — десятки кейсов по защите объектов критической информационной инфраструктуры (КИИ) в самых разных отраслях. И нет, это не реклама. Просто мы замечаем, что участники таких проектов часто наступают на одни и те же грабли. В результате страдают сроки реализации проектов и качество итоговых решений, а компании сталкиваются с рисками ИБ-инцидентов и штрафных санкций от регуляторов.
В этой статье мы собрали несколько рекомендаций для руководителей, ИБ-специалистов и других участников проектов по защите КИИ, основанных на нашем опыте. Как субъекту КИИ выбрать подходящего интегратора? Как наладить взаимодействие внутри проектной команды, чтобы избежать организационных проблем? Какие технические и юридические нюансы стоит учесть? Ответы — под катом.
Боков Фёдор, Security Vision
Инвентаризация IT‑активов — это процесс учета всего оборудования, программ, учётных записей и сервисов в компании. Считается технической рутиной, но на практике это основа для работы систем безопасности. Без точного и актуального списка активов невозможно эффективно защищать инфраструктуру, нельзя закрыть уязвимость на сервере, о котором не знаешь, или корректно оценить угрозу для системы, не понимая ее роли в сети.
Эта статья рассматривает, как данные инвентаризации напрямую влияют на работу основных классов продуктов информационной безопасности. В качестве примера мы рассмотрим использование инвентаризации и её преимуществ в продуктах Security Vision SOAR, VM и CMDB. Их функциональность и точность напрямую зависят от качества и скорости наполнения базы активов.
Эта статья для собственников или директоров компании, у которых ИТ вроде работает, но что там внутри на самом деле, они не знают. Разберем, по каким признакам понять, что ИТ-системы требуют внимания, во что обходится привычка «не трогай пока работает», какие объекты охватывает аудит ИТ-инфраструктуры и с какого первого шага начать, чтобы не платить сразу за дорогую процедуру. Если для вас ИТ — черный ящик, то эта статья поможет вам разобраться в базе и понять как действовать дальше.
Пятница, 23:47. prod-db-07 лежит, авторизация мобилки не работает, 40 000 пользователей не могут войти. В поле «владелец» — прочерк, последний ответственный уволился в ноябре. Чинят под паролем root/root из письма двухлетней давности.
В начале 2026 года произошло что-то странное. Количество IT-вакансий упало на треть, кандидаты месяцами не могут найти работу, джуны рассылают по сотне откликов без ответа - и при этом 64% российских работодателей говорят, что им катастрофически не хватает IT-специалистов.
Это не противоречие. Это новая реальность российского IT-рынка, в которой одновременно верны два тезиса: людей слишком много и людей катастрофически не хватает.
В этой статье мы пытаемся разобраться, как так получилось и что будет дальше.
За свои 17+ лет в активной разработке я встречал много проблем, но одна преследовала меня постоянно: JSON. Нет, с самим форматом все ок, но вот с его чтением — не все норм.
Когда я только начинал работать с PHP, я списывал это на скриптовость языка. Отчасти из‑за этого я даже поменял стек. Но когда приходили по‑настоящему большие файлы, это всегда было больно. Иногда — очень. Был проект, где мы ждали не обработку информации бизнес‑логикой, а банального парсинга. Файлы доходили до десятков гигабайт и не всегда влезали в оперативку. Тогда я и заработал себе персональный todo — разобраться с этим раз и навсегда.
Сейчас, находясь в поиске новых возможностей, я решил вспомнить эту старую боль. Я уже давно не PHP‑разработчик, но проблема в индустрии всё та же. Объемы данных растут, требования тоже, а воз и ныне там. Нет, есть море крутых решений. Даже тут, на Хабре. Но для меня всё не то.
Мне нужно решение, а не костыль. То есть: никакой кодогенерации и никаких JIT (я не противник JIT, просто не хочу тянуть эту сложность).
Я ступил на тонкий лед: в Go есть классная штука — пакет unsafe. Почему классная? Потому что она позволяет обойти тяжелые ненужные проверки. Плюс побитовые операции для ускорения всего, до чего только смогли дотянуться руки. Пока изучал чужие парсеры, столкнулся с обманом в репозиториях, подкручиванием статистики (куда же без него?) и перекладыванием ответственности (и аллокаций) на сторону разработчиков.
«Автоматизируй! AI! ИИ-агенты!» слышит ИТ-директор каждый божий день. В переговорках только и разговоров, что об автоматизации. При этом 95% ИИ-пилотов в компаниях проваливаются, то есть не достигают измеримого ROI. Давайте разбираться, почему, несмотря на популярность технологии, ИИ-инициативы в компаниях обречены.