Я Роман, CTO и сооснователь Web-Bee.

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

Обожаю задачи, когда «надо вчера». От «переверстать какое-то дерьмо» до «стойка сгорела, а запуск через неделю» или «во что мы вообще вписались?!».

Если у вас горит — пишите: @demeshenko
Мелкое потушу сам. Крупное — подтяну команду Web-Bee: разработка, highload, инфраструктура, 100+ человек.

Не горит, но давно тлеет и никто не понимает почему — тоже пишите.

Понедельник. Офис живёт на уже установленных соединениях. С каждым часом их меньше, новые не поднимаются.

ВПСка, через которую офис ходит наружу, внезапно стала недоступна. Из офиса, из дома, из Москвы, через Ростелеком и местных провайдеров.

Почему? Зацепило при массовых блокировках.

Написал сканер доступности адресов из РФ и прогнал его по пулам датацентров. У трёх популярных хостеров не проходят 20–30% IP, в некоторых пулах до 40%. У немецкого хостера 7%. Это уже похоже не на точечные блоки, а на выжигание целых подсетей.

И тут прикол: взять новую тачку — не выход. Тебе выдают свежеосвободившийся IP. Который кто-то выбросил. Потому что он заблочен.

Хецнер? Там свои приколы с оплатой из РФ.

Зато выяснилось, что Яндекс Облако видит машины, которые все провайдеры считают мёртвыми. Магия. И цена у магии соответствующая: обычная виртуалка (1 ядро, 1 ГБ, 15 ГБ NVMe) у хостера стоит рублей 300 в месяц. В Яндексе 0.4 ядра, гиг и 10 ГБ HDD — 1384.

Похуй. Работает.

Было: Tailscale → офис → анблокер → ВПС.
Стало: Tailscale → офис → анблокер → world (Яндекс) → ВПС.

Новое звено — это бэкапы, мониторинг и ещё одна точка отказа. Но больше всего бесит стрелочка world → ВПС. Умрёт она — умрёт всё. А Tailscale на ней уже шатается и активно пытается сдохнуть окончательно.

Нужен второй транспорт. Через кого-то, кого не забанят. Cloudflare.

Cloudflare работает с доменами. Поддомен — 20 баксов в месяц, и из РФ не оплатить. Домен целиком — бесплатно. Рабочие домены в такую схему светить не хочу, поэтому покупаю отдельный, специально под эту херню.

Настраиваю, всё работает. Скачивание — сотни мегабит. Аплоад — 1–2 Мбит. А через эту дырку надо протащить весь офис.

Смотрю трафик: скорость нормальная, но только первые 16 КБ соединения. Дальше пиздец.

Ну мы ж программисты. Режем поток на куски по 16 КБ и пускаем параллельно. ~10 Мбит. С такой дыркой (наверное, правильнее "технологическим отверстием") уже можно жить.

Два транспорта есть. Переключать руками по крикам в телеге? Не, я ленивый. Автобалансировка: Tailscale основной, Cloudflare резерв, проба каждые 10 секунд.

Работает.

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

Вроде живое. Пиздец, а не ночка.

Иногда расследование заканчивается очень неприятным открытием. Ты потратил день: снял дампы, проверил MTU, маршрутизацию, NAT и файрвол, залез в RouterOS и начал подозревать SSTP. А проблема оказалась в логине.

Жалоба была такая: сотрудники арендатора не могут подключиться по RDP через VPN к компьютеру в своей же локальной сети. Выглядит всё очень убедительно: ping проходит, 3389 открывается, появляется окно ввода логина — а потом соединение умирает по таймауту.

Ну и понеслось: PMTU blackhole и клэмпинг MSS, маршрутизация клиента, файрвол Windows, сетевая категория Public/Private, NAT. По пути на самом компьютере нашлась прекрасная вещь — кто-то вручную повесил на физический интерфейс второй IP из диапазона нашего VPN. Windows после этого считает VPN-сеть локальной и пытается ходить в неё напрямую. Удалил. Не помогло.

Иду в дампы и журналы. Там стабильно повторяющаяся ошибка TLS-хендшейка внутри CredSSP, одинаково на двух разных клиентских машинах. Гипотеза готова: что-то с SSTP-туннелированием в RouterOS. Уже морально готовишься разбирать полмира.

И тут выясняется, что весь день я тестировал с логином user. Только user — это не имя учётной записи, а отображаемое имя на экране входа Windows. Настоящий логин другой. Ввожу правильный — RDP сразу работает, без единого изменения в сети.

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

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

И день всё-таки не пропал зря. Пока ковырял роутер арендатора, нашёл старый проброс 3389 с публичного IP прямо на рабочий компьютер, без всяких ограничений по источнику. Видимо, наследство предыдущего админа. RDP наружу — это круглосуточный перебор паролей ботами. Удалил сразу. Проблема, которую я искал, оказалась выдуманной, а настоящая дыра лежала рядом и спокойно ждала, пока её кто-нибудь найдёт.

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

Вывод на будущее: прежде чем лезть в дампы, убедись, что входишь с гарантированно правильными учётными данными. Стабильно воспроизводимая проблема — ещё не понятая проблема. А иногда надо просто проверить логин.

Пришли ко мне с задачей: «Надо понять, кто у нас Middle, а кто Senior».

Матрица компетенций к тому моменту у нас уже была — большая, техническая, человек в ней описывался десятками компетенций. Но руководству нужен был один ответ: «Он кто? Middle или Senior?»

И тут выяснилось, что один и тот же человек может быть Senior в бэкенде, Middle во фронтенде и Junior в каком-нибудь DevOps. Вопрос «какой у него грейд?» просто не имеет нормального ответа.

Мы несколько раз пытались это чинить: придумывали правила, калибровки, автоматическое выставление грейдов. Всё упиралось в одно — мы пытались запихнуть многомерного человека в одну колонку.

В итоге поменяли модель. Матрица компетенций — источник данных. А Junior / Middle / Senior — не свойство человека, а представление, которое строится под конкретную задачу. Если по-программистски: грейд — не поле в таблице сотрудников, а view поверх матрицы.

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

То есть вместо «Петров → Senior» получаем «Петров → данные → нужное представление».

И внезапно спор «а он всё-таки Middle или Senior?» перестал быть центральной проблемой. Мы не стали лучше выставлять грейды. Мы перестали делать вид, что грейд — это исходная характеристика человека.

Прекрасная бухгалтерская история.

Пришёл новый компьютер, нужно настроить на нём токен. На старом всё работает, на новом — нет. Ставим Windows 10 — не работает. Ставим Windows 11 — тоже. Берём тот же набор программ и те же драйверы, ставим вроде бы один в один. Не работает.

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

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

Схема, очевидная задним числом:
токен → драйвер → криптопровайдер → программа

Я почему-то мысленно склеивал первые три звена в одну сущность «драйвер токена». А драйвер может стоять идеально, Windows может прекрасно видеть токен — и при этом криптографически использовать его всё равно нечему.

«Всё установлено» и «установлено всё необходимое» — две совершенно разные вещи. Поставили КриптоПро — заработало.

¯\_(ツ)_/¯

Иногда Windows ломается настолько интересно, что сначала даже не понимаешь, куда смотреть.

Бухгалтерский компьютер после отключения электричества перестал пускать по RDP. Пинг есть, 3389 открыт, машина живая. С мака — ошибка 0x204, с Windows — «Не удаётся подключиться». Ну, думаю, RDP. Начинаем смотреть — а RDP тут вообще ни при чём.

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

Первая: из реестра пропали системные настройки Schannel, и Windows перестала нормально поднимать TLS. HTTPS из PowerShell не работает, Get-TlsCipherSuite возвращает ошибку. То есть машина не просто «не пускает по RDP» — у неё сломался кусок системной криптографии.

Вторая была старше самого инцидента. Какой-то древний софт когда-то положил в реестр переопределения для SHA-256/384/512. На нормальной Windows crypt32 работает через CNG, а с этими записями идёт в старый CAPI-провайдер, который SHA-2 не умеет. TermService пытается создать сертификат для RDP, получает NTE_BAD_ALGID — сертификата нет, RDP не стартует.

И самое прекрасное — эти поломки маскировали друг друга. Чинишь одну — RDP всё равно лежит, потому что под ней вторая.

Пришлось лезть в ETW, сравнивать машину со здоровой такой же Windows, дёргать CertCreateSelfSignCertificate и смотреть, куда уходит crypt32. Постепенно дошли до конкретных веток реестра. Удалили старые OID-переопределения, восстановили системные настройки TLS — и всё ожило. Без переустановки Windows, без «давайте переустановим КриптоПро» и без шаманства с RDP.

А пока всё это расследовал, заметил ещё одну проблему: ИБП, похоже, уже не держит батарею даже несколько минут. Так что настоящий root cause инцидента, возможно, называется «купить новый аккумулятор для ИБП».

Помните многоножку из первого поста? Пару дней пожили с этой конструкцией, успокоились и наконец разложили по полочкам, что получилось.

1. Точка входа для сотрудников — офисный VPN на Tailscale. После хендшейка трафик идёт по WireGuard, который внутри РФ не блочится. Сотрудник и офис в одной стране — тут всё скучно.

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

3. Чтобы unblocker видел «всё», нужна иностранная VPS. А их постоянно блочит офисный провайдер (привет, ТМПК). При этом из Яндекс Облака те же VPS доступны довольно стабильно. Поэтому unblocker ходит в Яндекс, а уже Яндекс — в VPS.

4. Самое нервное звено — Яндекс → VPS. Блоки тут прилетают постоянно, поэтому связываем их всеми способами сразу. В идеале — ещё и с несколькими разными VPS, а Яндекс-тачку оставить оркестратором.

4.1. Базовый сценарий — Tailscale. И Яндекс-тачка, и VPS подключены к офисному серверу Tailscale, он видит обе — единый tailnet, всё работает.

4.2. Офис начинает мандить, и VPS перестаёт видеть офис. Не проблема: знакомим VPS с офисом через Яндекс — поднимаем VLESS-туннель, по которому VPS может достучаться до офиса через Яндекс. Всё ещё быстро, просто пинги побольше.

4.3. Мандят и офис, и Яндекс. Окей, идём в VPS через Cloudflare. DNS переезжает в Cloudflare, и блочить становится нечего: IP VPS знает только Cloudflare. А чтобы VPS вообще не светила свой внешний адрес, ставим на неё cloudflared-туннель. Итог — маршрут Яндекс → Cloudflare → VPS. Тут свои приколы: первые 16 КБ соединения летят быстро, дальше медленно. Лечится нарезкой трафика по 16 КБ — около 10 Мбит на аплоад, небыстро, но работает.

5. Оркестрировать всё это руками — ебануться. Поэтому на Яндекс-тачке живёт Mihomo (можно и sing-box, но Mihomo показался удобнее): он умеет работать с разными типами соединений и сам решает, куда отправлять конкретный трафик.

Итоговая схема:
сотрудник → офис → unblocker → Яндекс → [Tailscale / VLESS / Cloudflare] → VPS

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

Написал на Хабр большую историю про то, как я две недели пытался честно измерить качество поиска по 664 тысячам книг и несколько раз измерил не то.

Там есть всё, что я люблю: пилот, который отчитался «ноль ложных срабатываний», хотя на полном корпусе их было бы 34–47%. Финальный прогон «0 ошибок на 4060 запросах», где до проверки на самом деле дошли 232 запроса, потому что агент взял не ту базу, а я не проверил. И поле «уверенность» в данных, которое оказалось вообще не про уверенность.

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

https://habr.com/ru/articles/1088532/

Если есть что возразить по методологии — пишите в комментариях на Хабре, там я отвечаю.

Недавно встал вопрос: как передать работу одного руководителя другому человеку.

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

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

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

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

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

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

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

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

После этого заменить человека — уже довольно скучная техническая задача.

Иногда работа CTO выглядит так.

У Supermicro 745 салазки рассчитаны под 3.5" HDD. У меня SSD в переходнике, и SATA в нём не доходит до бэкплейна, мешает пара миллиметров салазок. Значит, надо подрезать.

Вышел на балкон с болгаркой. Стою, режу, никого не трогаю.

Внизу на крыльце курит гендир одного из арендаторов. Спрашивает:
— Чё ты там пилишь?

Я без задней мысли:
— Салазки для харда.

— Пиздец… — говорит он и задумчиво уходит.