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

Каждые несколько лет IT-индустрия переживает очередной ренессанс. Мы пишем новые языки программирования - Rust для безопасной работы с памятью, Go для идеальной конкурентности, Swift для экосистемности. Мы плодим новые фреймворки, стандарты и сетевые протоколы, пытаясь превзойти существующие ограничения.

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

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

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

Цель — передача опыта, способного упорядочить мышление управленцев, укрепить инженерную культуру и сформировать новое поколение ИТ-специалистов.

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

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

Поэтому я предлагаю перевод статьи о том, как работает правило 3-2-1, почему оно перестало быть универсальным, какие уязвимости оставляет в современных средах и как эволюционировало, чтобы соответствовать современным требованиям к защите данных.

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

Но это было когда-то.

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

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

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

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

У компаний, которые работают в облаке, каждый новый месяц начинается с сюрприза. Его преподносят счета, которые почему-то всегда оказываются процентов на 30-40 больше прогноза. И тут начинается. Финдир смотрит на тимлида. Тимлид — на команду. Команда — в логи. А в логах — тишина. Ничего же не меняли. Или меняли?

В прошлой статье мы собрали типовые сцены из жизни. Помните наших героев?

В прошлом году публиковал статью «Как выбрать ITSM/ESM-систему: пошаговая инструкция, ошибки и лучшие практики внедрения на 2026 год»‎. В этом же году продолжаю рассказывать о ITSM/ESM платформах.

В этом материале я хочу сравнить некоторые системы между собой. Сразу сделаю оговорку — несмотря на то, что я являюсь технологическим партнёром SimpleOne, обзор систем объективен. Мне не так важно, какую систему вы выберете — главное, пожалуйста, подойдите к этому серьезно: проанализируйте рынок, свои потребности, запросите референсы и внедрите систему качественно, чтобы она приносила желаемый результат.

Безопасная эксплуатация ноутбуков, или Защита пользовательского ключа с помощью USB-токена на примере Рутокен ЭЦП 3.0

Из второй части мы узнали, как настроить загрузку компьютера таким образом, чтобы для разблокирования системного диска использовались ключи, размещенные на внешнем USB-накопителе. Однако при краже компьютера вместе с этим накопителем злоумышленник сможет получить доступ к данным так, как если бы они не были защищены вовсе, поэтому наиболее привлекательным способом решения поставленной задачи видится использование USB-токенов и смарт-карт, таких как Рутокен ЭЦП 3.0 или JaCarta-2 ГОСТ. Токены представляют собой защищенные микроконтроллеры со встроенной энергонезависимой памятью, поэтому способны выполнять все вычисления самостоятельно без использования ресурсов центрального процессора, не допуская копирование закрытого ключа с устройства, что обеспечивает максимально высокий уровень безопасности.

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

Заваривайте чай и готовьтесь к погружению: сейчас мы будем препарировать код метриками, эмбеддингами и суровой статистикой

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

Дорогие мои дорогой Хабр! В 2026‑м почти в каждой крупной компании появился свой ИИ: чат‑бот для сотрудников, ассистент в CRM, помощник в DevOps, «умный поиск» по документации. На слайдах это выглядело как «повышаем эффективность и разгружаем людей». На практике быстро выяснилось, что один такой сервис иногда видит больше, чем любой живой сотрудник: обращения в поддержку, инциденты ИБ, договоры, переписку с ключевыми клиентами — всё это летит через один API.

Проблема в том, что защищаем мы эти штуки по старой памяти — как обычный внутренний сервис «за VPN‑ом». Логика такая: раз доступ только из корпоративной сети, значит, всё ок. Но LLM может крутиться в облаке, ходить в сторонние сервисы, дергать внутренние API и послушно выполнять любые запросы, если их правильно сформулировать. Отсюда вылезают знакомые уже истории: prompt‑injection, утечки через промпты и ответы, «внезапно» найденные в логах следы несанкционированных выгрузок.

На этом фоне Zero Trust перестаёт быть красивой теорией для CISO‑митапов. Если продолжать относиться к модели как к «чёрному ящику, который что‑то там отвечает», мы по сути открываем новый периметр атак — и для внешних злоумышленников, и для своих же людей с лишними правами. Модели и AI‑агенты становятся отдельными участниками инфраструктуры: у них есть доступы, они инициируют действия, они могут накосячить. Значит, им нужны свои роли, ограничения и прозрачный аудит.

В этой статье я разберу, как смотреть на LLM через призму Zero Trust: какие у такой системы реальные угрозы, как может выглядеть референс‑архитектура «доверенной» среды и с чего начать внедрение в живой компании. Цель простая: превратить AI‑сервисы из непонятной магии с доступом «ко всему сразу» в нормальных, управляемых жителей корпоративной ИТ‑архитектуры.
 

Разработка программного обеспечения не стоит на месте: меняется технологический стек, совершенствуются подходы к созданию ПО. Вместе с тем уточняются и требования к ПО и процессу разработки в целом. Все больше людей узнает о понятии SSDLC (Secure Software Development Life Cycle) или безопасный жизненный цикл разработки ПО. Как же построить такой цикл в команде? Как сформировать качественную стратегию построения безопасной разработки? Давайте разбираться!

В декабре 2025 года создатель Ruby on Rails Дэвид Хейнемейер Ханссон, также известный как DHH, представил Fizzy — новый open source-визуализатор, описанный им как «занимательный и современный взгляд на канбан». Это мог быть очередной пост с анонсом, если бы не одно «но»: лицензия Fizzy запрещает использовать проект для конкурирующих разработок.

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

Мы в Beeline Cloud решили разобраться в ситуации.

30 января были выпущены методические материалы ITIL Foundation (version 5) и стала доступна соответствующая сертификация, но еще до официального выпуска поисковая выдача уже успела наполниться частично или полностью ИИ-сгенерированными статьями, часть информации в которых не соответствует официальному пресс-релизу от PeopleCert.

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

Привет, Хабр! Меня зовут Кирилл Иванов. Я уже много лет участвую в организации процесса тестирования в Тензоре. У нас есть особенность — мы используем собственные разработки для управления релизами, хранения тестов и трекинга багов.

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

Всем привет, это снова я — Сторож Алексей, ведущий консультант AKTIV.CONSULTING! И, перед тем как продолжить, напомню — данный текст является продолжением большой статьи, в связи с чем я настоятельно рекомендую сперва ознакомиться с первой ее частью, где я рассказывал почему и кому ГОСТ 57 580.1 вновь скоро станет актуальным, а также объяснил, как Банк России (БР) видит защиту информации в финансовых организациях (ФО).

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

Корпоративные стандарты АСУ ТП часто считают бюрократией: «ещё один документ, ещё больше рамок для инженеров».

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

Nestlé, Bosch, GM и другие уже давно инвестируют в стандарты — не ради моды, а потому что это реальные деньги:

В статье разбираю механизмы, которые превращают стандарт из бумаги в работающий актив: библиотеки блоков, генераторы кода, копирование сигналов, контроль версий.

Kubernetes давно стал де-факто стандартом для оркестрации контейнеров. Его используют все – от крупных корпораций до мелких стартапов – и в ус не дуют. Потому что удобно: сервисы после падения поднимаются сами, трафик равномерно размазывается по репликам, деплой происходит в один клик, а масштабирование — по графику нагрузок, а не по звонкам в два часа ночи. Но это на бумаге. А вот на практике многие компании сталкиваются с тем, что за удобство приходится платить. Причем зачастую куда больше, чем рассчитывали первоначально. Бывали даже случаи, когда на кластер закладывали 200 тысяч рублей в месяц, а по факту отдавали 500-600. Естественно, работать в таких условиях нельзя. Поэтому надо разбираться, куда на самом деле уходят деньги и как сохранить их при себе.

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

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

С 2020 года я адаптирую стерильную эстетику Figma под суровую реальность промышленных мониторов.

Добро пожаловать в цех! Давайте разберем, как не провалить проект на этапе компонентов.