Двадцать лет: от инфраструктуры к экрану

Мера невидимой работы в том, что её судят только при отказе. Двадцать лет я этому учился; потом перешёл на видимую сторону.

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

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

2005–2013 — Корпоративная инфраструктура

Серверы, хранилища, резервное копирование, бесперебойность.

Если этот период чему-то и научил, то вот чему: работающая система невидима, пока работает. Резервное копирование годами не попадает ни в чью повестку. Потом в один день оно нужно, и этот день — экзамен для всего сделанного до него.

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

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

2013–2019 — Сети и безопасность

Маршрутизация, межсетевые экраны, доступ.

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

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

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

Поэтому комментарии в коде, которые я пишу сегодня, объясняют «почему так», а не «что делает». Что делает — уже написано в коде.

2019–2024 — Идентичность и M365

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

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

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

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

2024 — сегодня

Веб-приложения на базе ИИ и веб-технологии. Модели и агенты, повёрнутые к экрану с той же дисциплиной.

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

Слой ИИ при этом вознаграждает инфраструктурные привычки неожиданным образом. Языковая модель — недетерминированный компонент: на один и тот же вход она может дать разный выход, может быть тихо неправа и отказывает, не выдавая сообщения об ошибке. Это ровно тот класс сбоев, с которым работали годами, — сменился только слой.

Поэтому вопросы, которые я задаю при написании агента, те же, что и при настройке сервера: Где я измеряю? Как я пойму, что он ответил неверно? Насколько далеко я могу откатиться, если он сломается?

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

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

Двадцатилетняя привычка ложится сюда точно: доверяйте не выводу, а его основанию.

Что перенеслось

Общий знаменатель четырёх периодов — четыре привычки:

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

Общая нить: бюджет ошибок

Есть понятие, повторяющееся во всех четырёх периодах, хотя имя каждый раз меняется.

В инфраструктуре его звали «целевой доступностью». Стопроцентной доступности не бывает; бывает — заранее сказать, сколько простоя вы принимаете. Команда, которая этого не говорит, при каждом сбое заново ведёт один и тот же спор.

В сетях это «допустимая задержка». В безопасности — «принятый риск». В управлении идентичностью — «какие исключения одобрены». На стороне продукта — «бюджет производительности».

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

У раздела статей этого сайта тоже есть записанный бюджет: наибольшая отрисовка контента менее 2,5 секунды, скрипт страницы менее 60 КБ, никакого затвора непрозрачности перед текстом. Все три измеряются набором проверок при каждом запуске. Превышено число — тест краснеет, и обсуждение не открывается.

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

Что осталось позади

Есть вещи, которые не перенеслись, и отпустить их было тяжелее, чем перенести.

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

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

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

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

Почему переход кажется лёгким, но таковым не является

Большинство переходящих из инфраструктуры в продукт попадают в одну ловушку: считают техническую состоятельность переносимой. Она переносится — но сама по себе её недостаточно.

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

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

Второй пробел: у невидимой работы нет аудитории, у видимой есть. Двадцать лет собеседником работы была система. Теперь собеседник — человек, и его терпение, внимание и контекст переменчивы. Это не задача для решения, а реальность для учёта.

Примечание

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

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

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

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