Терминология IT

Кто на самом деле пишет ваш проект

Что происходит, когда разработку незаметно передают по цепочке — и почему проблема не в самом субподряде, а в потере контекста и ответственности.

Привет!

Заметка о правильности названий ETL процессов. Расставим точки над i.

Всегда было же нормально, коротко и звучно ETL. Теперь все чаще мелькает ELT, ETLT, EtLT.

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

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

Например, в потоке выполняется экстракция из базы данных, непосредственно при выборке происходят предварительные преобразования (отсечение миллисекунд у столбца времени), далее загрузка в цель - выполнился процесс ETL. Вторым этапом идут бизнес преобразования - процесс T, а вместе ETLT.

Таким образом и получается, что в большинстве случаев используется процесс ETLT, но исторически так сложилось называть все подобные процесcы просто и звучно ETL.
В аббревиатуре первая трансформация обозначается маленькой первой буквой t, и это не случайно. На данном шаге выполняются только предварительные преобразования данных: очистка, приведение типов. А вот уже вторая - это полноценная трансформация: бизнес преобразования, обогащения, расчеты и тд. Еще я встречал проставление индексов к буквам трансформаций ET₁LT₂.

Так же есть такое понятие как ETL++, но об этом в другой раз :-)

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

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

Я считаю, что революция искусственного интеллекта уже началась.

Не в том смысле, что ИИ уже заменил людей, наступил AGI или мы точно знаем, каким будет рынок труда через десять лет. Как раз этого мы не знаем.

Революция — это процесс. И процесс уже идёт.

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

Именно так происходило раньше.

Меня зовут Константин Кузнецов, в ПСБ я занимаюсь, в числе прочего, поддержкой ИТ-инфраструктуры.

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

Если вы начинающий специалист в области ИТ-инфраструктуры, который видит своё будущее в ИТ-менеджменте — эта статья для вас. Думаю, вам будет полезно ознакомиться с вызовами и олдскульными способами их решения, основанными частично на ITIL, частично на devops.

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

Эта статья - попытка показать другую сторону процесса найма и объяснить, почему результат собеседования не всегда является показателем уровня разработчика.

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

Ведущий специалист Отдел исследований и разработки АО «Гринатом» Валерий Поздняков провёл не один час за ГОСТами, законами и другими документами, чтобы разобраться — кто же всё-таки он, наш искусственно интеллектуальный коллега?

В прошлой статье я писал о том, что в концепции 1С:ERP 2026 не хватает предметно-ориентированного слоя. После обсуждения стало понятно, что этот вопрос шире одной ERP-системы: если предприятие уже использует LLM, ему нужен не только набор промптов, а общий семантический контур. В первой статье эта тема была обозначена, но, видимо, недостаточно явно. Исправляю. На мой взгляд, именно этот слой в ближайшее время станет одним из самых практичных и недооценённых артефактов ERP-проектов, СМК-проектов, проектов управленческого учёта и корпоративного внедрения LLM.

Проблема не в том, что предприятиям не хватает ещё одного красивого словаря. Проблема в том, что сотрудники уже используют LLM, и остановить эту реку невозможно. Кто-то работает в ChatGPT, кто-то в DeepSeek, кто-то в Gemini, кто-то в корпоративных чатах, кто-то в локальных моделях. Руководитель просит модель подготовить управленческую справку. Финансист просит объяснить отклонение бюджета. Начальник производства формулирует служебную записку. СМК-специалист готовит проект процедуры. Аналитик описывает бизнес-процесс. Консультант пишет черновик ТЗ. Формально всё выглядит полезно: люди быстрее пишут, быстрее структурируют мысли и быстрее получают черновики документов. Но есть одно слабое место: каждый такой чат начинает строить свою собственную версию смысла предприятия.

В обычной переписке это можно терпеть. В ERP-проекте, в СМК, в управленческом учёте и в производственном контуре это уже опасно. Один сотрудник пишет в модель слово «партия» и имеет в виду партию материалов на складе. Другой под партией понимает производственную партию. Третий — партию для контроля качества. Четвёртый — серию изделия. Пятый — объект прослеживаемости. Шестой — аналитический разрез себестоимости. Модель отвечает уверенно, но отвечает внутри того смысла, который она сама восстановила из контекста. Если этот контекст не зафиксирован предприятием, модель начинает угадывать.

В 2025 году мы работали над концепцией прикладного решения «1С Управление предприятием» для учебного курса УЦ №1 фирмы «1С». В основу легла процессная модель дискретного предприятия, которую мы много лет проверяли на реальных проектах. Видеоматериала получилось около 50 часов, а рабочих наработок — ещё больше.

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

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

Статья, которая поможет разобраться:
- такое tools, hooks и skills
- чем они они отличаются
- когда и что использовать

Привет! Меня зовут Павел Игнатё, я QA–инженер в платформенной команде Авито. Я занимаюсь развитием и поддержанием качества Backoffice as a Service (BaaS) — платформы, на которой строятся многие внутренние инструменты нашей компании. Моя работа — находить риски там, где их никто не ждёт, и превращать бесконечное ручное регрессионное тестирование в чёткие и стабильные автотесты.

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

Эта статья не про то, как «написать побольше автотестов». И не про то, как заменить ручное тестирование автоматизацией. Она про другой вопрос: как тестировать платформу, от которой зависят другие продукты.

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

Предлагаю вашему вниманию перевод seL4 Whitepaper, который является хорошим введением в одно из самых известных микроядер для ОС — seL4 (лицензия GPLv2).

Здесь не только специфика seL4 и микроядер, но и много полезного материала в целом по безопасности, формальной верификации, виртуализации и системам жёсткого реального времени.

Третья часть серии о Linux для DevOps и DevSecOps – разбираем права доступа, модель UGO, биты rwx, числовое и символьное представление, chmod и chown.

Привет, меня зовут Дмитрий Синявский. Я инженер по надёжности сервиса в Ви.Tech и одна из моих любимых тем SLI/SLO. Сегодня разберемся с «скоростью расхода бюджета ошибок».

Недавно я провел опрос в канале сообщества ALLSLO, в котором спрашивал вызывает ли понимание термина Error budget burn rate сложности. В опросе верный ответ отсутствовал и был вариант «нет верного ответа», однако более 40% выбрало неверный ответ. Потому давайте разберемся, что же это такое Error budget burn rate.

Привет, Хабр! Меня зовут Тимур Напреев, я основатель клуба рецензентов ИТ-литературы Read IT Club. В 2021 году я читал русскоязычное издание одной интересной книги по современной технологии. Перевод был не самым удачным и местами искажалась сама суть архитектурных паттернов. Я решил отправить в редакцию небольшой баг-репорт. К моему удивлению, они не просто ответили, а предложили: «Раз вы так хорошо разбираетесь, помогите нам сделать лучше».

Я понял, что к такой полезной активности нужно привлечь коллег – топовых экспертов рынка. Так появилась идея Read IT Club – сообщества практикующих ИТ-экспертов под эгидой КРОК, которые рецензируют ИТ-литературу до того, как она уйдет в печать. 

Со временем выяснилось: рецензирование – это чит-код для ИТ-карьеры. Почему? Читайте под катом!

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

Я давно вынашивал желание написать эту статью. И, наверное, мне бы стоило потратить некоторое время на то, чтобы написать её чуть более структурно и продуманно, но, пожалуй, я её в таком случае вообще не напишу, так что - статья будет ad hock, прям from the top of my mind.

Начнём с того, что в обсуждениях объектного программирования бытуют несколько популярных мнений

В этой статье на примере продуктов Контура разберём, зачем нужен глоссарий, какую пользу он даёт и как внедрить его в свою документацию.

В российских проектах НСИ часто выходит далеко за рамки справочников и включает задачи MDM и Data Quality. Разбираемся, чем это отличается от классического RDM и к чему это приводит.

Когда компания начинает выбирать систему для управления ИТ-активами (ITAM), кажется, что всё просто: посмотреть демо, сравнить функции и выбрать «лучшее решение».

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

Меня зовут Евгений Котухов, я более 10 лет занимаюсь внедрением и оптимизацией ITSM / ITAM-систем. В этой статье разбираю практические критерии выбора ITAM-решений, типичные ошибки компаний и подход, который помогает выбрать систему, подходящую именно вашей инфраструктуре.