Версия: 2.0 (Актуальная редакция)
Версия 1.0 (утратила силу 1 января 2026 г.)
Автор стандарта: Вячеслав Крампец
Дата последней редакции: 1 января 2026 г.

1. Термины и область применения

1.1. Что такое «Технологическая гарантия» в нашем понимании
Это наше обязательство перед заказчиком, что переданное в эксплуатацию программное решение (далее — Система) сохранит свою работоспособность и архитектурную целостность в течение установленного срока при соблюдении условий эксплуатации. В отличие от стандартной гарантии на ошибки, наша гарантия распространяется на устаревание технологий и потерю производительности.

1.2. Объект гарантии
Гарантия распространяется на исходный код, архитектуру базы данных, сценарии развертывания (деплоя) и конфигурационные файлы, разработанные непосредственно нами в рамках контракта.

2. Сроки и критерии гарантии по типу решений
Мы устанавливаем дифференцированные сроки гарантии в зависимости от слоя архитектуры и типа решения, так как темпы устаревания технологий в этих областях различаются.

3. Что покрывает гарантия
В течение гарантийного срока мы обязуемся за свой счет устранять:

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

4. Что НЕ покрывает гарантия и зона ответственности Заказчика

После завершения контракта мы отдаём готовое решение в рамках оказанной услуги. Это значит, что мы «заливаем» программный код на сервер, передаём все доступы ко всем системам.

Гарантия прекращает свое действие или не распространяется на сбои, вызванные следующими факторами:

4.1. Инфраструктура и среда исполнения
Мы гарантируем работу кода, но не гарантируем бесперебойную работу сервера, хостинга или облака. Сбои в работе оборудования, хостинг-провайдера, DDoS-атаки, взлом сервера по вине администратора Заказчика — это зона ответственности эксплуатационной службы Заказчика или хостинг-провайдера.

4.2. Внешние зависиммости (Интеграции)
Мы не несем ответственности за изменения в сторонних сервисах (обновление API, изменение форматов данных в 1С, смена платежного шлюза). Если внешний сервис изменил правила игры, доработка интеграции является новой задачей, а не гарантийным случаем.

4.3. Модификации кода третьими лицами
Гарантия немедленно и полностью аннулируется, если в исходный код Системы вносились изменения не нами или без нашего контроля и согласования. Это касается как правок силами Заказчика, так и привлеченными подрядчиками.

4.4. Технический долг (устаревание) 
Ситуации, когда Заказчик отказался контролировать получение патчей для используемой библиотеки или фреймворка или библиотека официально объявлена устаревшей и больше не получает патчей.

4.5. Форс-мажор и новые требования

• Изменение законодательства (например, требования к хранению персональных данных), требующее переделки архитектуры.
• Добавление нового функционала или изменение существующей бизнес-логики Заказчиком.
• Появление принципиально новых версий браузеров или мобильных ОС, ломающих старые стандарты (выход за горизонт планирования).

5. Процедура наступления гарантийного случая

Диагностика: Заказчик направляет обращение с четким описанием проблемы. Наша задача — подтвердить, что проблема связана с кодом (п.3), а не с инфраструктурой (п.4.1).

Локализация: Если проблема на стороне кода, мы выпускаем исправление в согласованные сроки (SLA оговаривается отдельно для критичности ошибок).

Снятие с гарантии: Если проблема вызвана факторами из п.4, мы предоставляем коммерческое предложение на доработку, так как это выходит за рамки гарантии.