Как стать автором

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

Я назвал его TLSS, или TLS Service — карманный pki сервис.

Кратко суть

Я QA Automation на Python, так что статья может быть искажена моей профессиональной деформацией и опытом.

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

Чтобы что?
• Счастье для всех, даром, и пусть никто не уйдет обиженным!
• Помочь компаниям быстрее находить подходящих специалистов.
• Помочь специалистам перестать осваивать профессию "проходителя" собеседований.

Я узнал об отключении не из новостей. Утром мне написал знакомый из небольшого банка: «всё упало, паспорта не проверяются, онлайн встал». В то время как раз дописывал обработку ошибок в smev4-rs, Rust-крейте для работы с СМЭВ 4.

Совпадение так совпадение.

Первые несколько часов ушли на то, чтобы понять, что вообще происходит. Минцифры говорило что транспорт в порядке. Жалобы шли и от тех, кто на СМЭВ 3, и от тех, кто переезжал на СМЭВ 4. Значит дело было не в версии протокола.

Штрафы «за персональные данные»: кого и за что штрафуют на самом деле. Судебная практика по ст. 13.11 КоАП РФ.

Вот есть Postman-коллекция из 40 запросов. Разложена по папкам, и с тестовыми скриптами, которые проверяют статус-коды. Вы потратили на неё время, она хороша.

И ещё у вас есть CI-пайплайн, который про Postman никогда не слышал и слышать не собирается.

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

Получается, коллекция документирует API. CI тестирует API. Они описывают одну и ту же систему и при этом никогда не встречались.

Я написал postman2pytest, чтобы их познакомить.

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

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

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

Есть три признака того, что в техподдержке что‑то системно сломано: 

Первый — лучшие инженеры заняты самыми простыми вопросами: клиент привык связываться с конкретным человеком. 

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

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

Если хотя бы два пункта про вас — у вас есть проблема, и это проблема со знаниями.

Техподдержка работает, как пожарная команда. Работа хорошая, но как пожар, так хоть увольняйся.

Покупка профессионала из другой компаний — это не приобретение готового решения.

Я разделяю мнение автора, изложенное в книге «В погоне за звездами» (Chasing Stars) Бориса Гройсберга: успех «звезды» на 70% зависит от среды, а не от самого человека. И ведь действительно, когда «звезда» переходит в другую компанию, её эффективность часто падает из‑за выхода из зоны комфорта.

Navisworks хорошо находит BIM‑коллизии, а Revit — инструмент для исправления. Но между ними часто остаётся хаос: XML и HTML‑отчёты, Excel, переписки, ручной поиск ID и вопросы руководителей в стиле «ну как там с коллизиями?».

Я расскажу, как из этой боли вырос внутренний web‑сервис Clash Analytics: импорт XML‑отчётов Navisworks, аналитика по проектам, история коллизий, статусы, комментарии, назначение отделам и локальный Revit Bridge, который открывает проблемное место в модели за один клик.

В последнее время все чаще звучат идеи — что капча переоценена, и что развитие ИИ технологий медленно но верно убивает индустрию сервисов распознавания капчи.

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

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова.

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

В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе.

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

У нас было 2 телефонии от разных вендоров, одна речевая аналитика и 300 тысяч звонков в месяц. И задача: сделать сквозную аналитику по звонкам сотрудников.

Привет! Я Никита, инженер системного проектирования в компании Передовые Платежные Решения. Расскажу, как мы использовали единый идентификатор через службу каталогов Active Directory (AD), и стали точно определять, кому из сотрудников принадлежит звонок. Независимо от того, из какой телефонии он исходит.

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

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

В софте всё обычно иначе. Распределённый пользовательский путь — например, оформление заказа — собирается из десятков микросервисов, баз и очередей. Разработчики добавляют новую зависимость, видят зелёные тесты, проверяют локальные метрики и выкатывают релиз. Считается, что если при сбое что-то пойдёт не так, настроенная система наблюдаемости обязательно это покажет.

Она, конечно, покажет. Но почему при проектировании микросервисов мы так спокойно относимся к тому, что узнаём о хрупкости архитектуры в основном по факту инцидента?

Эта статья о том, как получить грубый расчёт деградации системы ещё до релиза. Без отказа от хаос-инжиниринга или мониторинга, а как шаг перед ними. Я расскажу о двух экспериментах, в которых топологическая модель автоматически извлекалась из распределённых трейсов, после чего на ней просчитывались сценарии отказов методом Монте-Карло. Результаты моделирования я затем сравнивал с реальными инъекциями отказов на стендах DeathStarBench и OpenTelemetry Demo.

Решаем проблемы с использованием IPv6 в быту.

Проблемы, возникающие при использовании IPv6 дома и один из способов их решения.

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

В этой статье расмотрим как создавать типы используя Reflection.Emit и реализовывать методы через Expression Trees

iceberg и его философия metadata расскажем почему iceberg эффективно выполняет запросы и прост в управлении данными благодаря своей metadata

У кого на сервере крутится Xray, рано или поздно сталкивается с ошибками вerror.log: обрывы, таймауты, несовпадение SNI, исчерпанные попытки переподключения и прочая диагностика. Смотреть «хвостом» в консоли можно, но это плохо масштабируется: хочется понимать причины, динамику, кто к нам ломится — и желательно без тяжёлого стека вроде ELK на домашней VPS.

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

Когда я начал разбираться, чем в open source можно закрыть задачу ASOC / Vulnerability Management, выбор оказался довольно грустным. По сути единственный известный вариант это DefectDojo. Сам я его в production не тащил, но от коллег регулярно слышал одну и ту же боль: на больших объёмах findings он начинает захлёбываться, в UI быстро не хочется заходить, а аналогов с человеческим интерфейсом и БДУ ФСТЭК «из коробки» в open source я просто не нашёл. Так и появилась моя ASOC-платформа: Go + PostgreSQL + Redis Streams + React, развёртывание одной командой docker compose up, миллион findings без тормозов (почти), обогащение из 7 источников, формула приоритизации, которая учитывает не только CVSS, но ещё EPSS, CISA KEV и БДУ ФСТЭК. В статье расскажу про архитектурные решения, грабли и почему я выкинул ORM ещё до первой строчки SQL.

Это не статья про готовый коммерческий продукт и не пиар-релиз. Скорее разбор того, как и почему был спроектирован Red Lycoris, open source платформа для централизованного хранения, дедупликации, обогащения и приоритизации уязвимостей. Я делаю её один, и если кому-то она пригодится, буду только рад. Если найдёте, где я ошибся в архитектуре, буду рад вдвойне.

Я решил проверить, на что способен мой старый компьютер с Radeon RX 580 под управлением Fedora. В этой статье я пошагово разберу, как завести современный ИИ-стек (Ollama, n8n, Open WebUI) через Vulkan без боли с ROCm, и почему 15-35 токенов в секунду на железе 2017 года — это реальность, доступная каждому.