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

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

Последствия быстро вышли за пределы ИТ. Компания столкнулась с нарушением производства и отгрузок, дефицитом продукции и снижением продаж. Только прямые дополнительные расходы, признанные к концу 2023 года, составили около $49 млн.

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

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

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

Привет! На связи Влад, разработчик product-facade — сердца витрины Ozon и одного из самых высоконагруженных сервисов, который выдерживает до 2,2 млн RPS. В прошлой моей статье я рассказывал об одном из архитектурных вызовов, с которым мы столкнулись в процессе работы. В этот раз продолжим тему микросервисной архитектуры и поговорим о том, что происходит, когда привычная строгость контрактов начинает мешать.

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

Мы ИТ-компания, которая в течении 10 лет смогла создать прекрасную команду — по типу «Семья». Вырастили ее, начиная с ВУЗа, провели через свой акселератор: обучили, воспитали, вложили душу. Все работало очень эффективно и непритворно до поры времени. Но когда наступил очередной кризис рынка (задержка зарплаты), «дети» повзрослели и часть из них сказала: «Родители, отдайте мои деньги, я не хочу слушать про ваши проблемы».

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

Чтобы охватить проблему чуть шире и обстоятельно ответить на вопрос: «Почему организации и люди в них ведут себя так, а не иначе?», рассмотрим несколько конкурирующих объяснительных парадигм:

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

В WMS (Workshop Management System) мы как раз убирали это трение и выстраивали процесс так, чтобы стенд Astra Automation запускался быстро, предсказуемо и без лишней суеты. В итоге получился понятный сценарий: около 10–15 минут на запуск, после чего система уже сама доводит жизненный цикл стенда до завершения.

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

Я занимаюсь исследованиями цифровых банковских сервисов много лет. И уже 10 лет мы исследуем мобильные банки для бизнеса.

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

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

В этом году мы представили результаты исследования Markswebb Business Mobile Banking Rank 2026 и решили вспомнить, какими были сервисы 10 лет назад. В этой статье хочу поделиться своими наблюдениями.

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

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

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

Агент в Сан-Франциско тратит двадцать минут на то, чтобы пофиксить баг, который агент в Лондоне решил пять минут назад. Опыт первого умрёт вместе с сессией: завтра тот же баг будет с нуля решать кто-то третий. В Stack Overflow это называют Ephemeral Intelligence Gap — и 10 июня 2026-го компания запустила под эту проблему отдельную платформу: Stack Overflow for Agents, площадку, где опытом обмениваются не люди, а агенты.

На Хабре про запуск уже писали в паре статей, а в опросе под одной из них 59% проголосовали за «проект закроется». Мне есть что к этому добавить: я почти сразу после запуска завёл туда агента — научил его ходить на площадку по API — и спустя месяц он в топ-8 лидерборда. Всё это время я смотрел на платформу не из новостей, а изнутри — и встраивал её в свой пайплайн агентной разработки.

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

Пишу свой путь разработки self-hosted сервера с полностью автоматизированным развертыванием с полным циклом состоящим из около 15 DevOps технологий, а также 7 сервисов, которые будут полезны каждому!

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

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

Пайплайны редко тормозят из‑за одной большой проблемы — чаще минуты незаметно съедают неработающий кэш, тяжёлые образы, очереди и лишние зависимости между джобами.

Разберём шесть типичных ошибок в настройке GitLab Runner и посмотрим, как найти узкое место до того, как команда привыкнет ждать сборку по двадцать минут.

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

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

PHP‑массив выглядит универсальным, но внутри него скрыто множество оптимизаций и ветвлений, в их числе оптимизации для хранения и работы с массивами: Packed List & HashTable. Взаимодействие между ними и copy‑on‑write дают иногда неожиданное и непрозрачное поведение с точки зрения PHP программиста.

При миграции из одной корпоративной системы в другую часто встает задача репликации данных. Например, при поэтапной замене ERP по методологии Parallel Running во время опытной эксплуатации пользователи работают в двух системах, которые оперируют идентичным набором данных. Если модели данных сильно отличаются, а при репликации присутствует дополнительная логика, то команды чаще всего пытаются использовать шины данных (например Kafka). При таком подходе требуется самостоятельно реализовать механизмы копирования данных, обработки конфликтов, пересинхронизации, мониторинга и т. д. Все это увеличивает трудозатраты и потенциально может стать источником проблем. В этой статье разберем техническую реализацию репликации данных через шины, ее слабые места, а также альтернативные подходы.

Событийно-ориентированная архитектура красиво выглядит на схеме — пока не встречается с требованиями реального времени.

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

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

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

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

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

Представьте, что 12 нот хроматической гаммы и 12 оттенков цветового круга — это не просто разные физические волны, воспринимаемые нашими органами чувств, а проекции единой математической структуры. Что если законы музыкальной гармонии (аккорды) и правила художественного контраста (цветовые схемы) можно описать с помощью чистой арифметики делителей на гранях правильного многогранника?

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

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

Для кого

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

Кратко

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

Меня зовут Дмитрий Шестаков, основатель компании Сайткрафт. Чаще всего ко мне приходят с запросом в стиле: нам нужно SEO, конкуренты в топе, мы отстаём. И почти всегда мой первый честный ответ — давайте сначала посчитаем, окупится ли это у вас в ближайший год. Потому что для подписочного сервиса поиск умеет приносить дешёвые заявки годами, а умеет полгода жечь бюджет на трафик, с которого никто не покупает. Дело тут не в подрядчике и не в усердии. Решает то, готов ли продукт к этому каналу.

Содержание

1. Почему SEO советуют всем подряд

2. Признак первый: вы не знаете, по каким запросам у вас покупают

3. Признак второй: экономика не сходится даже на платном трафике

4. Признак третий: сайт не превращает визиты в заявки

5. Признак четвёртый: нет запаса хода на длинную окупаемость

6. Признак пятый: SEO некому вести в долгую

В этой статье мы вспомним, почему Vista была не такая плохая как кажется, разберём её сервис-паки, историю и какие глобальные изменения ввела имено Vista