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

Многие считают ITIL (Information Technology Infrastructure Library) устаревшим набором практик, которые не работают на современных процессах. Опыт «Петрович-ТЕХа» доказывает обратное.

Привет, Хабр! Меня зовут Антон Скутин и я business relationship & service level manager в «Петрович-ТЕХ». Вырос из специалиста техподдержки в лида направления качества и сервиса, в компании уже шесть лет, веду телеграм-канал BRM о своей работе. Расскажу про опыт, как мы в «Петрович-ТЕХ» внедрили ITIL и получили реальный профит. В процессе роста компании мы выделили три временных этапа внедрения ITIL-практик.

Статья написана по мотивам моего доклада для конференции DevOps Conf.

Всем привет! Меня зовут Олег Смоляков, в Яндексе я больше 15 лет занимался разработкой, а теперь отвечаю за улучшение процесса найма разработчиков.

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

TLDR: мы решили обновить процесс найма, вместо порой хаотичных собеседований в каждом отдельном сервисе внедряем единую систему оценки по профессии и уровню (например, «Senior C++ Developer»), кандидат, успешно прошедший оценку навыков, теперь сможет претендовать на аналогичные вакансии в любом из 90+ сервисов компании, а всё это вместе делает процесс найма прозрачным, понятным, без дублирования технических интервью и в целом эффективным для всех участников.

А теперь подробнее о том, почему мы на это пошли и как всё устроено.

В поисках идеального подхода к автоматизации UI-тестирования? В этой статье вы найдёте реализацию фреймворка UI-автотестов на Kotlin, основанного на компонентной архитектуре с использованием популярного инструмента Playwright.

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

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

Ок. Я задаю LLM один и тот же вопрос в разных формах. И этот статистический производитель ответов, архив человеческих знаний, даёт ответы, которые иногда кажутся удивительно новыми, а иногда вторичными и банальными.

Хабр говорит, что LLM не способна к новизне и творчеству. Пожалуй, соглашусь.
Хабр видит в ней искры нового разума. Пожалуй, соглашусь.

Проблема в том, что люди пытаются анализировать LLM как объект сам в себе, не до конца понимая, что такое LLM. Эта статья утверждает: вопрос не в том, что LLM знает или умеет, а в том, чем она является.

В 2025 году Kubernetes стал практически таким же распространенным решением, как и операционная система линукс. Действительно, с внедрением микросервисов и необходимостью управлять парком серверов нам нужна распределенная операционная система. Именно такой системой и является оркестратор Kubernetes. 

Не я один подметил это, этот факт подсвечен во многих материалах по K8s. Например, вот: 

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

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

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

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

Если разработчик сидит в офисе заказчика, имеет корпоративный e-mail, доступ к Jira и Confluence, участвует в стендапах, слушает руководителя проекта и работает по внутреннему графику, то все разговоры о том, что он «чужой сотрудник», бессмысленны. Он ваш.
Даже если у него в трудовой записано другое юрлицо, даже если все деньги проходят через подрядчика.

Ваш код принимает данные извне? Поздравляем, вы вступили на минное поле! Любой непроверенный ввод от пользователя может привести к уязвимости, и найти все "растяжки" вручную в большом проекте почти невозможно. Но есть "сапёр" — статический анализатор. Инструмент нашего "сапёра" — taint-анализ (aka анализ помеченных данных). Он позволяет обнаружить "грязные" данные, дошедшие до опасных мест без проверки. Сегодня мы расскажем о том, как он работает.

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

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

Мы запустили статусы в июне 2025 года, и это стало долгожданным событием для сотен тысяч наших пользователей. Не каждое нововведение настолько круто «заходит» в корпоративной среде. И конечно, за удобной и простой фичей стояла большая работа. О том, как это было, мы расспросили в команде разработки eXpress.

Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.

Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.

В этой статье я делюсь реальным опытом:

- как мы ушли от ручных релизов к автоматическому деплою в прод;

- какие практики и инструменты позволили нам перестать бояться каждого коммита;

- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.

Этот материал будет особенно полезен техлидам, инженерам DevOps, разработчикам и командам, которые всё ещё живут в мире ручных деплоев, боятся нажимать «мердж» в пятницу вечером. Если вы задумываетесь, как перейти от хаоса к предсказуемости в релизах — вы по адресу.

А как мы этого добились — читайте под катом!

Привет! Меня зовут Марина Павлова, я технический писатель в отделе документации 1С-Битрикс. В этой статье я расскажу, как мы полностью переделали документацию по Bitrix Framework и как команде из двух человек удалось выпустить доку за 9 месяцев с помощью ИИ.

Забудьте о ручном склеивании строк: с pathlib пути элегантно конструируются с помощью оператора /. Проверка существования, чтение, получение родительской директории — всё это становится методами и атрибутами самого объекта. В результате код получается не просто чище и читабельнее, он становится более надежным и по-настоящему "питоничным" (Pythonic).

С 1 октября у нас проходит открытое бета-тестирование нативного КОМПАС-3D для ОС на ядре Linux. Мы подумали, а что если провести здесь обзорную экскурсию для нового пользователя ОС Linux, который не имеет отношения к IT-сопровождению и не должен заниматься администрированием систем? Такой сотрудник работает, используя не операционную систему, а доступные в ней программы и инструменты. Цель этой статьи — показать эти инструменты.

Привет! Я Никита Хромушкин, технический руководитель кластера в Авито, и я буду сейчас отговаривать вас становиться тимлидами.

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

Давайте сразу расставим точки над i: универсального рецепта «тимлидства» не существует. В одной компании тимлид — это человек, который 80% времени пишет код, а в другой — полностью погружен в процессы и менеджмент. В Райффайзене, например, техлид мог руководить несколькими командами и заниматься people-менеджментом. В Qiwi была своя специфика. Я буду рассказывать в основном про то, как это устроено в Авито, т.к. многие боли универсальны.

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

Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно TTF порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!

Врет метрика, а вы ей верите.

Давайте разбираться.

За последние годы рынок IT сильно изменился. Сейчас найм Junior-разработчиков стал гораздо выгоднее для компаний: конкуренция среди молодых специалистов выросла, а текучка кадров снизилась. Разберём, почему именно сейчас лучшее время инвестировать в молодых разработчиков.

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

Сегодня доступно множество инструментов: Selenium, Playwright, Cypress и другие. Каждый имеет свои преимущества. Но в подавляющем большинстве наших проектов мы используем Selenium. Расскажу, почему мы сделали такой выбор.

Цель автоматизации — экономия

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

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

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

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

Требования клиентов и гибкость технологий

Как IT-компания, мы сталкиваемся с разными требованиями заказчиков. Клиенты часто просят использовать определенный язык программирования, чтобы их команды могли поддерживать тесты. Например, если бекэнд написан на C#, то и автотесты предпочтительнее на нем.

Что важно фронтенд-разработчику при создании веб-приложений? Поддержка текущей кодовой базы, удобство внедрения новых фич и возможность повторно использовать компоненты. Создать такие условия помогает популярный подход к проектированию — FSD (Feature Sliced Design). Разбиваем интерфейс на независимые, переиспользуемые модули (виджеты, фичи и т. д.), получаем чёткие правила, единую структуру проекта и ускорение разработки за счёт переиспользования кода и изоляции ответственности.

Подход FSD во многом прекрасен, но всё же нам в нём не хватало некоторых важных аспектов: внятного разделения слоёв бизнес-логики, удобства работы с кастомными хуками (они быстро разрастаются, обрастают связями и становятся сложными для тестирования). Также было неясно, куда выносить сложные общие компоненты из разных частей проекта. И, например, как легко отделять один бизнес-модуль от другого, не ломая всю систему…

Меня зовут Иван Соснович, я тимлид фронтенд-разработки в СберТехе, тружусь в команде Platform V Kintsugi — это графический инструмент для сопровождения, мониторинга и диагностики Postgres-like СУБД. В этой статье я покажу, как мы доработали FSD под себя, и дам ссылку на пример со структурой приложения. Надеюсь, будет полезно фронтенд-разработчикам.

Уголовка руководителя за предоставленный сотрудником логин и пароль

Что учесть работодателю и сотрудникам компании?

Заместитель начальника ОАО «Р» Г. осужден по ч. 3 ст. 272 УК РФ – неправомерный доступ к компьютерной информации, повлекший ее копирование, совершенный с использованием своего служебного положения.