Пробелы в ответственности за системы, из-за которых повторяются инциденты

Как выглядит пробел в ответственности

Обычно пробел в ответственности выглядит вполне обычно. Поэтому команды не замечают его месяцами.

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

Признаки обычно знакомы. Инструмент важен, но его никто не пересматривает по расписанию. В рабочей инструкции до сих пор описана конфигурация прошлого года. Алерты срабатывают, и первый вопрос в чате — «Кто за это отвечает?». Мелкие проблемы висят открытыми, потому что каждая кажется слишком незначительной, чтобы ее брать на себя.

Устаревшая инструкция часто и есть самый явный сигнал. Кто-то написал ее во время настройки, потом система изменилась, команда тоже изменилась, а документ перестал обновляться. Во время инцидента люди следуют шагам, которые больше не соответствуют реальности. Это быстро съедает время и делает маленькую проблему гораздо больше.

Алерты рассказывают ту же историю. Здоровые команды знают, кто реагирует, как быстро он это делает и что проверяет в первую очередь. Там, где есть пробел в ответственности, люди спорят в чате, пересылают сообщения друг другу или ждут того самого человека, который «может быть, знает». Сам сбой может быть небольшим. Путаница вокруг него — обычно нет.

Большинство повторяющихся инцидентов начинаются именно так. Не с одной громкой катастрофы, а с кучи мелочей: истекающего сертификата, предупреждения о резервной копии, которое никто не читает, изменения прав, из-за которого ломается интеграция, панели, которая уже несколько недель показывает ошибки. Каждая проблема по отдельности выглядит терпимой. Вместе они создают риск, который только растет, пока его не замечают клиенты или пока команда не теряет день на уборку последствий.

Понятная ответственность проста. Один человек или одна команда поддерживает систему в актуальном состоянии, обновляет инструкции, следит за алертами и решает, что чинить первым. Если за несколько секунд никто не может назвать этого владельца, пробел уже есть.

Где такие пробелы обычно прячутся

Пробелы в ответственности редко сидят в самых больших и заметных системах. Обычно команды находят их в тихих местах бизнеса — в инструментах, которые еще работают достаточно хорошо, чтобы никто не спрашивал, кто за них отвечает.

Классический пример — таблица, на которой держится еженедельный отчет. Продажи ее обновляют, финансы читают, а руководство доверяет цифрам. Несколько месяцев назад один человек сделал формулы, и теперь никто кроме него не знает, какие вкладки важны и что сломается, если сдвинуть колонку. С виду все просто, пока отчет однажды не уйдет с ошибкой.

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

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

Внутренние инструменты попадают в ту же ловушку. Поддержка, операции и финансы могут пользоваться одним небольшим приложением, но полностью не владеет им никто. Каждая команда думает, что кто-то другой утверждает изменения, проверяет доступы или сообщает об ошибках. Инструмент живет, но его будущее никто не управляет.

Настройки безопасности и биллинга легко игнорировать, потому что сначала они редко падают громко. Старые доступы остаются открытыми. Уведомления о продлении никто не читает. Правила резервного копирования и пороги алертов постепенно устаревают. Урон накапливается медленно: расходы растут, доступы остаются слишком широкими, а пропущенное продление отключает сервис в самый неподходящий момент.

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

Почему инциденты возвращаются снова

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

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

Срочная работа получает владельца. Уборка после нее — обычно нет.

Во время инцидента кто-то перезапускает задачу, повышает лимит или правит конфиг. Напряжение спадает, звонок заканчивается, а последующие задачи теряют темп. Никто не обновляет рабочую инструкцию. Никто не убирает временный обходной путь. Никто не проверяет, может ли тот же триггер сработать снова на следующей неделе. Так разовое решение превращается в ежемесячную проблему.

Передачи задач делают это хуже. Многие повторяющиеся инциденты находятся между командами, а не внутри одной команды. Команда приложения отвечает за логику продукта. Инфраструктура отвечает за серверы. Финансы проверяют результат. Поддержка первой слышит жалобы. Каждая группа закрывает свой кусок, но никто не отвечает за весь путь от входных данных до результата.

Это часто видно в растущих компаниях. Представьте стартап, где счета клиентам зависят от данных продукта, синхронизации и ручной проверки. Когда счета уходят с ошибкой, команда чинит синхронизацию и отправляет исправленные счета. Через месяц та же проблема возвращается. Баг был не только в синхронизации. Настоящий пробел — в ответственности за весь биллинговый процесс.

Старые исключения тоже становятся нормой. Временный скрипт остается в продакшене. Пропущенный тест так и не возвращается. Ручное утверждение сохраняется, потому что когда-то кому-то понадобился быстрый обходной путь. Через несколько месяцев никто уже не помнит, зачем это исключение существует, но команда продолжает жить с этим костылем.

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

Простой пример из растущей компании

Представьте интернет-магазин, где в обычные дни оформление заказа работает без проблем. Но каждые несколько недель письма с подтверждением заказа перестают отправляться на несколько часов.

Покупатели по-прежнему платят, но не получают чек, уведомление об отправке или сообщение «ваш заказ подтвержден». Поддержка заваливается тикетами от людей, которые спрашивают, прошла ли оплата.

Первое предположение обычно падает на приложение. Инженеры проверяют код оформления заказа и не находят ничего очевидного. Заказы есть в базе, оплаты проведены, логи приложения выглядят нормально.

Операции проверяют почтовый сервис и видят, что приложение передало сообщения правильно. На панели сервиса показана ошибка аутентификации для домена отправителя. Теперь проблема выглядит внешней, и все ждут, пока кто-то другой ее решит.

Настоящий пробел находится в общей схеме, за которую никто полностью не отвечает. Один человек создал учетную запись почтового сервиса в прошлом году с корпоративной карты. Другой управляет DNS. Третий добавил записи домена во время запуска и так и не задокументировал, что изменилось. За весь путь от оформления заказа до входящего письма никто не отвечает целиком.

На практике именно так такие пробелы и выглядят. Команда приложения владеет кодом. Операции — серверами и мониторингом. Финансы могут контролировать учетную запись поставщика. Маркетинг может трогать DNS для кампаний. Но за всю цепочку отправки писем не отвечает никто, поэтому никто и не замечает, что изменение DNS, просроченная карта или проблема с правами снова может сломать письма о заказе.

Команда продолжает чинить симптом, а не проблему ответственности. Кто-то заново добавляет запись, обновляет доступы или перезапускает сервис. Письма снова уходят, и компания идет дальше.

Каждый эпизод на бумаге выглядит небольшим. Выручка немного проседает, потому что часть клиентов идет в поддержку, а не покупает повторно. Кто-то просит возврат денег, потому что считает, что заказ не прошел. Но еще больший ущерб — это доверие. Если магазин не может отправить обычное подтверждение, покупатели начинают сомневаться и во всем остальном опыте.

Как составить карту систем, за которые никто не отвечает

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

Обычной таблицы достаточно. Для каждой системы запишите:

• что остановится, если она сломается
• кто вносит в нее изменения
• кто их утверждает
• кто подхватит ее, если основной владелец будет недоступен

Используйте имена, а не названия отделов.

Такое упражнение находит пробелы быстрее, чем большинство разборов инцидентов. Команды часто думают, что у инструмента есть владелец, потому что кто-то иногда к нему прикасается. Но это не владение. Настоящий владелец знает путь доступа, дату продления, настройки алертов и то, что сломается, если инструмент упадет.

Когда вы записали человека, который меняет систему, и человека, который утверждает изменения, задайте еще один вопрос: кто понесет проблему, если что-то сломается в пятницу вечером? Разделение контроля может быть нормальным. Разделение ответственности — обычно нет. Если хотя бы одна из этих ячеек пустая, вы нашли пробел.

Потом проверьте то, о чем команды забывают: админ-аккаунты, общие ящики, API-ключи, секреты, панели, продление сертификатов, логины поставщиков и служебные аккаунты. Они вызывают удивительно много повторных инцидентов, потому что команды не считают их продакшен-системами, хотя бизнес зависит от них каждый день.

В конце назначьте одного владельца и одного запасного на каждый рискованный элемент. Не усложняйте. Один человек владеет системой. Второй может подхватить ее в случае необходимости. У обоих должен быть доступ, понимание, где лежит документация, и знание, какие алерты важны.

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

Как риск растет со временем

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

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

Через несколько месяцев стоимость расползается. Пропущенный счет блокирует сервис в тот день, когда он нужен команде больше всего. Обычное обслуживание натыкается на непроверенный резервный путь, и восстановление занимает часы вместо минут. Единственный человек с админ-доступом уходит, и никто не может войти, чтобы починить проблему. Аудитор или клиент задает простой вопрос, и команда тратит полдня на поиск скриншотов, утверждений и старых сообщений.

Эти проблемы выглядят разными, но у них обычно одна причина. Люди закрывали отдельные части системы, но никто не вел продления, доступы, тестирование, документацию и шаги реакции как одну общую работу.

В растущей компании эффект сильнее. Больше клиентов, больше поставщиков и больше движущихся частей означают, что даже небольшая задержка быстро расходится дальше. Поддержка ждет инженеров. Инженеры ждут доступов. Финансы проверяют платежи. Продажи ждут ответа, чтобы закрыть сделку. Один отсутствующий владелец может сжечь время десяти человек за один день.

Потери денег не всегда видны в отчете по инциденту. Они проявляются как лишняя работа, более медленные релизы, задержанные счета и отложенные важные задачи. Команды помнят сам сбой и не замечают стоимость вокруг него.

Вот почему риск накапливается. Каждый месяц без понятной ответственности добавляет еще одно непродленное обновление, непроверенный шаг восстановления, отсутствующий доступ или недокументированное решение. Потом обычное окно обслуживания, смена сотрудника или проверка со стороны клиента превращают старое запущение в живую проблему.

Типичные решения, которые не работают

Когда команды реагируют на повторяющиеся инциденты, они часто называют отдел и считают, что задача закрыта. На бумаге это выглядит аккуратно, но коллективная ответственность редко выдерживает давление. Когда системой «владеют все», никто не чувствует полной цены плохих алертов, устаревших инструкций, рискованных изменений или пропущенных продлений.

Настоящая ответственность требует конкретного человека, а не только «платформу», «инженеров» или «ops». Один человек должен понимать, как выглядит нормальная работа, что может сломаться, кто может менять систему и когда ее пора заменять. Команда может поддерживать этого человека, но названия отдела недостаточно.

Еще одна частая ошибка — останавливаться на продакшен-системах. Команды описывают серверы приложений, базы данных и алерты, а все сервисы вокруг них игнорируют. Многие повторные инциденты начинаются в DNS-учетках, у платежных поставщиков, во внешних API, при продлении сертификатов или в ежедневных потоках данных, которые приходят поздно или с ошибками.

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

Ответственность начинается до алерта и продолжается дольше, чем само исправление. Владелец решает, что мониторить, какие риски принять, какая уборка не может ждать и когда хрупкую зависимость пора заменить.

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

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

30-минутный аудит, который можно сделать на этой неделе

Выделите полчаса и проведите простой аудит. Возьмите пять систем, без которых ваш бизнес не может прожить день. Это могут быть биллинг, репозиторий кода, облачный хостинг, поддержка клиентов или инструмент, который отправляет договоры. Если команде нужно больше минуты, чтобы согласовать список, это уже о чем-то говорит.

Для каждой системы запишите пять имен:

• кто утверждает изменения
• кто видит счет и может объяснить расходы
• кто управляет доступом и удаляет старые учетные записи
• кто держит документацию актуальной
• кто подменяет основного владельца на следующей неделе, а не когда-нибудь потом

Не принимайте названия команд вроде «engineering» или «ops». Нужны конкретные люди. Если два человека считают одну и ту же зону своей, спросите, кто принимает решение, когда они не согласны. Если никто не знает, у системы нет владельца.

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

Проверьте еще одно: найдите все, что по-прежнему связано с бывшим сотрудником. Старые адреса почты, просроченные номера телефонов для MFA, учетные записи поставщиков на личной карте и внутренние документы, которые последний раз редактировал человек, ушедший год назад, — частые источники проблем. Их легко пропустить, потому что система пока работает. Пока не перестанет.

Запишите результаты в один общий документ. Держите его коротким: название системы, владелец, запасной ответственный, найденные пробелы и следующий шаг.

Что делать дальше

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

Назначьте по одному человеку на каждую систему. Несколько команд могут ею пользоваться, менять ее или зависеть от нее, но один человек должен поддерживать документацию в актуальном состоянии, утверждать доступы, знать контакт поставщика и решать, когда схему нужно пересмотреть. Совместная работа — это нормально. Совместная ответственность обычно разваливается.

Сделайте ответственность заметной там, где люди смотрят в момент давления: рядом с рабочей инструкцией, на панели, в политике алертов и в записи об учетной записи поставщика. Если команде все еще нужно спрашивать, кто владеет инструментом во время сбоя, пробел все еще есть.

Практичный порядок такой:

• сначала системы продаж, биллинга и доступа клиентов
• затем идентификация, права, резервные копии и средства безопасности
• потом конвейеры развертывания, мониторинг и сторонние сервисы
• внутренние инструменты с меньшим бизнес-эффектом — в конце

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

Если команда небольшая, внешняя помощь может ускорить процесс. Oleg Sotnikov через oleg.is работает со стартапами и небольшими бизнесами как фракционный CTO и помогает распутать ответственность между продуктом, инфраструктурой, учетными записями поставщиков и операционными деталями, которые часто теряются.

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