Как выглядит идеальная эксплуатация обычной компании
Когда говорят «эксплуатация мирового уровня», обычно показывают зал с видеостеной, круглосуточную смену и команду инженеров надёжности. К обычной компании это не имеет отношения. Обычная компания - это несколько десятков систем, три-пятнадцать человек в эксплуатации, отсутствие выделенной команды процессов, бюджет, который надо защищать, и руководитель, у которого эксплуатация - одна из пяти его тем. Вопрос, который имеет смысл задавать, звучит иначе: как выглядит хорошо для такой компании.
Ответ у меня получился неожиданный для многих: идеальная служба эксплуатации выглядит скучно. В ней не происходит подвигов, никто не спасает ситуацию ночью, и рассказать на конференции особо не о чем. Ломается там ровно столько же, сколько у соседей, - разница в том, что происходит после. Ниже я разобрал это состояние по частям: как выглядит обычный день, по каким признакам такую службу узнают снаружи, чего в ней нет, на чём она держится и сколько времени команды на это уходит.
1. Что значит «идеальная» и что не значит
Начну с отрицаний, потому что именно здесь чаще всего ставится недостижимая цель, после чего работа над ней бросается. Идеальная эксплуатация - это не отсутствие отказов. Отказы будут: оборудование стареет, поставщики падают, люди ошибаются, а изменения нужны бизнесу быстрее, чем их можно безопасно вносить. Служба, поставившая целью «чтобы не ломалось», обречена считать себя неуспешной вечно.
Это и не максимальная доступность любой ценой. Каждая следующая девятка после запятой стоит кратно дороже предыдущей, и для большинства услуг обычной компании эти деньги приносят больше пользы в другом месте. Зрелая служба отличается тем, что знает, какая доступность нужна каждой услуге, и не выравнивает всё по самой критичной.
И это точно не толстая папка регламентов. Документ, написанный один раз и не меняющий поведение в три часа ночи, - это расход, а не актив. Идеальная служба узнаётся по поведению, а не по документации: набор написанного в ней обычно меньше, чем у компании, которая только что прошла сертификацию.
Рабочее определение, которым я пользуюсь: эксплуатация идеальна, когда результат не зависит от того, кто сегодня на смене, а любой отказ заканчивается предсказуемо и оставляет после себя запись, из которой можно учиться. Всё остальное - следствия.
2. Один обычный вторник
Абстрактные описания зрелости плохо приживаются, поэтому проще показать день. Компания средняя, несколько десятков систем, эксплуатация из шести человек, круглосуточной смены нет - есть дежурство по графику с телефоном.
Дежурный открывает сводку за ночь. Там три строки, а не триста: события, не требовавшие действий, ушли в журнал и в ленту не попали. Из трёх строк одна закончилась инцидентом - перезапуском службы по описанной инструкции, за одиннадцать минут, без звонков.
Никто ночью не просыпался. Это не потому, что ночь была спокойной, а потому, что правила пробуждения написаны и ни одно из них не сработало.
Пятнадцать минут утренней встречи. Обсуждают не «что вчера случилось» вообще, а три вещи: вчерашние инциденты с приоритетом выше среднего, изменения на сегодня и одну открытую карточку проблемы. У проблемы есть владелец и срок, и по ней сегодня есть движение.
Приходит предупреждение: на файловом хранилище место закончится примерно через две недели. Это не авария и не будит никого - это заявка в очередь на неделю. Тренд был виден заранее, потому что за ресурсами следят по наклону, а не по факту достижения порога.
Плановое обновление одной из систем. Окно согласовано за неделю, пользователи предупреждены, оповещения по этой системе на время работ подавлены, план отката записан вместе с временем принятия решения: если к 15:30 не поднялось - откат.
Поднялось в 15:05. Следующие сутки система в окне наблюдения: любой инцидент по ней до завтрашнего дня по умолчанию считается связанным с обновлением.
Клиент сообщает о медленной работе внешней услуги. Дежурный видит, что оповещение по ней уже пришло восемь минут назад и инцидент заведён; клиенту отвечают, что проблема известна, причина найдена на стороне провайдера, обращение к нему открыто, следующее обновление - через полчаса.
Это ключевой момент дня. Отказ есть, и он не свой, но клиент получает статус, а не тишину, и не оказывается источником новости.
Инженер дописывает в базу известных ошибок абзац по вчерашнему нестандартному случаю: симптом, обход, статус постоянного решения. Пять минут работы, которые в следующий раз сэкономят полтора часа - причём не ему.
Обратите внимание, чего в этом дне не было. Никто не искал, кто отвечает за систему. Никто не звонил единственному человеку, который «знает, как это чинится». Никто не узнавал об аварии от клиента. Никто не принимал решение об откате в панике, потому что оно было принято заранее, в спокойной обстановке. И при этом день был совершенно обычный: два инцидента, одно изменение, один внешний отказ.
3. Восемь признаков зрелой службы
Эти признаки видны снаружи и проверяются вопросами, а не аудитом. Они не требуют ни конкретной системы мониторинга, ни конкретной методологии - я встречал их и в компаниях, которые про ITIL никогда не слышали.
- У каждого инцидента есть владелец и запись, которую находят за минуту. Не «где-то в переписке» - в одном месте, с временем, объектом и исходом. Это фундамент: без записи невозможно ни измерить, ни научиться.
- Дежурный справляется без звонка «тому единственному». Известный отказ закрывается по инструкции человеком с базовой квалификацией. Экспертов зовут к неизвестному, а не к типовому.
- Ночью будят по правилу, а не по ощущению. Критерии записаны, дежурный применяет их за полминуты, и за звонок по правилу его никогда не отчитывают.
- Изменения проходят через окно и имеют план отката с временем решения. Не «если что-то пойдёт не так», а конкретный час, после которого откатываются.
- Повтор считается дефектом, а не невезением. Третий одинаковый отказ автоматически превращается в карточку проблемы с владельцем, а не просто закрывается третий раз.
- О сбое компания сообщает первой. Доля инцидентов, о которых узнали от клиента, известна и снижается. Это, пожалуй, самый честный внешний признак из восьми.
- Есть десяток показателей, на которые смотрят регулярно. Не сто и не три: столько, сколько помещается на одну страницу и обсуждается за полчаса раз в месяц.
- Раз в квартал служба сама приносит бизнесу список того, что улучшила. В часах и процентах, с базовым уровнем «до». Это то, что отличает службу-партнёра от службы-подрядчика.
4. Чего в ней нет
Отсутствия говорят о зрелости больше, чем наличия, и распознаются быстрее. Каждый пункт ниже в момент своего появления выглядел разумно - в этом и трудность.
- Нет героя. Человека, без которого не восстанавливается ничего, в зрелой службе не существует. Герой - это не достижение, а концентрация риска: его отпуск и его увольнение опаснее отказа оборудования.
- Нет утренних ручных проверок. Обход систем «посмотреть, всё ли живо» означает, что наблюдению не доверяют. Либо чинят наблюдение, либо ритуал остаётся навсегда.
- Нет ленты, которую смотрят по привычке. Если поток оповещений читают «краем глаза», значит, он в основном состоит из того, по чему не надо действовать.
- Нет временных решений старше квартала. Обход, поставленный «на неделю» восемь месяцев назад, - это не решение, это невидимый долг, который однажды предъявят.
- Нет отчёта, который никто не читает. Регулярный документ без адресата и без решений по итогам - чистый расход времени; такие отчёты закрывают, а не улучшают.
- Нет разбора инцидентов с поиском виноватого. Как только разбор становится дисциплинарным, записи становятся аккуратными и бесполезными, и вместе с ними исчезает возможность что-либо анализировать.
5. Четыре опоры
Всё описанное выше держится на четырёх вещах. Ни одна из них не требует крупных закупок, и все четыре нужны одновременно: убрать любую - и конструкция складывается за несколько месяцев.
- Данные. Один журнал, куда попадает каждый инцидент, с временем, объектом и исходом. Не для отчётности - для того, чтобы через полгода можно было посмотреть назад и увидеть закономерности, которых не видно в моменте.
- Правила. Кто узнаёт, кто действует, за какое время, кто следующий и когда будят руководителя. Короткий документ, который знают наизусть, работает лучше подробного, который открывают раз в год.
- Знание. Описанные типовые отказы: симптом, обход, статус решения. Это то, что превращает квалификацию отдельного человека в свойство службы.
- Ритм. Пятнадцать минут утром, полчаса в месяц на показатели, полдня в квартал на разбор данных и решения. Без ритма первые три опоры устаревают тихо и незаметно: инфраструктура меняется, а правила и знания остаются от прошлой версии компании.
Порядок построения при этом жёсткий: данные, правила, знание, ритм. Начинать с правил при отсутствии записи бессмысленно - нечем проверить, что они выполняются. Начинать со знания раньше правил тоже: описанные обходы некому будет применять, потому что до нужного человека событие не дойдёт.
6. Хаос, норма, идеал
Между хаосом и целевым состоянием лежит промежуточное - то, в котором находится большинство. Оно не плохое: в нём можно работать годами. Разница видна на конкретных ситуациях, поэтому вот они, восемь штук.
| Ситуация | Хаос | Норма | Идеал |
|---|---|---|---|
| Как узнают о сбое | От клиента или от руководства | Из мониторинга, но с задержкой и не по всем услугам | Из мониторинга, раньше клиента; доля исключений известна и снижается |
| Кто берётся за инцидент | Кто первый увидел или кого нашли | Дежурный, дальше по договорённости | Дежурный по правилу, эскалация по таймеру, у каждой роли есть замена |
| Ночной звонок | По ощущению дежурного; за ошибку в обе стороны прилетает | Есть договорённость, но трактуется по-разному | Четыре записанных критерия; звонок по критерию не обсуждается, дефект правила разбирается |
| Изменения | Когда удобно; откат придумывают на месте | Согласуются, но окна наблюдения нет | Окно, оповещение, критерий отката по времени, сутки наблюдения после |
| Повторяющийся отказ | Чинится заново каждый раз | Замечен, обход известен, причина не устранена | Карточка проблемы с владельцем и сроком; обход описан, решение в плане |
| Записи об инцидентах | В переписке и в памяти | В системе, но поля заполняются неровно | Полные настолько, что по ним считается статистика без ручной чистки |
| Разговор с бизнесом | Только когда что-то упало | Отчёт о доступности, который мало кто читает | Раз в квартал: что улучшено, в часах и процентах, с базовым уровнем «до» |
| Уход ключевого инженера | Катастрофа, часть систем становится непонятной | Болезненно, восстанавливаются месяцами | Заметно, но не критично: знание описано, роли имеют замену |
Таблицу полезно пройти вместе с командой и честно отметить свою колонку по каждой строке. Почти всегда картина оказывается смешанной - и это нормально: расхождение между строками показывает, куда двигаться, гораздо точнее, чем общая оценка зрелости.
7. Сколько это стоит в людях и времени
Главное возражение против всего написанного звучит так: «у нас нет на это людей». Возражение справедливое, поэтому вот честная оценка регулярной нагрузки для команды из пяти-восьми человек. Это не оценка перехода - это стоимость поддержания состояния, когда оно достигнуто.
- Ежедневно: 15 минут утренней встречи на всю команду и несколько минут на запись по каждому закрытому инциденту.
- Еженедельно: около часа на просмотр очереди проблем и трендов ресурсов.
- Ежемесячно: полчаса-час на страницу показателей и разговор по ней.
- Ежеквартально: полдня на разбор данных за квартал, пересмотр порогов и правил оповещения, и подготовку короткой сводки для бизнеса.
- Раз в год: одно учение по восстановлению ключевой услуги и одна проверка процедуры подъёма после обесточивания.
В сумме это единицы процентов рабочего времени команды. Сравнивать их надо не с нулём, а с долей времени, которая сейчас уходит на аварийную работу и на повторное выяснение уже выясненного. У команд, которые начинают считать эту долю впервые, она обычно оказывается заметно больше, чем предполагалось, и именно этот разрыв - главный аргумент в разговоре с руководством.
Переход - отдельная история, и его стоит планировать не проектом на год, а серией коротких шагов по кварталу: один шаг - один измеримый результат. Практика показывает, что инициативы в эксплуатации умирают не от сложности, а от длительности: команда не выдерживает полгода работы без видимого эффекта, и её нельзя за это винить.
8. Десять вопросов для самопроверки
Ответы только «да» или «нет», без «в основном» и «стараемся». «Да» считается, если это верно не для образцовой системы, а для любой из ваших ключевых услуг и в любую смену.
- Вы знаете долю инцидентов, о которых узнали от клиента, а не из мониторинга?
- Дежурный может за минуту найти, кто отвечает за любую ключевую систему, и его замену?
- Записаны критерии, по которым будят руководителя ночью, и знает ли их дежурный?
- У каждого изменения есть план отката с указанием времени принятия решения?
- Третий одинаковый отказ автоматически превращается в задачу на устранение причины?
- Десять самых частых отказов описаны так, что их закроет человек без опыта в этой системе?
- Есть ли сейчас в работе обход, поставленный «временно» больше квартала назад?
- Вы можете за десять минут получить статистику по инцидентам за полгода без ручной чистки?
- Плановые окна учитываются в общем балансе времени недоступности?
- Бизнес получал от вас за последний квартал сводку об улучшениях в часах и процентах?
Восемь и больше «да» - вы в целевом состоянии, дальше речь о его удержании. От четырёх до семи - обычная зрелая компания, и понятно, куда двигаться: берите строки с «нет» в порядке их номеров. Меньше четырёх - начинать надо с первой опоры, с записи, потому что без неё все остальные шаги невозможно ни спланировать, ни проверить.
Короткий вывод. Идеальная эксплуатация обычной компании - это не масштаб и не бюджет, а предсказуемость. Ломается столько же, сколько у всех; отличие в том, что отказ обнаруживается системой, попадает к нужному человеку по правилу, заканчивается в понятный срок и оставляет запись, из-за которой в следующий раз проходит быстрее. Всё остальное - производные от этих четырёх свойств, и ни одно из них не покупается.
Проверить себя можно двумя способами. Словами - десять вопросов выше или тест зрелости в нашем боте (7 вопросов, около 5 минут, в конце уровень и советы). По данным - прислать выгрузку инцидентов: вернём разбор, где концентрируется простой, какие отказы повторяются и как выглядит разрыв между обнаружением и починкой. Опрос показывает представления команды, выгрузка - её поведение.
Смежные разборы: шесть ступеней зрелости мониторинга, матрица эскалации и шум оповещений, что делать с находками отчёта. Обсудить своё положение с инженером-эксплуатационником - hello@opslab.consulting.