Kurgan-Telecom Ru | Информационные технологии

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

Но дизайн в IT — это не просто красивые карточки, но еще и продукт, метрики и пользовательский опыт. Поэтому если у вас амбициозные карьерные цели, присмотритесь к IT.

В статье разберём, какие навыки нужны для дизайнера в IT, чем IT-дизайн отличается от классического, куда расти, сколько можно заработать и где учиться.

Мы все привыкли к классическому раскладу: для поддержки есть сервис деск, в проектных командах — Jira, у ИБ — свои системы. При этом одни и те же сотрудники могут решать заявки, участвовать в проектах и устранять инциденты — сами или совместно с безопасниками. 

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

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

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

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

В этой статье разберём:
• какие типы запросов в поддержку можно убрать дизайном;
• как находить точки, где продукт «ломается»;
• какие UX-решения реально снижают нагрузку на поддержку;
• с чего начать, если ресурсы ограничены.

Кажется, что в ИТ всё меняется каждые пару лет. Фреймворки рождаются и умирают, архитектурные подходы сменяют друг друга, но SQL стабильно остается на месте. Он спокойно пережил хайп вокруг NoSQL, эпоху Big Data и повсеместное внедрение нейросетей.

Сегодня SQL давно перестал быть узким «языком админов». Это универсальный стандарт общения с данными, который жизненно необходим бэкендерам, аналитикам, QA-инженерам и даже продакт-менеджерам.

В этой статье мы пропустим скучную академическую теорию и разберем только то, что реально нужно в работе. Мы пройдем путь от анатомии таблиц и базовых джоинов до оконных функций. А в конце заглянем под капот базы данных и разберем логический порядок выполнения запроса — секретный ингредиент, который навсегда избавит вас от вопроса: «Почему эта строчка не работает?!».

Часто SDET-инженеры, работающие со встраиваемыми системами, не приступают к работе, пока не получат реальное железо: датчик, микроконтроллер или плату с новым чипом. Такой подход обычно оправдывают тем, что без физического девайса «на столе» писать корректно работающий софт невозможно. Очевидный минус: увеличивается время выхода продукта и нового функционала на рынок. Но разработку можно начать, даже не имея в своем распоряжении устройства: все дело в договоренности между командами.

Меня зовут Рустам Ахмадуллин, я старший инженер по системной верификации аппаратуры в YADRO. Расскажу на примере датчика температуры LM75A, как написать API без физического доступа к устройству и его прошивке. Разберем методологию Test Driven Development, при которой разработка начинается с написания автоматизированных тестов, а не самого кода.

«ИИ забирает у человека мотыгу и даёт ему пульт от дистанционно управляемого трактора».

Но в этом проекте пульт показал кое-что ещё: трактор ехал не туда, куда говорил водитель.

Этот проект — один из девяти в моём портфеле. Но он особенный, потому что демонстрирует три ключевых принципа моей работы:

Стратегия важнее технологии. Я выбрал поэтапный подход, а не «идеальное решение сразу» — и это спасло проект.

Финансовое мышление. Каждый технический риск я переводил на язык потерь и ROI. Это позволило защищать бюджеты и масштабировать решения.

Международный масштаб. Я доказал, что российский ИИ-руководитель может успешно внедрять проекты за рубежом, соблюдая местное законодательство и работая с локальными партнёрами.

Благодаря предобучению, большие языковые модели (LLM) приобретают широкие лингвистические способности и общий «кругозор» о мире. Но постобучение — не менее важный этап, на котором они как раз усваивают конкретные намерения человека, ограничения, присущие предметной области, а также требования к надёжности, предъявляемые в продакшне. В  Netflix исследовали, как именно LLM могут открыть новые грани рекомендаций, персонализации и поиска. Для этого в Netflix попробовали адаптировать универсальные обобщённые модели к имеющимся условиям так, чтобы они лучше отражали содержание каталога фильмов и нюансы истории взаимодействия пользователей с сайтом. В масштабе такой компании как Netflix постобучение быстро превращается как в инженерную проблему, так и в проблему моделирования: приходится выстраивать сложные конвейеры данных и оперировать ими, координировать распределённое состояние в масштабах многоузловых кластеров GPU и оркестровать потоки задач, в рамках которых перемежаются обучение и логический вывод. В этой статье описаны архитектура и инженерная философия применяемого в Netflix фреймворка постобучения, который был разработан командой по платформе ИИ с целью скрыть сложность инфраструктуры — так, чтобы исследователи и разработчики моделей могли сосредоточиться на внедрении инноваций, а не на латании распределённых систем.

В 2022 году мы приняли решение объединить множество показателей, связанных с разработкой, в интегральную метрику Contribution. Данной метрикой мы диагностируем Code review и считаем вклад разработчика в продукт.

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

Сейчас расскажу, зачем это нужно и как мы пришли к этой метрике.

Продолжим знакомство с работой современного французского энтузиаста-электровакуумщика Клода Пайяра [1], воссоздавшего в своей мастерской кустарное микропроизводство ранних высоковакуумных триодов — варианта легендарного ТМ [2]. Ранее мы уже рассмотрели его огневое оснащение [1], технологическую печь, контактную сварку [3] и ламповый аппарат ТВЧ [4], полюбопытствовали, чем Клод откачивает свои лампы [5]. С воображаемой лупой в руках посмотрим же, как устроен его вариант триода, чем он похож и чем отличается от исторических прототипов; по характерным примерам последних проследим часть эволюции этой выдающейся лампы.

Сон — это удивительное место, если его можно таковым считать. Место, где логика становиться второстепенным персонажем, а воображение дирижирует оркестром реальных людей и мест, выдуманных персонажей и фантастических локаций, ужасающих монстров и прекрасных созданий, невероятной силой и сковывающей безысходностью. Во сне возможно все, и сон порой слаще реальности, где краски не столь ярки, звуки не столь сладки, а гнетущее бремя нерешенных проблем тянет нас на дно отчаяния. Но может ли сон послужить инструментом, способным помочь нам решить задачи, которые казались непосильными? Ученые из Северо-Западного университета (Эванстон, Иллинойс, США) провели исследование, показавшее, что это вполне реально. Как именно ученые манипулировали снами, и насколько эффективным было это вмешательство? Ответы на эти вопросы мы найдем в докладе ученых.

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

В 2026 году регулирование в области персональных данных в России вышло на принципиально новый уровень. Принятые в 2024–2025 годах поправки в КоАП и отраслевые законы превратили формальное соблюдение бумажных требований в вопрос экономического выживания компаний. Штрафы за утечки теперь исчисляются миллионами и даже процентами от годовой выручки, а регуляторы получили инструменты для автоматического мониторинга нарушений.

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

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

Привет, Хабр! Меня зовут Дмитрий Овчаренко, я технический директор департамента разработки IBS для финансового сектора. За последние десять с лишним лет я успел поработать архитектором, тимлидом и техдиром, внедрять SOA, потом микросервисы, потом облака — и наступить на приличное количество грабель. В этой статье честно расскажу несколько таких историй, в которых либо ошибался сам, либо не дожал архитектурно, либо слишком доверился контексту. Без пожаров дата-центров и апокалипсисов, но с теми самыми локальными провалами, которые в реальных системах случаются чаще всего. Надеюсь, эти кейсы окажутся полезными для всех, кто проектирует, особенно в эпоху вайб-кодинга, и потом живет с результатами своих решений.

О чем эта статья

«Как дела? Не могу говорить, все горит!»

Реальность B2B SaaS (как и в большинстве направлений разработки) последние пару лет — это перманентный пожар. Заказчик просыпается с новыми вводными, рынок штормит, приоритеты меняются быстрее, чем успеваешь обновить Jira.

Как обеспечить устойчивое развитие IT-ландшафта под нужды бизнеса и снизить затраты на развитие в горизонте

Изображение от rawpixel.com на Freepik

Уникальное доменное имя — это важный идентификатор бизнеса в интернете. Чтобы приобрести нестандартный и запоминающийся URL, некоторые предприниматели готовы заплатить миллионы. Расскажем о самых дорогих приобретениях подобного толка в нашей статье.

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

Проблема в том, что управление обычно рассматривается как последовательность действий: поставить задачу, выполнить, проверить, скорректировать. Такой взгляд удобен, но он скрывает главное — проект развивается не по шагам, а по состояниям. Между «всё под контролем» и «проект провален» лежит широкий спектр промежуточных состояний. Именно в них и накапливается риск.

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

Приветствую всех!

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

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

Цифровые данные не рассчитаны на хранение десятилетиями, не говоря уже о веках. Жесткие диски и SSD со временем выходят из строя, архивные ленты нужно регулярно переписывать, а облачные сервисы зависят от электричества, серверов и самих компаний. На этом фоне проект Microsoft Silica предлагает другой подход — записывать информацию прямо внутрь стеклянных пластин с помощью фемтосекундных лазеров. И это не фантастика, а реальность. Команда проекта показала рабочий прототип, увеличила скорость записи и продемонстрировала, что при обычных условиях данные могут сохраняться не менее 10 тысяч лет. Давайте разберемся, что это за технология, как она работает и на каком этапе развития находится.

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

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

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

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