SLA_Legal_ITMO

1. SLA & LEGAL

SLA & LEGAL

2.

SLA - не формальность, а механизм построения
доверия между бизнесом, ИТ и юристами и
всеми кто причестен к бизнесу

3. Что такое SLA в Legal

- Уровни сервиса: реакция, восстановление,
доступность
- Окна обслуживания, эскалации
- Компенсации и метрики
- Пишется понятным языком

4. Почему SLA важен

- Делает ожидания измеримыми
- Устраняет двусмысленность
- Снижает количество конфликтов
- Управляет качеством и ресурсами

5. Внешний vs внутренний SLA

– Внешний SLA:
• Формальные обязательства
• Репутационные риски
– Внутренний SLA:
• Координация между командами
• Управляемость процессов

6. Роль юриста в SLA

- Юрист - не про штрафы, а про операционность
- Юрист – это про адекватный подход
- Должен понимать архитектуру и процессы***
- Юрист должен быть хорошим специалистом***

7. Когда SLA должен обновляться

- Критическое изменение продукта
- Ежекватально* (при условии 1-2 минорные
релизы в месяц)
- Новые зависимости (API, сервисы)
- Изменение процессов
– Е***е пользователи нашли к чему
прикопаться

8. SLA как инструмент доверия

- Прозрачность ответственности
- Предсказуемость реакции
- Меньше микроменеджмента
- Рост зрелости коммуникации
- Понятен процесс решения проблемы

9. Практика. Последнее задание

• Сдало 10 из 17
• Смотрел по M4200c

10. Практика. Последнее задание

Научить студентов мыслить как
продакт/архитектор/юрист/внешний подрядчик по SLA:
выявлять дисбалансы, определять операционные риски,
видеть перегибы и приоритеты, и формировать зрелую
позицию по управлению редкими, но критичными
событиями (чёрными лебедями).

11. Практика. Последнее задание

Шаг 1. Возьмите SLA-документ другого студента

12. Практика. Последнее задание

Шаг 2. Проведите анализ перегибов и «красных зон»
Найти моменты, где SLA уводит сервис в сторону от оптимального
баланса между:
• качеством сервиса,
• затратами и операционным реализмом,
• управляемостью,
• юридической и технической исполнимостью.
В этом разделе вы должны ответить:
• Где SLA обещает невозможное?
• Где команда «перестраховалась» и сделала SLA слишком жёстким?
• Где наоборот - недописано, слишком мягко, слишком неопределённо?
• Какие пункты создают риск юридического или операционного
«техдолга»?

13. Практика. Последнее задание

Шаг 3. Оцените работу SLA при появлении чёрного лебедя
Что произойдёт, если случится серьёзный инцидент?
Например:
• падение ключевого сервиса на сутки,
• потеря части данных,
• недоступность внешнего API,
• резкий рост нагрузки ×100,
• отказ нескольких узлов инфраструктуры,
• баг в обновлении, который ломает прод.
В оценке нужно раскрыть:
• Какие пункты SLA помогут в кризисе?
• Какие - наоборот усугубят ситуацию?
• Какие зоны ответственности определены хорошо, а какие - размыты?
• Хватает ли приоритезации инцидентов?
• Ясно ли определено, кто принимает решения и в какие сроки?

14. Практика. Последнее задание

Шаг 4. Что бы вы точно НЕ делали
Команда даёт честную экспертную позицию:
Примеры:
• «Мы бы не стали продлевать SLA до 99.99%, если архитектура не
выдерживает»
• «Мы бы не вводили штрафы за задержку в окнах обслуживания,
потому что бизнес-процесс не так устроен»
• «Мы бы не фиксировали время восстановления для P1 в 1 час — у нас
нет резервирования такого уровня»

15. Практика. Последнее задание

Шаг 5. Что бы вы наоборот сделали
Примеры:
• добавить регламент коммуникации в момент аварии;
• ввести отдельный SLA для работы с внешними API;
• сделать матрицу приоритетов для разных типов лебедей;
• описать порядок отмены релиза и «rollback window;
• добавить правила изменения SLA при архитектурных изменениях;
• прописать правила Freeze Period;
• добавить operational readiness checklist.

16. Практика. Последнее задание

Шаг 6. Подготовьте короткую презентацию (5–6 минут)
Структура презентации:
Слайд 1. Краткое описание исходного SLA
Что за документ? Какие задачи закрывает?
Слайд 2. Перегибы, недочёты, риски
3–5 пунктов.
Слайд 3. Оценка SLA в контексте чёрных лебедей
Что сработает? Что не сработает? Почему?
Слайд 4. Что бы вы НЕ делали
Честная позиция команды.
Слайд 5. Что бы вы сделали по-другому
Ваши улучшения и аргументация.
Слайд 6. Вывод
Какую оценку вы бы поставили по 10 бальной шкале и почему

17. Примеры SLA: Время реакции

Плохо:
• Мы реагируем максимально быстро
Хорошо:
• P1 - отклик до 15 минут
• P2 - до 1 часа
• P3 - до 4 часов

18. Примеры SLA: Время восстановления

Плохо:
• Сервис восстанавливается оперативно
Хорошо:

19. Примеры SLA: Время восстановления

Плохо:
• Сервис восстанавливается оперативно
Хорошо:
• P1 - восстановление до 4 часов
• P2 - до 12 часов
• P3 - до 3 рабочих дней

20. Примеры SLA: Доступность

Плохо:
• Сервис работает круглосуточно
Хорошо:

21. Примеры SLA: Доступность

Плохо:
• Сервис работает круглосуточно
Хорошо:
• Uptime 99,5% в месяц
• Плановые работы до 10 часов/месяц в какое
время суток

22. Примеры SLA: Эскалации

Плохо:
• Обращайтесь к ответственному сотруднику
Хорошо:

23. Примеры SLA: Эскалации

Плохо:
• Обращайтесь к ответственному сотруднику
Хорошо:
• L1 - 15 минут
• L2 - 30 минут
• Дежурный инженер - 1 час
• CTO - 2 часа

24. Примеры SLA: Компенсации

Плохо:
• Компенсации по договорённости
Хорошо:

25. Примеры SLA: Компенсации

Плохо:
• Компенсации по договорённости
Хорошо:
• <99,5% - 10%
• <98% - 25%
• <95% - 50% кредитов

26. Примеры SLA: Изменения SLA

Плохо:
• Поставщик может менять SLA при
необходимости
Хорошо:

27. Примеры SLA: Изменения SLA

Плохо:
• Поставщик может менять SLA при
необходимости
Хорошо:
• Вступает через 30 дней уведомления
• Согласование обеими сторонами

28. Кейс 1. Ложные ожидания

– Клиент ожидал реакцию мгновенно - SLA
говорил о 4 часах.
– Решение: пересмотр SLA + примеры категорий
инцидентов.

29. Кейс 2. Архитектура* изменилась - SLA нет

Кейс 2. Архитектура* изменилась SLA нет
– Микросервисы* увеличили время
восстановления, SLA остался старым.
– Последствие: штрафы, конфликт.
– Решение: обязательный пересмотр SLA при
изменениях.

30. Кейс 3. Внутренний SLA спас проект

– Dev и Support спорили о зоне ответственности.
Ввели нужные протоколы и стандарты
общения.
– Внутренний SLA - время реакции снизилось на
40%.

31. Ошибки в Практическом задании

1. Определите уровни инцидентов.
2. Пропишите время реакции/восстановления.
4. Добавьте компенсации.
5. Проверьте понятность формулировок для
нетехнарей.

32. Выводы

- SLA не бюрократия
- Юрист – медиатор* между бизнесом и ИТ
- SLA должен отражать реальность
- SLA должен обновляться в нужные моменты