IT-стандарты *

Привет, Хабр! Я Николай Видов, разработчик в команде чатботов. Я работал как в небольших компаниях, так и в тех, которые на слуху: EPAM, QIWI, Т-Банке. За время работы я часто сталкивался с понятием продуктовости: «Разработчики должны активно участвовать в бизнесе», «Разработчики должны предлагать улучшения для продукта», «Разработчики должны аргументированно спорить, если не согласны с предложенной функциональностью».

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

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

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

Привет, Хабр! C вами сегодня Владимир Кудрявцев, Илья Князев и Иван Пономарев.

Дело было вечером, дебажить было нечего. К нам пришел Анатолий, менеджер продукта ALD Pro, и попросил разобраться, с чего это Linux приходит в такую задумчивость от недоступности первых двух DNS-серверов, в то время как Windows вполне нормально справляется с таким сценарием. «Да, как два байта переслать», – подумали мы. И начался квест длиной в две недели.

Материалы будут полезны, даже если вы все ещё используете обычные Linux-системы с ванильными версиями компонентов.

Введение

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

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

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

Концептуальная основа: ООП (Объектно‑ориентированное программирование)

Концепция ООП лежит в основе структуры и окружения нашей платформы. Понимание ООП необходимо аналитику для:

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

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

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

Несмотря на то, что я обладаю практическим опытом создания технических команд с нуля, внедрения CMDB и разработки корпоративных регламентов, ранее эти процессы не были формализованы в виде единого стратегического плана. За 6,5 лет работы в холдинге FIBA Group, я глубоко изучил все этапы развития ИТ-команд и проектов изнутри. Данное тестовое задание стало для меня отличной возможностью систематизировать накопленные знания и представить их в виде структурированного документа.

Открыв свою любимую библиотеку ITIL 4, я начал обдумывать проект. У каждого проекта должны быть цели, а значит, и мне нужно их определить. Какими они могут быть для новой службы ИТ-поддержки? В первую очередь - достижение ключевых показателей эффективности (KPI).

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

Бизнес-требования на автоматизацию и их связь с корпоративной архитектурой организации

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

Представьте: у вас десятки микросервисов, миллионы логов и трассировок, а ваша задача — поддерживать SLA и не дать системе сломаться. Ручная настройка SLO (Service Level Objectives) и мониторинг SLI (Service Level Indicators) превращается в кошмар.

SLO-Scout решает эту проблему с помощью AI, анализа телеметрии и автоматизации, позволяя SRE сосредоточиться на надежности, а не на ручной рутине.

Привет, постоянные и не очень читатели!

CXL (Compute Express Link) — свежий стандарт интерконнекта, появившийся в 2019 году. Его главная фича — новый подход для работы с памятью и вычислениями: поддержка когерентного кэша и трафика между процессорами и ускорителями, возможность собирать инфраструктуру как конструктор, гибко распределяя ресурсы, и другой функционал.

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

Здесь будет всё, что вы хотели знать про CXL, но лень было искать, так что заваривайте чайничек листового — и приятного чтения! :)

В прошлой статье мы рассмотрели новые поправки в законодательстве об административной и уголовной ответственности за правонарушения в сфере персональных данных (ПДн). Дорогие Операторы ПДн, как вы там? Успели подать уведомление в Роскомнадзор, победив перебои в работе портала? Приступили к выстраиванию правомерных процессов обработки ПДН и системы их защиты?

Как мы знаем, Федеральный закон от 27.07.2006 г. № 152-ФЗ «О персональных данных» призван в первую очередь защищать права и свободы граждан, поэтому важно его соблюдать не с точки зрения защиты от штрафов, а с точки зрения защиты ПДн граждан. Нововведения в КоАП и УК РФ заставили Операторов собраться и все-таки заняться пробелами в обработке и защите ПДн в их организациях. На мой взгляд, это послужило первым шагом в налаживании диалога с регуляторами и к действиям, направленным в первую очередь на выстраивание грамотной защиты данных граждан.

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

JPEG — формат-динозавр. Ему уже за тридцать, но он по-прежнему живее всех живых: даже в 2025 году изображения в JPEG встречаются повсюду.

В конце 80-х инженерам нужно было как-то справляться с растущими размерами файлов. Интернет был медленным, а фотографии — всё тяжелее. Тогда и придумали решение: сжатие с потерями, основанное на дискретном косинусном преобразовании (DCT). Если по-простому, DCT — это способ выкинуть из картинки то, чего наш глаз почти не заметит, и оставить главное. В итоге получаем файл в разы меньше, а картинка всё ещё выглядит прилично.

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

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

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

Привет, Хабр! Меня зовут Роман Изотов. Последние 5 лет я провел по ту сторону баррикад – в роли IT-рекрутера, где отсмотрел более миллиона резюме и провел тысячи собеседований. Сегодня я помогаю IT-специалистам взламывать систему найма, и вот что я вижу: многие по-настоящему сильные Senior-инженеры, тимлиды, архитекторы сталкиваются с одной и той же проблемой – их резюме просто не работает.

«Мой опыт говорит сам за себя!» – Главное заблуждение.

Кажется логичным: если у тебя 7-10 лет опыта, куча проектов, сложные технологии, то резюме должно привлекать. Но в 2025 году это больше не так. Рынок перегрет, конкуренция бешеная. На одну Senior-вакансию приходят десятки, а то и сотни откликов. И вот тут в игру вступают фильтры, о которых вы могли даже не догадываться.

Фильтр №1: Автоматизированные системы отбора (ATS) – ваш первый и самый беспощадный враг.

Забудьте про креативный дизайн и инфографику. Для ATS ваше резюме – это набор ключевых слов. Если вы не используете точную лексику из описания вакансии, не указываете конкретные технологии и метрики – ваша заявка просто не дойдёт до HR. Система не поймёт, что "оптимизировал производительность" означает "сократил время отклика сервиса на 30% на пять миллионов пользователей". А если она не поймёт, то вы в корзине.

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

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

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

Сегодня я пытаюсь понять реальные риски внедрения нейросетей в рабочие процессы. Надеюсь на твои комментарии, наблюдения и страхи, Хабр!

Когда я впервые узнал о кодировке UTF-8, то был поражён её продуманностью и структурой. Тем, как изящно её авторам удалось выразить миллионы символов разных языков и письменностей, параллельно сохранив обратную совместимость с ASCII.

В UTF-8 используется 32 бита, а в старой доброй ASCII — 7 бит. Но UTF-8 выстроена так, чтобы:

- Любой файл в кодировке ASCII являлся валидным файлом UTF-8.

- Любой файл в кодировке UTF-8, имеющий только символы ASCII, также являлся валидным файлом ASCII.

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

Привет, Хабр! Я старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой. Материал основан на реальных кейсах из практики: мы в школе System Analyst не просто рассказываем теорию, а делимся тем, что действительно работает на проектах.

За свою карьеру я написала не одну сотню требований и поняла такую вещь – самые важные и самые незаметные, это блок нефункциональных требований. 

В этой статье я расскажу, как правильно выявлять и формулировать НФТ.

Привет! Я Лев, специалист продуктовой поддержки в Selectel. Ранее мы разобрались, какими бывают технологии при строительстве межцодовых трасс, а также прокачали навыки в резервировании. Теперь перейдем к практике и разберемся, как составлять проект межцодовой трассы. Изучим, как выбрать технологии, рассчитать пропускную способность и обеспечить надежность инфраструктуры.

Привет, Хабр!

Продолжаю публиковать наши разговоры из телеграм-канала Dev Q&A. В этот раз собрались обсудить одну из самых спорных тем в российском IT — low-code платформы. Тема настолько горячая, что удалось собрать представителей ведущих российских low-code платформ и практикующих разработчиков.

$199 за файл.

Не за программу. Не за базу данных. Даже не за документ с полезной информацией. За файл в несколько килобайт зашифрованного текста, который говорит браузеру «этот сайт действительно тот, за кого себя выдает».