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

Три года назад нас было восемнадцать человек, мы пилили свою систему для управления задачами. Всё шло спокойно, пока не пропали Джира и Трелло. Параллельно мы выросли до 100+ человек. 

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

Сквозных процессов не было вообще. Каждая вертикаль стала отдельным мини-бизнесом со своим планом действий. Одни упоролись в RnD, другие в этот момент пилили «свой Ноушен» с документами. Каждый делал хорошо, но никого не волновало, что делает сосед.

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

В этой войне локальных KPI против общих целей мы упустили, что продукт-то у нас один. Клиенты спрашивали, чего вообще ждать от системы, а мы даже не могли сделать нормальный роадмэп. 

Нам пришлось полностью снести старые подходы. Сейчас расскажу, как мы это пережили и сколько народа полегло.

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

Я редактор, работаю с образовательными лонгридами на 15–20 страниц и заметила закономерность: если текст сложный/непонятный, то чаще всего из‑за плохой структуры. Когда мысль прыгает туда‑сюда, за ней сложно уследить и понять, что хотел сказать автор. 

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

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

В статье разбираем три источника скрытых потерь в IT‑разработке: лишние согласования, ожидание между этапами и раздувающиеся расходы на облака и SaaS.

Большинство Telegram-ботов выглядят одинаково. /start — стена текста — кнопки. Пользователь тыкает, получает ответ, закрывает. Никакого ощущения что за ботом стоит что-то живое. Конверсия падает, люди не возвращаются, и ты не понимаешь почему — ведь функционал вроде работает.

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

В этой статье я собрал 7 конкретных фич с кодом на aiogram 3.x которые это исправляют. Некоторые внедряются за пять минут, некоторые требуют больше времени — но каждая влияет либо на удержание, либо на монетизацию, либо на рост аудитории. Без воды, сразу к делу.

За неделю я прошел хх. Это как в Тиндере, когда ты свайпнул всех и видишь плашку “сорян, под ваши запросы у нас больше нет людей”. Вот и я вручную просмотрел 4700+ вакансий в Москве и Минске, откликнулся на 156, получив 0 созвонов с эйчарами.

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

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

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

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

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

Два часа ночи, у разработчика горит релиз, он подключает ваш API — и получает в ответ голое «invalid_request». Что не так, почему, что делать — ни слова. Сорок минут гаданий и злое письмо в поддержку.

Разбираем, как сделать опыт разработчика (DX) человеческим: как переписать ошибки по стандарту RFC 9457, но для живого человека; почему время до первого успешного вызова — главная метрика онбординга; и отчего предсказуемый, «скучный» API — это комплимент. С готовым шаблоном, который можно прикрутить к себе сегодня.

В проде бывает так, что одна и та же операция часто повторяется: клиент не дождался ответа и ретраит, балансер порвал соединение, очередь переиграла сообщение. Вспоминаем про идемпотентность - это правило «повтор не должен создавать новый платёж/заказ».

Чтобы отличать повтор от новой операции, используют idempotency key (ключ идемпотентности). Это обычная уникальная строка-идентификатор, которую клиент или апстрим отправляет вместе с запросом (часто в заголовке Idempotency-Key). Сервис сохраняет этот ключ у себя и связывает с результатом операции.

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

В новом переводе от команды Spring АйО рассмотрим не самые очевидные ошибки и то, о чём стоит подумать, при реализации идемпотентного API.

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

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

Спроси ChatGPT или Claude про топовых экспертов в твоей нише и с большой вероятностью себя в ответе не найдёшь. Так было и у меня: руковожу AI-направлением в Т-Банке, выступаю, пишу, а модель об этом не знала, потому что меня не было в данных, по которым она отвечает. За вечер я это починил и собрал пошаговый гайд: как сделать сайт читаемым для агентов, попасть в Wikidata и Google Knowledge Graph. Без IT-бэкграунда, по шагам, с готовым репозиторием для форка.

Меня зовут Егор Спирин, я руковожу лабораторией прикладных агентов (ЛаПА) в магистратуре AI Talent Hub при ИТМО. Мне всегда были интересны соревнования в IT — сначала ICPC, где важны алгоритмы и скорость, потом Kaggle, где всё сводится к одной метрике на фиксированном датасете. В обоих случаях понятно, что именно оценивается и как улучшить результат. Агентные соревнования устроены иначе: здесь оценивается не ответ, а поведение системы в процессе. Это ставит новый вопрос — как вообще провести такое соревнование?

В этой статье расскажу о сути агентских соревнований, чем они отличаются от классических, и об опыте участия в BitGN PAC1 и AgentBeats.

Начать генерацию диплома онлайн

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

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

Привет, Хабр! Меня зовут Сергей Клюев, я техлид команды, которая занимается внедрением ИИ на платформе MWS Octapi.

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

По мере расширения возможностей ИИ-ассистента нам понадобилось множество интеграций. В MWS Octapi уже более 700 интеграций (OpenAPI, SOAP, AsyncAPI, GraphQL и другие). Мы решили переиспользовать их, внедрив на платформу протокол MCP. Добавление поддержки MCP позволило превратить привычные API в «руки» для ИИ и быстро интегрировать ИИ-агентов в ИТ-ландшафт.

Про возможности протокола MCP и особенности его внедрения в Enterprise среде — далее под катом. Эта статья — текстовая версия вебинара. Видеоверсия доступна по ссылке.

Сгенерировать отчет по практике

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

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

Когда RTX 5060 только появилась в продаже, вопросов к ней было предостаточно, и главный из них — про 8 ГБ видеопамяти. Уже тогда многие думали, насколько вообще хватит этого объема. Единственное, что хоть как-то успокаивало, была поддержка DLSS 4 и GDDR7, который был ощутимо быстрее GDDR6. Все-таки у 4060 тоже было 8 ГБ, и ничего. Но вот, прошел год, и пришло время посмотреть, как RTX 5060 чувствует себя в реальных сценариях использования.

1.   Введение

Всем привет! Меня зовут Яблоков Олег, я — ведущий инженер ИТ-отдела Navio и отвечаю за систему мониторинга основной инфраструктуры компании. Это работа на стыке разработки и эксплуатации (development & operations, DevOps), наблюдаемости (Observability) и обеспечения надёжности сервисов (Site Reliability Engineering, SRE). Моя основная задача не просто собирать метрики, а сделать так, чтобы по ним можно было быстро понять статусы сервисов и не утонуть в шуме оповещений.

Когда я пришел в компанию около года назад, система мониторинга уже существовала и закрывала базовые задачи. В наборе технологий использовались Prometheus, Thanos, Alertmanager, Grafana, Elasticsearch и различные наборы оповещений. Со временем количество компонентов и инструментов увеличилось, что усложнило их сопровождение и масштабирование.

В этой статье я расскажу, как происходила миграция мониторинга в Kubernetes, почему в качестве основной базой данных временных рядов (Time Series Database, TSDB) была выбрана Victoria Metrics, как мониторинг связали с Gitlab и Argo CD, пересобрали систему оповещений (alerting) и начали постепенно двигаться от инфраструктурного мониторинга к сервисному подходу и практикам обеспечения надёжности сервисов (Site Reliability Engineering, SRE). 

2. С чего все начиналось.

Изначально мониторинг представлял собой связку Prometheus, Thanos, Alertmanager, Grafana и Elasticsearch. Разворачивалось все через Docker Compose на отдельных серверах, а сама система постепенно росла вместе с инфраструктурой.

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

Вызубрить десяток флагов для docker run — недостаточно. Интервьюеры хотят видеть, что вы понимаете саму архитектуру контейнеризации: как работает изоляция процессов, почему данные внезапно исчезают после рестарта, чем слои отличаются от томов и что будет, если PID 1 внутри контейнера завершит работу.

История создания открытой настольной CO2-станции на базе микроконтроллера ESP32-C3, круглого дисплея GC9A01 и честного оптического NDIR-сенсора углекислого газа Sensirion SCD41.

Большинство бюджетных мониторов воздуха используют дешевые eCO2-датчики, которые лишь угадывают уровень углекислого газа по качеству летучих веществ. Этот проект — полностью открытая альтернатива. Прошивка написана на чистом фреймворке ESP-IDF, использована моя собственная графическая библиотека. Устройство передаёт данные по протоколу MQTT, откуда информацию может забирать умный дом или любая другая похожая система. В настоящий момент показания интегрированы в Home Assistant.