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

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

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

Инфраструктура и облако

Начиная с 8 октября у Яндекса началась череда аварий: сначала дата-центр в Рязанской области, затем в Калужской и Владимирской, результатом стал критический сбой serverless-вычислений и деградация множества сервисов — в какой то момент облако накрыло целиком, а не только пострадавшие зоны.

А у нас на Яндексе жило многое: правовой сервис, личные чаты, DataLens, Sentry, пайплайны и сборки GitLab, объектное хранилище S3 со статикой и так далее. Что то встало разом, что то отваливалось постепенно: упали деплои, отвалилась аналитика и мониторинг, статика отдавала ошибки и прочее...

Что сделали:

- за короткое время перенесли критичные сервисы в другой дата-центр — они уже работают оттуда;

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

- завели резервный S3.

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

Индексация и SEO

Здесь не «разовая победа», а планомерная чистка того, что годами копилось в выдаче:

- чистка дублей заголовков — убираем одинаковые тайтлы, чтобы поисковик не путал страницы. Для автоматизации процесса провели аудит дефолтных заголовков. По удачному совпадению накануне аварии была выгружена база по страницам в индексе поиска, в них найдены дефолтные, а уже по ним изменен заголовок ответа Last-Modified чтобы роботы Яндекса самостоятельно обновили данные страницы, без необходимости ручной отправки на переобход;

- бренд в title — добавляем «Клерк» в заголовки, где это уместно - это является рекомендацией поисковика чтобы было более корректное отображение, а поисковик учитывал тайтл правильно;

- ручные мета — перепроверили, что вручную заданные заголовки и описания сохраняются и выводятся правильно;

- оптимизация изображений — уменьшаем вес картинок, это плюс и к скорости, и к SEO;

- дубли контента в справочно-правовой системе — убрали задвоенные материалы.

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

- Пайплайны сборки. Настроили CI/CD для новых микросервисов в рамках перехода на целевую микросервисную архитектуру.

- Логи в одном месте. Поднимаем стек ELK для консолидации и анализа логов, — сейчас ошибки приходится искать по разным машинам.

- Настраиваем алертинг. Повышаем наблюдаемость по ключевым метрикам.

- Железо и сеть. Подключаем удалённое управление серверами (IPMI), поднимаем шлюз для поддоменов, выносим сервер рекламы «Клад» на отдельную машину, чиним docker-зависимости и DNS-записи для Mindbox.

- Регламенты. Зафиксировали, как обновлять тестовые стенды и как тестировать задачи с учётом разичных проверок в том числе и SEO.

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

- Ускоряем выдачу страниц документов. Переписываем медленный endpoint, который отдаёт текст статьи, — сейчас это одно из узких мест.

- Карточки контрагентов. Раньше открывались долго — оптимизировали, теперь быстрее.

- Время загрузки страниц. Начало подрастать — нашли причину и вернули в норму.

- Подсчёт пользователей на странице. Оптимизировали тяжёлый запрос — страница перестала тратить на него время.

- Админка модерации. Страница модерации тормозила — оптимизировали, редакторы работают быстрее.

- Разбор падения 502. Сняли slow логи медленных запросов и процессы базы, вычислили виновников, один из примеров: запрос сканировал 600 тысяч строк, чтобы вернуть одну, а соединения с базой открывались сотнями в секунду и не освобождались. Запросы починили, соединения привели в порядок.

Редактор и модерация — то, с чем редакция работает каждый день. Каждый баг здесь — потерянные часы людей.

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

- Старые ленты на новый API. Переделываем ленты на новый API, чтобы они работали единообразно и предсказуемо.

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

- Пустой /drafts/. Починили баг, когда после публикации редактора выбрасывает на пустую страницу черновиков.

- Автомодерация. Разобрались, почему пост сам уходит в красную зону при любом действии редакции.

- Отклонение поста при взаимодействии. Починили баг, когда пост слетает на модерацию от действий через меню «три точки» и ИС.

- Забаненные пользователи больше не достают. Заблокированный на сайте пользователь теперь не может писать в чатах.

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

- Микросервис пользователей. Разрабатываем новый сервис пользователей на Laravel с новым API-контрактом — это фундамент для дальнейших переездов.

- Перенос лайков. Переводим лайки документов с устаревшей таблицы на новую схему — убираем техдолг.

- UTM-метки. Обновляем логику работы UTM, чтобы атрибуция источников была корректной.

- Подсчёт переходов. Делаем нормальный подсчёт переходов на фронте.

- Датаньютон. Починили утечку запросов к сервису контрагентов.

- CDP. Чиним баги, из-за которых не фиксировался весь путь пользователя.

- 404 в бланках. Устранили битые ссылки — документы снова открываются.

- Дескрипшен в структуре тегов. У страниц тегов теперь корректное описание вместо пустоты.

- Сегменты и статистика. Починили некорректную работу сегментов.

Мы пробуем то, что прямо просится в наш процесс. Отчётность по задачам — это рутина, которая съедает время команды: пока соберёшь контекст, посмотришь код, вспомнишь, что было сделано, — прошёл час. А без отчёта задача «висит в воздухе».

Идея простая: привязать LLM-агента к Трекеру.

Как это работает:

- у Трекера есть набор событий — задача сменила состояние;

- агент видит событие, открывает репозиторий и саму задачу;

- пишет резюме: что сделано в коде, какой результат, оценка выполненного и что нужно проверить;

- резюме возвращается в задачу как готовый отчёт и раскладывается по блокам.

Что это даёт, помимо экономии времени:

- Качество код-ревью. В отчёте видно, на каком уровне качество кода, — ревьюер приходит к задаче уже с контекстом, а не выясняет всё с нуля.

- Качество тестирования. В отчёте указано, что именно и где тестировать, — тестировщик не гадает, с чего начать, и не пропускает важные места.

- Прозрачность. У каждой задачи появляется внятное описание сделанного, а не «что-то поправил».

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

Зачем это нам: с нашей текущей проблематикой — десятки задач, разбор инцидентов, размазанный контекст — это mast have. Цель простая: упростить рутину и освободить время команды для того, что действительно требует человеческого участия.

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

первая часть

вторая часть

Артём Аксянов, технический директор «Клерк.ру»