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

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

За 8 лет работы с стартапами я видел эту картину десятки раз. Команды тратят 6-12 месяцев на разработку — и только после запуска узнают, что рынка нет. Можно иначе: проверить гипотезу за две недели, потратив 150-300К рублей.

В предыдущей статье мы подключали OpenGL. Но подключали его без уважения… Давайте сделаем это как надо!

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

Давайте разбираться, как с этим жить.

Классическая архитектура сетевой безопасности строилась вокруг одной предпосылки: существует чёткая граница между «внутри» и «снаружи». Межсетевой экран нового поколения (NGFW) стоит на этой границе и инспектирует трафик. Модель работала, пока сотрудники сидели в офисе, приложения - в корпоративном ДЦ, а удалённый доступ оставался исключением из правил.

Сегодня, особенно в эпоху «после ковида» и во времена рассвета облаков, это уже не так. Мы в Айдеко сами живем «гибридной» реальности с 2021-го года: работая полностью распределенной по всей России командой 300+ сотрудников в гибридной цифровой среде (где множество сервисов в облаках, но есть и локальные устройства и серверы связанные с необходимостью работы с «железом» ПАК-ми, стендами для нагрузочного тестирования NGFW и т.п.).

Наша цель – предоставить корпорациям решение для организации безопасной работы с современной ИТ-инфраструктурой где бы не находились сотрудники: на удаленке, в командировке, в офисе или других странах.

Классический NGFW в таких условиях остается необходимым - но его одного уже недостаточно.

Ответом индустрии стала архитектура SASE (Secure Access Service Edge), предложенная Gartner в 2019 году. SASE объединяет сетевые и security-функции в единую облачную платформу. Глобальные вендоры уже перестроили свои продуктовые линейки: Palo Alto Networks развивает Prisma SASE, Fortinet - FortiSASE, Zscaler выстраивает cloud-native SSE-платформу. По данным Gartner, к 2028 году 50% SASE-развёртываний будут базироваться на решении одного вендора - с 30% в 2025 году. Консолидация ускоряется.

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

Лично на форуме я не присутствовал, но, учитывая, что до недавнего времени я был сотрудником ФНС и эта тема мне более чем знакома и интересна, пройти мимо такой повестки, конечно, не могу.

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

Сегодня на очереди запись онлайн-трансляции пленарного заседания «Экономическая справедливость».

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

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

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

Седьмой выпуск еженедельных IT-новостей от OpenIDE: новый бенчмарк AGI, которому модели не смогли угодить, трёхбитная квантизация от Google, ACP-протокол в OpenIDE, GigaChat 3.1 и бесславный конец Sora.

RAG-система для документации 1С: архитектура MCP-серверов documents1c и metadata1c

Когда разработчик 1С задаёт вопрос AI-ассистенту, ему нужен точный, актуальный ответ со ссылкой на источник — документацию по 1С или описание объекта конфигурации. Именно для этого созданы два MCP-сервера: documents1c (поиск по документации 1С) и metadata1c (поиск по конфигурациям 1С). Оба сервера реализуют многоуровневую RAG-систему с несколькими слоями ранжирования.

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

Сегодня многие пользователи ИИ живут в двух параллельных реальностях: одни получают гранты и «стебут» Голливуд с помощью SeeDance 2.0, а другие не знают, как зарегистрировать аккаунт без зарубежной карты и получить охваты в Тик‑Ток, получая шаблонные «пластиковые» видео на выходе, которые уже «надоели» всем алгоритмам во всех существующих социальных сетях. Отсюда простой вывод — для генерации видео нужно понимать свои цели и потолок того или иного AI для масс‑маркета в контексте поставленной задачи. Сегодня мы расскажем, как создавать любительские видео для развлечений и трафика в социальных сетях максимально просто, и на что способны доступные языковые модели — без профильного образования оператора или дизайнера. 

За последние дни произошло сразу несколько событий вокруг VPN, которые в совокупности кардинально меняют правила игры для миллионов пользователей.

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

Мы решили сломать привычную модель корпоративных мессенджеров.

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

В 8 из 10 случаев компании внедряют ИИ туда, где ещё не выстроены базовые процессы - и именно поэтому он зачастую не ускоряет Time-to-Market, а иногда даже замедляет его.

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

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

Представьте, что вы платите за электричество, которое не используете. Не потому что ошиблись в расчётах, а потому что так устроена тарифная модель. Именно это может стать реальностью операторов ЦОДов: переход к оплате за резервируемую мощность превращает каждый запас на будущее в убыток в текущий момент. То, что раньше считалось хорошей практикой ― строить с запасом и постепенно загружать мощности, ― теперь становится финансовой ловушкой.

В Enterprise-сегменте (ритейл, финтех, промышленность) часто возникает типичная задача: есть тяжелое, неповоротливое ядро (SAP, Oracle, IBM Tririga или монолитная 1С) и есть необходимость дать доступ к части его данных внешним контрагентам.

Бизнес просит: «Давайте сделаем легкий B2B-портал для подрядчиков, чтобы они сами обновляли свои лимиты/квоты/статусы».

На первый взгляд задача кажется тривиальной: подняли Frontend на React/Vue, сделали пару REST API эндпоинтов и пишем напрямую в базу ядра. Но именно здесь начинаются архитектурные катастрофы, которые стоят корпорациям миллионы рублей из-за потерянных данных и логических конфликтов.

В этой статье я разберу паттерн отказоустойчивой двусторонней интеграции через шину данных (ESB) и покажу, как мы стандартизируем описание таких узлов с помощью протокола АОК (Архитектурно-Ориентированное Знание).

В первой статье цикла мы рассказали о том, что несет в себе понятие сетевых скрытых каналов. Во второй статье мы поговорим о том, как строятся сетевые скрытые каналы в реальных сетях пакетной передачи на примере протоколов IPv4, ICMP и HTTP.

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

Получается, один бот в одном чате одновременно и ИИ-ассистент, и мост между людьми. Как именно — рассказываем.

Привет, Хабр! Меня зовут Иван Костыря, и я работаю в команде SOC UserGate.

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

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

Прежде чем говорить о коммуникации, определимся с терминами:

JMX-файл на 50 000 строк, merge-конфликты при каждом коммите и PR-ревью, которое никто не читает - знакомо? Я столкнулся с этим на реальном проекте и нашёл способ декомпозировать JMeter-тесты так, чтобы основной файл похудел в 10 раз, а работать с тестами стало можно прямо из IDE.

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

Евгения Крюкова, старший аналитик «Оптимакрос», разобрала в статье, как OLAP-кубы (Online Analytical Processing) меняют бюджетирование и планирование в организации и почему именно их выбор становится критически важным этапом цифровой трансформации финансового подразделения компании.

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

MCP выглядит как удобный способ структурировать LLM-приложение, но за это приходится платить. При этом попытки «ускорить систему» через C++, IPC или смену сериализации не всегда дают ожидаемый результат. В статье разбираю, где на самом деле возникает latency и почему архитектура оказывается важнее, чем выбор технологий.

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

1 - Бани в Европе пришли в упадок между 500 - 800 годами. И расцвели по новой, начиная с 900-х годов. Связано с ростом городов, плотность населения возросла, интенсивность торговли снова позволила людям зарабатывать и делала выгодным такие заведения. Главная причина упадка культуры была в бедности, а не запретах религиозных. Арабы бегали по Ближнему Востоку и на сотни лет заблокировали торговлю и приток серебра в Европу. Когда вопрос решили через крестовые походы, бани снова вошли в моду.

2 - На Руси баню переняли от финно-угорских народов, она фиксируется с 900 - 1000 годов. Вот только чума в Европе была, а на Русь не сразу дошла не по причине бань. Мылись люди и в Европе, но плотность населения была не сравнима с Русью. Русь по сути была безлюдной территорией площадью более 1 000 000 км2. Большая часть народу жила на Руси в те годы в мелких поселениях, буквально по 5 - 10 дворов.

3 - Пометочка - все эти чумы, оспы и прочая гадость, приходили с южных регионов. Ну потому что так называемые природные очаги болезней, когда болезнь живёт в постоянной популяции крыс, кроликов и наподобие, стабильнее в южном регионе, а не в холодном. Хотя изначально чума появилась в степном регионе где-то в регионе Алтая, точнее не сказать, около 6 000 - 7000 лет назад, среди кочевых европеоидных культур. https://www.trv-science.ru/2018/07/stepnoj-koridor-dlya-chumy/