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

На техновыставке CES 2025, кроме прочих hi-tech чудес, представлены HDMI 2.2 и DisplayPort 2.1b. Обновленные технологии обещают всякое — от сверхчеткой графики до плавного воспроизведения видео с высоким FPS. Геймеры, киноманы, создатели контента и просто любители крутых гаджетов наверняка заинтересуются. Давайте разберемся, в чем разница между DP и HDMI, что привнесут новые стандарты и когда появятся первые устройства с их поддержкой.

При создании этого материала были использованы данные отчета DORA Accelerate State of DevOps 2024

В конце октября 2024 DORA выпустила очередной отчет Accelerate State of DevOps — результаты масштабного ежегодного исследования об эффективности разработки. В этой статье команда KT.Team суммировала выводы исследователей DORA о том, как работают эффективные команды разработки. Здесь же вы найдете ключевые советы DORA: какие подходы внедрить, чтобы повысить результативность команды и оправдать ожидания бизнеса.

Статья будет полезна руководителям ИТ любого уровня — от проектных менеджеров до ИТ-директоров.

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

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

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

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

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

Суть эффекта Makefile сводится к следующему:

В 18 версии PostgreSQL появится функция uuidv7(). Она разработана для замены последовательных автоинкрементных идентификаторов SERIAL, BIGSERIAL и IDENTITY, которые могут привести к катастрофическому дублированию ключей при слиянии данных, и для замены более медленных UUIDv4.

Использование функции uuidv7() позволит упростить архитектуру информационных систем, упростить SQL-запросы, избежать некоторых ошибок, облегчить внесение изменений и благодаря этому повысить надежность и снизить стоимость разработки и сопровождения информационных систем.

Однако для объективной и корректной оценки использования функции uuidv7() необходим официальный бенчмарк в PostgreSQL. Без такого бенчмарка может быть сделан необоснованный выбор в пользу автоинкремента.

Мы привыкли доверять приложениям, которые установили на свои гаджеты. Порой обоснованно, порой не очень. Если посмотреть документацию на API авторизации какого-нибудь крупного российского банка или соцсети, то можно увидеть Oauth 2.0, OIDC, authorization code flow и т.д. К сожалению, в большинстве случаев это либо не соответствует действительности вообще, либо частично. Как будто-то за всеми этим упускается один важный момент, и сегодня мы поговорим об этом более подробно.

С багажом из предыдущих серий мы отравляемся в следующий эпизод, в котором мы определим имманентные (простите вырвалось) проблемы ИТ-архитектуры 4-го поколения, на примере ВТБ 2019 года выпуска. А также узнаем, как решаются эти проблемы в Омниканальной архитектуре. В рамках этого мы сформулируем формулу омниканальности.

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

Вы когда-нибудь задумывались, как незрячий человек смотрит фильмы, а глухой зритель — понимает атмосферу сцены без звуков? В Кинопоиске теперь это не просто возможно — это удобно и доступно. Меня зовут Настя, я отвечаю за продуктовое направление Инклюзии в Яндексе. Вместе с командой мы работаем над тем, чтобы каждый, независимо от особенностей здоровья, мог наслаждаться фильмами и сериалами. В этом посте я расскажу, как мы делаем Кинопоиск местом, где кино доступно для всех.

Последний год мы активно ведем работу над доступностью Кинопоиска.  Он стал тринадцатым сервисом Яндекса, адаптированным для незрячих и слабовидящих людей — это случилось в начале 2024 года. Это означает, что сервис доступен для использования с помощью специальных программ экранного доступа (другими словами — скринридеров), которыми пользуются незрячие пользователи. 

А ещё контент Кинопоиска начал пополняться субтитрами для глухих и слабослышащих людей и тифлокомментариями. 

Вот как выглядит видео с SDH и тифлокомментариями.

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

Творческий центр Департамента ИТ-архитектуры ВТБ, при сдержанной поддержке Технологического блока банка, под настороженно-дружелюбными взглядами неравнодушных представителей ИТ-производства, и с трудно угадываемым молчаливым одобрением служб эксплуатации, неожиданно представляет: первый в России (а значит и в мире) архитектурный сериал «Через тернии к Омни». Присоединяйтесь к нашему многосерийному лонгриду.

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

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

Приведённое противоречие обычно и логика его устранения понятна:

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

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

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

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

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

К данной статье я намеренно переиначил популярный в некоторых кругах заголовок ("Billion dollar mistake" про null как значение ссылок/указателей). Старое цепляется за своё зубами и когтями. Новое приходит в новые ниши и уже не имеет этих проблем. Но без их рассмотрения мы рискуем повторять прежние ошибки...

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

Как сократить расходы на ИТ-инфраструктуру: три ключевые стратегии с помощью ITAM

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

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

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

В статье мы подробно рассмотрим пути оптимизации расходов благодаря ITAM.

Привет. На связи Саша Липин, продакт-лид Garage Eight. Расскажу, какие методы приоритизации продуктовых штук я пробовал, для чего хорош каждый из них и на что опираться при выборе.

Модель OSI является эталонной моделью взаимодействия сетевых устройств. В реальности в сети Интернет для этого взаимодействия применяется стек протоколов TCP/IP.  Модель TCP/IP состоит из четырех уровней, которые соответствуют определенным уровням модели OSI. Соответствие модели TCP/IP и модели OSI представлено на рисунке 1.