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