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

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

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

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

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

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

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

— Мы берём ресурсы с запасом. Так надёжнее.
— А какой у вас сейчас CPU utilization в проде?
— Ну... где-то 12%. Но в пике бывает больше.
— Хорошо. А в staging?
— Там вообще 3%. Но там нельзя трогать — там всегда так было.
— Почему нельзя?
— Ну, так исторически сложилось…

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

Система управления сервисами — универсальная таблетка для оптимизации сервисных процессов и способ вывести обслуживание бизнеса на новый уровень. Так говорят многочисленные маркетинговые материалы. А как на самом деле? Забегая вперед, скажу: во многих случаях — да, ESM / ITSM действительно полезны. Однако за красивыми цифрами часто скрывается сложный, а порой и болезненный путь. Многие проекты внедрения сталкиваются с неожиданными препятствиями, не достигают заявленных целей или, что еще хуже, создают новые проблемы и заставляют сотрудников искать обходные пути.

Я Сергей Вараксин — методолог-аналитик Directum, сертифицированный эксперт по ITIL4. В этой статье на примере реальных кейсов разберу наиболее распространенные причины, по которым система не оправдала ожиданий.

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

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

Возможно вам знакома ситуация, когда отчеты по SLA 99,9%, заявки закрываются в срок, но при этом пользователи жалуются, что работать невозможно. Показатели в системе и реальность расходятся — это как мерить среднюю температуру по больнице. 

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

_{Прежде чем начну, вот репозиторий. Я не хочу ничего монетизировать, продавать или куда-то вас вести (в секту имени меня, например). Если этот бот, идея или даже отдельные куски кода окажутся кому-то полезны в жизни - я сделал чей-то день и, возможно, чья-то жизнь стала немного ярче.}

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

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

Меня учили в вузе, что если мы сталкиваемся с комплексной задачей, то и её оценку надо проводить комплексно. А ещё, что если это не семинар, то придумывать велосипед необязательно и можно достать табличку объёмов красных шариков, которую за тебя уже продумали и составили эксперты в красных шариках. В нашем случае это ФСТЭК (Разрабатывает стандарты и требования по защите персональных данных (ПДн) и критической информационной инфраструктуры (КИИ) в РФ) и CVSS (Открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет её исправления).

Так мы сможем описать и дать оценку конкретному сценарию эксплуатации уязвимости. Но помня мои вопросы выше, ради объективности и полного раскрытия темы мы рассмотрим 2 сценария:

Сегодня Agile — почти стандарт в IT(и не только). Его используют стартапы, корпорации и даже государственные организации. Но мало кто задумывается, что Agile — это не методология.

Agile — это философия управления разработкой, основанная на адаптации к изменениям, быстрых итерациях и тесном взаимодействии с пользователями.

Ни‑че‑го не понятно. Да, есть такое, но давайте разбираться, что такое Agile, откуда он взялся, что было до него и почему сейчас большинство рынка его придерживаются.

До Agile: эпоха водопадов

До начала 2000-х основной моделью разработки была каскадная модель (Waterfall/Водопад).

Модели OSI и TCP/IP своими словами, тут я пытаюсь рассказать своими словами про модели OSI и TCP/IP, писал статью для себя чтоб освежить память, но решил поделиться с вами.

Впервые в истории человечество может генерировать программное обеспечение быстрее, чем способно понимать создаваемые системы.

На протяжении многих лет индустрию программного обеспечения волновал один вопрос:

Кто будет писать код?

Теперь искусственный интеллект способен генерировать тысячи строк кода за секунды.

Но это порождает гораздо более важный вопрос — тот, который почти никто в технологическом мире не задаёт:

Кто будет нести ответственность за жизнь программных систем, которые ИИ собирается создавать?

Потому что написать код легко.
Жить с последствиями этого кода следующие двадцать лет — значительно сложнее.

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

1️⃣ Написание кода
2️⃣ Проектирование алгоритмов и систем
3️⃣ Ответственность за жизненный цикл программного обеспечения

Эти роли часто воспринимаются так, будто это одно и то же.

Но это не так.

И появление ИИ заставляет нас наконец увидеть эту разницу.

Я долго думала, что PEP — это про оформление. PEP 8: называй переменные вот так, PEP 257: пиши докстринги вот так.

Потом начала использовать их по‑настоящему и выяснилось, что часть из них вообще не про то, как выглядит код!

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

Учебные симуляции не дают эффекта, потому что реальные риски никто не оценивал, а атаки давно не ограничиваются массовыми рассылками типа «Срочно переведи деньги! Некогда объяснять».

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

Зачем бизнесу новая позиция в C-suite и что она означает на практике

Когда одни компании обсуждают, нужен ли им ИИ, другие уже нанимают человека, который будет отвечать за него (или сейчас  сам сидит и пилит ИИ-агентов ) и все это на уровне совета директоров. Chief AI Officer — позиция, которая ещё три года назад звучала как фантастика, сегодня становится такой же обычной как СТО (ТехДир), CFO (ФинДир)или CHRO (HR).

Ну и что это за роль такая, откуда она взялась, чем отличается от CTO и CDO(Chief Digital Officer — директор по цифровой трансформации (это в больших банках есть такая позиция)), какие технические компетенции требует — и нужен ли он вам сегодня или как обычно, уже вчера.

Сколько раз вы сталкивались с ситуацией, когда по документам сервер есть, а в стойке его нет? Или когда компания продолжает платить за сотню лицензий софта, которым давно никто не пользуется?

Если эти боли вам знакомы, значит, вы уже поняли: вести учет «железа» и софта в Excel — это путь самурая, но он ведет к финансовому харакири.

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

Именно поэтому ITAM-системы (IT Asset Management, системы управления ИТ-активами) перестали быть роскошью для корпораций и стали гигиеническим минимумом для любого среднего и крупного бизнеса.

В 2026 году выбор инструмента для стилизации — это не вопрос вкуса, а вопрос архитектуры. Мы разберём, где Tailwind CSS v4 выигрывает у признанных лидеров: компонентных библиотек (MUI, Ant Design) и CSS-in-JS решений (Styled Components).

Сегодня ядром данной статьи будет MCP — как мост между бекендом‑оберткой с LLM и внешними источниками, но при этом я также затрону смежные темы, чтобы картина была полной и не требовалось дополнительно гуглить.

Я постараюсь не давать устоявшиеся термины в контексте MCP, а также в процессе буду пояснять некоторые «базовые» термины, которые все как бы понимают — но нередко нет, чтобы мы все улавливали один и тот же контекст статьи.

Недавно один мой приятель после релокации переехал из дома в квартиру. Места стало меньше — и в приглашении на день рождения дочери появилась фраза:
“No more physical toys.”

Не потому что он стал «строгим родителем».
А потому что складывать уже некуда, игрушек слишком много и каждая новая мгновенно обесценивает предыдущие.

В бизнесе мы ведём себя точно так же. Мы обожаем новые «игрушки»:

Привет, Хабр!

  Многие знают, что один из четырех всадников апокалипсиса типов собеседований в Бигтех — это так называемое «Behavioral interview». Этот тип собеседований вполне заслуженно считается самым недооцененным среди всех остальных. Казалось бы… Прийти и поговорить про опыт и поотвечать на всякие дурацкие вопросы непонятно зачем. 

Процесс собеседований в Бигтех разнится от компании к компании, но везде есть Behavioral. На это собеседование приходят интервьюеры, как правило выше чем тот, на который вы собеседуетесь.Очень часто это человек, который будет принимать решение, брать ли вас к себе в команду. Почему же это настолько важно, что 25% вашего успеха (возможно, даже больше) на финальном этапе зависит от прохождения этой части?

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