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

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

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

На практике всё часто работает чуть иначе.

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

И вот именно на них люди регулярно сыпятся.

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

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

Сразу уточню важный момент. Я не пытаюсь доказать, что такие вопросы идеальны или что именно так и нужно проводить собеседования. У многих к ним вполне обоснованные претензии, и я их понимаю. Но пока рынок продолжает их задавать, полезно хотя бы понимать, что именно через них пытаются считать и почему на seemingly простом ответе иногда тихо умирает оффер.

Почему вообще такие вопросы так важны

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

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

Именно поэтому рынок так любит эти странные вопросы, которые вроде бы не про технологии.

Они не проверяют знания. Они проверяют совместимость.

В своем Telegram-блоге я регулярно пишу про рынок IT, тестирование, автоматизацию и карьеру в индустрии.

Всегда рад новым читателям!

512 000 строк утёкшего кода, совещание ботиков, и почему человек стал узким местом разработки

31 марта 2026 года Anthropic случайно выложила npm-пакет с source map файлом на 59.8 мегабайт. Внутри - 512 000 строк TypeScript, 1 900 исходных файлов и 44 скрытых feature flags. Весь исходный код Claude Code, включая вещи, о которых пользователи даже не подозревали.

За несколько часов репозиторий форкнули 41 500 раз. Anthropic начала рассылать DMCA-takedowns, но было поздно. Сообщество успело найти упоминания KAIROS - автономного агента, который работает пока ты спишь, консолидирует память и проактивно действует без промптов. 150+ упоминаний в коде. Нерелизнутые модели Opus 4.7 и Sonnet 4.8. Режим "Undercover" для сотрудников Anthropic, скрывающий AI-атрибуцию в коммитах на публичных репозиториях.

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

Начнём с десяти вещей, которые делают Claude Code не просто ещё одним AI-помощником.

Мы десятилетиями строим IT-системы, но до сих пор не можем ответить на элементарный вопрос: кто за что платит? Теги есть, аллокация настроена, но в отчетах — хаос. Затраты разбросаны по разным системам (биллинг облака, CMDB, Excel-таблицы у финансистов), и все это приходится собирать вручную перед каждым советом директоров.

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

1000 устройств, 5 офисов, 1 Excel. Разбираем, где ломается учёт оборудования при росте компании и как перестать терять технику между филиалами.

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

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

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

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

В корпоративном ИТ всё работает точно так же. Пока вы не заглянете в серверную, не проведете инвентаризацию и не сверитесь с бухгалтерией, ИТ-инфраструктура находится в суперпозиции: ноут уволившегося разработчика одновременно сдан на склад и потерян; дорогая лицензия всё еще действует и уже просрочена; сервер выполняет критически важную бизнес-задачу и вхолостую жжёт электричество. Драгоценная табличка в Excel с гордым названием Оборудование_финал_v4_Копия.xlsx не связана с реальностью — она всего лишь описывает вероятности. И управлять многомиллионным бюджетом на основе таких вероятностей — путь к финансовой катастрофе, седым волосам по всему телу и хаосу.

На контроллере домена система EDR фиксирует подозрительную активность. Кажется, ничего такого. Обычный алерт, один из нескольких тысяч, которые ежедневно обрабатывает SOC. Однако уже через 15 минут этот инцидент приведёт к полному хаосу в ИБ‑отделе и заморозит деятельность всей компании. 

Меня зовут Сергей Нестерук, я отвечаю за безопасность применения искусственного интеллекта в Yandex Cloud. В этой статье расскажу, как не допустить ситуации, которую я только что описал.

Привет. Я фронтенд-разработчик. По мнению тех, кто, по мнению некоторых, перекладывает джейсончики туда-сюда, я крашу кнопочки. Но сам я себя идентифицирую иначе: я тоже перекладываю джейсончики, и у меня всё точно так же, как у них. Даже архитектура. У меня тоже есть контроллеры, сервисы и хранилища, и я также обрабатываю запросы пользователей. Даже больше, я делаю HATEOAS, «тру» RESTful, если хотите. Давайте расскажу, как я к этому пришел.

Когда-то давно я только верстал. Накидывал разметку, добавлял классы, идентификаторы и стилизовал ЦСС-ом. И было хорошо. Потом от меня потребовали динамичности — пришлось добавить JavaScript. И было очень хорошо.

Технологии развивались, и мне хотелось пробовать новое. Я попробовал AJAX. Это было так волнительно... Я сказал бэкендерам: основную разметку жду от вас, а опции для выпадающего списка, например, отдавайте джейсоном по запросу. Они были не в восторге. «Одному HTML подавай, другому CSV, третьему ещё что-то — безобразие!» Но мы нашли компромис. Бэкэндеры сказали: «Вот вам, мол, джейсон, дальше сами как-нибудь». И назвали это REST API.

Сначала было очень круто! Мы, верстальщики, организовались. Мы стали фронтендерами! Конечно же, мы сразу побежали решать ещё нерешённые сто раз решённые задачи. Мы писали библиотеки и фреймворки — четыре миллиона штук! Да у нас даже есть библиотека с функцией для умножения чисел — lodash.multiply. Мы придумывали свои паттерны и архитектуры, например FSD. Короче, мы стали очень крутые.

Но то уже были «мы», а не я. Мне было сложно. Шутка ли, изучать по одному новому фреймворку в неделю? А ведь еще переписывать всё надо, стек-то устарел... В общем, в какой-то момент я перестал поспевать за модой и справляться со сложностью. Переходишь из одного проекта (на React) в другой (на Vue), а там всё иначе. Берешь нового разработчика в команду с опытом в React, например, а ему нужно время, чтобы вникнуть, потому что в его старой команде был другой «стейт-менеджер». Вавилон, никто друг друга не понимает.

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

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

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

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

В частности, писатель обнаружил существование областей общественной жизни, которые остаются без наблюдения: «огромная часть русского строя жизни осталась вовсе без наблюдения и без историка, … У нас есть бесспорно жизнь разлагающаяся …. Но есть, необходимо, и жизнь вновь складывающаяся, на новых уже началах. Кто их подметит, и кто их укажет? Кто хоть чуть-чуть может определить и выразить законы и этого разложения, и нового созидания?» Он как раз и стремился подметить законы и разложения, и созидания.

Метод позволил самому Достоевскому стать всемирно известным писателем и повлиять не только на российскую и мировую литературу и культуру, но и на науку. Альберт Эйнштейн писал, что Достоевский дал ему необычайно много, больше чем величайший математик Гаусс. Физик не объяснил, чему именно научился он у писателя, но можно предположить, что это касается способа мышления, который у них обоих совпадает в ключевом моменте.

Привет, Хабр! Вот два факта:

R&D - это единственный путь к реальным инновациям, которые дают конкурентные преимущества и, потенциально, меняют или даже создают новые рынки

Большинство менеджеров и представителей бизнеса боятся столкновения с R&D-задачами как огня, и решаются эти задачи, часто, “вопреки”, а не “благодаря”

Давайте разберемся, почему так происходит и что с этим делать.

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

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

Давайте придумаем наглядный и понятный галактический ID, с которым сосуществование разных форм разумной жизни станет более комфортным и упорядоченным.

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

Вместе с Виталием Глушаковым мы решили разобрать, как это работает (или не работает, пусть будет сюрприз) на практике. Виталий имеет большой опыт управления и FinOps-трансформации отделов разработки и уже опубликовал свою часть на LinkedIn — «FinOps: 5 шагов к зрелости». Обязательно почитайте, там много интересного. А мы, со своей стороны, дополняем каждый тезис практическим контекстом, потому что между тем, как должно быть и как оно бывает на самом деле, иногда помещается целая пропасть.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

Приветствую всех!

У меня было обилие мыслей на тему того, что можно сюда написать и решил разобраться в фундаменте мироустройства языков программирования. Копнуть в самую суть с разбором когда американских дедов(и их же репозиториев), которые вполне себе могли написать нечто и под знаменитым кукурузным XXX самогоном.

Решил я фундаментально разобрать то, как работает Golang, потому что в интернете(YT, Конфы и пр.), на мой взгляд, крайне много откровенно поверхностной и верхнеуровневой информации. Я, конечно, буду рад, если вы укорите меня в моих слабых навыках поиска и покажете мне, что реальность не такая, какой я её выдумал, но субъективно это так.

Разборы здесь будут скорее про то, что лежит в порождении сумрачного американского гения по ссылке github.com/golang/go с периодической синхронизацией с официальной документацией.

Моя главная цель – разобрать всё максимально исчерпывающе, насколько я это смогу.

Чтож, поехали!

Ах, да. В этом цикле не будет особо веселых рисуночков с гоферами, а скучные блок-схемы, диаграммы и вырезки из кода.

Структурная схема

Автор: Елизавета Пермякова, консультант по информационной безопасности Innostage

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

Для выполнения большинства моих рабочих задач мне необходимо анализировать существующую и разрабатывать недостающую организационно-распорядительную документацию для организаций из разных отраслей (это и ТЭК, и металлургия, и финансовые организации). На практике замечаю, где компании с низким уровнем зрелости ИБ допускают одни и те же ошибки, и благодаря каким подходам компании со средним и высоким уровнем зрелости ИБ – выстраивают работающие процессы ИБ. В этой статье я покажу, где обычно «хромает» документация, и дам лаконичный чек-лист, с которым большинство документов можно проверить примерно за 15 минут.

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

Решил написать эту статью, чтобы один раз объяснить тему на языке бизнеса. Не для того, чтобы читатель сам пошёл настраивать интеграцию — а чтобы он мог внятно передать требования дальше, задать правильные вопросы подрядчику и понять, на что смотреть в отчётах. Если вы продакт, BA, маркетолог или руководитель направления, которому приходится иметь дело с CPA-партнёрами и трекерами — это для вас.

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

Современная разработка погрязла в driven, first и based подходах, недавно этот зоопарк пополнился еще одним заморским зверем под названием AI-driven (пусть меня простят свидетели AGI, но я сознательно не выделяю этот подход на фоне остальных и в конце объясню почему). Но не пытаются ли все эти подходы на самом деле решить одну и ту же проблему, известную еще с середины прошлого века, проблему "абстрактного перехода"?

WebSocket vs SSE простым языком: двустороннее и однонаправленное соединение, как работает TCP и HTTP upgrade, и какие вопросы по этим темам чаще всего задают на собеседовании.

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

Меня зовут Гайнутдинов Роман, я старший инженер по автоматизированному тестированию в компании «БКС Мир инвестиций». За плечами построение автоматизации с нуля, поддержка готовых решений и оптимизация уже раздутых регрессионных наборов.

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

Этот текст родился из разговоров с руководителями, у кого ИТ живет отдельной жизнью. Вроде все есть — сервера, админы, регламенты, — а по факту то кассы встали, то 1С не отвечает, то люди боятся сказать, что что‑то сломали. После каждого инцидента начинаются поиски «крайнего», но толку от этого мало.

Меня зовут Мария Богданова, я веду проекты в ALP ITSM и часто приезжаю в компании именно «на пожар». Где‑то вытащили данные после шифровальщика, где‑то разбирали, почему заявки в ИТ теряются в переписке и мессенджерах. Истории разные, но суть одна и та же. ИТ как будто есть, а доверия к нему нет.

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