Как устроена эксплуатация: мониторинг, SLA, регламенты, разбор инцидентов, обновление базы знаний и планирование доработок.
Система, сданная и забытая, деградирует за несколько месяцев: меняются прайс, регламенты, формулировки клиентов и API смежных сервисов. Всё это происходит незаметно, пока кто-нибудь не обнаружит, что бот полгода называет неверные сроки поставки.
Раздел о том, как устроена нормальная эксплуатация: что мониторить, что записать в SLA, кто отвечает за базу знаний и сколько на всё это закладывать в месяц.
База знаний — единственная часть ИИ-решения, которая обязана меняться каждую неделю. Разбор сроков годности по разделам, правил назначения владельцев, трёх календарей обновления и версионирования — с расчётом трудозатрат для компании с одним ассистентом.
ПрактикаРазбор самой тихой проблемы эксплуатации: ничего не ломается, просто система постепенно начинает врать. Шесть источников дрейфа, числа, по которым он виден за месяц до жалоб, квартальный техосмотр на два часа и расчёт ущерба от одного неисправленного факта.
ПрактикаТехнический мониторинг показывает, что сервис жив, и молчит, когда заявки вторые сутки лежат неразобранными. Разбор девяти сигналов — пяти технических и четырёх бизнесовых, — порогов к ним, маршрутов оповещения и минимального контура, который собирается за один рабочий день.
ДеньгиРазбор соглашения об уровне обслуживания как четырёх чисел, за которые вы платите деньги: время реакции, время обхода, время восстановления и доступность. С модельным расчётом ущерба от одного инцидента и честным ответом на вопрос, кому нужно круглосуточное дежурство.
МетодикаКалендарь первого года работающей системы по четырём контрольным точкам: что ломается на первом месяце, что дорабатывают к третьему, что тихо расходится с реальностью к шестому и что пересматривают к двенадцатому. С ролями, восемью метриками здоровья и модельным бюджетом на год.
Что происходит с работающей системой за первые двенадцать месяцев, из каких строк складывается счёт за сопровождение и как отличить настоящий SLA от абонентской платы за доступ к электронной почте подрядчика.
Раздел выходит частями. Ниже — темы, которые уже расписаны и ждут очереди. Если нужен ответ по одной из них прямо сейчас — напишите нам, разберём вашу ситуацию отдельно и без ожидания.
Главный спор в поддержке — не про цену, а про границу: где заканчивается «поправить сбой» и начинается «сделать новое за отдельные деньги». Статья описывает эту границу словами, которые можно перенести в договор, и сравнивает четыре модели оплаты на одном примере.
Решение о переписывании обычно принимают на эмоции после третьей неудачной правки. Статья переводит его в пять проверяемых критериев и модельный расчёт, а также честно называет случай, когда правильный ответ — не трогать ничего.
Ретроспективный замер отличается от предварительного расчёта окупаемости: цифры «после» уже лежат в самой системе, и их можно достать без опросов. Статья показывает три источника данных и что делать, если базовые метрики до старта никто не снял.
Шаблон разбора на одну страницу и правило без поиска виноватых: пока сотрудник боится признаться, что нажал не туда, причина сбоя не находится, и он повторяется через месяц.
Конкретная процедура вместо призывов «контролировать ИИ»: сколько диалогов брать в неделю при известном потоке, по каким четырём критериям их оценивать и что делать с найденной ошибкой — править знания, правило или сценарий.
Обмен ломает не сбой, а плановое обновление, о котором подрядчика никто не предупредил. Статья описывает четыре типа ломающих изменений и простой регламент предупреждения за пять рабочих дней.
После сдачи роли обычно растворяются: владелец процесса вернулся к своей работе, ИТ считает, что это не их система. Статья описывает три роли в часах и задачах и матрицу ответственности на одну страницу.
Большинство поломок рабочих систем — не аварии, а торопливые правки по звонку. Статья описывает маршрут заявки на изменение, тестовый контур и стоп-дни, когда в систему не вносят ничего.
Копия, которую ни разу не восстанавливали, копией не является. Статья переводит RPO и RTO на человеческий язык, задаёт ритм учебного восстановления и показывает, что именно облачный провайдер вам не бэкапит.
Передача поддержки — это список из двенадцати позиций и две недели параллельной работы, а не письмо с паролями. Статья даёт этот список и разбирает случай, когда прежний подрядчик отдавать ничего не хочет.
Объясняет техдолг руководителю, а не разработчику: как заметить его без чтения кода, по каким признакам он растёт и какую долю бюджета поддержки разумно тратить на его погашение.
Статья против собственной услуги: пять случаев, когда абонентская поддержка не окупается, и что взять вместо неё. Плюс минимальный набор, который нужен даже без подрядчика.
Журнал нужен не для наказаний, а для двух ситуаций: разобрать инцидент и ответить на вопрос, кто выгрузил базу клиентов. Статья перечисляет минимальный состав записей и отдельно разбирает журналирование решений ИИ-агента.
Опишите процесс словами, голосом или файлами — вернёмся с картой процесса, вариантом решения и предварительной вилкой бюджета. Бесплатно и без обязательств.
