Есть ли у вас опыт заключения SLA с вашими заказчиками?
Какие сроки закладываете на устранение ошибок, на консультации, на какие-нибудь разовые выгрузки или на обработку бизнес-данных?
И как обходите моменты, когда вопрос в принципе невозможно решить в установленные сроки?

Пишите по-русски

А зачем оно нужно? Что именно в рамках "соглашения об уровне обслуживания" вы у себя прописываете? И как вы собираетесь их выполнять?

Нам в IT и без этого хорошо. А вот заказчикам нужна гарантия качества потребляемых ими услуг :)
Например недоступность базы в рабочее время. SLA 30 минут. Этого вполне хватит чтобы проверить сеть, серверы, лицензии и переключиться на резервный ЦОД если потребуется.
А вот как гарантировать обработку более сложных запросов - я бы сам хотел послушать :)

общее правило в подобных случаях гласит что сложные вещи надо декомпозировать на более простые.
до того уровня пока простые не становятся понятными измеримыми элементарными кирпичиками для строительства более сложных.

Объясняю порядок расчета и установки необходимых сроков исполнения работ. Нужно определить срок исполнения работы с учетом времени на перекуры, чай и трындение на мисте, увеличить его сначала на порядок, а затем применить коэффициент прочности примерно для срочных работ 2,0..2,5, для обычных от 3,0 и более с учетом мнения заказчика, чтобы уложиться точно в срок.

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

(5) Хитрован-заказчик разводит ТС на SLA. И вряд ли его устроят означенные сроки.

(5) все проще: "плановый срок увеличивается втрое, и берется следующая единица измерения времени"©.

"вопрос в принципе невозможно решить в установленные сроки?"
это признак кривого SLA
в SLA не должно быть заложено услуг с неопределенным временем выполнения.
не нужно формулировать "Поиск ошибки при перепроведении документа закрытия месяца" - потому что эту ошибку можно найти как за час так и не найти за 2 недели.
расценивайте элементарные операции.
ну и приведите пример
что у вас является невозможным решить в сроки.

Только один раз за все время клиент ставил вопрос о SLA. По сути мы расписались в полном бессилии. Клиент ушел. Ну и с Богом

(6) Скорее не устроит цена, а так быстро\дёшево\качественно — выбери два любых

(10) быстро\дёшево\качественно - выберите ОДНО

(3) А вот как гарантировать обработку более сложных запросов - я бы сам хотел послушать

Я правильно понял, ты предлагаешь кому-то рассказать тебе, как у них организована работа в части оказания сервисной деятельности?

Святая ж простота.

(9) КМК, есть некоторое недопонимание сущности SLA. По сути это только для услуг и сервисов 24*7*365 работает. В случае сбоев, возвращается условно абонентка на время простоя в пятикратном размере, к примеру. По сравнению с возможными убытками, это сумма символическая. Никто вам ничего никогда не вернет, ну разве что госконтора может отсудить много денег и поставщик услуг закроется.

(13) быстро поднятое упавшим не считается

(13) SLA - это действительно поддержка непрерывности процессов. У нас были внутренние SLA на поддержку основных процессов. Теоретически за несоблюдение могли депремировать, но такого не было. Хотя и нарушались они редко.
В чем еще помогает SLA - в приоритетизации реакции на проблемы. Т.е. в первую очередь решаются "самые дорогие" проблемы (типа "оперативный контур" "дороже" "бухгалтерского", в оперативном контуре "товарооборот" дороже "финансового",  и т.п.). Причем  это касалось не только учетной системы, но и проблем с оборудованием и коммуникациями ("операторы" "дороже" "снабжения", а "снабжение" "дороже" "финменеджеров"), и даже с энергопитанием (в первую очередь восстанавливаетсся питание серверной и операторов, во вторую - склада, в третью подразделений, обеспечивающих продажи, и т.п.).

как правило в договор включают некие формулировки типа "при выполнении не менее 90% (95,97 тут уж как договоритесь) задач без нарушения SLA" и дальнейшие санкции за нарушения/ненарушения.
и по отдельным группам SLA
потому что может быть 100 обращений от Марь Иванны, которые закрыли в срок и без нарушений
и может быть одно падение сервера БД которое не отработали в срок - понятно что это услуги разного уровня и санкции за нарушения тут будут разные даже для единичного случая во второй категории.

(16) которые закрыли в срок и без нарушений

Как определяешь этот факт?

(11) Я щедрый, третье выбираю сам

(13) Обычно что ближе к зарабатыванию денег для компании - то и важнее.

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

> как обходите моменты, когда вопрос в принципе невозможно решить в установленные сроки

если это требует хз сколько времени, значит это точно не бага и не типовой какой-то вопрос. В таких случаях договариваюсь о конкретных сроках отдельно.
Бывают баги, которые прокрались в прод, всё доверху усрали и, как это правильно починить, пока не ясно. В этих случаях в рамках SLA тушим пожар (например откатываем нафиг обновление) и даем людям воркараунд (он может быть изнурительным, да, но фухле вы хотели), а фиксим по-красоте уже в рамках разработки с предварительным исследованием, что за нах и как жить дальше.

(20) "баги..в проде..всё усрали" - звучит как песня! Возьму на заметку

Так для разных обращений (заявок) разный регламент и, соответственно, SLA. Например для ЗнИ (заявка на изменение), которыми оформляются всяческие изменения в системах, есть вообще только время реакции. Срок исполнения оговаривается индивидуально по каждой работе. И неважно описание поля поправить или алгоритм расчета изменить. На тупую самую простую, но согласованную в установленном порядке ЗнО (заявку на обслуживание) срок от 1 рабочего дня. А есть ещё статус "В ожидании", когда требуется уточнение или дополнительная информация, в этом случае SLA не капает от слова совсем.

в поиск ITIL (первый и второй)

из личного опыта:

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

(23) SLA - это прежде всего упорядочивание. Бизнес оценивает свои хотелки, а ИТ - свои могелки. Оцифровывают.

(24) в контексте одного холдинга бизнес все равно будет ходить в этот магазин с безлимитным кошельком и любые кивки на SLA от сервисного подразделения будут заканчиваться звонком от гены "вы чо там, цуки, ухи поели все?  Всем всё бросить и резко все нАчать!".
Только время в итоге потеряют обе стороны на перелай про SLA

(23) ну ты предлагаешь открыть перевод стандарта, да за 10 минут, под чашечку кофийку, познакомиться с этими фундаментальными трудами? :)

(25) Не совсем так, но был опыт когда тупо из-за нарушения мы не согласовали акт исполнения SLA, и не заплатили всю сумму за период.

(25) ну у нас даже не в "контексте одного холдинга", а в пределах одного предприятия слово SLA помогло оценить и хотелки, и могелки. оценив хотелки, мы выкатили сумму на бесперебойники и резервный сервер. бизнес охренел и немного ужался. мы тоже ужали сумму. в результате сошлись на приемлемом варианте и по времени реакции, и по объемам сервиса, и по зарплатам....

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

(29) Согласен, отличная формулировка. Но как бы это донести заказчику.
Например у него ошибка в закрытии месяца, которую со стороны it можно искать 5 минут, а можно 5 дней.
А вот со стороны заказчика это видится как то, что у него закрытие сегодня и сегодня же ничего не работает, а значит исправлять все должны сегодня, ни раньше, ни позже ))

(30) Если "сломался" сервис, который уже был, то это инцидент. На него время реакции только распространяется. Время разрешения зависит от причин, его вызвавших,  и устанавливается и/или продляется отдельно. Был когда-то КПЭ, связанный с инцидентами, но настолько лайтовый (96 часов простоя на год для всех систем в зоне ответственности), что отказались.

(0) вот SLA от 1с https://consulting.1c.ru/upload/adminFiles/services/reglament-corp-tech-podderzhky-polzovateley_1sept2023.pdf

(30) [которую со стороны it можно искать 5 минут, а можно 5 дней] это твои риски и функциональному заказчику глубоко безразлично, как ты обеспечишь бесперебойную работу РСВ в ERP менее чем за 24 часа с момента обращения

(0) у нас внутри компании SLA есть, риски и сроки востановления, бизнес вкурсе и согласовывал. Если провалы и бывают то вё в пределах SLA.
(23) Внутри компании польза есть, руководство четко знает какие риски и какие сроки исправления, если неустраивают сроки как правило выкатывается ценник на доп специалиста или железо с лицензиями которое дублировать будет работу, после чего компания вполне осознано говорит нет, мы к этому неготовы, в данном случае мы готовы ждать.
Но и у нас есть план востановления например бекапа, и тренировались переодически.Чего случись с серваком знаем где разворачиваемся из бекапа как прописываемся итд. Всё конечно предусмотреть нельзя, но наиболее вероятные критичные риски прописаны, админы с ужасом в глазах не будут бегать со словами шеф все пропало (в теории).