Большинство проблем во внутренних системах возникают не из-за багов или вендора, а из-за самих пользователей и заказчиков. Вместо того чтобы разобраться в коробочном функционале, они с порога требуют доработок "под себя". А ИТ, в свою очередь, заставляют воплощать в жизнь весь этот цирк без разбора.
🔥 Приходя на "горящий" проект хочется немедленно включить DevOps-турбо-режим: настроить CI, написать сотни автотестов...
Пользователь создает запрос на изменение: "Добавьте галочку". Кажется просто - но это уже готовое решение. А действительно ли нужна именно галочка?
Выстроил процессы? Закрыл баги? Написал скрипты для операторов и сделал систему настолько устойчивой, что она работает сама? Поздравляю - ты только что создал самую скучную систему на свете. Она не ломается, не бесит и не требует героизма. Никому нет до нее дела.
Быстрое обслуживание без системности редко бывает устойчивым. Мы честно оценили, где мы находимся сейчас и в какие стороны стоит расти. Для этого разработали компактный опросник на базе ITIL 4 и теперь делимся опытом, как это можно сделать в любой команде.
После того как команда просмотрела все метрики и обсудила результаты недели, мы переходим к неформальной части - рефлексии.
Одна лишняя "девятка" в SLA звучит круто, но за нее платят не клиенты, а ваш бюджет и скорость изменений.
Инциденты случаются даже в лучших сервисах. Итог падения определяется нашей реакцией: это может быть паника и поиск виновных или шанс стать лучше и сделать систему надежнее. В основе ITSM лежит создание непрерывного потока ценности - даже ошибки должны работать на развитие. Поэтому главное правило разбора таково: Мы разбираем систему, а не людей. Задача руководителя - понять, где защита дала сбой, и направить усилия на укрепление сервиса.
Продолжаем серию о сервис‑ревью. Работа с изменениями - тема отдельного разговора, а вот их результаты мы фиксируем именно на регулярных оперативных обзорах сервиса. Сегодня - блок "Реализованные изменения за неделю".
## Хроника Васиного погружения в корпоративный шум
