Как мы строили фундамент для надежности Кайтен: итоги 2025 года
Привет! Это технический обзор от команды R&D Кайтен. Год подходит к концу, и мы хотим рассказать, через что прошли, что построили и куда движемся.
Сразу главное: с апреля 2025 года у Кайтена не было ни одного полного падения. Замедления случались, но недоступности сервиса практически не было. Это результат большой работы, которую мы вели все это время.
2025-й стал для годом серьезных изменений. Мы столкнулись с проблемами роста, приняли непростые решения и заложили фундамент, который позволит Kaiten расти дальше.
Этот текст — о том, что происходило за кулисами в этот год и почему мы уверены в выбранном направлении.
В начале года мы сталкивались с проблемами доступности. За первый квартал произошло 7 серьезных инцидентов общей длительностью больше суток. Случалось, что на восстановление работы уходило до половины рабочего дня — самый тяжелый инцидент в апреле длился 9 часов. Для B2B-продукта, от которого зависит работа команд в крупных компаниях, это недопустимо, и мы это понимали.
Причин было несколько:
Кайтен рос быстрее, чем мы успевали адаптировать архитектуру. Накопился технический долг.
Отдельные решения, принятые на ранних этапах развития продукта, перестали справляться с возросшей нагрузкой. Знакомая история для любого SaaS-продукта в фазе активного роста.
На тот момент мы уже начали менять инфраструктуру и архитектуру. Но каждый новый инцидент замедлял процесс — было опасения за систему. Классический замкнутый круг: проблемы мешают чинить проблемы.
Чтобы его разорвать, мы решили перестать латать дыры и начать строить фундамент системно.
Работа была в 3 направлениях: процессы, команды и инфраструктура.
Внутренние дежурства. Раньше на инциденты реагировали по ситуации — кто заметил, тот и занимается. Это означало задержки: пока кто-то увидит проблему, пока разберется, пока позовет нужных людей. Поэтому мы ввели роль дежурного инженера с четким регламентом. Дежурный следит за метриками, алертами от системы мониторинга, сбором ошибок и обращениями от службы поддержки.
Регламент реагирования на инциденты. Сформировали группу реагирования из опытных инженеров. Каждый инцидент теперь проходит через четкий процесс: обнаружение → локализация → устранение → разбор причин. Выводы из разбора в итоге стали превращаться в задачи: доработка мониторинга, изменение процессов, модернизация сервисов.
Архитектурный комитет. Создали постоянную рабочую группу для управления технической эволюцией продукта. Задача комитета — не допускать хаотичных и рискованных решений, снижать стоимость поддержки за счет системного подхода, ускорять принятие бизнес-решений за счет качественной технической экспертизы.
Усиление CI/CD. Внедрили автоматизированные проверки качества кода на ранних стадиях разработки: линтеры, статический анализ, автоматизированный выпуск версий. Теперь потенциальные проблемы и уязвимости выявляются до того, как код попадает в продакшн.
Одно из важных решений года — создание специализированных команд с конкретным фокусом.
Enabling Team. Команда инженеров с глубокой экспертизой в области архитектуры, работы с базами данных, оптимизации и информационной безопасности. Их фокус — отказоустойчивость, производительность и безопасность.
Команда инфраструктуры. Отдельная группа, которая занимается созданием, поддержкой и развитием инфраструктуры — архитектура, CI/CD, мониторинг, логирование, алертинг.
Здесь произошли самые масштабные изменения. Фактически мы спроектировали и построили инфраструктуру заново.
Смена облачного провайдера. Мы перешли на новую площадку и используем 3 географически разнесенных центра обработки данных. Это дает нам резервирование на уровне инфраструктуры — если один ЦОД испытывает проблемы, нагрузка распределяется на другие. Дополнительно у нас есть резервный облачный провайдер для критических сценариев.
Infrastructure as Code. Вся инфраструктура теперь описана в коде (Terraform). Это означает версионирование, ревью изменений, с возможностью быстро воспроизвести окружение.
GitOps-подход. Все изменения в инфраструктуре проходят через Git (ArgoCD). Это обеспечивает прозрачность, аудируемость и возможность откатить любое изменение.
Современный стек мониторинга. Развернули Grafana LGTM stack с максимальным покрытием служебных компонентов: метрики, логи, алерты, дашборды. Теперь мы видим, что происходит с системой в реальном времени. Тут есть куда расти, и эта работа будет продолжаться.
Синтетический мониторинг. Добавили внешние проверки доступности — система постоянно имитирует действия пользователя и проверяет, чтобы все работало так, как ожидается.
Политика резервирования. Внедрили обязательное резервирование для всех служебных компонентов. Отказ одного элемента не приводит к отказу всей системы.
Бесшовная миграция. Отдельно гордимся тем, как провели миграцию. Переносили сервисы по одному, аккуратно, с минимальным влиянием на пользователей. Данные мигрировали последовательно — частично в managed-сервисы нового провайдера, частично в self-hosted решения. Перенесли в Kubernetes почти все служебные компоненты, которые раньше жили на виртуальных машинах.
Это была сложная инженерная задача, и команда справилась.
Отдельно расскажем о работе команды, которая занималась внутренней системой. Это не такая заметная, но критически важная работа.
Оптимизировали работу с базой данных. Выявили и оптимизировали тяжелые SQL-запросы, устранили длинные блокировки в транзакциях, переработали повторяющиеся задачи, которые создавали избыточную нагрузку. Провели партицирование журнала событий — самой большой таблицы в базе данных.
Устранили проблемы с памятью. Команда нашла и устранила утечки памяти — как на клиенте, так и на сервере. Это та категория проблем, которые накапливаются постепенно и проявляются внезапно.
Асинхронизировали тяжелые операции. Вынесли ресурсоемкие операции в фоновые процессы (cron-задачи). Пользователь не должен ждать, пока система «думает» над сложной задачей.
Внедрили технические метрики. Добавили новые метрики и настроили правильное логирование. Это инвестиция в будущее — теперь мы можем точнее диагностировать проблемы и понимать, где система испытывает нагрузку.
Запустили программу Bug Bounty. Внешние исследователи безопасности ищут уязвимости в системе за вознаграждение. Закрыли критические и серьезные уязвимости.
Оптимизировали хранилища. Разделили монолитное key-value хранилище на несколько специализированных под конкретные задачи. Ускорили отдачу статики и добавили политики retry для устойчивости к временным сбоям.
Enabling Team за год закрыла критические точки: база данных стала быстрее и стабильнее, утечки памяти устранены и уязвимости закрыты.
Было бы нечестно рассказать только об успехах. Вот что не удалось или от чего пришлось отказаться:
Автоматическое масштабирование по нагрузке. Временно отключили — оно мешало диагностике проблем. Когда система автоматически подстраивается под нагрузку, сложнее понять, где именно узкое место. Вернемся к этому, когда стабилизируем базовый уровень.
Полноценная трассировка запросов. Хотели реализовать сквозное отслеживание каждого запроса от пользователя до базы данных. Пока не видим, кто и с какими параметрами выполняет запросы, вызывает функции в PostgreSQL. Технически сложная задача, не решена полностью.
Партицирование всех планируемых таблиц. Разбили на части самую критичную таблицу, но не все запланированные. Это итеративный процесс.
Идеальный набор метрик. До сих пор не всегда можем быстро ответить на вопрос «где болит и почему». Работаем над этим.
Автоматическая выкатка новых версий. Отказались в пользу контролируемых релизов. В текущей ситуации предсказуемость важнее скорости.
Уменьшение порций данных для операций. Чем больше компания (пользователей, сущностей), тем менее отзывчив Кайтен. Из-за этого дольше выполняется каждая операция — и на клиенте, и на сервере. Эту проблему пока решили не везде.
Часть этих пунктов — осознанный выбор. Мы сфокусировались на стабильности, а потом уже потом перейдем к автоматизации.
Фундамент заложен. Вот главные направления работы на первое полугодие следующего года.
Наблюдаемость и диагностика:
Сквозная трассировка через OpenTelemetry — прокидывание Trace ID через всю цепочку: балансировщик → приложение → база данных.
Real User Monitoring — большую часть метрик производительности (LCP, FID) из браузеров клиентов мы уже собираем. Следующий шаг — сегментация по клиентам, которая покажет, у кого именно возникают проблемы.
Детальный анализ медленных запросов дольше 500 мс с привязкой к Trace ID.
Оптимизация базы данных:
Тюнинг пула соединений — устранение очередей на получение коннекта
Продолжение партицирования крупных таблиц.
Переработка системы прав доступа — самая дорогостоящая операция в базе. Оптимизация через кеширование и упрощение графа.
Надежность:
Улучшение коллаборации в документах — предотвращение потери изменений при обрывах соединения.
Failover для файлового хранилища — прокси для переключения между основным и резервным S3.
Выстраивание релиз-менеджмента — регламент подготовки, роль релиз-менеджера, автоматический сбор changelog.
Скорость для регионов:
Подключение CDN с максимальным покрытием по России — для Сибири, Дальнего Востока, Урала.
Синтетический мониторинг с точки зрения реального пользователя из разных точек страны.
Мы построили инфраструктуру с тремя ЦОД и резервированием, сформировали команды с фокусом на производительность и надежность, внедрили процессы, которые превращают каждый инцидент в улучшение системы.
В 2026 году фокус будет на отзывчивость Кайтена: трассировка запросов, оптимизация базы, CDN для регионов. Цель — чтобы Кайтен работал одинаково быстро и в Москве, и во Владивостоке.
Спасибо, что остаетесь с нами!